Eduticles » Web Services With Axis2/C

Web Services With Axis2/C

July 25, 2009
12:22
CMake based build system for Axis2/C
» ‎ Web Services With Axis2/C

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.
March 07, 2009
0:08
Memory Handling conventions in Axis2/C
» ‎ Web Services With Axis2/C

Memory Handling conventions in Axis2/C
November 20, 2008

Permalink for 'Axis2/C Handler Parameters'

22:57

Axis2/C Handler Parameters

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"> [schemas.xmlsoap.org]

  16:   </operation>

  17:   <operation name="Resolve">

  18:     <parameter name="wsamapping"> [schemas.xmlsoap.org]

  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.

November 18, 2008
0:30
Axis2/C modules and persistent configurations
» ‎ Web Services With Axis2/C
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;
```
October 21, 2008
4:18
Adding Custom SOAP Headers to Web Service Request
» ‎ Web Services With Axis2/C

How to Add Custom SOAP Header to SOAP Requests using Axis2/C Service Client
October 19, 2008
23:42
TCPmon C tool
» ‎ Web Services With Axis2/C

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.
September 10, 2008
2:40
Javascript binding for Axis2/C server side
» ‎ Web Services With Axis2/C

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: [developer.mozilla.org]
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] - [en.wikipedia.org]
[2] - [rajikacc.googlepages.com]
[3] - [rajikacc.googlepages.com]
September 08, 2008
4:07
WS-Transfer for creating and exchanging state information of resources
» ‎ Web Services With Axis2/C

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. [www.w3.org]
August 29, 2008
2:02
Debugging Axis2/C services and clients
» ‎ Web Services With Axis2/C

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.
August 25, 2008
21:08
Terminator - Cross-platform Terminal Emulator with Window Splitting
» ‎ Web Services With Axis2/C

Terminator - Cross Platform GPL Terminal Emulator with Multiple Window Support
3:25
High performance Axis2/C – Tips and Tricks
» ‎ Web Services With Axis2/C

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
August 18, 2008
23:41
WS-Discovery WS Gateway to the Devices
» ‎ Web Services With Axis2/C
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:
1. 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.
2. 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.
3. 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).
August 14, 2008
0:00
Debugging Axis2/C services – Linux
» ‎ Web Services With Axis2/C

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.
August 06, 2008
23:18
Debugging Axis2/C Services - Windows
» ‎ Web Services With Axis2/C

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.
July 30, 2008
3:37
Axis2/C Performance
» ‎ Web Services With Axis2/C

Axis2/C benchmark performance test results are published here
July 22, 2008
2:05
Eucalyptus Use Axis2/C and Rampart/C
» ‎ Web Services With Axis2/C

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.
July 21, 2008
5:59
Deploying Axis2/C in Apache - Common Erros
» ‎ Web Services With Axis2/C

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.
4:08
Apache Axis2/C 1.5.0 Released
» ‎ Web Services With Axis2/C

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
July 15, 2008
0:07
Axis2/C Deployed in IIS Family - My First Article
» ‎ Web Services With Axis2/C

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. [wso2.org]
June 20, 2008
3:45
Top ten reasons for using Axis2/C over other Web Services Engines
» ‎ Web Services With Axis2/C

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!
0:06
Interesting performance results
» ‎ Web Services With Axis2/C

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.
June 16, 2008
5:43
Developers quick start guide for Axis2/C - Windows
» ‎ Web Services With Axis2/C

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 idesvcaxis2cdeploybin

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 idesvcaxis2cdeploy directory. Also make sure that AXIS2C_HOME and PATH variables are set to {AXIS2C_SOURCE_DIST}idesvcaxis2cdeploy and {AXIS2C_SOURCE_DIST}idesvcaxis2cdeploylib directories. Set the axis2 [http_server] as the startup project and set the working directory of this project to {AXIS2C_SOURCE_DIST}idesvcaxis2cdeploybin. 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.]
June 12, 2008
6:19
IIS 6 & 7 Support for Axis2/C
» ‎ Web Services With Axis2/C

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).
April 25, 2008
7:34
Federated Sign-Out
» ‎ Web Services With Axis2/C

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).
April 04, 2008
6:31
Top Axis2/C Articles
» ‎ Web Services With Axis2/C
- 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.

← Computer Science kilomentor →

Eduticles » Web Services With Axis2/C

Feeds

Web Services With Axis2/C