Are there any lightweight alternatives to gSOAP?

Question

I've tried using gSOAP for accessing a web service (e.g. using supplied WSDL to generate C stubs and then using them in an app). However, I've found that the generated .c and object files is quite big (several megabytes), which is a problem in embedded environment where I work.

Do you know of any simpler SOAP libraries, or do I have to fall back to generic XML generators and parsers like ezXML?

Ordovician

Welcome to the (not-so) "Simple Object Access Protocol" - the bloated <strike>pig</strike> elephant solution to SOA (Service Oriented Architecture). – Kuth

I fail to see why SOAP is to blame here. It's the size of the services definition, which has nothing to do with SOAP. XML or JSON over REST would be the same, size-wise. But in the end that probably would be worse because you have to code all the serialization yourself without a convenient data binding that generates all the code for you. I use gSOAP for automatic data bindings, clear winner. Otherwise, without gSOAP, making programmers work long hours on tedious XML or JSON API coding for large services is so of the past. – Philologian

Further checking reveals that a pretty standard app for XML message exchange with gSOAP takes under 100k of code and runs 10k messages/sec. Mostly being auto-coded by tools, no hard work. Welcome to the future of auto-coding. – Philologian

Answer 1

I recently looked into this question too, and the best option I found was gSOAP, it is very mature and well tested. However, I decided to go a non-SOAP route, which was an option since I'm on both client and server sides. Before using gSOAP, make sure you can live with their license, you may be obliged to release your code or pay them, depending how you use it.

Another option is Apache Axis2/C, though I have no experience with it (I would guess that it has a similar sized footprint to gSOAP). Their client API is here. A tutorial on the client API is here.

If you decide to go the parsed XML route, you might be interested in this SO question (see answers).

You might also checkout boost::spirit for the parsed route. It has the ability to make small, fast, specialized (and general) parsers, if you're comfortable with C++ (they can be written to be reentrant, so a calling them through a static object with an extern "C" interface is kosher). I can vouch for it in the general sense (not specific to XML). Steep learning curve, but big payoff.

Pontianak

Answer 2

Is this a web service that you are creating? If so, consider using REST instead of SOAP. REST is far simpler, and you can use existing, tested, working now HTTP handlers instead of going through a huge HTTP - XML - SOAP translation layer.

If you are consuming someone else's web service, examine the SOAP schema and/or examples of responses. I cannot believe I am advocating this, but if the schema is not extensible or recursive, you may be better off using a simple LALR parser or even string matching in the raw HTTP responses instead of trying to parse SOAP or XML at all. This is far simpler to implement in embedded C.

Camfort

I have to use someone's web service. So far we have usable XML parsers (above mentioned ezXML works quite nice), so unless some miraculous SOAP library shows up I'll probably have to do it that way :-) – Ordovician

REST has also one additional major disadvantage: it doesn't fit events-oriented web services, which are the most of the real world web services. – Irresistible

Answer 3

Usually we fall back to creating the XML directly (mostly by string concatenation) where no good SOAP library can be used.

Another solution could be that you switch to JSON, which (usually) has smaller overhead and request/response sizes so it could be better in embedded programs. If you only have a SOAP WebService available you could use a proxy Script on the Server which translates JSON Requests to SOAP Requests and SOAP Responses to JSON Responses.

Winola

Answer 4

Have you looked at Apache CXF. It has several code gen features

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

A more helpful guide to build a consumer is here.

Chick

That seems nice, however it seems to support Java only and I don't really have the option to use Java runtime on client side. – Ordovician