Web Services With Axis2/C

CMake based build system for Axis2/C

2009-07-25T10:22:00.000-07:00

This post is about the new CMake based build system for Axis2/C. Once the patch applies to the Axis2/C trunk the Axis2/C community will benefit from it.

CMake is a cross platform build system. It generates build files for native build environments(i.e. Makefile for UNIX/Linux, VS Projects/Workspaces for Windows and Xcode for Apple). It's doing the same job as popular GNU build tools(autoconf, automake, Libtool). CMake has a lot of cool features. Some of are listed below. And CMake is opensource.

CMake features
1. Manage, complex and large build environments (ex: KDE4)
2. Very Flexible and Extensible.
3. Very simple script language for build script writing.
4. Support both in-source and out-source builds.
5. Cross compiling.
6. Integrated testing and packaging tools(CTest, CPack)

Instructions to use CMake build system for Axis2/C on UNIX/Linux
The build has written to run as a out of source build. This mean that the build files and then object files will be generated out side of the main source tree.
Once you checkout the soure from the trunk, issue the following commands to build Axis2/C using CMake. You need to have CMake installed(2.6 or above) on your system.

1. export AXIS2C_HOME=/path/where/you/want/axis2c/to/live
(e.g.: export AXIS2C_HOME=/home/rajika/project/axis2c/axis2-build/deploy)

2. mkdir axis2c-build(assuming you are at /home/rajika/project/axis2c/)

3. cd axis2c-build

4. cmake ../ (you have checked out the Axis2/C source into /home/rajika/project/axis2c/)

5. make

6. make install

Done!. You'll see all the binaries are available inside deploy directory together with the libraries and the configuration files requires to run the server and the samples successfully.

It built within less than 20 seconds in my laptop(running Fedora 10 with gcc 4.3.2 with Dual core processors-2.20GHz,2.20GHz and with 3GB of physical memory). Following are few screen shots of Axis2/C CMake build in action. You'll notice the cool CMake features there.

A separate blog will follow describing how to extend the new build system when extending Axis2/C using samples(client+services), transports and message receivers.

Memory Handling conventions in Axis2/C

2009-03-06T22:08:00.000-08:00

Memory Handling conventions in Axis2/C

Axis2/C Handler Parameters

2008-11-20T20:57:00.001-08:00

Axis2/C allows to extend its functionality by using modules. A module is a set of handlers. A handler is the smallest execution unit along the Axis2/C execution path. When we write a handler sometimes we may want to specify parameters for configuring it. Here is a example of a module.xml file (the configuration file for a module) with handler specific parameters.

        1: <module name="discovery" class="discovery">

       2:   <inflow>

       3:     <handler name="DiscoveryInHandler" class="discovery">

       4:       <order phase="Discovery"/>

       5:     </handler>

       6:     <handler name="DiscoveryDuplicateInHandler" class="discovery">

       7:       <order phase="Transport" phaseLast="true"/>

       8:       <!--after="addressing_based_dispatcher"/-->

       9:       <parameter name="algo">DiscoveryDuplicateAlgoCount</parameter>

      10:       <parameter name="count">1000</parameter>

      11:       <parameter name="time">10</parameter>

      12:     </handler>

      13:   </inflow>

      14:   <operation name="Probe">

      15:     <parameter name="wsamapping">http://schemas.xmlsoap.org/ws/2004/10/discovery/Probe</parameter>

      16:   </operation>

      17:   <operation name="Resolve">

      18:     <parameter name="wsamapping">http://schemas.xmlsoap.org/ws/2004/10/discovery/Resolve</parameter>

      19:   </operation>

      20: </module>

Here you can see I have specific configurations for the DiscoveryDuplicateHandler.

If you have access to the axis2_handler_t object, you can access these parameters.

       1: void AXIS2_CALL get_parameters(axutil_env_t *env, axis2_handler_t *handler)

       2: {

       3:     axis2_handler_desc_t *handler_desc = NULL;

       4:     axutil_param_t *param = NULL;

       5:     axis2_char_t *temp = NULL;

       6:  

       7:     handler_desc = axis2_handler_get_handler_desc(handler, env);

       8:     param = axis2_handler_desc_get_param(handler_desc, env, DISCOVERY_DUPLICATE_HANDLER_ALGO);

       9:     if (param)

      10:     {

      11:         temp = (axis2_char_t *)axutil_param_get_value(param, env);

      12:         if (!axutil_strcmp(temp, DISCOVERY_DUPLICATE_ALGO_COUNT_STR))

      13:         {

      14:             dup->algo = DISCOVERY_DUPLICATE_ALGO_COUNT;            

      15:         }

      16:         else if (!axutil_strcmp(temp, DISCOVERY_DUPLICATE_ALGO_TIME_STR))

      17:         {

      18:             dup->algo = DISCOVERY_DUPLICATE_ALGO_TIME;

      19:         }

      20:         else 

      21:         {

      22:             AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "Invalid value for parameter algo: %s", temp);

      23:             return NULL;

      24:         }

      25:     }

      26: }

First you need to get the axis2_handler_desc_t from the handler. Then you can access the parameters using this structure and its associated methods.

Axis2/C modules and persistent configurations

2008-11-17T22:30:00.001-08:00

Some Axis2/C module specific configurations are built only once and stored in the context hierarchy of Axis2/C. If you want to do some serious configurations with Axis2/C you should always do it in the handler invocation functions. Other API functions of handlers and modules doesn't provide enough information for a reasonable configuration. This is because of the in-ability to access the axis2_conf_t from these functions. But handler invocation functions have access to this information and are ideal for module configurations except they are called request basis. Usually we build configurations at the start-up time. But since we cannot do the configurations at the start up time we have to deal with the fact that we are using the same function for configurations as well as invocation of our logic on the messages.

The way to deal with this is to use a mutex. But before going in to detail we should look at why we need mutexes. Axis2/C is designed to handle a single execution in a single thread. That means if you have multiple messages coming into Axis2/C at the same time they should be processed in different threads of Axis2/C execution.

Now we have decided that we should do the configuration in a message processing path. So the ideal time to build the configuration is when the first request comes to the server. If the first request comes alone then there is no problem. We can safely create the configuration and store it in the axis2/c context hierarchy. But in reality, there may not be a first single message and a bunch of messages may come at once. Since we are going to process these messages in different threads it may end up creating multiple configurations leading to memory leaks and memory corruption.

Now our requirement is clear. We want to create the configuration only when the first message comes. This is where we need mutexes.

First thing that we will do is try to access the property from the conf.

        1: axis2_ctx_t *ctx = NULL;

       2: axis2_conf_ctx_t *conf_ctx = NULL;

       3: axutil_property_t *prop = NULL;

       4:  

       5: conf_ctx = axis2_msg_ctx_get_conf_ctx(msg_ctx, env);

       6: ctx = axis2_conf_ctx_get_base(conf_ctx, env);

       7: prop = axis2_ctx_get_property(ctx, env, DISCOVERY_CONF_DUP_PROPERTY);

If the property is not in the conf that means it is not created and we need to create it.

       1: if (!prop)

       2: {

       3:     /* make sure we only create the property once */

       4:     axutil_thread_mutex_lock(discovery_thread_mutex);

       5:     /* make sure only one threa create the property. If more than one thread come to the mutex lock at the first 

       6:     time this code will ensure, only one thread actually create the property */

       7:     prop = axis2_ctx_get_property(ctx, env, DISCOVERY_CONF_DUP_PROPERTY);

       8:     if (prop)

       9:     {

      10:         axutil_thread_mutex_unlock(discovery_thread_mutex);

      11:         return prop;

      12:     }

      13:  

      14:     prop = axutil_property_create(env);

      15:     /* here populate the property with your configuration */

      16:  

      17:     /* ******* */

      18:  

      19:     /* set the property */

      20:     axis2_ctx_set_property(ctx, env, "Your custom property name", prop);

      21:     /* unloack the mutex */

      22:     axutil_thread_mutex_unlock(discovery_thread_mutex);

      23: }

The mutex that I have used is from axutil_thread.h file. I have used a global variable for holding the mutex.

       1: axutil_thread_mutex_t *discovery_thread_mutex = NULL;
  

Adding Custom SOAP Headers to Web Service Request

2008-10-21T02:18:00.000-07:00

How to Add Custom SOAP Header to SOAP Requests using Axis2/C Service Client

TCPmon C tool

2008-10-19T21:42:00.000-07:00

Axis2/C has a command line TCPmon tool, which can use to caputure the message which travels on the wire. It has features such as pretty printing, MTOM handling etc.. The usage is as follows.

[rajika@localhost tools]$ ./tcpmon -h
Usage : ./tcpmon [-lp LISTEN_PORT] [-tp TARGET_PORT] [-th TARGET_HOST] [-f LOG_FILE] [options]
Options :
-lp LISTEN_PORT port number to listen on, default is 9099
-tp TARGET_PORT port number to connect and re-direct messages, default is 9090
-th TARGET_HOST target host to connect, default is localhost
-f LOG_FILE file to write the messages to, default is tcpmon_traffic.log
--format enable xml formatting
--test enable testing last request/response by logging it separately
Help :
-h display this help screen.

Javascript binding for Axis2/C server side

2008-09-10T00:40:00.001-07:00

There is a small message receiver for Axis2/C which plugged the Spider monkey(The javascript C engine) to Axis2/C server side. Now Axis2/C services can be written in Javascript. The services should be written using E4X API[1]. A service has the XML string in/out model. The result is available here[2]. A direct patch also available [3]. Please note that some work are still there.
Follow the following steps to get this work on Linux. This only tested on linux platform.
1. Compile and installed the Spider monkey- Javascript C engine.
Refer here: http://developer.mozilla.org/en/SpiderMonkey_Build_Documentation
2. Place the js_xml_in_out_msg_recv.c, axis2_js_common.h and Makefile.am to /src/core/receivers/
3. Compile and install Axis2/c.
4. Compile the sample client in sample/cleint. You can use the build.sh file for this.
5. Create a folder called js under deploy/services directory and place the services.xml and the test.js file
inside that.
6. Add the following entry to the services.xml
put the path of test.js here
Remember to put the script path to the value of Script parameter.
7. Invoke the sample client in step 4
If you run into shared libraray problems try exporting LD_LIBRARY_PATH to libjs.so location

[1] - http://en.wikipedia.org/wiki/E4X
[2] - http://rajikacc.googlepages.com/js-binding.tar.gz
[3] - http://rajikacc.googlepages.com/axis2c_js_binding.patch

WS-Transfer for creating and exchanging state information of resources

2008-09-08T02:07:00.001-07:00

WS-Transfer for creating and exchanging state information of resources
The Web service Transfer (WS-Transfer) is a specification to capture the current or intend state of a resource(resource can be defined as anything like, this web page, a SOAP message, a header of a SOAP message) and transfer that representation among components in a heterogeneous network. It is an abstraction of the architectural elements in a distributed system. WS-Transfer defined an implementation and maintenance of resources from its state. Specification defines the key elements of the system as follows.

Resources
The resource can be anything that can be named. eg:a web page, an article, a SOAP message, a weather report etc... So this resource has a particular representation which is given by resource representation. It can be either a static information (such as a web page, an article ) or a dynamic information (such as weather data, stock market data)

Resource Identifier
This is the logical representation of the resource. This enables to identify the resource or its parts.

Resource factory
Resource factory is a web service which is capable of creating a resource state. This should be capable of creating a resource state from and XML representation and returns its identifier.

Resource Operation
A web service which is capable of manipulating the state of a resource.

Resource factory and Resource operations together defined the followings operation on the resource.
There are four operations defined in WS-Transfer specification.
1.Create - The operation creates a state of a resource and returns the end point reference (EPR) of that resource in the response.
2.Get – This operation brings the XML representation of the resource.
3.Put – This operation update the representation of the resource with a new representation.
4.Delete – This operation delete the state representation of the resource.

Following diagram shows WS-Transfer in action.

1.A client application request for the representation of a resource using Create request supplying the EPR of the resource.
2.The Resource factory of the WS-Transfer enabled service will response with the CreateResponse reply together with the resource representation.
3.Once the resource representation is in hand the client application can do further processing and issue any other operation on the resource state using Get/Put/Delete operations.
4.The representation of the new state will be returned back to the client application in Ge/Put/Delete Response.

Reference:
1. http://www.w3.org/Submission/WS-Transfer/

Debugging Axis2/C services and clients

2008-08-29T00:02:00.001-07:00

Apache Axis2/C is mainly supported in Linux and Windows. You can use it as a standalone product or deploy it in Apache web server or IIS. You may want to debug the services that you've written for axis2/C under these different scenarios. This tutorial in Oxygen Tank of WSO2 explains how to setup and debug Axis2/C services and clients in few easy steps.

Terminator - Cross-platform Terminal Emulator with Window Splitting

2008-08-25T19:08:00.000-07:00

Terminator - Cross Platform GPL Terminal Emulator with Multiple Window Support

High performance Axis2/C – Tips and Tricks

2008-08-25T01:25:00.000-07:00

You can deploy a web service inside Apache/httpd web server using mod_axis2 apache module. In a production environment this is the recommended way of deploying your services.
In a production environment performance is an important factor to improve. Axis2/C shows very interesting performance figures. You can see that in the latest Axis2/C performance results article in WSO2, oxygen tank.
Following are few tips and tricks that you can use to set up a high performing instance of Axis2/C

1.If you compile the sources of Apache/httpd and Axis2/C to get the final binary, compile without any debugging enable or without any optimizations(avoid using -g or -o options)
2.Always set the debug level of Apache/httpd and Axis2/C to critical. The level of the logging may depend upon your production environment.
3.In addition to these things you can do some optimizations for Apache/httpd which will result high performance of Axis2/C.
- Equipped your server hardware with more main memory
- Calculate the optimal number of Maxclient which suits your available hardware.
- Adjust the other options to get the maximum from Apache/httpd, Refer the guide here.
Next you can tune some kernel level parameters as well. But these requires some experimentation to identify the optimal combination for your resources. Best thing is to follow the given

References.
http://httpd.apache.org/docs/2.0/misc/perf-tuning.html
http://www.xs4all.nl/~thomas/apachecon/PerformanceTuning.html
http://www.stdlib.net/~colmmacc/Apachecon-EU2005/scaling-apache-handout.pdf

WS-Discovery WS Gateway to the Devices

2008-08-18T21:41:00.001-07:00

WS-Discovery allows a client to discover service end points by sending multi cast messages (UDP transport). For example, clients search for services by asking things like “is there a printer in this network”. In technical words clients search by type and scope of the services. If a matching service is in the network it will respond with its network address and client can use the provided information to communicate with the service.

At the very high level a WS-Discovery implementation facilitates the following:

Services can be made discoverable Services should be able to specify the criteria under which they are discovered. This include it's type and scopes under which it can be used.
Clients should be able to discover services. Clients send multicast messages to the network to discover the services. Clients specify the criteria that they are looking for in a service. Services that match the criteria will respond and client can use the provided information to communicate with the service.
To be able to write "Discovery Proxies" to minimize the network overhead Discovery proxy is an optional component in the architecture. Discovery proxies keep track of services in the network. If a client detects a discovery proxy, then it doesn't send unicast messages, instead it send unicast messages to the discovery proxy and discovery proxy is responsible for finding the services (usually this information is cached in the discovery proxy).

Debugging Axis2/C services – Linux

2008-08-13T22:00:00.000-07:00

On some phase of your development , you may need to debug your web service clients or the simple axis2 server or when you deploy your services inside Apache httpd server. This guide shade some light on doing that with the help of gdb on linux platform.
For debugging purposes with gdb you should compile your source with -g option. So make sure that you compile Axis2/C and your client with that options. And also note to avoid optimization, do not use any -o options in the compilation process.

1.Debugging a client.
This is a very straight forward work. The client is a standalone C program, in which it depends on few other libraries(ex: axiom). So start the program in gdb and set up few break points and start the debugging process.

2.Debugging simple axis2 server/simple tcp server.
In case where you need to debug simple axis2 server (or the tcp server) you can start the simple_axis2_server binary inside debugger and follow the debugging process.
$gdb axis2_http_server
Now set few debug points inside your service. Next from another terminal send a request to your service. You will see how the debugger hits the breakpoints that you placed.

3.Debugging services inside in Apache/httpd.
Axis2/C services can be hosted inside Apache httpd using mod_axis2 module. To debug a service hosted inside mod_axis2 follow this procedure.
$gdb httpd
Set up few breakpoints within your service.
(gdb) run -X -d /usr/local/apache (path of your Apache installation)
Then from another terminal send a request to your service. At this point you'll see the debugger hits your breakpoints.

Debugging Axis2/C Services - Windows

2008-08-06T21:18:00.000-07:00

Axis2/C web services are dll files that exports two functions and create a instance of axis2_svc_skeleton_t structure. Services are deployed in the {AXIS2C_BIN_HOME}\services directory. A service has a dll file and a configuration file called services.xml. Services should be hosted within a folder of same name as the service.

Deploy your service in to Axis2/C. Also make sure that the service is built with debug enabled. Axis2/C doesn’t have to be built with debug enabled but it is easy if it is built with debug enabled. Now I'll explai how to debug services in different deployment scenarios.

Simple http server

The simple http server is part of Axis2/C and as the name suggests is a simple http server capable of hosting Axis2/C web services only.

Start the simple axis2 server. If you start the simple http server from the VC solution you can straightaway start debugging the services. All you have to do is put some break points in to the service files within the Axis2/C solution. If you didn’t start the simple axis2 server from the Axis2/C VC solution you need to have a VC project for the service that you have written. In the service’s VC project go to debug menu and choose attach to process. In “attach to process” dialog box choose the simple_http_serve.exe.

Put some break points in the service’s files and send a request to the service. If the service is loaded correctly by the Axis2/C, you must be able debug the service.
The above process is similar in tcp server as well.

Apache Server

Follow the instructions in the Axis2/C manual to install Axis2/C with the Apache server. Start Apache server by giving the –X option. This will force Apache not to create threads in Windows and it will ease the debugging process.
$ httpd.exe –X
Then again go to the Axis2/C VC solution or the service VC solution and from the debug menu choose attach to process. Choose the httpd.exe from attach to process dialog box. Put some break points in the service and send a request to the service. If everything goes well the break points should be hit.

IIS

With IIS server the process is almost same as with the Apache server. Deploy Axis2/C in the IIS following the guidelines in the Axis2/C manual. Then start IIS server.
From the VC solution (Service or Axis2/C) go to debug menu and choose attach to process.
If you are using IIS 5.1 choose the process inetinfo.exe. If you are using IIS 6 or 7 first you need to send a request to the IIS server before debugging can begin. Then choose the process W3wp.exe.
Put some break points in the service and send a request to the service.

Axis2/C Performance

2008-07-30T01:37:00.000-07:00

Axis2/C benchmark performance test results are published here

Eucalyptus Use Axis2/C and Rampart/C

2008-07-22T00:05:00.000-07:00

Today I heard about Eucalyptus(open-source software infrastructure for implementing cloud computing) from InfoQ news. It's nice to see that they use Axis2/C and Rampart/C inside it. Here is a screen shot of download page of Eucalyptus, which shows Axis2/C and Rampart/C in the list.

As a developer of Axis2/C and Rampart/C I am verry happy about this, because someone is using what we wrote. As open source developers all we want is to see others using what we have written.

Deploying Axis2/C in Apache - Common Erros

2008-07-21T03:59:00.000-07:00

One of the main deployment scenarios of Axis2/C is with Apache Web Server. Axis2/C becomes one of the best enterprise grade web web service engines when deployed in Apache and IIS. It is faster, more reliable can scale to large requests etc. When deployed in Apache server Axis2/C uses the memory pools supplied by Apache and guarantees zero memory leaks. Also due to the custom memory implementation Axis2/C can perform up to its maximum.

You can find the installation guidelines for Axis2/C in the manual page. Here I'm not going to discuss those details. Instead I will focus on the things that can go wrong when trying to deploy in Apache Server.

Axis2/C is loaded by Apache when it starts. So we use the LoadModule directive of Apache to specify the Axis2/C module which connects Apache and Axis2/C. You don't have to copy the Axis2/C module to the Apache modules directory always, but it is a good practice. You can keep it in anywhere you like and give the complete path to the LoadModule directive.

The Axis2/C Apache module depends on the Axis2/C libraries. Some of these dependencies are axis2_engine, axutil, neethi etc. So make sure that these libraries are in the library path in Linux and Path in windows. If these libraries are not in the path the module will complain that it cannot find these libraries and it will fail.

Normally Apache server is started as an unprivileged user in most of the operating systems. So make sure that it has read access to the place where Axis2/C libraries are kept and write access to the Axis2/C log file.

Axis2/C can fail due to invalid service and module configurations. Some of these are

1. A module is built with a earlier version of Axis2/C binary
2. Errors in module.xml file or module xml file doesn’t exists
3. A service is built with a previous version of Axis2/C
4. service links to a library which is not in the library path
5. Services xml is missing
6. Empty services folders

Here I’m not going to talk about the specific errors that are reported in the Axis2/C log file under these circumstances. But most of the time by looking at the log file you can figure out where the problem occurs.

Another thing with Apache is, if you don’t configure the log file correctly it will write the Axis2/C log file in to its error log.

Here I have described the most common mistakes that you can make when deploying Axis2/C in Apache web server. There may be others and you are welcome to share your experiance.

Apache Axis2/C 1.5.0 Released

2008-07-21T02:08:00.001-07:00

Key Features

1. Support for one-way messaging (In-Only) and request response messaging (In-Out)
2. Client APIs: Easy to use service client API and more advanced operation client API
3. Transports supported: HTTP
* Inbuilt HTTP server called simple axis server
* Apache2 httpd module called mod_axis2 for server side
* IIS module for server side. Supports IIS 5.1, 6 and 7
* Client transport with ability to enable SSL support
* Basic HTTP Authentication
* AMQP Transport based on Apache Qpid (Experimental)
* libcurl based client transport
4. Module architecture, mechanism to extend the SOAP processing model
5. WS-Addressing support, both the submission (2004/08) and final (2005/08) versions, implemented as a module
6. MTOM/XOP support
7. AXIOM, an XML object model optimized for SOAP 1.1/1.2 messages; This has complete XML infoset support
8. XML parser abstraction
* Libxml2 wrapper
* Guththila pull parser support
9. Both directory based and archive based deployment models for deploying services and modules
10. Description hierarchy providing access to static data of Axis2/C runtime (configuration, service groups, services, operations and messages)
11. Context hierarchy providing access to dynamic Axis2/C runtime information(corresponding contexts to map to each level of description hierarchy)
12. Message receiver abstraction
* Inbuilt raw XML message receiver
13. Code generation tool for stub and skeleton generation for a given WSDL (based on Java tool)
* Axis Data Binding (ADB) support
14. Transport proxy support
15. REST support (more POX like) using both HTTP POST and GET
16. Comprehensive documentation
* Axis2/C Manual
17. WS-Policy implementation called Neethi/C, with WS-SecurityPolicy extension
18. TCP Transport, for both client and server side

Changes Since Last Release

1. AMQP Transport support with Apache Qpid. (At an experimental stage and not working under Windows)
2. Modifications to IIS Module to support IIS 6 & 7.
3. Added a JScript file to automate IIS module registry configuration
4. Specifying the MEP in the services.xml for non in-out messages made mandatory
5. Improved the in-only message handling
6. Improvements to Guthtila for better performance
7. Improvements to TCPMon tool
8. Memory leak fixes
9. Many bug fixes

Axis2/C Deployed in IIS Family - My First Article

2008-07-14T22:07:00.000-07:00

The first article I have written is now published! The article is about how Axis2/C is connected with IIS. If you are interested in learning technologies like ISAPI and how these can be used in a real production environment you can read here. http://wso2.org/library/3799

Top ten reasons for using Axis2/C over other Web Services Engines

2008-06-20T01:45:00.001-07:00

1. Axis2/C is written in C. So it is fast. Also it uses the pull model of XML parsing (StaX) which gives good performance in client server applications.
2. Support for different platforms. Linux, Windows, MacOS.
3. Tight integration with Apache2 Web Server and it supports Microsoft IIS 5, 6 & 7.
4. Complete support for WS-* specifications.
WS-Addressing
WS-ReliableMessaging
WS-Security
WS-Eventing
WS-Policy
5. Highly Customizable. Anyone can write their own modules to extends the functionality of Axis2/C
6. Support for different transports (http, amqp, tcp)
7. The exccellent support given by the Apache Axis2/C developer community allows you to solve all the user problems in a very short time.
8. It is open source and goes under Apache license so you can do virtually anything with it.
9. This is the underlying Web Service Engine behind WSF/PHP WSF/Ruby WSF/Perl which enables web services to be written and consumed in the PHP, Ruby and Perl.
10. Last but not least: I'm a developer in Axis2/C! So try it out!

Interesting performance results

2008-06-19T22:06:00.000-07:00

Recently we have done performance tests on Axis2/C with Apache Web Server. Axis2/C can be considered as a dynamic content generator when it is behind a web server. The interesting thing is about the performance results. We used Apache "ab" for generating the requests and Benchmark Service as the service.

For small request/responses Axis2/C was running around 12000 req/s and for large request/responses Axis2/C was running around 4000 req/sec.

We have done a very interesting thing as well. We put the SOAP message as static XML file into the server and we tested the performance of the Apache server with static content. The results were surprising!!. Apache handled around 16000 req/sec for small files and 9000 req/sec for the large files. Here the request was a GET request(server has to process one line). In the case of Axis2/C the request and response are same size and request was a POST request. So effectively the work that needs to be done by the Apache is doubled in our case. But as you can see the performance differences are not that high!

There should be another reason behind this performance results. May be we are missing something. There are so many variables in this equation we might not find a answer soon.

Developers quick start guide for Axis2/C - Windows

2008-06-16T03:43:00.000-07:00

There are lots of developers who are using Axis2/C for creating and consuming web services in their software projects. There are various user requests for creating a quick start guide for Axis2/C. Here I will explain how to start things in the Windows operating systems.

Here I assume you are using Microsoft Visual Studio 2005 as it is the only supported development environment for Windows in Axis2/C.

The VC project for Axis2/C can be found in the ides/vc/axis2c/deploy directory. Solution name is axis2c.sln. Double click the axis2c.sln or open it from the Visual Studio file menu.

I will explain each of the projects in the build order. All these separate projects will be ultimately compiled into a dll or an exe.

axutil
This project contains the basic utility functions required by axis2/c. For example it contains functions like logging, error handling, string operations, lists, hash maps, qnames, date time formats etc. This library is linked to every other library and every web service and client written for axis2/C.

Guththila
Guththila is the XML parser for Axis2/C. Axis2/C can be built to use the third party XML parser libxml2 as well. Guththila is linked to the axutil and used by axis2_parser only. Users are not required and not encouraged to use this library directly. Instead they should use the Axiom/C library for processing XML.

axis2_parser
Axis2/C provides a parser abstraction layer. This is that parser abstraction layer. This library links to either guththila or libxml2 depending on what the user wants.

axiom
This is the XML model layer provided by Axis2/C for manipulating XML. Axiom/C is build according to the pull model of XML parsing.

Neethi
This is the Web Services policy implementation for Axis2/C. This has the Web Service Security policy implementation as well. Moving the security policy stuff in to the Rampart/C space is a todo in Axis2/C.

axis2_engine
This project encapsulates the main functionalities of Axis2/C. So this is the core of Axis2/C. Every service and client should linke to this library.

axis2_http_sender and axis2_http_receiver
This two are the http senders and http receivers of the Axis2/C engine. They are linked to axis2_engine. Axis2/C supports plugging of various transport senders and receivers. Best example is tcp senders and receivers.

axis2_mod_addr
This module implements the WS-Addressing specification. This is a module for Axis2/C and it connects to the Axis2/C via the handlers interface.

mod_axis2
This is the Axis2 module for Apache web server. This module is used to connect Axis2/C and Apache web server. When Axis2/C is deployed in Apache server, Axis2/C services are served via the Apache server. Client side of Axis2/C has nothing to do with this.

mod_axis2_iis
Same as mod_axis2, instead of the Apache Web Server this module connects Axis2/C and Microsoft Internet Information Server (IIS).

axis2_simple_http_server
This is the simple http implemented by Axis2/C for for http transport. User can use this server instead of IIS or Apache for deploying their services. But its main purpose is to serve as a development tool. If you want to debug your services this is the easiest way. You cab do this by setting this project as the startup project and run the debugger. Also note that the workign directory of this project must be set to ides\vc\axis2c\deploy\bin

axis2_tcp_server, axis2_tcp_sender and axis2_tcp_receiver
These are equivalents of axis2_http_sender, axis2_http_receiver and axis2_http_server for TCP transport.

tcpmon
This is a tool which can show tcp messages. This can be used as a debugging tool to see the actual messages that are going in the wire.

services folder
This folder contains the sample service projects that ship with Axis2/C.

clients folder
This folder contains the sample clients that ship with Axis2/C.

When the Axis2/C solution is built Axis2/C is built in to the ides\vc\axis2c\deploy directory. Also make sure that AXIS2C_HOME and PATH variables are set to {AXIS2C_SOURCE_DIST}\ides\vc\axis2c\deploy and {AXIS2C_SOURCE_DIST}\ides\vc\axis2c\deploy\lib directories. Set the axis2_http_server as the startup project and set the working directory of this project to {AXIS2C_SOURCE_DIST}\ides\vc\axis2c\deploy\bin. Then start the debugger.

By default the axis2_http_server runs on port 9090. You can change this by specifying the command line argument -p PORT. You can also set the log level by using the command line option -l{LOG LEVEL}. By default the log is set to debug and you can change it to critical by specifying -l0.

Axis2/C VC project doesn't copy the include files in to the deploy directory. So you have to manually copy them to the deploy directory in case this is used as a development distribution for other projects.

Debugging with IIS server

First you need to setup the IIS server for loading Axis2/C as described in the Axis2/C manual. Make sure that mod_axis2_IIS is the startup project. Then go to debug->attach to process and in the dialog box select the IIS process. For IIS 5.1 this is inetinfo.exe and for IIS 6 and IIS 7 this is w3wp.exe. If Axis2/C is properly loaded by IIS this will allow you to debug Axis2/C under IIS.

Debugging with Apache Server

The instructions are same as IIS server. You need to make the mod_axis2 as the startup project. When doing the attach to process, Apache process name is httpd.exe.

IIS 6 & 7 Support for Axis2/C

2008-06-12T04:19:00.000-07:00

Now Axis2/C Supports IIS 6 and 7 at a more deeper level than it was before. Previously Axis2/C and IIS was connected by a ISAPI Filter + ISAPI Extension. Now Axis2/C integrates with IIS only through a ISAPI Extension. The extension is a Wild Card Map and it intercepts all the incoming requests.

Instructions to connect Axis2/C and IIS.

All the instructions that are in the Axis2/C manual up to the register variable are same. These are the new steps to connect Axis2/C and IIS.

IIS 6 & 7

Using the IIS management console, add the mod_axis2_IIS.dll as a Wildcard Script Map.
Executable should be the complete path to the mod_axis2_IIS.dll
You can put any name as the name of the Wildcard Script Map

Please don't add the mod_axis2_IIS.dll as a filter to IIS as in the IIS 5.1 case.

Note: If the Axis2/C failed to load, verify that Axis2/C and its dependent DLLs are in the System Path (not the user path).

Federated Sign-Out

2008-04-25T05:34:00.000-07:00

In the context of Federated Identity ecosystem, when a participant entity (requester or ‘principal’) decides to terminate the Single Sign On (SSO), there should be a mechanism to flush all the cached data and completely terminate the session.

Federated sign-out mechanisms designed to indicate to federation participants that a particular federation is being terminated and they may want to clean up any cached state or security tokens for a principal that are no longer required because the principal's session is being terminated. And the federated sign-out applies to all tokens and all target sites for the principal within the federation.

The implementation of federated sign-out should based on the concept of parallel distribution of the sign-out message. As shown in following figure, the initiator of sign out message is the requester (most of the common scenarios). Therefore, when the principal decides to sign-out, it sends the messages to its STS, indicating that the requester is initiating a termination of the SSO. The Principal’s STS is responsible for federating the sign-out message that is received from the requester.

The mechanism that is used to facilitate the federating process of the sign-out message is defined under WS-Eventing. The other participants of the federated realms (i.e. other than requester and its STS) want to receive Single Sign-Out messages when requester decides to sign-out from SSO (i.e. events occur). A mechanism for registering interest of receiving Sign-Out Messages is needed because the set of Web services interested in receiving such messages is often unknown in advance. WS-Eventing defines a protocol for other entities (subscribers: Other than Principal and its STS) to register interest of receiving a Sigh-Out Message (subscription) with Principal’s STS (Single Sign-Out Notification end-point which can be acquired at the initial configuration process that is related to Federation Metadata) in receiving sign-out messages about federated sign out of the requesters (notifications/event messages).

Top Axis2/C Articles

2008-04-04T04:31:00.000-07:00

Introducing Apache Axis2/C - In this article, Apache Axis2/C project lead Samisa Abeysinghe gives some inside details about features of Axis2/C and architecture of Axos2/C.
Flows, Phases, Handlers, and Modules - Apache Axis2/C project lead Samisa Abeysinghe describes heart of the Axis2/C Architecture.
Apache Axis2/C, Web Services engine - This article by Samisa Abeysinghe explains how Apache Axis2/C stands out as the most complete Web services engine implementation in C.
Enabling Web Services by Embedding Axis2/C - Apache Rampart/C project lead, Kaushalye Kapuruge in this article does a fantastic job in explaining how to embed Axis2/C in your platform to enable Web services. He uses a Axis2/C's PHP and AJAX extensions to demonstrate adding Web services capability to any C based platform.
Implementing libcurl based HTTP Transport in Apache Axis2/C - This article by Dinesh Premalal carries implementation details about libcurl based HTTP transport.
Web Service End Points with Apache Axis2/C - Samisa Abeysinghe, current project lead of the Apache Axis2/C gives to you a detailed descriptions on customizing the endpoint address format of hosted services via Axis2/C, the Web services engine for providing and consuming Web Services in C.
Introduction to Axis2/C Service Client API - In this article by Dinesh Premalal, he introduces Axis2/C Service Client API for the beginner.

Limits in Key Management of Rampart/C

2008-04-02T21:33:00.000-07:00

At the moment Rampart/C has a static configuration of certificates and private keys though configuration. That means the service writer has to specify his own certificate, private key, receivers certificate and password for obtaining the private key in a static configuration file.

This configuration limits the service from serving multiple clients. The service writer can only specify one receiver certificate file. That implies the server can verify signatures from only one client. If server uses signature as a user confirmation method this implementation doesn't take you that far.

The solution is to use key stores for key management. At the moment work is underway to implement pkcs12 key store for Rampart/C. I will give you more information on that later.

Axis2/C and Apache Memory Pools

2008-04-01T22:01:00.001-07:00

Axis2/C works with Apache2 as a module to the web server. Apache server provides various functionalities to its modules with Apache Portable Runtime (APR) library. Apache Memory pools is one such important functionality.

Axis2/C uses apache memory pools for automatic memory handling. When a request comes to Axis2/C the allocation and free functions in Axis2/C is set to the Apache memory pool functions. Axis2/C uses the Apache request pool allocation and free functions for single requests. The memory allocated using the request has the scope of a HTTP request. When used with Apache there is an interesting thing happening in Axis2/C. Axis2/C has a increasing memory consumption when used with Apache. But it has zero memory leaks and steady memory consumption when used with the standalone http server.

It seems that Apache server doesn't free its request pools regularly. This is the only conclusion that we can arrive at with the information at hand. But I think it is worth a try to look in to this to find out weather this is an Axis2/C bug or not.

Is it possible to wrap a SAX XML parser to a be StaX XML parser

2008-03-31T23:25:00.000-07:00

I personally believe that it is a very hard thing to do if not impossible. The issue is that SAX parsers tend to control the XML parsing and StaX parsers tend to give the control of XML building to the user. These are completely different paradigms.

First I will describe a StaX XML parser API.
Usually there is a method to parse the next XML entity. When this method is called the parser parse the next XML entity (i.e XML start element, end element, character data) and return a event corresponding to the parsed XML entity. It is the responsibility of the user to collect the relevant information for that event. i.e if the event is start element then user can query the local name, prefix etc.

In SAX parsing user registers functions for various events like start element, end element, text etc. When the parsing started and parser encounter an entity related to a registered function (i.e start element) it calls the registered function with the information required.

So as we can clearly see the two methods are completely different.

Rollback the Subversion Repository to Previous Revision

2008-03-31T04:13:00.000-07:00

This afternoon we accidentally commit some changes to trunk which must go to scratch area. If any of you do such thing this is how we rollback it to previous revision.

1. First find the last revision before your revision using "svn log" command or if you are in windows using your favorite svn tool.

2. Then merge the HEAD revision with the previous revision which is the one before your commit.
You can use svn merge -rHEAD:previous_revision command to do it on Linux command line. If you are in windows use Tortoise SVN's merge wizard to merge it.

3. After merging with last good revision, commit the changes.

Apache Axis2/C 1.2.0 Released

2008-01-18T06:47:00.000-08:00

Apache Axis2/C team has announced the release of Axis2/C 1.2.0 version. You can download this from http://ws.apache.org/axis2/c/download.cgi.

Key Features:
1. Support for one-way messaging (In-Only) and request response messaging (In-Out)
2. Client APIs: Easy to use service client API and more advanced operation client API
3. Transports supported: HTTP

Inbuilt HTTP server called simple axis server

Apache2 httpd module called mod_axis2 for server side

IIS module for server side

Client transport with ability to enable SSL support

Basic HTTP Authentication

libcurl based client transport

4. Module architecture, mechanism to extend the SOAP processing model
5. WS-Addressing support, both the submission (2004/08) and final (2005/08) versions, implemented as a module
6. MTOM/XOP support
7. AXIOM, an XML object model optimized for SOAP 1.1/1.2 messages; This has complete XML infoset support
8. XML parser abstraction

Libxml2 wrapper

Guththila pull parser support

9. Both directory based and archive based deployment models for deploying
services and modules
10. Description hierarchy providing access to static data of Axis2/C runtime
(configuration, service groups, services, operations and messages)
11. Context hierarchy providing access to dynamic Axis2/C runtime information
(corresponding contexts to map to each level of description hierarchy)
12. Message receiver abstraction

Inbuilt raw XML message receiver

13. Code generation tool for stub and skeleton generation for a given WSDL
(based on Java tool)

Axis Data Binding (ADB) support

14. Transport proxy support
15. REST support (more POX like) using both HTTP POST and GET
16. Comprehensive documentation

Axis2/C Manual

17. WS-Policy implementation called Neethi/C, with WS-SecurityPolicy extension
18. TCP Transport, for both client and server side

Major Changes Since Last Release

1 Improvements to Java tool, WSDL2C, that generates C code
2 Improvment to Apache2 module so that it

Create a shared memory global pool

create context hierarchy in the global pool

enabling it to have true application level scope.
3 Improved Policy
4 Improvements to thread environment
5 Improvements to error handling
6 Memory leak fixes
7 Many bug fixes

Rampart/C 1.1 Released

2008-01-16T21:26:00.000-08:00

Apache Rampart/C Team has announced the release of Apache Rampart/C 1.1 version.
You can download this release from http://ws.apache.org/rampart/c/download.cgi.

Key features of the release
1. Ability to send and verify UsernameTokens with
- Username and PlainText password
- Username and Digested password
2. Ability to send Timestamp tokens
3. SOAP message encryption
- With derived key support for improved security
- Symmetric and Asymmetric modes of operations
- Support for AES and Tripple DES encryption
- Signature encryption
- Keys encryption
4. SOAP message signature
- XML signature with RSA-SHA1
- Message authentication with HMAC-SHA1
- Signature confirmation support
- SOAP Header signing
5. WS-Security Policy (spec 1.1) based configurations
- Support for both Symmetric as well as Asymmetric policy bindings
- Support for different modes of key identifiers
- Support for different algorithm suites [Basic128, Basic 192, Basic256, TrippleDES, Basic128Rsa15,Basic192Rsa15,Basic256Rsa15, TripleDesRsa15]
6. Replay detection support
- Easy to use built-in replay detection module
- Ability to deploy a customized replay detection module
7. Different protection orders
- Encrypt before signing
- Sign before encrypting
8. Extensible modules
- Password callback module
- Authentication module
- Credentials module
9. Keys management
- Support for X509 token profile
- Support for Key identifiers, Thumb prints, Issuer/Serial pairs,Embedded and Direct references
10. Other
- Easy to use deployment scripts
- A comprehensive set of samples

Major Changes Since Last Release
1. MAC support with HMAC-SHA1
2. Derrived key encryption
3. Derived key signing
4. Symmetric policy bindings
5. New security header processor based on SOAP header layout
6. Security policy validator
7. Extensible Replay detection module
8. Signature confirmation support
9. Support for X509 thumb prints
10. Easy to use deployment scripts
11. Memory leak fixes
12. Many bug fixes

How to get the root node of an axiom node?

2008-01-16T20:06:00.000-08:00

This is trivial, but most of the people find it difficult to and some may think axiom doesn’t support this. So I thought I should explain how to do it.Every axiom node has a field called parent node. This field can be accessed via the axiom_node_get_parent method. I use that function to get the root node of a given axiom node.


axiom_node_t * get_root_node(const axutil_env_t *env, axiom_node_t *scope)
{
  axiom_node_t *p = NULL; 
  axiom_node_t *root = NULL;
  p = scope; 
  do{
      root = p;
      p = axiom_node_get_parent(root, env);
  }while (p);
return root;
}

Here I have used the property: parent node of the root node is null.

Beginners guide to Axiom/C

2008-01-14T01:14:00.001-08:00

Axiom is an XML object model written for the Axis2/C engine. The object model is based on the pull model of XML parsing. Because of that we can use the axiom object model on partially parsed XML documents. Axis2/C web service engine is heavily dependent on this very important component.
Every web service or client developer who uses the Axis2/C engine should be aware of the Axiom/C object model. The model consists of many important structures. Axiom/C works by creating, populating and querying these structures. I’ll explain some of the most important ones as we go on.
When using Axiom we can create the Axiom/C object model programmatically or using an XML document. I will explain the latter case first.
First thing to do is creating an axiom_xml_reader_t object. According to the source that we are going to use for reading the XML we have to change the creation method. Axiom_xml_reader can read XML objects from three types of sources,

File
Memory Buffer (char buffer)
From a call back function

In the example given it is created for reading a XML file.
The next step is to create an axiom_stax_builder_t object using the previously created reader. The actual Axiom object model is done using the axiom_stax_reader. As I have mentioned earlier we can use this to build the object model to the extent that we want.
Then the next step is to get the axiom_document_t object in the stax_builder object. Axiom document hold a pointer to the root element of the object model. It has some other information like the character encoding of the XML document, XML version used.
Then there are two options for us. We can build the whole document at once or build it as we like. But most of the time client and service writers build the whole XML document at once. So I will explain that part only and I will explain the partial building in another tutorial. The method for building the complete Axiom abject model is axiom_document_build_all. Note this method returns the root element of the axiom model.


axiom_xml_reader_t *r = NULL;
axiom_stax_builder_t *sb = NULL;
axiom_document_t *doc = NULL;
r = axiom_xml_reader_create_for_file(env, file, NULL);
if (r)
{
    sb = axiom_stax_builder_create(env, r);
    if (sb)
    {
        doc = axiom_stax_builder_get_document(sb, env);
        if (doc)
        {
            return axiom_document_build_all(doc, env); 
        }
    }
}

In the case of a XML string buffer we need to use the axiom_xml_reader_create_for_memory and this is same for callback readers. Note arguments for these methods are different. Now we know how to build the object model from a XML source like file or memory.
The next thing is to get the required information from this object model in memory. In doing so the most important structure is axiom_node_t. Axiom object model is a tree and nodes of this tree are constructed from axiom_node_t structure. You can see that the axiom_document_build_all returns a pointer to axiom_node_t structure. In other words root node of the tree is an axiom_node_t, so as the rest of the tree.
Every node carries a payload and this payload can be a XML element, XML comment or text. There are other possibilities as well. But these are rare in web services scenarios. When we are presented with an axiom_node_t there is a way to know what the payload it carries. Method call axiom_node_get_node_type returns the integer value for the paylod containin in the node. Following table shows some of the common return values and there meaning. Note the return values are defined in as an enum called axiom_types_t.

AXIOM_ELEMENT: The node is a carries a pointer to axiom_element_t structure. This structure contains all the information relavant to that XML element like attributes, namespaces, local name, prefix.

Actually when I start that table I thought of filling it with sevaral rows. But AXIOM_ELEMENT is the only meaning full and usefull return type I had encountered.
Now lets look at various ways of traversing the Axiom tree. Here traversing tree ultimately becomes traversing the axiom_node_t structures. So every time we are given axiom_node_t objects to traverse and allmost evry time these node are of the type AXIOM_ELEMENT.
Before doing anythinf we have to get the element in the axiom node.


axiom_element_t *element = NULL;
if (axiom_node_get_node_type(node, env) == AXIOM_ELEMENT)
    element = (axiom_element_t *)axiom_node_get_data_element(node, env);

Retrieving the Basic information

Then we can use this axiom element to access all the required details. To get the local name of the element we can use the


name = axiom_element_get_localname(element, env);

Method and similarly we can get the namespace by calling the method.


namespace = axiom_element_get_namespace(element, env);

All these methods can be seen in the axiom_element.h.

Retrieving the Attributes
The next important thing is getting the attributes of this element. There are various ways to do this as well.
If you know the attribute name you can directly call the


attr_name = axiom_element_get_attribute_value_by_name(element, env, “A”);

Or if you know the namespace and local name of the attribute (qualified name) you can call the


axutil_qname_t *qname = axutil_qname_create(env, “A”, http://uom.com, NULL);
attr_name = axiom_element_get_attribute_value(element, env, qname);

Note that the third argument is a pointer to axutil_qname_t structure. This structure holds the qualified name of the attribute. You can see before calling the attribute retrieval method we are creating a axutil_qname_t object.
If you want to go through all the attributes and you don’t know the names you can use the hash returned by the axiom_element_get_all_attributes method.


attr_hash = axiom_element_get_all_attributes(element, env);
for (hi = axutil_hash_first(attr_hash, env); hi; hi = axutil_hash_next(env, hi))
{
    void *v = NULL;
    axutil_hash_this(hi, NULL, NULL, &v);
    if (v)
    {
        axis2_char_t *attr_val = NULL;
        axiom_attribute_t *attr = (axiom_attribute_t*)v;      
        attr_val = axiom_attribute_get_value(attr, env);
     }
}

Here the values containing in the hash are axiom_attribute_t structures. You can use the methods in axiom_attribute.h to query the attribute.
Accessing the Child Elements
If you are not interested in the qualified names of the child elements that you want to deal with you can use the axiom_children_iterator_t structure. This structure can be retrieved by calling the axiom_element_get_children method.


axiom_children_iterator_t *it = axiom_element_get_child_elements(element, env, node);
if(it)
{
    while(axiom_child_element_iterator_has_next(it, env))
    {
        child_node = axiom_child_element_iterator_next(it, env);
    }
}

The next case is when we want to get the only the child elements with specific qualified names. Here the concept is same as above but we have to use axiom_children_qname_iterator_t struture with the axiom_element_get_children_with_qname method.


axutil_qname_t *qname = axutil_qname_create(env, “ElementName”, http://uom.com, NULL);
axiom_children_qname_iterator_t *qit = axiom_element_get_children_with_qname (element, env, node);
if(it)
{
    while(axiom_children_qname_iterator _has_next(it, env))
    {
        child_node = axiom_children_qname_iterator_next(it, env);
    }
}

We can traverse the elements using only axiom_node_t methods as well. But this is little bit difficult than the above two methods and hense I’ll skip it this time.
In this article I tried to show only the most popular methods used for creating and traversing axiom object model. If you have any doubts or comments please feel free to contact me or you can directly ask from the axis2/c user list or development list.

Richard Stallman's visit to Sri Lanka

2008-01-13T06:00:00.000-08:00

SAML Token Support for Rampart/C –Overview

2007-12-02T19:10:00.001-08:00

Security Assertion Markup Language is becoming the de-facto standard for exchanging security information. SAML is a XML based language defined by the OASIS and at the moment two major versions of SAML are in use. They are SAML 1.1 and SAML 2.0 specifications. Rampart SAML implementation is based on the SAML 1.1 specification.
SAML 1.1 consists of three major parts and they are

1. SAML assertions
2. SAML protocol
3. SAML bindings

SAML assertions are in the heart of the SAML specification, because the other two parts i.e. SAML protocol and SAML binding define how to get and transfer SAML Assertions through many transport mechanisms. The SAML implementation both supports SAML Assertions and SAML protocol.

A SAML assertion consists of Conditions and Statements. Conditions specify various things under which the assertions should be evaluated. Statements provide claims about subjects. A single assertion can have multiple statements as well as conditions in it.

Some statements are Authentication Statement, Attribute Statement and Subject Statement. Authentication statement provides a subject’s authentication information in a system. It includes information like the authentication method used i.e. username/password; the time at the authentication took place etc. Attribute statements can carry information about a subjects properties in XML form. Subject statements are for carrying information about the subject like e-mail address, domain name, and XML signature key information regarding the subject.
Basic idea behind the SAML implementation is to provide the necessary mechanisms to process and construct SAML Assertions based on the Axiom/C XML object model.

The basic pattern of the SAML is very simple. Each and every SAML important data structure is captured as a data structure. To use SAML you have to either build the object model from a XML node or build it programmatically.

If you are going to build the model from a XML node the most important method is the build method. For example to build a SAML assertion the method you have to use is

AXIS2_EXTERN int AXIS2_CALL
saml_assertion_build(saml_assertion_t *assertion,
axiom_node_t *node, axutil_env_t *env)

This pattern is common to every other structure in the SAML model. Then you can use the public methods available for querying the information required from the object model.
If you are going to build the model programmatically, first you have to specify all the information using the public methods available. Then you can use the method to construct an axiom node from the object model.

AXIS2_EXTERN axiom_node_t * AXIS2_CALL
saml_assertion_to_om(saml_assertion_t *assertion,
axiom_node_t *parent, axutil_env_t *env)

WS-Federation in Service Oriented Business World

2007-11-27T01:49:00.000-08:00

WS-Federation is one of the immerging technologies in the Service Oriented World. The power of WS-Federation in the context of WS-Security related web services can be used to fulfill the sophisticated business requirements of the modern business entities. The necessity of a ‘Federation’ among business entities is a typical requirement in the situations where business entities and their partners are co-related based on web services and securely exchanging sensitive data among different or like realms.

The growth of partnerships into seamless e-business networks is one of the most significant trends in the evolution of SOA based Internet Commerce. Some of the most successful global enterprises have achieved a very high level of coordination (or Federation based on security) between their own ICT systems and those of their customers, suppliers and business partners. This coordination is being used to differentiate solutions, reduce costs and improve speed and agility. In business-to-consumer scenarios where consumers communicate with an enterprise that presents products or services from multiple partners simultaneously, access to shared resources must be secure and structured to meet the requirements of each partner in the business relationship, while meeting the consumer's needs. In application-to-application or business-to-business environments where Web services are increasingly used, remote or partner access to corporate data and applications must be achieved securely and seamlessly. For example following scenario (figure 1) illustrates the federation of the business entities. The main business entity of the scenario is Fabrikam Inc. and other entities are the business partners of Fabrikam.

Effective identity federation benefits both users and enterprises. It provides end users with a seamless cross domain experience through single sign-on (SSO) and it enables enterprises to expose resources to a larger class of users not directly administered by the enterprise.

The development of Federated web services can be based on a WS-Federation framework and the user (web service developer) has to customize it according to the specified needs. A complete WS-Federation framework is designed to meet and fulfill the following business requirements.

Provide a framework built on industry standards (data format and message structure) that are independent of specific implementations (client type or server type) and network protocols

Provide the ability for business partners to exchange information about their users in a secure way

Protect the privacy of users within a federation, i.e., keep user identity information secret

Allow each company in a federation to manage the identities of their own users without relying on a centralized third-party

Support standard security information descriptions or use existing standard security tokens

Support a standard protocol to exchange security tokens amongst federation participants

Provide a way to establish trust amongst federation participants

A WS-Federation framework (FEDi-which is based on WS-Federation and WS-Trust open standards) for Apache Axis2/C is currently under development.

Web Service Trust Practical Scenario

2007-11-01T22:25:00.001-07:00

WS-Trust can be expressed using above practical scenario. The relevent message formats that exchange among the business parties are illustrated below.

Request Security Token (RST)

The RST message content is digitally signed by the Requestor. (with hash and his private key)

Encrypt the signed content by the public key of the Department of Driving License.

Request Security Token Response (RSTR)

Obtain the session key for the trust session
Encrypt the session key with the public key of Online Wine Shop
Find and set the claims that are requested
Digitally signed the content (Claims + Encrypted session key) (with hash & private key)
RSTR is consists of both the security token (SAML in this case) and proof token.

Returning the Security Token to Relying Party

Obtain the session key for the trust session, and decrypt the service request (e.g. ‘buy wine x’) and obtain the service request.

Adding your own headers to out going soap message in the service level using Axis2/C

2007-10-18T02:24:00.000-07:00

WS-Trust specification describe a way to send requested security token in the soap header. So we need a way to add custom header while we are in the Axis2/C service level. This is our solution for that problem. I think, this will be helpful to anyone how want to add custom headers to soap message while in the service level(not to go for something like handlers).

First you need to create a soap envelope using axiom_soap_envelope_create function. Then you need to create soap header using created soap envelope as the parent (axiom_soap_header_create_with_parent). Then add a header block to that header using axiom_soap_header_add_header_block function.

After adding the header block you need to get the base axiom node from it using axiom_soap_header_block_get_base_node function. You can add whatever the content you want inside your custom header block.

Also you need to create the soap body using axiom_soap_body_create_with_parent function and add the payload to body using axiom_soap_body_add_child function.

Finally you have to set the outgoing soap envelope using axis2_msg_ctx_set_soap_envelope function.

You can downloaded the edited version of echo_skeleton.c file which comes with Axis2/C samples from this link.

Here is the changes we have to made inside invoke function of service skeleton:


axiom_node_t *AXIS2_CALL
echo_invoke(
   axis2_svc_skeleton_t * svc_skeleton,
   const axutil_env_t * env,
   axiom_node_t * node,
   axis2_msg_ctx_t * msg_ctx)
{
   /* Invoke the business logic.
    * Depending on the function name invoke the correct impl method.
    * We have only echo in this sample, hence invoke echo method.
    * To see how to deal with multiple impl methods, have a look at the
    * math sample.
    */
   axis2_op_ctx_t *op_ctx = NULL;
   axis2_msg_ctx_t *in_msg_ctx = NULL;
   axiom_soap_envelope_t *soap_env = NULL;
   axiom_soap_envelope_t *ret_soap_env = NULL;
   axiom_namespace_t *ns_soap = NULL;
   axiom_namespace_t *my_ns = NULL;
   axiom_soap_header_t *header = NULL;
   axiom_soap_header_block_t *header_block = NULL;
   axiom_node_t *header_block_node = NULL;
   axiom_node_t *header_child_node = NULL;
   axiom_element_t *header_child_ele = NULL;
   axiom_soap_body_t *body = NULL;

   op_ctx = axis2_msg_ctx_get_op_ctx(msg_ctx, env);
   in_msg_ctx = axis2_op_ctx_get_msg_ctx(op_ctx, env, AXIS2_WSDL_MESSAGE_LABEL_IN);
   soap_env = axis2_msg_ctx_get_soap_envelope(in_msg_ctx, env);
   ns_soap = axiom_soap_envelope_get_namespace(soap_env, env);
   ret_soap_env = axiom_soap_envelope_create(env, ns_soap);

   my_ns = axiom_namespace_create(env, "http://think2ed.blogspot.com", "tbc");
 
   header = axiom_soap_header_create_with_parent(env, ret_soap_env);
   header_block = axiom_soap_header_add_header_block(header, env, "myCustomHeader", my_ns);
  
   header_block_node = axiom_soap_header_block_get_base_node(header_block, env);
   header_child_ele = axiom_element_create(env, header_block_node, "MyCustomChild", my_ns, &header_child_node);
   axiom_element_set_text(header_child_ele, env, "My Custom Header Content", header_child_node);

   body = axiom_soap_body_create_with_parent(env, ret_soap_env);
   axiom_soap_body_add_child(body, env, axis2_echo_echo(env, node));

   axis2_msg_ctx_set_soap_envelope(msg_ctx, env, ret_soap_env);   

   return axis2_echo_echo(env, node);
}

Additional header files which needs to add are in the above mentioned file. Important thing is you need to add the soap body. Otherwise this code will not generate the correct soap message.

Accessing incoming SOAP Envelope inside the service skeleton's invoke method

2007-10-18T01:09:00.000-07:00

While we were working on the WS-Trust implementation for Rampart/C, we had to access the incoming soap envelope. We first try to invoke the axis2_msg_ctx_get_soap_envelope on the message context given as a parameter to invoke function. But it returns a NULL. After some discussions we figure out that the message context given is out message context and at this phase of the service the out soap envelope is null in out message context.
To access the incoming soap envelope, first we need to get the operation context from the out message context using axis2_msg_ctx_get_op_ctx function. Then we need to get the in message context from operation context. After above step you can directly access the incoming soap envelope from the in message context.


axiom_node_t* AXIS2_CALL
trust_sts_invoke(axis2_svc_skeleton_t *svc_skeleton,
        const axutil_env_t *env,
        axiom_node_t *node,
        axis2_msg_ctx_t *msg_ctx)
{
    axis2_op_ctx_t *op_ctx = NULL;
    axis2_msg_ctx_t *in_msg_ctx = NULL;
    axiom_soap_envelope_t *soap_env = NULL;
    axiom_node_t *base_node = NULL;
    
    op_ctx = axis2_msg_ctx_get_op_ctx(msg_ctx, env);
    in_msg_ctx = axis2_op_ctx_get_msg_ctx(op_ctx, env, AXIS2_WSDL_MESSAGE_LABEL_IN);
    soap_env = axis2_msg_ctx_get_soap_envelope(in_msg_ctx, env);

    /*Get the axiom node for soap envelope contents.*/
    base_node = axiom_soap_envelope_get_base_node(soap_env, env);

    return node;
}

SAML for Axis2/C & Rampart/C

2007-10-17T03:25:00.001-07:00

SAML 1.1 specification implementation for Axis2C and Rampart/C is in its final stages of development. The development is happening in the scratch area of the Rampart and it is still not moved to the main development area of Rampart/C. We are hoping to complete the remaining development as quickly as possible and the library will be available to the public very soon.

Understanding WS-Trust

2007-10-05T11:11:00.000-07:00

‘Trust’ is often refers to the expression between the parties that one party believe the statements made by the other parties. In the context of Web Services, a generic procedure of establishing the trusted relationship between the web services can be illustrated through a simple requestor/resource provider scenario.

The initial step of the generic WS Trust scenario is to identify the web service of the Resource Provider. (RP)

The Requestor examines the WS-SecurityPolicy statement associated with the Resources Provider’s web service. (Policy statement specifies the type and authority of security tokens that the Web service requires for massages it processes).

The Requestor can determine its capabilities (i.e. Tokens etc.) to access the Resource Providers web service by examining the Policy statements.

If the Requestor doesn’t have an acceptable token (by the RP), then the Requestor requests for an appropriate security token from an eligible Security Token Service (STS). This request is defined as RST (Request Security Token) by WS-Trust specification.

The appropriate STS can be identified from the Resource Providers policy statements.

In order to access the STS, the Requestor must have the acceptable tokens to satisfy the security credentials of the STS.

The STS issues the requested token via another message defined as RSTR (Request Security Token Response).

The Requestor, then present the acquired security token from the given STS (of RP) to Resource Provider. In the case, since the Resource Provider relying on the security tokens issued (validates, renewed, and cancelled as well) by the STS, it is often called the ‘Relying Party’.

The Resource Provider can use the same STS to validate the security token which are received from the Requestor. After the successful validation of the security tokens, the Requestor can consume the services (of RP) through the trusted, secured communication path.

Axis2/C VC project

2007-10-04T02:13:00.002-07:00

Although not very popular among developers (because most of the Axis2/C developers develop using Linux) Axis2/C source has a VC project. But this is the way to develop if you are a Windows developer. The VC project can be found in the ides/vc/axis2c folder. There are three separate VC2005 solutions available for developers. They are

· Axis2c.sln – Main VC project with the Axis2c engine
· Services/services.sln - A solution for sample services
· Clients/clients.sln – A solution for sample clients

Aixs2c.sln is the main VC solution and it comprises of several separate VC projects. These include

1. axutil
2. axis2_parser
3. axiom
4. neethi
5. axis2_engine
6. axis2_http_sender
7. axis2_http_receiver
8. axis2_http_server
9. axis2_mod_addr

A basic configuration of Axis2/C only requires above projects. Note that above list displays the build order of Axis2/C. So when building the project if there are linking errors to the Axis2C generated libraries better check the build order. So axutil should be built first and then axis2_parser and so on. A successful build of the solution will create the nessasary structure and copy the appropriate build files and other files in the ides/vc/axis2c/deploy folder.

When building the project using Axis2/C one important thing is to properly setting up the external libraries. For a basic configuration of axis2c libxml2, iconv and zlib are required. To setup these libraries and include files we can use the tools->options->projects and solutions->vc++ directories in the VC2005 IDE. The directories that we need to setup are libraries directory and include directories.

Apart from the default projects we can customize the Axis2/C build by using different projects. For example to build Axis2/C with the Guththila we need to add the Guththila project to the axis2c solution. Guththila project can be found in the guththila folder inside the axis2c solution folder. To compile with the Guhthila project we need to change the axis2_parser project to include the guththila_wrapper files. We can remove the libxml_wrapper files from the axis2_parser and add the guththila_wrapper files instead. Guththila_wrapper files can be found in the axis2c\axiom\src\parser\guththila folder.

Insiders guide to writing Axis2/C services

2007-10-02T22:22:00.000-07:00

Roughly, the service implementation of Axis2/C works as below. Engine uses the dynamic loading of DLL’s to load the service DLL’s. The dynamic DLL loading of Axis2/C requires two entry point functions present in the DLL to successfully load and unload DLLs. These functions are


AXIS2_EXPORT int axis2_get_instance(struct axis2_svc_skeleton **inst,
       const axutil_env_t *env)
AXIS2_EXPORT int axis2_remove_instance(axis2_svc_skeleton_t *inst,
       const axutil_env_t *env)

In the case of services, get_instance function should create and return a axis2_svc_skeleton structure to the Axis2/C engine. After that all the communication with the service and engine is done using this axis2_svc_skeleton structure.

axis2_svc_skeleton is a very important data structure for the Axis2/C service developers. This structure provides the interface between a service and the Axis2/C engine.

   
   /**
    * service skeleton struct.
    */
   struct axis2_svc_skeleton
   {
       /** operations of service skeleton */
       const axis2_svc_skeleton_ops_t *ops;
       /** Array list of functions, implementing the service operations */
       axutil_array_list_t *func_array;
   };

The definition of this structure can be found in the axis2_svc_skeleton.h header file. Most important field here is the ops field. The definition of the axis2_svc_skeleton_ops_t can be found in the same header file. This structure provides the entry point functions and invokation functions for the service. It is the resposibility of the service implementor to provide appropriate functions and initialize the ops structure with these function pointers.


struct axis2_svc_skeleton_ops
   {

       /**
        * Initializes the service implementation.
        */
       int (AXIS2_CALL *
               init)(
                   axis2_svc_skeleton_t *svc_skeleton,
                   const axutil_env_t *env);

       /**
        * Invokes the service. This function should be used to call up the
        * functions implementing service operations.
        */
       axiom_node_t *(AXIS2_CALL*
               invoke)(
                   axis2_svc_skeleton_t *svc_skeli,
                   const axutil_env_t *env,
                   axiom_node_t *node,
                   axis2_msg_ctx_t *msg_ctx);

       /**
        * This method would be called if a fault is detected.
        */
       axiom_node_t *(AXIS2_CALL*
               on_fault)(
                   axis2_svc_skeleton_t *svc_skeli,
                   const axutil_env_t *env,
                   axiom_node_t *node);

       /**
        * Frees service implementation.
        */
       int (AXIS2_CALL *
               free)(
                   axis2_svc_skeleton_t *svc_skeli,
                   const axutil_env_t *env);

       /**
        * Initializes the service implementation.
        */
       int (AXIS2_CALL *
               init_with_conf)(
                   axis2_svc_skeleton_t *svc_skeleton,
                   const axutil_env_t *env,
                   struct axis2_conf *conf);
   } ;

Axis2/C uses the init function pointers to initialize the service. In the current implementation this happens when the first request arrived for a service. Sevice implementators can use this method to do all their one time initializations. For example a connection to a database can be created in this method which exists through out the lifetime of the service.

The related method to the init is the free method. This method is called when the Axis/C engine is stopped. So the uninitalization canbe done in this method.

Invoke function pointer is very important as it provides the actual implementation of the buisiness logic to the service. When a request arrives, ultimately it is send to the invoke function for proccessing. The service implementor can access all the required details of the request using the axis2_msg_ctx and the axiom_node. Axiom_node provides access to the actual soap body of the request and axis2_msg_ctx provides the state and structures related to the request in the Axis2/C engine.

Apache Axis2/C 1.1.0 released!

2007-10-02T02:05:00.000-07:00

Apache Axis2/C Team has announced the release of Apache Axis2/C 1.1.0 with following key features:

1. Support for one-way messaging (In-Only) and request response messaging (In-Out)
2. Client APIs: Easy to use service client API and more advanced operation client API
3. Transports supported: HTTP
* Inbuilt HTTP server called simple axis server
* Apache2 httpd module called mod_axis2 for server side
* IIS module for server side
* Client transport with ability to enable SSL support
* Basic HTTP Authentication
* libcurl based client transport
4. Module architecture, mechanism to extend the SOAP processing model
5. WS-Addressing support, both the submission (2004/08) and final (2005/08) versions, implemented as a module
6. MTOM/XOP support
7. AXIOM, an XML object model optimized for SOAP 1.1/1.2 messages;This has complete XML infoset support
8. XML parser abstraction
* Libxml2 wrapper
* Guththila pull parser support
9. Both directory based and archive based deployment models for deploying services and modules
10. Description hierarchy providing access to static data of Axis2/C runtime (configuration, service groups, services, operations and messages)
11. Context hierarchy providing access to dynamic Axis2/C runtime information (corresponding contexts to map to each level of description hierarchy)
12. Message receiver abstraction
* Inbuilt raw XML message receiver
13. Code generation tool for stub and skeleton generation for a given WSDL (based on Java tool)
* Axis Data Binding (ADB) support
14. Transport proxy support
15. REST support (more POX like) using both HTTP POST and GET
16. Comprehensive documentation
* Axis2/C Manual
17. WS-Policy implementation called Neethi/C, with WS-SecurityPolicy extension
18. TCP Transport, for both client and server side

You can download this release from:
http://ws.apache.org/axis2/c/download.cgi

Securing the Axis2/C future

2007-08-30T21:16:00.000-07:00

The C language which is used to write the Axis2/C provides the foundations for a long standing web service engine. The language scales well in performance and scalability provided that they are being well planned at the beginning not as an afterthought. I think Axis2/C has a huge advantage over the traditions web services engines written in Java or C# like languages because of the performance characteristics.
Axis2/C is built on a good architecture which performs and scales well. But architectures are independent from the languages and when it comes to implementation and design we have to consider the language aspects as well.
An application written in C has the above advantages but to become a successful application a rock solid design and a very good implementation is required. What I meant by a rock solid design is not the whole design but there are some things that must be carefully designed. One important thing is how memory management is done.
Axis2/C doesn’t have a unified view of how memory is managed. This is very important given that Axis2/C is server software which needs to run for months without stopping. The current implementation does not have memory leaks but the handling of memory is not at a satisfactory level of a rock solid design.
Program structure is another issue that I can leads to inconsistencies. Some parts of the Axis2/C code are done in a hurry and due to that the some parts of the code is not well structured. This is not the case in majority of the code.
If we want to make the Axis2/C a long lived and successful project we have to make the base of the Axis2/C as solid as possible.

JSON – A fat free alternative to XML

2007-08-10T02:56:00.000-07:00

JSON (JavaScript Object Notation) is a lightweight data format based on the object notation of the JavaScript language. It does not require JavaScript to read or write; it is easy to parse by any language and libraries and tools exist in many languages to handle JSON.
In the context of the web services, JSON plays a significant role. Even though, there aren’t many web services based on JSON, the debate between XML and JSON was a quite interesting one.
The debate about JSON vs. XML as a data interchange format has begun in blogspace, following JSON inventor and architect at Yahoo Douglas Crockford's talk at XML 2006 JSON, the fat-free alternative to XML.
JSON is a data interchange formats whose design goals were to be textual, minimal, and a subset of JavaScript; it supports two structures: objects (unordered collections of name/value pairs) and arrays (ordered sequences of values), as well as four simple types: strings, numbers, booleans, and null.
A few arguments in favor of JSON briefed as follows.

It's simultaneously human- and machine-readable format;
It has support for Unicode, allowing almost any information in any human language to be communicated;
The self-documenting format that describes structure and field names as well as specific values;
The strict syntax and parsing requirements that allow the necessary parsing algorithms to remain simple, efficient, and consistent;
The ability to represent the most general computer science data structures: records, lists and trees.
As we compare XML and JSON in technical vise JSON has several plus points over XML but still JSON has a huge hill to climb to displace XML.

There is a ongoing project on JSON for Apache Axis2/C.

WS-Trust Coming Up!

2007-08-08T20:46:00.000-07:00

WS-Trust is a key specification in the Web services security stack. So we thought it is time to give this nice capability to Rampart/C so that users can leverage the through power of web services security.

We are undertaking this project as part of a University of Moratuwa Cource module. If everything goes well (I'm sure they will), we will be able to add this nice feature to the Rampart/C at the end of this month.

Guththila working with Rampart

2007-08-03T02:35:00.000-07:00

Rampart is the web services security implementation of Axis2/C. Rampart is a rapidly evolving project with hundreds of lines of code added everyday. We’ve encountered few problems using Rampart with Guththila XML parser and we’ve found several bugs in the Guththila code. All of these errors were simple errors such as using a wrong identifier, forgetting to set a variable to NULL etc. But we could very easily fix all of these errors and now Rampart is working with Guththila XML parser.

"Apache Axis2/C - Web Service Engine" Article

2007-07-28T01:46:00.000-07:00

Article Link : http://wso2.org/library/2406

In this article, Samisa Abeysinghe (One of the key developers behind Axis2/C) describe the Axis2/C engine. This article summarize the architectural overview, programming model, code generation, data binding, developing clients and services, and many features of Axis2/C.

Using WSDL2C Tool

2007-06-28T20:35:00.000-07:00

What is WSDL2C?
WSDL2C is a command line tool comes bundled with Apache Axis2/Java as a part of Axis2/Java Code Generation Tool.

Axis2 Code Generation tool has a core that processes the WSDL and produces a model object. Using this model object it generate XML models according to the code must be generated and parse this XML models against XSLT Templates to generate the actual code. Code Generation Engine which is the core component of the Tool simply calls the extensions one by one and then calls the component called Emitter which generates the main parts of the code. Emitters are language dependent and when developing WSDL2C Tool C language specific emitter called “CEmitter” is used. For the data binding process specific to C language component called “CStructWritter” is used. This component implements the BeanWritter interface of the Axis2 Code Generation tool and “CEmitter” implements the Emitter interface.

Currently WSDL2C tool support XML In-Out model code generation and code generation with C language specific Axis Data Binding(ADB).

Using WSDL2C
Go through following steps to use the WSDL2C Tool:

Download the Axis2 Standard Binary Distribution and extract it to your hard disk. If you want to get the advantage of latest features added to the WSDL2C tool download the latest nightly build from Axis2 download zone or get a checkout from current SVN head and build it by following steps in Axis2 manual.
The shell and batch scripts (WSDL2C.sh & WSDL2C.bat) for the WSDL2C Tool is available inside bin directory under the Axis2/C tools directory. You have to set the AXIS2_HOME variable to point your Axis2 binary distribution directory or if you build it from source, point it to your target directory inside Axis2 directory.
Add the path to the shell/batch script to your systems PATH variable and make scripts executable.

Now scripts are ready to use, you can use WSDL2C.sh in Linux or WSDL2C.bat in Windows with necessary options to generate the code to use with Axis2/C engine.

Use WSDL2C script with following options to generate server side code without data binding.
$: WSDL2C –uri –ss –sd –d none –u –f –o
Following artifacts will be visible inside the specified out put directory after code generation completed:

Service.xml
axis2_svc_skel_.c
axis2_skel_.c
axis2_skel_.h

Using WSDL2C with following options, you can generate server side code with ADB.
$: WSDL2C –uri –ss –sd –d adb –u –f –o
Following artifacts will be visible inside the service directory after the code generation:

service.xml
axis2_svc_skel_.c
axis2_skel_.c
axis2_skel_.h
source and header files for data binding with axis2_ prefix.

Source code for WSDL2C.sh

#!/bin/sh
export AXIS2_HOME=/home/axis2java
for f in $AXIS2_HOME/lib/*.jar
do
 AXIS2_CLASSPATH=$AXIS2_CLASSPATH:$f
done
export AXIS2_CLASSPATH
echo the classpath $AXIS2_CLASSPATH
java -classpath $AXIS2_CLASSPATH org.apache.axis2.wsdl.WSDL2C $*

How to configure Guththila

2007-06-28T02:36:00.000-07:00

At the moment Axis2/C supports two XML parsers and they are Guththila and libxml2. The default axis2/c source distribution comes with libxml2 XML parser. In order to use Guththila XML parser the source code must be compiled with Guththila parser enabled.

To compile with guthtila following configuration parameters must be specified.

Under Linux:

--enable-guththila=yes

Under Windows

ENABLE_GUTHTHILA = 1

For more information refer the Axis2/C installation guide

Guththila XML parser is ready to use with Axis2/C

2007-06-27T23:55:00.000-07:00

I have been developing the Guththila XML parser and was able to integrate it with Axis2/C. When it was first integrated with Axis2/C it has few problems and I have fixed them all. Another issue with integration with Axis2/C is that it uses structure called axutil_env in every function. Axis2/C keeps all the global structures like logs, custom memory allocation functions in this structure. At the begining of the project Axis2/C has taken a implementation disicion to incude a reference to this structure in every function call as an argument. My opinion is this is not a good idea at all. Anyway the axutil_env is a global structure and no point in passing a pointer to it in every function call, but implementors took that decision and we have to live with that weather we like it or not. So I had to introduce this structure to every function call and it was a nightmare.

Then there were few problems about the handling of white spaces in Guthtila. Initially my idea was to parse white spaces to Axiom as well but after intergration is done I found out that Axiom cannot handle whitespaces. So I had to ommit the whitespaces and in the Guthtila parser and by doing so I have introduced few bugs as well so I had to fix them.

But as a whole it works fine and now we are running with Guththila and with unrealistic performance for a web service engine.

Attracting developers to Open Source projects

2007-06-21T05:36:00.000-07:00

Being open source doesn't guarantee that there will be developers who are willing to contribute to the project. There is lot more than that.
People may like to hack in to others code, identify bugs but these are not compelling reasons for a person to truly contribute to a open source project. A reasonable developer always likes to actively participate in a projects important decisions and they really hate when most of the important decisions about the project is taken by a secret council. This is a common case in open source projects funded by organizations. Most of the projects developers may be in that organization and they will find it easier to talk to each other and come to a decision. But in this case outside people who are willing to contribute to the project may feel that they are left out of the projects important decisions and they will simply go to some where else where they can participate actively. So a successful open source project will always take every decision in mailing list and allows developers or what ever person from outside to have their say in every important decision in the project.

Treating every user who are willing to contribute by bug reports as potential developers is also may be a good investment in the future. Even if a new person takes 7days to fix a bug which can be fixed by a projects developer in 1 hour it is better to give the user the chance to fix that bug by taking time, because in the future that person may be a key developer in the project.

Some developers like to solve very hard intangible problems and they don't like to hand around with fixing bugs and improving the documentation. Of course at one point of time they will have to contribute to the project by fixing bugs. But if the projects developers always keep the good stuff for them selves people may find that they get only the left out things and they won't like it.

So attracting users is an art by itself and every developer should master that art to a some extent if they are working in a open source project.

Improved XML parser for Axis2/C

2007-06-20T06:44:00.000-07:00

For the past month I was working very hard on one project. That is to produce a Stax based XML parser for Axis2/C. The goal was not only to develop a XML parser but to write a XML parser which is running faster than the existing ones.

Now I'm very happy to announce that my work has been integrated in to Axis2/C. Today evening I committed the code to the SVN trunk of Axis2/C. I had the chance to do a performance test on one of the high end machines and it turned out that with the new parser Axis2/C ran beyond 10,000 requests per second. Previously it was only about 4000 request per second and this is a huge performance gain. Actually I was surprised by the test results as I never expected this much of performance gain. But it seems that with the new XML parser Axis2/C will break all the performance records for web services engines.

So if someone wants a web service engine with extreme performance Axis2/C may be the ideal candidate.

New XML parser for Axis2/C

2007-06-15T00:15:00.000-07:00

Axis2/C is a web service engine and essential part of it is to process XML messages (SOAP). Axis2 architecture is based on the XML pull model and it has defined its own XML object model called Axiom on top of the XML pull parsing (Stax). At the moment the parsers that are being used are libxml2 and guththila and performance vise these two parsers are almost the same. Guththila is a parser specifically written for Axis2/C and it had its share of strengths and weaknesses.

In the past month I was involved in developing a new improved version of Guththila parser and now it is almost done except for few concerns such as error handling and few XML validation issues. I could integrate it with the Axis2/C and it worked well according to my opinion. I have done few performance tests here and there and it seems that with the new parser Axis2/C performance is increased somewhere around 35% - 45 % and I'd like to consider this as a huge gain.

Another new feature of the new parser is its ability to parse tokens instead of strings in to the Axis2/C but unfortunately I couldn't test this feature yet. The problem that we had earlier was we are using strdup to create string from the parser to the web service engine. This is a really expensive operation both in time and space. Specially it effects the memory locality of the Axis2/C engine quite drastically. But with the new improvement this will no longer exists and I'm hoping to get around 150% percent increases in the performance of the Axis2/C engine.

Axis2/C may be the future of Web Services

2007-06-14T06:59:00.001-07:00

Axis2/C is a Web Service engine written for producing and consuming Web Services. Axis2/C is a fully open source project and goes under the Apache2 license. Unlike most of the current web services stacks which are developed in Java or C#, Axis2/C is written in C. At the moment Axis2/C is thriving forward as new developers and users joining the project. Axis2/C provides a very good colleberative environment for developers who are keen on producing high performance open source software. Being said that one of the main goals of Axis2/C is to run faster. The next major goal is to provide Web Service extensibility to exsiting technologies like PHP, MySQL or Perl.

Recently Axis2/C project went through a major milestoen and it is the 1.0 release and it was kind of a mixed success. Still there are lots and lots of areas in Axis2/C to be covered and project is more than willing to accept developers who has the intension to right free software.

Axis2/C a web service engine written in C

2007-06-14T03:42:00.000-07:00