2008-09-05 14 views
11

Tengo una aplicación C++ que necesita conectarse a una aplicación web JAVA, ¿hay algún buen paquete SOAP de código abierto para esto, o sería más fácil crear mi propia cuenta?C++ y SOAP

Respuesta

1

Un rápido Google apareció this por un kit de herramientas. Si bien nunca lo he usado, parece ser bastante popular y sólido. No es exactamente un paquete, y realmente no funciona, pero está en el medio.

0

Eche un vistazo al proyecto Axis de Apache. Está bien soportado en C++ (y Java) y si tienes la buena suerte de comenzar con un buen WSDL para el servicio objetivo, estarás en casa.

11

Voy a votar hasta darkhelmet desde gSoap también sería mi recomendación. Principalmente somos una tienda de Java pero con algunos bits C++ y gSoap ha sido nuestra forma de integración SOAP preferida. De hecho, es más trabajo que las típicas acumulaciones de Java, pero parece sólido.

1

Fuimos con gSOAP en lugar de Axis para evitar tener una dependencia de JRE y Axis solo para construir un proyecto de C++. Ha funcionado bien, lo cual es bueno ya que el código de gSOAP es horrible y hace que sea muy desalentador arreglar cualquier error en él.

Advertencia sobre el enlace gSOAP: nunca se puede usar más de un WSDL en un único objeto de enlace (ejecutable, dll, objeto compartido). Esto se debe a que algunas de las funciones específicas de WSDL generadas tienen nombres generales (por ejemplo, soap_getfault()).

Peor aún, con enlaces ELF Unix, estos nombres causarán enlaces cruzados entre objetos compartidos, por lo que un error FooService podría ser procesado por soap_getfault() para BarService, corrompiendo la memoria si las estructuras de detalles de fallas son diferentes.

La solución alternativa consiste en asegurarse de que no exista nada relacionado con los SOG relacionados con el SO al que están vinculados. Esto puede resolverse dando gcc estas definiciones _both al vincular la biblioteca gSOAP sí mismo y la vinculación de su código:

#define SOAP_FMAC2 __attribute__ ((visibility ("hidden"))) 
#define SOAP_FMAC4 __attribute__ ((visibility ("hidden"))) 
#define SOAP_FMAC6 __attribute__ ((visibility ("hidden"))) 
#define SOAP_NMAC __attribute__ ((visibility ("hidden"))) 

Lo resuelto por ponerlos en un archivo de cabecera y obligando a gcc para incluir que antes de cualquier otra cosa con -include fixsoaplink.h.

Una mejor manera si puede hacer un esfuerzo podría cambiar la visibilidad ELF predeterminada a oculta, y solo exportar los símbolos que desee (como dllimport/dllexport en VC).

+1

Huh. De hecho, creo que vi algunas cosas buenas en gSOAP sobre poner todo el código generado detrás de un espacio de nombres. En realidad, estoy casi seguro. Eso significaría que las funciones de nombre general, como soap_getfault() no colisionarían, incluso en un único objeto de enlace. –

+1

De hecho, puede poner más de una wsdl en un único objeto de enlace, ¡actualmente lo estoy haciendo! – fido

0

Cuando vi el código generado de gSOAP, tuve un ataque al corazón.

El hecho de que el usuario debe hacer toda la gestión de la memoria para cada objeto me dejó boquiabierto. Entonces, me senté e hice algo probablemente estúpido a largo plazo, pero bastante satisfactorio en el corto plazo ...

Escribí un programa que ajusta el código gSOAP con mis propias clases de CPP que hacen que la interfaz se parezca más a Me gustaría que se vea.

Usé Scoped Guards dentro de cada método de servicio para conservar la memoria, y como estoy tratando con todo tipo de tipos diferentes, usé un std::list<boost::any> para hacerlo. Tengo funciones que hacen que cada tipo de objeto que necesito, y ponen la memoria real en mi list<any>. Ha tenido algunos problemas, principalmente cambios de configuración. Ahora estoy generando miles de clases, hablando con docenas de servicios web.

No estoy seguro de que recomiende el mismo camino a nadie más ...Probablemente debería romper la bala y comenzar a intentar contribuir con gSOAP, en lugar de mantener mi propia herramienta, que depende de la salida de gSOAP ...

+0

Hice una cosa similar y luego me di cuenta de lo estúpido e inmanejable que era. Después de refactorizar el código, tuve una clase de plantilla que podría funcionar para cualquier clase generada de GSOAP C++. Puedo enviarte el código si quieres. – fido

+0

¡Agradecería eso! - [email protected] o tal vez podría publicarlo en el código de google, o algo similar. :-) –

0

Aquí hay otro problema con gSOAP que acabamos de descubrir por la vía difícil: usa seleccionar() para todas las encuestas, por lo que una vez que haya 1024 descriptores de archivos abiertos (64 en Windows?) se descartará la pila. Eso da como resultado errores espurios en los que no puede enviar mensajes, para completar bloqueos de la aplicación.

La solución, a menos que estés preparado para parchear gSOAP en sí, es escribir su propio código de red y conectarlo con de jabón> fconnect, -> fsend, -> frecv etc.

Cuestiones relacionadas