C++ and SOAP

Question

I have a C++ app that needs to connect to a JAVA web app, are there any good, open source SOAP packages for this, or would it be easier to just roll my own?

Answer 1

A quick Google turned up this for a toolkit. While I have never used it, it seems to be quite popular and solid. Not exactly a package, and not really rolling your own, but sort of in the middle.

Answer 2

Take a look at Apache's Axis project. It's well supported on C++ (and Java) and if you have the good fortune to start with a good WSDL for the target service you'll be home-free.

Answer 3

I'll vote up darkhelmet since gSoap would also be my recommendation. We're mostly a Java shop but with some C++ bits and gSoap has been our preferred SOAP integration way. It is indeed more work than your typical Java stacks but it seems solid.

Answer 4

We went with gSOAP rather than Axis to avoid having a dependency on both a JRE and Axis just for building a C++ project. It's worked ok, which is good since the gSOAP code is horrible and makes it very daunting to fix any bugs in it.

A warning about gSOAP linking though: you can never use more than one WSDL in a single link object (executable, dll, shared object). This is because some of the generated WSDL-specific functions have general names (e.g. soap_getfault()).

Worse, with Unix ELF linking, these names will cause cross-linking between shared objects, so a FooService fault might be processed by the soap_getfault() for BarService, corrupting memory if the fault detail structures are different.

The workaround for that is to make sure that nothing gSOAP-related is exposed outside the SO they are linked into. This can be solved by giving gcc these definitions _both when linking the gSOAP library itself and linking your code:

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

I solved it by putting them into a header file and forcing gcc to include that before anything else with -include fixsoaplink.h.

A better way if you can take the effort might to change the default ELF visibility to hidden, and only export the symbols you want to (like dllimport/dllexport in VC).

Answer 5

When I saw the generated code from gSOAP, I about had a heart attack.

The fact that the user is required to do all of the memory management for each object just boggled my mind. So, I sat down and did something probably stupid in the long term, but fairly satisfying in the short term...

I wrote a program that wraps the gSOAP code with my own CPP classes that make the interface look more like I'd like it to look.

I used Scoped Guards within each service method to hold onto memory, and since I'm dealing with all sorts of different types, I used a std::list<boost::any> to do it. I have functions that make each object type that I need, and they put the actual memory into my list<any>. It's had a few problems - mostly just configuration changes. I'm generating thousands of classes now, talking to dozens of web services.

I'm not sure I'd recommend my same path to anyone else... I should probably bite the bullet and start trying to contribute to gSOAP, rather than maintain my own tool which is dependent on the output of gSOAP...

Answer 6

Here's another issue with gSOAP we just discovered the hard way: it uses select() for all polling, so once you've got 1024 file descriptors open (64 on Windows?) it will trash the stack. That results in either spurious errors where it is unable to send messages, to complete crashes of the application.

The workaround, unless you're prepared to patch gSOAP itself, is to write your own network code and hook it in with soap->fconnect, ->fsend, ->frecv etc.