Utilizing a Non-Java Web Service with Axis2

Writing a Non-Java Web Service

There are two new features in Axis2 that help write non-Java Web services with Axis2. They are as follows:

Message receiver: Axis2 assumes the service end point as a message receiver (Axis2 does not have any business with the actual service implementation class), so it's up to the message receiver to talk to the service implementation class and get the response and send it to the request initiator, if any. Therefore, it is easy to write a MR that invokes a non-Java class to process a message.

Service isolation: In Axis2, each service deployed in the system has its own class loaders. A class loader can be used to access all the resources corresponding to that particular service.

Note: The class loader for a given service can be obtained from its corresponding AxisService object (org.apache.axis2.description.AxisService). Say foo is an AxisService; a user can access his/her resources by using:

Writing a Sample Non-Java Web Service

Groovy (http://groovy.codehaus.org/) is a very advanced scripting language that can run on Java JVM, so this sample is based on writing a Web service using Groovy, deploying that in Axis2, and finally invoking using an Axis2 client (no need to be an Axis2 client). If you are not familiar with Groovy, don't worry. Try to get the concepts and apply them into some other languages that you are familiar with. The service class implemented using Groovy will look like Figure 4.

Writing a Message Receiver to Invoke the Service

The default message receivers mentioned above cannot handle this situation (the default message receivers are only for invoking Java services); therefore, to invoke this service there should be a custom message receiver. The message receiver's implementation logic is described below.

Step 1: Getting the service implementation class

The service implementation class is described in services.xml as a parameter. At deployment time, the service implementation class is neither loaded nor initialized, so at run time the service implementation class has to be loaded and initialized. The parameter that describes the service implementation class look like the following:

Step 3

In Axis2, an incoming SOAP message is represented as an object model called AXIOM, but Groovy cannot work with AXIOM. It can handle Xpath and DOM-like XML inforset representations. Therefore, you cannot directly get an incoming SOAP message into a Groovy object. You first need to serialize that into the original SOAP message and get the input stream that corresponds to it.

Creating a Service Archive File

To deploy the service in Axis2, you must create a service archive file. For that, you need to do the following:

Compile the source code.

Write the service description file (services.xml).

Put "groovy-all-1.0-jsr-01.jar" in the class path (create a lib directory inside service archive and drop the above jar file into that).

Create a jar file out of all those resources and class files.

Note: To invoke this service, you do not need to have a specific client; you can use the normal Axis2 client (Call). Complete source code for the service and client are available for download from the Apache SVN repository.

Conclusion

Axis2 architecture is flexible and highly extensible; the ability to invoke a non-Java application using Axis2 shows its extensibility. The ability to write a custom message receives is not only useful to invoke a non-Java Web application, but also to build an application such as a work flow model on it (BPEL).