Web services and service oriented architecture has been gaining ground with the promise of solving problems in traditional software. Interoperability, modularity and composability are the key factors that drive software professionals to embrace Web services and related technologies. With the popularity of Web services came the need for tools. There are many tools today that support basic Web services specifications such as XML, SOAP and WSDL. There are a few tools that support the full Web services stack, with support for essential WS-* specifications such as WS-Addressing, WS-Security and WS-ReliableMessaging. Apache Axis2/C is among those few that has support for the full Web services stack.
Apache Axis2/C is a Web services engine implemented in the C programming language. It is based on the extensible and flexible Axis2 architecture, and has been implemented with portability and ability to embed in mind. One of the key objectives of Axis2/C, when it was initially designed, was to use it as a Web services enabler in other software, scripting languages such as PHP, Perl, Ruby; database management systems such as MySQL and Postgress, and Web browsers like Firefox. Almost all of them are written in either C or C++. Given that Axis2/C is written in C as well being designed to be embedded, makes Axis2/C simple to use to enable Web services from other open source software.
Apache Axis2/C  grew out of a need for a Web services engine written in C that supports the full Web services stack. Prior to Axis2/C, Apache Axis C++ was filling in this need. However, there were a few concerns. One major concern was that Axis C++ was written in C++. So those who wanted to use it to work in C had problems. It is natural that C++ software uses C libraries. On the other hand, using C++ libraries in C software is not that common due to obvious technical concerns. Hence there was the need for a C library. Also, Axis C++ had a few limitations when it came to supporting WS-* specification. The Axis2 architecture solved those problems effectively, and hence the next generation architecture was implemented in C with the capability to support any Web services specification.
Figure 1: Axis2/C Architecture Overview
Apache Axis2/C is based on the XML-in and XML-out processing principle. The Web services engine expects the input to be in XML and returns the outcome of the processing in XML. To facilitate the efficient processing on XML, an XML object model called AIOM is used. AXIOM stands for AxIs Object Model. AXIOM depends on the StAX (Streaming API for XML) model pull parsing for building the XML model. The pull based, lazy building style of the XML payload is ideal for a SOAP processing engine.
Contract first model, that is implementing Web services or clients starting with a WSDL is a popular programming model in Web services space. Hence a tool that could generate code for a given WSDL is a must for a Web services toolkit to be complete. For Apache Axis2/C, code generation can be done using the WSDL2C tool that comes with the Apache Axis2/Java tool. This tool, even though written in Java, is written for generating code in a programming language independent manner. Therefore, it could be used to generate client stubs and service skeletons that could be used with Axis2/C API. Since code generation is an offline activity, and also since the Java tool is mature and well tested for many WSDL files with Axis2/Java itself, using that for code generation makes good sense rather than building our own.
In Axis2/C, data binding is abstracted from the SOAP engine processing. Hence any desired data binding framework could be plugged in. A data binding framework, called ADB (Axis Data Binding) is built into the Java based WSDL2C code generation tool. You can generate C code that works with Axis2/C API with ADB data binding support for a given WSDL. If you want to use your own data binding framework, you can plug that into the code generation tool. The Java tool is template based and you can use an XSLT template to configure the code generation tool to use your own data binding framework.
You can also afford to plug in data binding at the business logic processing layer of a service implementation. Once the control reaches the service, you can use your own data binding framework and deal with the AXIOM payload.
You can find a detailed and step-by-step description on how to get your first Web service up and running with Axis2/C and then consume that service using an Axis2/C client in the quick start section of the Axis2/C manual.
There is a comprehensive set of samples that comes with Axis2/C that demonstrates the various features. You can develop clients by way of both synchronous (blocking) and asynchronous (non-blocking). There is the option of using dual channels when using clients. When using dual channels, the request would be sent on one channel and the response would be received on another channel.
One key advantage of Axis2/C is that you can develop a single Web service and expose that service as both a SOAP style as well as a REST style service. Axis2/C supports POX (Plain Old XML) style REST invocations both on the server side as well as the client side.
With the samples, you get a Google spell checker, SOAP client, and Yahoo search REST client demonstrating both SOAP and REST capabilities They also demonstrate that Axis2/C is interoperable with other systems. I have tested Axis2/C services with Axis2/Java clients for various scenarios and have it has proved to interoperate.
Axis2/C has been designed ground up with portability and plugability in mind. Axis2/C has abstracted out memory management, so that you can plug in any memory allocation and de-allocation mechanism, including memory allocation pools. The abstraction layer can be seen in action with the Apache HTTPD module, where it uses APR memory pools, in place of malloc, and is free for memory management.
Similar to memory management, logging, threading and error reporting has been abstracted out to facilitate the ability to plug any user desired platform specific implementation.
Apache Axis2/C has the provision to support multiple transports. It has built in HTTP support. The transport layer abstraction has the provision to support other transport protocols such as TCP/IP, SMTP and XMPP. It also allows plugging in multiple implementations of the same transport. For example, in addition to built in HTTP client transport, a libcurl based client transport is also implemented. On the server side, in addition to the simple axis server transport, Apache HTTPD based as well as Microsoft IIS based transports are also supported. Basically you can plug in any transport you wish.
XML processing within the Axis2/C engine is based on AXIOM. However, in order to build AXIOM, the incoming request stream needs to be parsed using an XML pull parser. Axis2/C uses Libxml2 as the default parser. A parser named Guththila, which is a pure pull parser and is within the Axis2/C source tree can also be used. If you want to plug a parser of your choice, all that you need to do is to implement the XML reader and writer, abstract APIs, and place that parser wrapper library in the lib folder.
Extensibility was one of the key attributes built into the Aixs2 architecture when it was designed. One of the key objectives here was to allow the support of WS-* specifications through modules . Apache Aixs2/C has leveraged this design characteristic of Axis2 architecture to support WS-Addressing, WS-Security, WS-ReliableMessaging and WS-Eventing.
WS-Addressing is built into the Aixs2/C engine given the fact that WS-Addressing is used by many other Web services specifications as well as some of the Axis2/C features, such as dual channel clients use WS-Addressing concepts to operate.
Modules in Axis2 architectures adhere to the separation of concerns principle. Hence some of the modules implementing WS-* specifications are run as separate independent projects in Apache.
Apache Rampart/C  project implements the WS-Security as an Axis2/C module. It supports basic UernameToken profile as well as message signing and encryption. Rampart/C is the only open source project that covers most of the WS-Security specification in C or C++.
Apache Sandesha2/C  project implements the WS-ReliableMessaging specification. It implements both version 1.0 of the specification as well as parts of the version 1.1 of the specification. Sandesha2/C is most probably the only open source C based implementation of the WS-ReliableMessaging specification.
Apache Savan/C  project implements the WS-Eventing specification, and again is most probably the only open source C based implementation of the specification.
In addition to the above mentioned specifications that are implemented as modules, Apache Axis2/C also has built in support for MTOM/XOP as part of its AXIOM implementation. MTOM implementation could be used when sending binary data as attachments with SOAP messages.
Though the 1.0 release of Axis2/C did not have it, the next release of Axis2/C would also have WS-Policy support built into the engine.
Figure 2: Axis2/C WS-* Support
Axis2/C already has support for a comprehensive set of WS-* specifications. Moreover those implementations are already tested for interoperability, at least with Axis2/Java. If the WS-* specification that you are looking for is not already implemented, you can use the well defined APIs and implement it as a module and plug that into Axis2/C with minimal effort.
The Apache Axis2/C Web services engine is the state of the art Web services engine that supports the most number of WS-* specifications in C. The Web services engine's extensibility and ability to plug into other systems allow it to be customized to suite the requirements of the users. Axis2/C would be the ideal choice for deploying enterprise grade Web services, and consuming the services in the SOA era, in C or C++, given the coverage of Web services specifications with proven interoperability.
Samisa Abeysinghe, Software Architect, WSO2 Inc, samisa at wso2 dot com