[xml] communicatie tssn java en c++

[Verwijderd]

De bedoeling is dat ik communicatie kan voorzien tussen een java en een c++ programma, en liefst zou ik dit via sockets doen, met xml als protocol,
nu vraag ik mij af hoe ik dan die gegenereerde xml moet doorsturen,
moet ik dit omzetten naar asci tekst en lijn per lijn overzenden naar de andere kant, of moet ik de hele lap tekst in 1 keer overzenden

als iemand andere suggesties heeft hoor ik ze graag

[Verwijderd]

Ik zou aan beide kanten een parser hangen en dan gewoon bytes gaan sturen.
Sommige parsers kan je zelfs een pointer naar je stream/socket geven, en sturen/lezen ze vanzelf

[whoami]

Is SOAP daar niet voor bedoeld?

[ Voor 73% gewijzigd door whoami op 05-08-2003 11:02 ]

[Verwijderd]

whoami schreef op 05 August 2003 @ 11:01:
Is SOAP daar niet voor bedoeld?

Hmm, misschien wel.
SOAP is wel een vorm van communicatie tussen 2 programma's, en is zo handig omdat je echt objecten kan doorsturen.
Je maakt bijv. een RecordSet aan de ene kant, stuurt 'm door (via SOAP) naar een ander programma, en daar heb je ook weer een RecordSet.
Werkt dus ongeveer zo:
Object -> SOAP Parser -> XML -> [communicatiemiddel, zoals 't internet] -> XML -> SOAP Parser -> Object

Ik weet niet of dit is wat de TS nodig heeft, of dat 'ie liever (zoals ik doe ) een eigen XML'etje maakt om over te sturen.

[mbravenboer]

Aan de ene kant moet je een xml produceren, aan de andere kant moet je het consumeren. Beide problemen staan min of meer los van elkaar.

Alle xml parsers lezen op de een of andere manier wel van een stream, reader of wat dan ook, dus daar hoef je je eigenlijk niet druk om te maken.

Het produceren van xml is allereerst een kwestie van API kiezen. Als je performance problemen hebt oververwacht kan je ervoor kiezen om via SAX xml te produceren en een op SAX gebaseerd XML serializer te gebruiken.

Als je voor een DOM api kiest, zit er vaak een serializer bij de DOM implementatie (bijvoorbeeld JDOM, XOM). Deze serializers willen over het algemeen ook gewoon een stream of writer hebben.

Ik zou dus niet al te veel piekeren en gewoon aan het proggen gaan. Kies een API om xml te produceren en kijk hoe je daar XML kan serializeren.

Ga in ieder geval niet zelf XML produceren met behulp van het direct wegschrijven van van strings. Het gebruik van een API handelt xml well-formedness en serializatie details netjes voor je af.

[Alarmnummer]

Ik zou idd ook SAOP aanbevelen of XML-RPC. En anders kan je altijd nog kijken naar Corba of RMI-IIOP kijken als je niet aan XML wilt vastzitten.

[ Voor 4% gewijzigd door Alarmnummer op 05-08-2003 11:07 ]

[Verwijderd]

ja, soap, daar hoor ik veel van, maar hoe zou dat dan concreet te werk gaan?

[Verwijderd]

corba lijkt me iets te zwaar voor deze toepassing, ik ga immeers gn hele objecten doorsturen

ok, mbravenboer,
kdacht voor java zowel als voor cpp xerces te gebruiken om de productie en consumptie van de xml te verwezelijken
dan is mijn enige bezorgdheid hoe het via de socket goed versturen, je zegt via de stream, wordt dat dan als een gewone asci string verstuurd?

[mbravenboer]

Als je XML wilt uitwisselen hoef je zeker niet percee te kiezen voor SOAP of XML-RPC. XML op zich is al bedoeld voor de uitwisseling van data tussen software component dus daar heb je niet percee weer een nieuwe laag voor nodig.

Schone SOAP is geen onaardige keuze, maar je ziet helaas erg veel vieze SOAP. Als je SOAP gaat gebruiken, lees dan goed de laatste SOAP recommendation en raadpleeg wellicht wat discussies over SOAP en REST.

Heel nuttig bij het maken van een goede keuze is de discussie rond weblog APIs. Hier:

http://www.intertwingly.n...03/01/26/evolve.html#REST

staan prachtig alle alternatieven op een rijtje. Je ziet hier schone SOAP en REST voorbeelden. De XML-RPC voorbeelden aan het begin zou ik maar overslaan .

[mbravenboer]

Noble_Paladin: dan is mijn enige bezorgdheid hoe het via de socket goed versturen, je zegt via de stream, wordt dat dan als een gewone asci string verstuurd?

Tja, XML is text . XML is encoding onafhankelijk, dus er vanuit gaan dat het als ASCII tekst wordt verstuurd is in principe incorrect. Je zou je misschien geeneens druk moeten maken om de encoding die gebruikt wordt: de parser en de serializer handelen dit zelf wel af. Hooguit kan je ze configureren met een encoding. Meestal wordt UTF-8 gebruikt.

[Alarmnummer]

Verwijderd schreef op 05 August 2003 @ 11:14:
corba lijkt me iets te zwaar voor deze toepassing, ik ga immeers gn hele objecten doorsturen

Corba is juist gemaakt om calls te laten plaatsvinden tussen systemen die geschreven zijn in verschillende talen. Voor zover ik weet is het niet mogelijk om een object te serializen in java, en deze weer te laten deserializen in bv Delphi.

RMI-IIOP is hier trouwens ook voor gemaakt, en is minder opdringerig in je java ontwerp aanwezig dan Corba.

[Verwijderd]

ok,

ik ga alle hints eens goed bestuderen,
alvast bedankt voor alle moeite

[SartriX]

Als beide programma's door dezelfde developer worden gemaakt en de datacommunicatie verder niet inzichtelijk, interchangeable met latere software of anderszins beschikbaar voor derden hoeft te zijn, zou ik niet eens kiezen voor xml.

Xml generatie en parsing is niet bepaald snel en de datasize ook niet. Dit geld ook net zo hard voor de genoemde Xml-varianten. Mijn suggestie zou zijn om de kant die het meest efficient moet zijn, zijn waarden te laten serializen (native) en de voor de andere kant een generator/parser te maken die dat zelf kan unserializen en serializen in hetzelfde formaat. Zeker de java-serialization is vrij simpel te emuleren in C.

[hobbit_be]

met Corba heb ik niet zo'n goede ervaring, xml-rpc daarentegen is klein en dapper een mini-soap. Soap is bloated, maar krachtig Maar meestal overkill IMHO. xml kent altijd overhead dus niet te gebruiken voor real-time gevallen (ie bijvoorbeeld fps shooter). Maar xml heeft wel als voordeel dat het gewoon op quasi elk platform werkt (zo zou je met Flash ook jouw c/++ server kunnen aanroepen). Als het op snelheid aankomt - tja dan kun je maar best op byte-niveau werken (de Java NIO classes kennen Native ByteBuffers die je razendsnel kunt doorpompen naar NIO sockets - in java is dat het snelste systeem). Meestal gebruikt ik XML-RPC (als ik weet dat er een developper na mij eraan moet werken) of mijn eigen xml 'formaat', wat toch minder overhead kent.