[C++/Java] SOAP, Axis (CORBA?)

[Tjeerd]

Ik ben van plan om aan de server-kant C++ te programmeren, omdat ik ook veel andere C++-programmatuur/bibliotheken moet gaan aansturen op de server. De client-kant zal Java worden. Ik heb eerst nog gedacht aan JNI of CORBA, maar deze zijn denk ik te onpraktisch om te gebruiken. Ik dacht toen een mooie oplossing te hebben gevonden, namelijk de Axis C++ bibliotheek om WSDL/SOAP-achtige services te gaan bouwen aan de server-kant.. Zodat ik netjes via Java deze services kan aanroepen via SOAP.

Nu vraag ik me af of er hier ook mensen zijn die er ervaring mee hebben. Of er nog alternatieven zijn voor Axis (al een tijdje lijkt de C++ versie stil te staan) en of er misschien sowieso nog betere manieren zijn om mijn C++ programmatuur aan te sturen op de server via een Java-client?

Ik begrijp ook dat je in principe met alleen Axis C++ een webservice kunt bouwen en dat je Apache daar niet voor nodig hebt (als je het niet als .so-module in Apache inlaadt, dat heb ik hopelijk goed begrepen).

(enkele tutorials die ik gevonden heb 1, 2, 3)

[Janoz]

Waarom lijken je JNI en CORBA onpraktisch? In dit geval lijkt JNI me helemaal niet zo vreemd. Daarnaast moet je je ook niet teveel aantrekken van de spookverhalen rond CORBA. CORBA is uit de mode omdat XML nu natuurlijk helemaal de bom is (lees: afgeven op CORBA is meer een mode verschijnsel dan daadwerkelijk gefundeerde kritiek).

[Kettrick]

Ik denk dat je vooral ook moet kijken wat de toekomst brengt, webservices kan je bijvoorbeeld eenvoudig koppelen in BPEL processen, mocht je dat later willen. (voor zover ik weet is dit met corba lastiger, correct me if im wrong ).

[Soultaker]

Ik denk dat je je eerst af moet vragen of je je C++ applicatie als library wil gebruiken in Java; in dat geval ontkom je niet echt aan JNI, hoewel JNI programmeren nogal vervelend is. Uit je topic start lijkt mij dat je van plan bent een client/server applicatie op te zetten en dan is JNI niet echt aan de orde.

In dat geval ligt CORBA voor de hand. Vooral de Java-kant is best makkelijk. Als interoperabiliteit met andere (CORBA) systemen geen punt is, kun je ook naar ICE kijken, wat een soort CORBA in een nieuw jasje is (eenvoudigere APIs etc.)

Het voordeel van CORBA en ICE ten op zichte van SOAP, XML-RPC etc. is dat deze laatste methoden véél trager zijn, geen support hebben voor OOP, en niet op een standaardmanier integreren met Java/C++ waardoor je alsnog veel code zelf moet schrijven (om b.v. SOAP calls op methodes van een onderliggen object te mappen). Die protocollen zijn dus vooral geschikt voor echte internetapplicaties waar de afstand tussen twee applicaties groot is en je hoge latency verwacht.

Aan de andere kant integreert gebruik van CORBA veel dieper in je applicatie, ook op code-niveau, wat niet altijd wenselijk is. Daar zit dus een afweging tussen de mate waarin je je applicatie gescheiden wil houden van de communicatieprotocollen, en de mate waarin je die integratie wil automatiseren (wat natuurlijk wel werk scheelt).

[ Voor 22% gewijzigd door Soultaker op 15-04-2008 11:37 ]

[Tjeerd]

Voor zover ik wat documenten heb gelezen is er wel een groter risco verbonden aan JNI, omdat je C++ en Java-code eigenlijk gaat mengen met elkaar. Gaat er iets fout in de C++ code of tijdens het uitwisselen van informatie tussen C++ en Java (via JNI). Ik had zelfs begrepen dat de JVM er door onderuit kan gaan en dan ben ik de communicatie helemaal kwijt met de clientkant.

Voor zover ik nu begrjip zou het in JNI als volgt werken: [server: C++ <-> Java] --- [client: Java].

Eigenlijk zijn er verschillende manieren om het te doen dus, CORBA, JNI of SOAP. Het voordeel van webservices is dan weer dat die erg makkelijk in vele talen en vanuit allerlei bibliotheken aan te roepen zijn omdat het een vrij open formaat is en eenduidig XML.

Maar stel dat ik aan de serverkant een C++ programma heb welke al het rekenwerk moet doen en ik wil dat makkelijk kunnen aansturen vanuit de client kant met Java. En ik wil ook dat het server-programma eventueel vanuit andere talen aan te roepen is (Python, PHP enz.), dan lijkt me SOAP toch geen slecht idee? Dan hoef ik niet opnieuw de server te schrijven/aan te passen is mijn gedachte.

Ik hoor graag of iemand dus ervaring heeft met dezelfde opzet of misschien argumenten kan geven waarom ik niet Axis C++ (SOAP) zou moeten doen of juist CORBA of JNI. Of iets heel anders.

Het voornaamste doel van de communicatie tussen Java (client) en C++ (server) is om o.a. opdrachten te versturen om berekeningen te starten op de server. Eventueel status terug te krijgen e.d. Dus niet grote hoeveelheden data versturen. Ik wilde niet op socket-niveau programmeren, dus vandaar dat ik aan SOAP dacht.

[ Voor 10% gewijzigd door Tjeerd op 15-04-2008 11:42 ]

[Verwijderd]

In Java kun je met JAX-RPC alles omtrent SOAP en WebServices laten genereren. Ik zit er net over te lezen

[Tjeerd]

Verwijderd schreef op dinsdag 15 april 2008 @ 11:42:
In Java kun je met JAX-RPC alles omtrent SOAP en WebServices laten genereren. Ik zit er net over te lezen

Als ik het goed begrijp is dat meer voor communicatie tussen Java-client en Java-server wat ipv serieel nu in XML gaat.

En voor de duidelijkheid: ik wil dus het liefst alles in c++ aan de serverkant doen, dus dat Axis - als ik daar voor zou kiezen - ahw geintegreerd is met het serverprogramma.

[ Voor 20% gewijzigd door Tjeerd op 15-04-2008 11:54 ]

[Verwijderd]

Nestor schreef op dinsdag 15 april 2008 @ 11:45:
[...]
Als ik het goed begrijp is dat meer voor communicatie tussen Java-client en Java-server wat ipv serieel nu in XML gaat.

nee, zolang er maar aan de server kant een WSDL is (xml-filetje waarin je web-service wordt beschreven), kun je op je Java-client JAX-RPC gebruiken en op je Server in een compleet andere taal werken. Als je met SOAP/Web Services de Basic Profile-standaard volgt heb je in principe de garantie dat je met elke taal op elk platform kunt communiceren.

Je kunt echter met JAX-RPC ook afwijken van de basic profile, bijvoorbeeld door attachments te introduceren en dan wordt het wellicht lastiger.

[ Voor 3% gewijzigd door Verwijderd op 15-04-2008 16:51 . Reden: linkje naar basic profile bijgevoegd ]

[Tjeerd]

Ik zit nog wat rond te kijken en zie dat er ondertussen ook Axis2 is, maar deze is alleen (nog maar) in C. Dus niet C++. Het ziet er ook uit dat er verdomd weinig wordt gedaan met Axis en C++ om SOAP/WSDL-services te maken als ik zoek op Google.

Ben ook nog gSOAP tegengekomen, dat ziet er ook nog wel interessant uit. Maar dat is ook niet een veelgebruikt stuk software.

Zijn er echt zo weinig mensen die ervaring hebben met het maken van SOAP/WSDL-services in C++ onder Linux? Of kijk ik totaal naar de verkeerde bibliotheken?

[ Voor 4% gewijzigd door Tjeerd op 15-04-2008 16:22 ]

[Verwijderd]

Dit lijstje al gezien?
Wikipedia: List of Web service Frameworks

Zie er nog AlchemySOAP bij staan, verder geen ervaring met web services in C++.

[Tjeerd]

Verwijderd schreef op dinsdag 15 april 2008 @ 16:51:
Dit lijstje al gezien?
Wikipedia: List of Web service Frameworks

Zie er nog AlchemySOAP bij staan, verder geen ervaring met web services in C++.

Hartstikke bedankt , dat is een mooi overzicht waar ik wat mee ga doen.