Gibt es leichte Alternativen zu gSOAP?

Ich habe versucht mit gSOAP für den Zugriff auf einen Web-Service (z. B. mithilfe von bereitgestellten WSDL C-Stubs generieren und dann in einer App verwenden). Ich habe jedoch festgestellt, dass die generierten C- und Objektdateien ziemlich groß sind (einige Megabyte), was ein Problem in der eingebetteten Umgebung ist, in der ich arbeite.Gibt es leichte Alternativen zu gSOAP?

Kennen Sie einfachere SOAP-Bibliotheken oder muss ich auf generische XML-Generatoren und Parser wie ezXML zurückgreifen?

Quelle

2010-03-25 che

Willkommen bei der (nicht so) "Simple Object Access Protocol" - die aufgeblähte ~~Schwein~~ Elefant Lösung für SOA (Service Oriented Architecture). –

Ich verstehe nicht, warum SOAP hier schuld ist. Es ist die Größe der Service-Definition, die nichts mit SOAP zu tun hat. XML oder JSON über REST sind in der Größe gleich.Aber am Ende wäre das wahrscheinlich noch schlimmer, weil Sie die Serialisierung selbst programmieren müssen ohne eine bequeme Datenbindung, die den gesamten Code für Sie generiert. Ich verwende gSOAP für automatische Datenbindungen, klarer Gewinner. Sonst, ohne gSOAP, ist es der Vergangenheit zu verdanken, dass Programmierer lange Stunden mit langwieriger XML- oder JSON-API-Codierung für große Dienste verbringen. –

[Weitere Überprüfung ergibt] (https://www.genivia.com/dev.html#performance), dass eine hübsche Standard-App für den XML-Nachrichtenaustausch mit gSOAP weniger als 100k Code benötigt und 10k Nachrichten/Sek. Meistens werden sie automatisch von Werkzeugen kodiert, keine harte Arbeit. Willkommen in der Zukunft der automatischen Codierung. –

Ich habe kürzlich auch diese Frage untersucht, und die beste Option, die ich gefunden habe, war gSOAP, sie ist sehr ausgereift und gut getestet. Ich entschied mich jedoch für eine Nicht-SOAP-Route, was eine Option war, da ich sowohl auf Client- als auch auf Serverseite bin. Stellen Sie vor der Verwendung von gSOAP sicher, dass Sie mit Ihrer Lizenz leben können. Sie sind möglicherweise verpflichtet, Ihren Code freizugeben oder zu bezahlen, je nachdem, wie Sie ihn verwenden.

Eine andere Option ist Apache Axis2/C, obwohl ich keine Erfahrung damit habe (ich würde vermuten, dass es einen ähnlich großen Fußabdruck wie gSOAP hat). Ihre Client-API lautet here. Ein Lernprogramm für die Client-API lautet here.

Wenn Sie sich für die geparste XML-Route entscheiden, könnten Sie an this SO Frage interessiert sein (siehe Antworten).

Sie können boost :: spirit auch für die analysierte Route auschecken. Es hat die Fähigkeit, kleine, schnelle, spezialisierte (und allgemeine) Parser zu erstellen, wenn Sie mit C++ vertraut sind (sie können als reentrant geschrieben werden, so dass ein Aufruf durch ein statisches Objekt mit einer externen "C" -Schnittstelle koscher ist)). Ich kann dafür im allgemeinen Sinn bürgen (nicht spezifisch für XML). Steile Lernkurve, aber große Auszahlung.

Quelle

2010-05-17 00:32:51 academicRobot

Normalerweise greifen wir auf die direkte Erstellung des XML zurück (meistens durch String-Verkettung), wo keine gute SOAP-Bibliothek verwendet werden kann.

Eine andere Lösung könnte sein, dass Sie zu JSON wechseln, das (normalerweise) kleinere Overhead- und Request/Response-Größen hat, so dass es besser in eingebetteten Programmen sein könnte. Wenn Sie nur einen SOAP-WebService zur Verfügung haben, können Sie ein Proxy-Skript auf dem Server verwenden, das JSON-Anfragen in SOAP-Anfragen und SOAP-Antworten auf JSON-Antworten übersetzt.

Quelle

2010-05-10 11:15:19 dbemerlin

Ist dies ein Webdienst, den Sie erstellen? Wenn dies der Fall ist, sollten Sie anstelle von SOAP REST verwenden. REST ist weitaus einfacher und Sie können vorhandene, getestete, jetzt funktionierende HTTP-Handler verwenden, anstatt eine riesige HTTP-XML-SOAP-Übersetzungsschicht durchzugehen.

Wenn Sie den Webdienst eines anderen Benutzers verwenden, untersuchen Sie das SOAP-Schema und/oder Beispiele für Antworten. Ich kann nicht glauben, dass ich dies befürworte, aber wenn das Schema nicht erweiterbar oder rekursiv ist, ist es besser, einen einfachen LALR-Parser oder gar einen String-Abgleich in den rohen HTTP-Antworten zu verwenden, anstatt zu versuchen, SOAP oder XML zu parsen. Dies ist viel einfacher zu implementieren in Embedded C.

Quelle

2010-05-13 18:15:17

Ich muss den Webservice von jemandem benutzen. Bis jetzt haben wir brauchbare XML-Parser (das oben erwähnte ezXML funktioniert ganz gut), also wenn nicht eine wundersame SOAP-Bibliothek auftaucht, muss ich es wahrscheinlich so machen :-) – che

REST hat auch einen zusätzlichen großen Nachteil: Es tut es nicht passen ereignisorientierte Webdienste an, die die meisten realen Webdienste darstellen. – rkellerm

Haben Sie sich Apache CXF angesehen. Es hat mehr Code gen verfügt

* Java to WSDL 
* WSDL to Java 
* XSD to WSDL 
* WSDL to XML 
* WSDL to SOAP 
* WSDL to service

Ein hilfreicher Leitfaden Verbraucher sind here zu bauen.

Quelle

2010-05-16 15:58:24

Das scheint nett zu sein, aber es scheint, nur Java zu unterstützen, und ich habe nicht wirklich die Option, Java-Laufzeit auf der Clientseite zu verwenden. – che

Antwort

Verwandte Themen