[Disc] Verschillen tussen CORBA en .NET webservices *

[Verwijderd]

Hey,

Ik ben benieuwd naar ervaringen van gebruikers hier als je praat over de verschillen tussen beide technieken op de volgende punten :

-installeren van beide technieken
-configureren
-opzetten van een testomgeving
-schrijven van een testprogramma

Iemand ervaringen ?

[whoami]

Heb je zelf al enig onderzoek gedaan ?

[Verwijderd]

Ja, ik ben voorstander van .Net, ben dus met name op zoek naar meningen van anderen...die dus beide technieken gebruiken / gebruikt hebben...

[EfBe]

CORBA is een binary object systeem. Webservices is dat niet. Webservices werken alleen met XML en zijn derhalve dus niet binary.

[Creepy]

Verwijderd schreef op 03 november 2003 @ 12:17:
Ja, ik ben voorstander van .Net, ben dus met name op zoek naar meningen van anderen...die dus beide technieken gebruiken / gebruikt hebben...

En je bent voorstander van .NET omdat ......

[Alarmnummer]

Bij Corba kan je clients en server met elkaar laten praten, zonder dat ze zelf hoeven te weten waar ze zijn. De servers melden zich aan bij de Broken (vandaar de b uit corba), en de clients komen daarna bij de broker voor een bepaalde service.

Verder is door toevoeging van een idl (interface definition language) het mogelijk om clients en server geschreven in verschillende talen, met elkaar te laten communiceren.

Ik ben niet thuis in webservices, dus daar kan ik je niets over vertellen.

[Robtimus]

Kijk op http://www.win.tue.nl/~mchaudro/cbse/CBSE.htm, met name de slides over CORBA, .Net en zeker de comparisons.

[curry684]

Verwijderd schreef op 03 november 2003 @ 12:17:
Ja, ik ben voorstander van .Net, ben dus met name op zoek naar meningen van anderen...die dus beide technieken gebruiken / gebruikt hebben...

Als je een discussie wil aanzwengelen zul je echt met wat argumenten moeten komen hoor, als je hier alleen een opsomtopic wil houden van wie er allemaal Corba prefereert en wie .NET kom ik dadelijk met een stuk oud ijzer langs

[Soultaker]

Alarmnummer schreef op 03 november 2003 @ 12:41:
Bij Corba kan je clients en server met elkaar laten praten, zonder dat ze zelf hoeven te weten waar ze zijn. De servers melden zich aan bij de Broken (vandaar de b uit corba), en de clients komen daarna bij de broker voor een bepaalde service.

Hmm, dat is leuk bedacht, maar helaas nergens op gebaseerd. De 'broker' ('makelaar') is gewoon de library die aan het proces gelinkt wordt en de abstractielaag verzorgt waardoor de programmeur lokale en gedistribueerde objecten op dezelfde manier kan aanspreken (en nog een hele zwik andere taken voor z'n rekening neemt).

Objecten kunnen references naar nieuwe objecten retourneren en zo kun je objecten "vinden", maar er is dan nog steeds een bootstrapping probleem: hoe kom je aan een eerste object (op een server bijvoorbeeld) om mee te communiceren? Dat wordt bij CORBA ofwel ad-hoc opgelost door de object reference in string-vorm mee te geven, ofwel (mooier) door gebruik te maken van een Naming Service, waar objecten zich onder een bepaalde naam kunnen registreren. Dat is echter nauwelijks een CORBA-specifieke oplossing; ik geloof dat bij Java RMI bijvoorbeeld daar ook gebruik van wordt gemaakt. Overigens is dat nauwelijks een betere oplossing, aangezien je dan weer de reference naar de Naming Service (die zelf een CORBA object is!) ergens hard moet specificeren. Voordeel is wel dat de interfaces voor een Naming Service vastliggen en je dus een product van elke willekeurige maker kunt gebruiken met een ORB van elke gewenste andere maker (in theorie dan).

Een belangrijk verschil tussen CORBA en .NET is wat mij betreft dat CORBA vooral een specificatie is; de OMG levert geen enkele implementatie bij hun specificaties (zelfs niet ter referentie!) en je bent dus afhankelijk van derden voor betrouwbare, goedfunctionerende componenten. Omdat in een typische omgeving verschillende componenten van verschillende makers met elkaar samen werken, wordt de kwaliteit van de infrastructuur (zowel qua ontwerp als qua implementatie) sterk op de proef gesteld. .NET is natuurlijk ook gebaseerd op een specificatie, maar die komt van een enkele maker (zonder structureel overleg in een open discussie) die ook de hoofdimplementatie levert. Voor de praktijksituatie (installeren, testen, incompatibiliteiten, etcetera) maakt dat een wereld van verschil.

[Alarmnummer]

Soultaker schreef op 03 november 2003 @ 14:14:
[...]

Hmm, dat is leuk bedacht, maar helaas nergens op gebaseerd.

Ik zou zeggen: koop dit boek eens en ga lezen op pagina 99.. daarna mag je nog eens een poging wagen om commentaar te leveren. ok? Ik adviseer je om je in de toekomst gewoon stil te houden over zaken waar je geen kaas van hebt gegeten, ipv mensen op een nare toon onderuit te halen.

Mag wel iets rustiger hoor, hoeft niet meteen vol boven op de kast als iemand het niet met je eens is

[ Voor 45% gewijzigd door curry684 op 03-11-2003 15:12 ]

[Soultaker]

Alarmnummer schreef op 03 november 2003 @ 14:33:
Ik zou zeggen: koop dit boek eens en ga lezen op pagina 99.. daarna mag je nog eens een poging wagen om commentaar te leveren. ok? Ik adviseer je om je in de toekomst gewoon stil te houden over zaken waar je geen kaas van hebt gegeten, ipv mensen op een nare toon onderuit te halen.

Nou nou, zo gemeen bedoelde ik het niet hoor. Verder lijkt me hier ook het mooie spreekwoord van toepassing: "wat gij niet wilt dat u geschied, doe dat ook een ander niet"!

Laat ik dan nog even een plaatje uit de CORBA FAQ van de OMG halen om m'n standpunt verder te onderbouwen; dit is wat de Object Request Broker (ORB) is en doet:


Hoewel er wel een naming service specificatie bij CORBA zit (wat nogal een uitgebreide verzameling specificaties is) is het toch echt een component dat los staat van de ORB.

Qua referentiedocumentatie is voor C++ trouwens het boek van Henning en Vinoski aan te raden. Dat is wat meer op de materie toegespitst.

[ Voor 23% gewijzigd door Soultaker op 03-11-2003 15:09 ]

[Alarmnummer]

Soultaker schreef op 03 november 2003 @ 15:06:
Nou nou, zo gemeen bedoelde ik het niet hoor.

Je toon komt nogal denigrerend over.

Laat ik dan nog even een plaatje uit de CORBA FAQ van de OMG halen om m'n standpunt verder te onderbouwen; dit is wat de Object Request Broker (ORB) is en doet:
[afbeelding]

Hoewel er wel een naming service specificatie bij CORBA zit (wat nogal een uitgebreide verzameling specificaties is) is het toch echt een component dat los staat van de ORB.

Qua referentiedocumentatie is voor C++ trouwens het boek van Henning en Vinoski aan te raden. Dat is wat meer op de materie toegespitst.

Het gaat niet om die namingservice (heb ik het ook nooit over gehad). De essentie van de broker design patterns is dat je de server via een broker loskoppeld van een client. Als een client komt bij een broker voor een bepaalde dienst, dan bepaald de broker welke server die client toegewezen krijgt en zet daarna de communicatie tussen beiden op. Dit heeft niets te maken met een naming service.

Als je naar dat plaatje kijkt, dan zie je dat ook.

Dat je een namingservice hebt om bij een bepaalde broker te komen is leuk. Maar het heeft niets te maken met een broker.

[ Voor 5% gewijzigd door Alarmnummer op 03-11-2003 15:20 ]

[Soultaker]

Alarmnummer schreef op 03 november 2003 @ 15:15:
Je toon komt nogal denigrerend over.

Daar kan ik me iets bij voorstellen, maar het zou je sieren als je dat dan zelf beter zou doen, in plaats van er nog even dubbel overheen te gaan. Beetje flauw om zo de discussie op de spits te drijven, als je het mij vraagt.

Het gaat niet om die namingservice (heb ik het ook nooit over gehad).

Je zei twee dingen; het eerste was:

Bij Corba kan je clients en server met elkaar laten praten, zonder dat ze zelf hoeven te weten waar ze zijn. De servers melden zich aan bij de Broken (vandaar de b uit corba), en de clients komen daarna bij de broker voor een bepaalde service.

En naar mijn mening is dat niet direct de hoofdcomponent van CORBA, noch heeft het met de CORBA Object Request Broker (ORB) te maken.

De essentie van de broker design patterns is dat je de server via een broker loskoppeld van een client. Als een client komt bij een broker voor een bepaalde server, dan bepaald de broker welke server die toegewezen krijgt en zet daarna de communicatie tussen beiden op. Dit heeft niets te maken met een naming service.

Volgens mij redeneer je nu uitsluitend vanuit je design patterns boek en betrek je de informatie daaruit direct op CORBA. Ik heb namelijk wel redelijk wat praktijkervaring met CORBA en daar vind ik dit kenmerk niet in terug; zeker niet als dusdanig kenmerkend dat het als hoofdpunt genoemd zou kunnen worden. De constructie en de doelstellingen die jij omschrijft komen wel in de CORBA specificaties voor en daar gaat het toch echt om Naming Services.

Blijkbaar is de term "broker" niet zo eenduidig gedefinieerd als je misschien dacht. Alle respect voor je kennis van design patterns, maar daarmee ken je (blijkbaar) nog niet direct alle specificaties die daar een woord in hun titel mee gemeen hebben. Ik hoop dat je het niet al te denigrerend opvat, maar naar mijn mening is je opmerking over "je mond houden over waar je geen kaas van gegeten hebt" ook een beetje op jezelf van toepassing.

[Alarmnummer]

Soultaker schreef op 03 november 2003 @ 15:26:
Daar kan ik me iets bij voorstellen, maar het zou je sieren als je dat dan zelf beter zou doen, in plaats van er nog even dubbel overheen te gaan. Beetje flauw om zo de discussie op de spits te drijven, als je het mij vraagt.

Tja... op jouw soort reacties kan je commentaar krijgen. Ik pik het niet als iemand anders op zo`n manier commentaar loopt te leveren.

En naar mijn mening is dat niet direct de hoofdcomponent van CORBA, noch heeft het met de CORBA Object Request Broker (ORB) te maken.

Wat is volgens jouw dan het hoofdcomponent van CORBA? In welk opzicht verschilt CORBA dan tov andere low level middleware implemenaties zoals RMI?

De hoofdreden achter CORBA is dat je diensten en services (communicatie tussen objecten) van elkaar kan loskoppelen. Ze hoeven niet meer te weten waar ze staan, en waarin ze zijn geimplementeerd.

Een Service meldt zich aan bij de Broker. Als een client vervolgens bij een Broker komt voor een bepaalde dienst, dan bepaald de Broker welke Service hij krijgt. Dit maakt het ook heel eenvoudig om de service met een andere te uit te wisselen omdat clients nooit harde links hebben naar die service.

Volgens mij redeneer je nu uitsluitend vanuit je design patterns boek en betrek je de informatie daaruit direct op CORBA. Ik heb namelijk wel redelijk wat praktijkervaring met CORBA en daar vind ik dit kenmerk niet in terug; zeker niet als dusdanig kenmerkend dat het als hoofdpunt genoemd zou kunnen worden. De constructie en de doelstellingen die jij omschrijft komen wel in de CORBA specificaties voor en daar gaat het toch echt om Naming Services.

Afgezien dat in het boek ook wordt uitgelegd hoe de Broker binnen CORBA is terug te vinden, heb ik zelf ook enige ervaring met CORBA. Ik zie het wel heel duidelijk terug dat je een plaats/implementatie ontkoppeling tussen client en server krijgt.

Blijkbaar is de term "broker" niet zo eenduidig gedefinieerd als je misschien dacht. Alle respect voor je kennis van design patterns, maar daarmee ken je (blijkbaar) nog niet direct alle specificaties die daar een woord in hun titel mee gemeen hebben. Ik hoop dat je het niet al te denigrerend opvat, maar naar mijn mening is je opmerking over "je mond houden over waar je geen kaas van gegeten hebt" ook een beetje op jezelf van toepassing.

Tja.. ik denk dat we een verschil van mening houden. Ik adviseer je om gewoon wat minder arrogant te reageren. Dan krijg je dit soort antwoorden van mij ook niet zo snel terug.

[ Voor 7% gewijzigd door Alarmnummer op 03-11-2003 15:59 ]

[Verwijderd]

agh kinderen misschien is het een goed idee om eens terug te gaan naar topic!!

persoonlijk ben ik wel een fan van CORBA ik neem direct aan dat de punten die jij beschrijft

-installeren van beide technieken
-configureren
-opzetten van een testomgeving
-schrijven van een testprogramma

over algemeen met elkaar te vergelijken zijn... ik moet er even bij zeggen dat ik niet veel ervaring het met webservices. Maar aangezien het een .NET tech is neem ik aan dat webservices niet met een java platform praat, zelfde als RMI niet met een .NET platform praat. CORBA doet dat wel!

dus CORBA is gewoon wat breder misschien is .NET web services beetje vriendelijker ik weet het niet he... maar uit eindelijk komt het neer op een persoonlijke smaak totdat je een .NET omgeving wilt laten praten met een JAVA omgeving dan moet je wel omgaan naar CORBA....

dus als uiteindelijk JAVA/ .NET communicatie belangrijk is of andere programmeer talen... ja dan maak je een betere keuze met CORBA!

[Alarmnummer]

Verwijderd schreef op 03 november 2003 @ 16:03:
over algemeen met elkaar te vergelijken zijn... ik moet er even bij zeggen dat ik niet veel ervaring het met webservices. Maar aangezien het een .NET tech is neem ik aan dat webservices niet met een java platform praat, zelfde als RMI niet met een .NET platform praat. CORBA doet dat wel!

Voor zover ik het weet zijn webservices niet eigendom van .NET:
http://java.sun.com/webservices

dus als uiteindelijk JAVA/ .NET communicatie belangrijk is of andere programmeer talen... ja dan maak je een betere keuze met CORBA!

En verder is het denk ik niet verstandig om te zeggen 'betere keuze' in het algemeen., Je moet de middleware keuze afstemmen op de eisen. Als je een highspeed verbinding nodig bent, ga je niet lopen kloten met Corba. Als je een java-java communicatie hebt, ga je ook niet klooien met Corba.

Corba bied veel meer tov de meer lowlevel middleware implementaties. Als je belangstelling hebt bij die extra`s, dan pak je CORBA, anders pak je iets wat beter geschikt is.

[ Voor 41% gewijzigd door Alarmnummer op 03-11-2003 16:13 ]

[Verwijderd]

moet je zien leer ik weer wat bij

moet wel zeggen dat ik dit: .NET webservices niet zo goed begrijp in het topic. aangezien ik at first glance niets over .NET tech zag in die link

[ Voor 68% gewijzigd door Verwijderd op 03-11-2003 16:15 ]

[LordLarry]

Webservices (SOAP) hebben ook niets specifiek te maken met .Net. Ik zou eens in je onderzoek verder zoeken naar SOAP in het algemeen ipv een specifieke implementatie ervan in .Net. Daar vind je vast veel meer over.

Nog wat andere verschillen waar ik zo even kan opkomen:
- SOAP specificeerd niet het transport middel aan. Dat kan HTTP zijn, maar ook email of een postduif.
- SOAP is stateless. Als je state wil onthouden moet je het zelf regelen.
- SOAP zegt niets over encryptie, security, compression, authentication.

De punten die je opnoemt kan je vast zelf simpel proberen. Er zijn zat voorbeelden van SOAP clients en servers en zeker in VS.Net.

[Soultaker]

Voor alle mensen

Alarmnummer schreef op 03 november 2003 @ 16:08:
En verder is het denk ik niet verstandig om te zeggen 'betere keuze' in het algemeen., Je moet de middleware keuze afstemmen op de eisen.

Mee eens.

Als je een highspeed verbinding nodig bent, ga je niet lopen kloten met Corba. Als je een java-java communicatie hebt, ga je ook niet klooien met Corba.

Het tweede kan ik me voorstellen; bij het eerste stel ik mijn vraagtekens. Als snelheid van belang is, dan zou ik zeggen dat je juist voor CORBA moet kiezen; CORBA is ontworpen met efficiëntie in het achterhoofd. Op tekst gebaseerde protocollen (XML-RPC en SOAP en dergelijke) zijn relatief juist vreselijk traag als je grote hoeveelheden gegevens heen en weer wilt sturen.

CORBA bied veel meer tov de meer lowlevel middleware implementaties. Als je belangstelling hebt bij die extra`s, dan pak je CORBA, anders pak je iets wat beter geschikt is.

Hmm, naar mijn ervaring is het prettige van CORBA juist dat simpele dingen goed werken en makkelijk uit te breiden zijn tot ingewikkeldere dingen. Iets als (bijvoorbeeld) SOAP schaalt niet echt lekker op (bij gebrek aan een serieuze objectstructuur; het is meer een RPC-mechanisme) maar je zit al vanaf het begin te klooien met XML envelopes enzo. Nu is CORBA ook niet zo simpel als (bijvoorbeeld) Java RMI omdat je nog steeds interface definities moet schrijven (los van de daadwerkelijke code) maar daar staat tegenover dat daaruit de basis voor je programmacode automatisch gegenereerd wordt en je zelf met nog geen 100 regels een simpele CORBA service kunt schrijven.

[Alarmnummer]

Soultaker schreef op 03 november 2003 @ 18:43:
Het tweede kan ik me voorstellen; bij het eerste stel ik mijn vraagtekens. Als snelheid van belang is, dan zou ik zeggen dat je juist voor CORBA moet kiezen; CORBA is ontworpen met efficiëntie in het achterhoofd. Op tekst gebaseerde protocollen (XML-RPC en SOAP en dergelijke) zijn relatief juist vreselijk traag als je grote hoeveelheden gegevens heen en weer wilt sturen.

Een socket connection is denk ik sneller dan CORBA, dus voor een echte highspeed domme verbinding zou ik dan weer kiezen voor sockets. Je zit sowieso met het marshallen en het unmarshallen van argumenten bij CORBA.

De vraag blijft natuurlijk of je met een sockets tevreden bent.

[ Voor 11% gewijzigd door Alarmnummer op 03-11-2003 18:50 ]

[Soultaker]

Alarmnummer schreef op 03 november 2003 @ 18:49:
Een socket connection is denk ik sneller dan CORBA. Je zit sowieso met het marshallen en het unmarshallen van argumenten bij CORBA. Maar het natuurlijk ook de vraag of je tevreden bent met een socket connection.

Hmm, wat bedoel je met "socket connection"? Marshallen en unmarshallen moet hoe dan ook. Ik heb bijvoorbeeld hele goede ervaringen met simpele TCP sockets in combinatie met Java's serialization, maar ook daar moet gewoon gemarshalled worden en gegevens verstuurd worden over een socket. Ik heb geen idee hoe efficiënt dat gaat, maar ik betwijfel of het significant efficiënter is dan marshallen naar GIOP.

edit:
Beetje gegoogled en toen kwam ik dit tegen:
Can Web Services run along side CORBA and RMI?

Summary

Web Services in general and XML-RPC in particular has many good promises for the future. When interoperability and easy access of enterprise business operations are the key focus, XML-RPC is a very good candidate to investigate and compare to CORBA. Simply, because it is so easy to inspect exactely what "goes on the wire".

On the other hand, if performance such as low latency, large number of service calls per time unit and large bandwidth is the key aspects for an enterprise application, XML-RPC is not the first hand choice.

My quick study shows that during the best conditions, when the JVM Hotspot has been given its chance to perform run-time optimization, the Java version of XML-RPC called JAXRPC, still is 15 times slower than Java RMI and 12 times slower than JDK CORBA. It is possible that another CORBA implementation might perform better than the JDK version.

In deze test is Java RMI dus iets sneller dan de Java ORB, maar het zit in de zelfde orde van grootte, terwijl XML-RPC (zoals verwacht) een stuk trager is. Overigens worden hier dus Java applicaties vergeleken; er wordt niet gebenchmarkt met andere ORBs in een native applicatie (vooral ORB's als TAO en omniORB gaan er prat op dat ze aanzienlijk sneller zouden zijn dan de concurrentie).

Overigens gaat het hier dus over Java RMI en dat is nog wat complexer dan de geserialiseerde objecten over TCP sockets waar ik het eerder over had. Maar goed, dat wil je ook alleen maar voor simpele toepassingen gebruiken, denk ik.

[ Voor 57% gewijzigd door Soultaker op 03-11-2003 19:01 ]

[Verwijderd]

LordLarry schreef op 03 november 2003 @ 18:15:
Webservices (SOAP) hebben ook niets specifiek te maken met .Net. Ik zou eens in je onderzoek verder zoeken naar SOAP in het algemeen ipv een specifieke implementatie ervan in .Net. Daar vind je vast veel meer over.

ohh is webservices SOAP aha zeg dat dan! nouja dan snap ik echt niets meer van de titel SOAP lijkt echt op de verste verte niet op CORBA.

SOAP ligt in de lijn van JMS
CORBA ligt in de lijn van RMI

[guanpedro]

Ik heb niemand nog de term .Net Remoting horen roepen dus ik dacht ik roep het ff Dit is dus vergelijkbaar met RMI van Java of DCOM van het oude COM systeem van MS.

http://msdn.microsoft.com...mainsusingnetremoting.asp

Als je dus Corba met een .NET variant gaat vergelijking zoek dan hier ff op. Natuurlijk is dit niet platform onafhankelijk zoals Corba kan zijn.

Corba heeft inmiddels implementaties om met .NET te werken:

http://www.omg.org/technology/corba/corbadownloads.htm
http://kristopherjohnson....rc/wiki.pl?Remoting.Corba

[LordLarry]

En niet te vergeten Borland Janeva: http://www.borland.com/janeva/

[Verwijderd]

Ik ben voor stander voor CORBA, taal onafhankelijk en machine onafhankelijk. Opensource en geen onnodig gezeik. Daarnaast biedt CORBA echt te veel om op te noemen, services waarbij server en client niet bekend bij elkaar hoeven te zijn, dynamic invocation en nog veel meer.

[Verwijderd]

humh misschien een idee.. je kan CORBA en SOAP niet met elkaar vergelijken

[Soultaker]

Verwijderd schreef op 04 november 2003 @ 13:15:
humh misschien een idee.. je kan CORBA en SOAP niet met elkaar vergelijken

Dat zei je eerder al, maar waarom eigenlijk niet? CORBA is in de kern een object-georienteerd framework voor gedistribueerde executie. SOAP is veel beperkter (geen object context) en verbergt het verschil tussen locale en gedistribueerde calls niet, maar in essentie is SOAP ontworpen om hetzelfde probleem op te lossen: hoe kunnen gedistribueerde componenten (die op hele andere platforms draaien en misschien wel in andere talen geschreven zijn) met elkaar communiceren?

Ik ben het met TimD eens dat het prettige van CORBA is dat er heel veel mogelijkheden zijn. De CORBA specificaties zijn ontzettend uitgebreid. Dat is enerzijds een nadeel, omdat het dus niet eenvoudig is om een volledig CORBA-compliant product te ontwikkelen en te gebruiken, maar gelukkig hoef je door de gestructureerde opzet maar een klein deel van de specificaties te kennen om er al zinnig gebruik van te kunnen maken.

Hoewel ik denk dat het goed mogelijk is om zelf met behulp van TCP en wat standaard XML componenten een applicatie te schrijven die van SOAP gebruik maakt, heb je voor CORBA echt een aparte library nodig. Dat is een natuurlijk gevolg van de complexiteit van CORBA. Voordeel is wel dat er verschillende goede ORB's gratis beschikbaar zijn en dat ze source code compatible zijn (wat dus betekent dat je zonder veel moeite van product kunt wisselen).