CORBA of SOAP

[Verwijderd]

Beste mensen,

Ik doe een klein onderzoek naar de moeilijkheidsgraad van implementatie
van CORBA en SOAP.
Het schijnt dat SOAP makkelijker te implementeren is dan CORBA.
Ik wil graag weten waarom CORBA lastiger is te implementeren en wat
maakt SOAP dan eenvoudiger.


Of maakt het eigenlijk helemaal niks uit.


mensen die ervaring hebben met CORBA moeten toch weten wat hier lastig
aan is.


alvast bedankt voor de info

[Qwerty-273]

http://www.google.com/search?q=CORBA+vs+SOAP
Wat heb je er zelf al over gevonden? Wat is je ervaring tot nu toe?

[Verwijderd]

googleit

Wil je dit soort opmerkingen voortaan achterwege laten?

[ Voor 81% gewijzigd door RobIII op 05-12-2006 10:26 ]

[F_J_K]

Ik neem aan dat je CORBA en Webservices (incl. SOAP, wsdl, etc.) bedoelt ipv. alleen SOAP. Anders is SOAP simpeler omdat het veel minder doet

Wat wil je precies doen? Binnen de organisatie of over organisaties heen? Legacy of allemaal nieuwbouw? Waar heb je al kennis van?
Een antwoord is zo wat lastig te geven.

offtopic:
Edit: del_toro, reageer dan gewoon niet: klik

[ Voor 11% gewijzigd door F_J_K op 23-11-2006 15:33 ]

[Verwijderd]

Ik heb weinig ervaring met SOAP en CORBA.

ik heb zeker wel vel informatie gewvonden over hoe het ongeveer werkt allebij.

SOAP met XML berichten enz,

CORBA met API's en ORB's

de globale werking van het systeem ken ik dus.

Nu wil ik graag weten welke van de twee makelijker is te implementeren in een client/server applicatie.
ik begrijp inmiddels dat SOAP meer te programmeren is in modernere programeer omgevingen zoals JAVA en .NET. deze zouden dus meer ondersteuning bieden voor SOAP.

[Qwerty-273]

Als je alleen de keuze moet maken tussen SOAP en CORBA, dan is het makkelijkste om SOAP te kiezen, aangezien dat veel kleiner is:
"First and foremost, you cannot compare CORBA to SOAP. SOAP is the protocol part of the RPC mechanism. The corresponding part of CORBA is IIOP, so you can only compare SOAP and IIOP directly. CORBA is much bigger than IIOP alone."
Lees voor de grap bijvoorbeeld eens http://www.xs4all.nl/~irmen/comp/CORBA_vs_SOAP.html door en ontdek het verschil tussen CORBA, Web Services en SOAP.

[F_J_K]

Bedenk wel dat dat stuk geschreven is door iemand met een hele duidelijke voorkeur voor corba Mooi overzicht maar besluit niet alleen op basis daarvan. Een redelijk deel van ws nadelen heb je misschien ook niet als je het binnen je eigen organisatie houdt. Maar goed, er zijn natuurlijk net zoveel stukken op het net vanuit het andere gezichtspunt, zoals http://acmqueue.com/modul...ntent&pa=showpage&pid=396 (een van de bedenkers van corba).

k begrijp inmiddels dat SOAP meer te programmeren is in modernere programeer omgevingen zoals JAVA en .Net. deze zouden dus meer ondersteuning bieden voor SOAP.

Niet helemaal eens. .Net is inderdaad niet met corba in het achterhoofd verzonnen. Maar J2EE vrijt erg met corba (want gebruikt onder de moterlap IIOP). Maar inderdaad, bij geen van beide is corba heel eenvoudig in te zetten. Maar denk niet dat je niet hoeft na te denken als je de hele webservices stack gaat invoeren.

Ik denk wel dat inderdaad tegenwoordig veel meer ondersteuning heeft vanuit IDE's etc.

Webservices lijkt me overigens duidelijk meer toekomstvast, ik zie corba niet groeien en soap/wsdl duidelijk wel.

Maar ik vind eigenlijk geen van beide een voor de hand liggende keuze voor een c/s applicatie. Waarom twijfel je tussen deze twee opties en overweeg je geen andere?

Edit: ik verplaats - op de gok dat het hier beter past, wellicht denken de mods hier er anders over - het even van PNS naar SEA.

[ Voor 4% gewijzigd door F_J_K op 24-11-2006 10:15 ]

[voodooless]

Vaak zijn zowel Soap als Corba veel te complex voor de toepassing.

Ik heb wel eens een opdracht gedaan met Corba. We hebben toen drie OS'en (Linux, OSX, Irix) met drie talen (java, C++ en ObjectveC) aan elkaar geknoopt. Dat werkt op zich best leuk, maar al die corba libs waren niet altijd even gemakkelijk en je zit ook nog met de verschillende taalconcepten, zoals het missen van garbage collection in C++ en Objective C. Bij webservices geldt natuurlijk iets soortgelijks ook.

Persoonlijk heb ik nog steeds iets tegen al dat ge'xml. Het is totaal niet efficiënt, iets wat tegenwoordig, met de vele in verhouding trage en dure mobile netwerken die steeds belangrijker worden niet erg handig is.

Ik zou zeggen, kijk goed wat je precies moet maken, en maak aan de hand daarvan je keuze.

* voodooless is momenteel met het java-only RMI bezig, dat werkt erg prettig

[ Voor 5% gewijzigd door voodooless op 30-11-2006 17:48 ]

[Verwijderd]

Uiteraard veroorzaakt zowel CORBA als WebServices heel wat overhead, maar je moet het dan ook enkel gebruiken waar nodig. Namelijk op die systemen waar taalonafhankelijk de belangrijkste reden is, maw waar verschillende, al dan niet nieuwe, systemen met elkaar moeten communiceren op een uniforme manier. Indien je alles van nul ontwikkelt dan kan je ervoor opteren om dit slechts in één taal te doen, waardoor je de overhead van bv. CORBA kan ontwijken door bv. te gebruik maken van RMI in Java, spreekt voor zich imo...
RMI heeft dus eigenlijk een ander publiek dan bv. CORBA, ik weet dat dit niet altijd op deze manier gebruikt wordt, maar uiteindelijk was dit wel de bedoeling...

Bram

[mOrPhie]

Overigens is in mijn optiek een goede reden om voor SOAP te gaan (als je kiest tussen SOAP en CORBA), dat SOAP naast de minder stijle leercurve, ook veel bekender bij developers is tegenwoordig. Dat kan in het kader van het beheer van de software in de toekomst wel belangrijk zijn.

[yrew]

voodooless schreef op donderdag 30 november 2006 @ 17:43:
Al die corba libs waren niet altijd even gemakkelijk en je zit ook nog met de verschillende taalconcepten, zoals het missen van garbage collection in C++ en Objective C. Bij webservices geldt natuurlijk iets soortgelijks ook.

Over dat soortsgelijks, doel je daarmee op de verschillede corba libs t.o.v bijvoorbeeld de proxies van webservices? Of op het missen van bijv. de garbage collection? Want voornamelijk dat laatste snap ik niet helemaal. En hoe los je met RMI de problemen van corba-libs of proxies op?

[Soultaker]

F_J_K schreef op vrijdag 24 november 2006 @ 10:11:
Bedenk wel dat dat stuk geschreven is door iemand met een hele duidelijke voorkeur voor corba

Ik moet de eerste SOAP-voorstander die serieuze werkervaring heeft met CORBA nog tegenkomen. (Iemand?)

Eenvoudiger dan CORBA maar minder omslachtig en inefficiënt dan SOAP zijn bijvoorbeeld Java RMI (maar dan mis je een groot stuk interoperability) en ICE (een CORBA-clone).

[Tuxie]

Ik heb ervaring met beiden en ik kan je vertellen dat het appels met peren vergelijken is. Als je een serieus onderzoek wilt doen zal ik je aanraden:

* om eerst een stukje achtergrondinformatie te doen (wanneer zijn de technieken ontwikkeld, in welke tijd/jaar etc. , met welk doel, welke problemen had men toen of probeerde men op te lossen met een bepaald stukje techniek etc.) CORBA stamt b.v. uit een ander tijdperk dan SOAP en is ontwikkeld met hele andere doelen.
* zoek een aantal voorbeelden: 1 waarvoor CORBA geschikt is en 1 waarvoor SOAP wat meer geschikt is
* bekijk de reference modellen en pas deze toe op de voorbeelden

Uiteindelijk zul je de trend gaan zien: CORBA is een verzameling van een heleboel technieken die een heleboel problemen wil oplossen, terwijl SOAP alleen maar min of meer het RPC protocol is (CORBA --> IIOP tegenhanger) , zoals iemand hier terecht al opmerkt. Vaak wordt de tem SOAP ook misbruikt in dezelfde context als webservices, maar dit is slechts een onderdeel.

[Verwijderd]

De Term RMI is al gevallen in combinatie met Java.

Kijk in dat opzicht ook eens naar Remoting voor C#.

Remoting mist een deel van de overhead die je met webservices hebt.

[Verwijderd]

Wanneer je client- en serverdeel zelf in de hand hebt, en ze gebruiken beide hetzelfde platform, dan zijn oplossingen als .NET Remoting of RMI inderdaad prima en performante oplossingen.
Maar helaas is 't lang niet altijd een optie...

De laatste jaren hebben wij (bedrijf met op dit moment 4 ontwikkelaars, we maken software voor de hotel-branche) 100-en koppelingen met externe systemen gemaakt, varierend van kassasystemen of pay-tv systemen over RS232 of soms DCOM, tot internet boekingssystemen als Expedia, bookings.nl, hotels.nl, etc. via SOAP webservices (en voor SOAP via XMLRPC) of (vooral) HTTP POST.

CORBA ben ik in deze branche nog nooit tegengekomen, net als RMI of .NET Remoting.
Ik ben allang blij als de andere kant SOAP webservices ondersteunt... (bij voorkeur doc|lit, dat ontwikkelt wel zo handig in C#)
Intern gebruiken we wel .NET Remoting voor nieuwe 3+ tier oplossingen, maar dat staat bij ons nog in de kinderschoenen.

[F_J_K]

Op het moment dat je inderdaad buiten de eigen bedrijfsgrenzen komt, ontkomt je er imho niet aan om de webservices stack (of evt. ebMS) te gebruiken. Andere keuzes zorgen er voor dat je technologie en / of licenties afdwingt bij andere partijen. En die kiezen er vast voor om het gewoon niet A2A te doen...

Maar inderdaad; webservices != webservices != webservices != ... Als twee diensten SOAP praten, praten ze nog niet zonder hard nadenken perse met elkaar.