One Year of Contribution to Axis2/C

It is quite hard to understand how fast time advances, as it has been like yesterday to me, when I made my first contribution to Axis2/C, in the form of reporting a bug on the manual (you can find the ticket here). If you are interested in understanding what I meant in this issue: I reported, the file found in here was missing, an year back.

It is quite interesting to see how I gradually got on track with Axis2/C development activities. But, to be honest I haven't been doing much ever since I started my final year at the University. I'm looking forward to re-join the contribution camp as soon as I find some free time, which is somewhat a scarce resource these days.

Axis2/C recently began its third year. More information is found on Samisa's post made here. It is quite nice to see many new names appearing on the mailing lists, and also several new contributors joining the project. A special thanks to the two participants of GSoC 2008 who worked with Axis2/C.

When I started working with Axis2/C the project had merely completed its 1.1 release and was looking forward to further additions before the next major release. It was during this era I started working on a improved scheme for HTTP Authentication on Axis2/C. A more detailed description of what it is all about is found in here. My contributions to Axis2/C helped me become a committer to the Web Services Project at the Apache Software Foundation.

Afterwards, during the latter part of my internship at WSO2, I worked on implementing support for RESTful Services on Axis2/C. This was one of the major additions to the project. I also contributed fixing a number of bugs and added few other improvements as well. Thanks to ohloh, you should be able to see some of my commits to Apache Axis2/C in here.

Many thanks to all those who helped me and supported me with my work on Axis2/C, and also to many others who were major factors that influenced my contributions to the project. Today, Axis2/C is perhaps the best and fastest Web Service engine written in C, supporting both SOAP and REST over a magnitude of transport protocols. Axis2/C is also the basis of other popular WS projects at WSO2 including WSF/PHP and WSF/C.

AMQP support now in Apache Axis2/C

Axis2/C, the world's best implementation of a WS engine in C supports both SOAP and REST style invocations. Axis2/C can be used to implement web services in many other languages as well due to it's inherent portability allowances. Examples found in the WSO2 stack, such as PHP, C++, Ruby and Perl fortify this aspect. An implementation supporting WS on Python is also underway, and will be released soon. Axis2/C can also operate based on a number of transports such as HTTP, TCP, and XMPP. The latter being a part of WSO2 WSF/C which is a glorified implementation of Axis2/C with all of its sub projects.

AMQP, or the Advanced Message Queuing Protocol is a relatively new protocol supporting network communication which was introduced about 2-3 years back. AMQP is an open standard application layer protocol for message oriented middleware. AMQP is intended to bridge the gap between common guaranteed-delivery messaging middleware, which enables complete interoperability at both protocol level and broker services semantics level. AMQP also defines an efficient wire-level format to enable a technology-neutral interoperable standard.

The AMQP transport for Axis2/C which was introduced few days ago addresses a popular demand for making it possible to author web services to use the AMQP protocol, which is a best of both worlds implementation. AMQP + Axis2/C makes it possible to integrate the world of AMQP based communication with WS services based on other standards. The Axis2/C project uses an extension provided by Apache Qpid to implement a transport based on AMQP.

REST on Axis2/C

Rest is a well known concept in the world of HTTP. However, it didn't fully make it through to Web Services until very recently. RESTful Web Services became popular with many benefits of REST against SOAP, which would drive SOA towards its ultimate potential.

However, it is a well known fact that REST and SOAP do things differently. Thus, the requirement of new implementations are needed. The WSDL 2.0 HTTP Extensions do provide some convenient implementation of REST for existing SOAP engines, but, RESTful Web Services demands more.

Axis2/C addresses these demands well. Now it has support for HTTP Headers (Standard and Custom), the entire range of valid HTTP Status Codes, and also has the capability to handle several content types, demanded by RESTful implementations.

At present, Axis2/C still lacks the support for much needed x-www-form-urlencoded, which I hope to add in the future. I hope that the experience of Axis2/C REST implementation is as RESTful as one would expect.

WSF/C++ 1.0.0 Released

Wso2's latest approach towards popularizing Web Service Frameworks on C compatible languages resulted in its latest offspring, WSF/C++ or Web Services Framework for C++. I happened to be working on the project in making an all new C++ style exposure to the C API, with C++ style functionality. The initial release focused on the Client API, leaving out the server-side implementation in native C.

In terms of features, WSF/C++ in its full capability surpasses Axis/C++ by quite a margin mainly due to its highly advanced Axis2/C core with supplements such as Rampart/C, Sandesha2/C, and Savan/C.

Among the list of features available on the initial release

1. Client API to consume Web services
   • WSSOAPClient class with one-way and two-way service invocation support for SOAP 1.1, and SOAP 1.2.
   • WSRESTClient class with one-way and two-way service invocation support for REST style invocations.
   • Options class for getting and setting generic service related options, for SOAP and REST clients. REST Clients ignore SOAP related options and vice versa.
2. Attachments with MTOM
   • Binary optimized
   • Non-optimized (Base64 binary)
3. WS-Addressing
   • Version 1.0
   • Submission
4. WS-Security
   • UsernameToken and Timestamp
   • Encryption
   • Signing
   • WS-SecurityPolicy based configuration

The team is hoping to complete the entire Framework by implementing full Server-Side support making it the most complete Web Service Engine for C++ users.

Proxy Authentication on Axis2/C

I believe that it is better to have a brief analysis on Proxy "Basic" Authentication support, which was lately added into Axis2/C.

THE REASON
The main reason behind implementing Proxy Authentication was due to a user request made on the Axis2/C JIRA, which was in fact a major improvement. This is due to the widespread use of proxies in the corporate environment where Axis2/C deployment is mainly targeted.

THE ANSWER
I have implemented Proxy "Basic" Authentication and am presently working on Digest Authentication so that the requirement would be addressed. The basis of this implementation is the RFC2617, which describes authentication requirements in general.
I have added several mechanisms of setting up proxy authentication in Axis2/C clients, which can be found on the Axis2/C Manual.

THE ADVANTAGES
In the current implementation their are some added benefits with respect to Proxy "Basic" Authentication. They are,

• Ability to authenticate blind proxies
• Ability to globally or locally set-up authentication
• Preemptive authentication support
• Client API integration
  

Why CURL shouldn't be the 1st choice in Axis2/C

There have been quite an amount of concerns regarding, making CURL's library for HTTP Transport in C, LibCURL the first choice for our HTTP Sender as well as the HTTP Responder in the Axis2/C engine. Thus, the interest is to make the engine do the processing up to Layer IV and get CURL to handle Layer IV. This fact is strongly supported by means explaining the advantages of CURL's widespread implementation support for HTTP Transport.

However, Axis2/C is an engine designed to port to multiple platforms ranging from Mainframe to Mobile computers, and thus making it the widest as well as the most feature rich Web Services Engine written in C. Thus, I, for several reasons, believe, CURL shouldn't be our 1st choice in terms of transport, as it,

1. Introduces an additional dependency (MS Windows is a good example).
2. Might have issues in terms of mobile platforms.
3. Lesser control over the transport layer.
4. Threading issues that may crop up.
5. License issues that may change in time.
6. Dependency on CURL's performance.
7. Additional size in binary distributions.
   

These are only a few examples. Dinesh, has written a nice article to why he believes CURL must be made the 1st choice at [1]. Samisa, has replied to Dinesh, explaining why CURL should not be the 1st choice at [2]. This discussion is open for anybody else who wishes to contribute.

[1] http://nethu.org/2008/01/14/axis2c-default-http-transport-should-be-libcurl-based/
[2] http://wso2.org/mailarchive/wsf-c-dev/2008-January/003101.html

MD5 support integrated to Axis2/C

Apache Axis2/C a fully fledged SOAP processing Web Service Engine, lacked one very important feature in the past. That was the ability to generate digest checksums. In order to sort this out, OpenSSL a common SSL extension was used as it had integrated support for generating digest checksums. I was able to develop a utility capable of generating md5 (Message Digest Algorithm) checksums based on rfc1321.

With this inclusion, I also added support for generating checksums of files and also a test-case for testing md5 operation. Now, we can look forward for another major inclusion to our client-side. That is the inherent support for handling HTTP Digest Authentication.

The ability of generating md5 checksums for files is exposed through a command line utility, md5, which can be found inside the bin/tools directory at the deployment (installation) location.

I would like to sincerely thank Ronald Rivest in his approach in making md5 a reality.