A Hello World gSOAP Client
For our example, the supporting WSDL is generated from the header file (Server.h), which is used to generate the supporting SOAP server code using the soapcpp2 utility. If you have an existing WSDL, C++ client-side code is easily generated using the wsdl2h utility. It's also possible to generate SOAP client code automatically from WSDL files using other toolkits. For example, the wscompile utility in the Java JaxRPC module of the WSDP 2.0 toolkit can be used to generate a Java JaxRPC client for a gSOAP Web Service.

Server.h

//gsoap ns1 service location: http://192.168.0.2/cgi-bin/article.cgi
int ns1__shareLegacyData(char *&resp);

The //gsoap directive in the header file can be used to specify, among other things, a SOAP endpoint when not explicitly supplied to the client application. The client C++ source code listing is in Listing 2

And last but not least, in Listing 3 there's a simple Makefile that can be used to:

1. Generate the necessary stub/skeleton code from the header file;
2. Compile the example legacy library code;
3. Compile the server example and
4. Compile the client example.

In summary, this simple Hello World example has demonstrated the fundamentals of building and deploying a complete end-to-end Web Service using gSOAP - one that makes functions defined in external C/C++ libraries accessible throughout the Web Services universe using HTTP. So this example can be used as a template for more sophisticated legacy systems integration using gSOAP.

Conclusion
The successful use of gSOAP for solving problems associated with integrating internal legacy application code with new software modules, using the patterns and techniques described above, makes certain key assumptions:

1. Legacy system application code is written in C/C++ and
2. The legacy functions that need exposing will ideally already be available in static or shared C/C++ libraries.

These assumptions don't invariably apply to all situations, but will undoubtedly apply to some, in which case the lessons shared in this article may prove helpful. Once employed, however, the resulting Web Services will be universally accessible and usable for years to come.

As the SOA revolution progresses, slowly but surely, it's becoming more and more evident how SOA can be leveraged to create complex new functionality quickly by mixing and mashing Web components from around the Web Services universe, as well as to breathe new life into legacy systems code. Frameworks such as gSOAP are powerful, cost-effective tools in facilitating the development of Web Service APIs intended for both internal and external consumption. Long live the revolution!