Feature Comparison of WSF/C and gSOAP

Archived Content
This article is provided for historical perspective only, and may not reflect current conditions. Please refer to relevant product page for more up-to-date product information and resources.
  • By damitha nanda mangala kumarage
  • 24 Sep, 2008


gSOAP is a Web services project for C/C++ platform. It is being developed for more than six years now. Axis2/C is an open source Web services project which also supports C++ through a wrapper layer. It is being actively developed for about 3 years now. It's predecessor is Axis/C++, which is written in C++. Some of Axis/C++ main developers are still working on Axis2/C. The reason for moving from Axis/C++ to Axis2/C could be attributed to the following:

  1. Axis/C++ architecture is not versatile enough to expand itself to allow WS-* implementations to be integrated to it. For example, there were difficulties implementing the WS-Reliable Messaging specification for Axis/C++. Axis2/C is designed with expandability in mind. New WS-* specification implementations could be easily integrated into it as Axis2/C modules. It has a clever plugin design that uses modules, which allows vertical expansion.
  2. Axis2/C acts an embedded platform for scripting languages: Axis2/C act as the base implementation for popular scripting languages for supporting Web services. Axis2/C is the base for very successful open source Web services products for PHP, Ruby Perl and Python. There are browser pluggins for Mozilla Firefox and Microsoft IIS, and currently work for Google Chrome is underway.
  3. Supports C++ in the form of a wrapper layer - This is a smarter approach than the alternative approach of supporting C language from Axis/C++. However, currently wrapper layer exists only for client side. Server side wrapper layer will be expected in the near future.

Much of these design goals are already achieved in a very short time. 

WSO2 Web Services Framework for C (WSO2 WSF/C) is a Web services platform released under the Apache license v2.0, that is based on Axis2/C and it's constituent products. WSO2 WSF/C is a product of WSO2 with all of its code open source. The strength of WSF/C, is in its integrated platform for various Axis2/C Web services projects. It has an integrated build system and a test platform, which eases the burden of users having to download several products or versions and integrating them.

Table of Contents

WS* Support

WSO2 WSF/C is extensible through modules, for supporting WS-* specifications. For WSF/C, Sandesha2/C is the WS-Reliable messaging implementation, Rampart/C the Web services security implementation and Savan/C the WS-Eventing implementation. It has various other implementations like WS-Federation, WS-Transaction, WS-Enumeration and WS-Transfer. Most of these projects are Apache projects on their own.

WSF/C is the base for Web services implementations of WSO2 (all of which are open source) for scripting languages. WSF/PHP, WSF/Ruby, WSF/Perl and WSF/Python are all popular, in their respective platforms. This is the strongest area of WSF/C when compared with gSOAP. WSF/PHP for example, is very popular among PHP developers for hosting/consuming Web services.

WSF/C by design, can easily be extended in terms of WS-* support. To support additional specifications, a WSF/C module need to be written implementing that particular specification. After that it could be built separately and added to WSF/C as a dynamically loadable shared module.

As far as I could understand from gSOAP documentation, WS-* specification implementations in gSOAP only supports Web services security. Even security is not as comprehensive as WSF/C security support. WSF/C supports addressing by default, whereas gSOAP supports addressing only as an add on.

WSF/C and gSOAP Services

Both WSF/C and gSOAP claim to be versatile platforms for writing and hosting Web services written in C/C++. But the approach each have taken to achieve the goal is different. gSOAP's approach for services is CGI based. Although there is a way to write services as Apache modules, the approach is not emphasized. Even if you write services as Apache modules, it is one Apache module for one service basis. This means if you write 3 services, there will be three different entries in httpd.conf Apache2 configuration file corresponding to each service. In addition, service developer needs to take care of all complexities of handling threads and other chores, in addition to handling his own business logic and user data for the service.

WSF/C has a cleaner design. It has the concept of service/module repositories. Once you write your service(which involves only writing your own business logic), you need built and put it into a service folder in the repository. Now, whatever the deployer you use, whether it is WSF/C stand alone server or the WSF/C apache module, repository structure or configuration will not change. I.e. repository becomes deployer independent. You can have any number of services(of course restricted by system resources), in that repository and in case of Apache, WSF/C Apache2 module takes care of all of them.

I'll demonstrate here some server side code example for a calculator service, for both WSF/C and gSOAP. What is essentially shown is the amount of work the service developer needs to do upon generating server side skeletons.

#include "soapH.h"
#include "CalculatorSoapBinding.nsmap"

   // create soap context and serve one CGI-based request:

__ns1__add(struct soap* soap,
        struct _ns1__add *add,
        struct _ns1__addResponse *response)
    response->addReturn = add->arg_USCORE0_USCORE0 + add->arg_USCORE1_USCORE0;
    return SOAP_OK;

Here, service developer needs to create service implementation files and write service functions from scratch, which are defined in soapH.h. Additionally, he needs to provide a main function for the CGI.

         * auto generated function definition signature
         * for "add|https://localhost/axis/Calculator" operation.
         * @param add
        adb_addResponse_t* axis2_skel_Calculator_add (const axutil_env_t *env  ,
                                              adb_add_t* add )
          /* TODO fill this with the necessary business logic */
          adb_addResponse_t *response = NULL;

          response = adb_addResponse_create(env);
          adb_addResponse_set_addReturn(response, env, adb_add_get_arg_0_0(add, env) + 
                  adb_add_get_arg_1_0(add, env));

          return response;

You can easily see that WSF/C service design allows service developer to simply concentrate on his business logic for a service, without worrying about WSF/C internals. In addition to server side code, WSF/C tool generates service configuration files and build files. User is expected to simply generate server side and fill his business logic, and build using the build file. Thereafter, copy the dll and service configuration file into a folder, and copy that folder into repository service folder. In gSOAP, you need to write the service file given above, in addition to the user's business logic and then build the service manually using his compiler. Then copy the cgi generated into Apache cgi-bin folder. (If you use gSOAP Apache modules, you need to update the Apache configuration file for each of your services). Main factor to note here, is that Apache configuration for WSF/C is a one time process, whereas if you use gSOAP with Apache, it should be done for each new service you deploy. Other limitation of gSOAP is that it currently support only Apache 1.x.

WSF/C and gSOAP Clients

Both have tooling support for generations of proxies. Here again, I'm demonstrating the amount of work needed by client developer after generating the stubs.

#include "soapH.h"
#include "CalculatorSoapBinding.nsmap"
    struct soap soap;
    const char *soap_endpoint = "https://localhost:9090/cgi-bin/Calculator.cgi";
    const char *soap_action = "Calculator#add";
    struct _ns1__add add;
    struct _ns1__addResponse response;

    add.arg_USCORE0_USCORE0 = 10;
    add.arg_USCORE1_USCORE0 = 20;
    soap_call___ns1__add(&soap, soap_endpoint, soap_action, &add, &response);

    printf("result:%d\n", response.addReturn);
          axis2_char_t *endpoint_uri = NULL;
          axis2_char_t *client_home = NULL;
          axis2_stub_t *stub = NULL;
          adb_add_t *add = NULL;
          adb_addResponse_t *response = NULL;
          const axutil_env_t *env = NULL;

          env = axutil_env_create_all("calculator.log", AXIS2_LOG_LEVEL_TRACE);

          client_home = AXIS2_GETENV("AXIS2C_HOME");

          endpoint_uri = axutil_strdup(env, "https://localhost:9090/axis2/services/Calculator");
          stub = axis2_stub_create_Calculator(env, client_home, endpoint_uri);
          axis2_stub_populate_services_for_Calculator(stub, env);
          add = adb_add_create(env);
          adb_add_set_arg_0_0(add, env, 10);
          adb_add_set_arg_1_0(add, env, 20);
          response = axis2_stub_op_Calculator_add(stub, env, add);
              int result = adb_addResponse_get_addReturn(response, env);
              printf("result:%d\n", result);

Messaging Style

Both gSOAP and WSF/C support, document/literal and RPC/Encoded styles. But gSOAP is more emphatic on RPC/Encoded style, while WSF/C is strong in document/Literal. There is long running debate, as to which of the two implementations should be adopted. But in the world of Web services, Document/Literal implementations has gained more ground.

Service Discovery

Initially UDDI was one of three constituent parts of Web services(other two parts are SOAP and WSDL). In essence, it is the technology for publishing Web services. But use of it has never been popular among major vendors. According to a recent InfoQ news article, UDDI committee is now closed. WSO2 has opted for its Registry technology over UDDI. But gSOAP still relies on UDDI technology, for service discovery.

Tooling Support

It should be noted that gSOAP xml to C/C++ data mapping layer is implemented using native language compiler support which it claims to be more robust and faster than mapping using xml based parsers. WSF/C has taken the latter approach. It's code generation and data binding tool is derived from popular Axis2/Java code generation methodology and data binding tools has given additional strength to be a reliable and a highly tested tool.

MTOM Support

gSOAP is more emphatic on DIME/MIME support than on MTOM support. WSF/C does not support DIME but supports MIME and MTOM fully and effectively.

REST Support

WSF/C fully supports the REST API, whereas I did not see any mentioning of REST support in gSOAP documentation


WSF/C also supports host of other enterprise ready features. In terms of interoperability, gSOAP claims it's interoperability with lot of other Web services engines. But most of them, if not all, are basic SOAP stacks. Basic as in, it do not provide much WS-* support for those stacks. WSF/C claims to interoperate with popular Axis2/java and Microsoft WCF platforms.


In this article I have attempted to perform a feature comparison of WSF/C and gSOAP. Each stacks have it's own strengths and weaknesses. gSOAP is a particularly strong stack as a Web services platform for small devices. This is an area WSF/C has plans to expand in future. WSO2 WSF/C is strong in it's robustness in design in addition to its extensibility and scalability. In terms of features, WSF/C has many more features than gSOAP. Understandably, C++ support in gSOAP is much stronger than WSF/C. Still, C++ support in WSF/C is still fast growing and is only a matter of time before it could be used as a fully fledged C++ Web services stack. The focus in this article was on comparing features rather than on performance. In a future article, I intend to address performance differences of the 2 technologies.


  1. WSO2 WSF/C - WSO2 WSF/C is an open source framework for providing and consuming Web services
  2. Axis2/C- Axis2/C is an Apache Web services platform implemented in C language around which the WSO2 WSF/C project is built.
  3. gSOAP- is an open source C/C++ Web services stack.
  4. Complete sample used for this article.


Damitha Kumarage is a Senior Software Engineer WSO2 and a committer for Apache Software Foundation. damitha at wso2 dot com

About Author

  • damitha nanda mangala kumarage
  • senior tech lead
  • wso2