October 31, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Writing an Axis2 Service from Scratch

  • June 16, 2006
  • By Deepal Jayasinghe
  • Send Email »
  • More Articles »

Accessing Message context inside the service implementation class

Message context is the property bag + the incoming SOAP message representation in Axis2. There are some services that want to access message context inside its service implementation class; one probable use case could be to access a transport header inside the service and make a decision on that. Axis2 uses a technique called dependency injection to inject message context to the service implementation class; Axis2 uses Java reflection for that. So, if the service wants to access message context inside its service implementation class, it has to add a method called setOperationContext to service the implementation class as follows.

public class HelloWorld {

   private MessageContext inMesasgeContext;

   public void setOperationContext(OperationContext opCtx)
      throws AxisFault {
         inMesasgeContext = opCtx.getMessageContext(
            WSDLConstants.MESSAGE_LABEL_IN_VALUE);
   }

   public String sayHello(String name) {
      return "Hello " + name;
   }
}
Note: Axis2 calls setOperationContext using Hava reflection before it calls an actual Java method corresponding to the incoming message.

Service group and single service

To deploy multiple services (they may be logically related or not) together in a single service archive file, Axis2 introduced the concept of a service group. There, you can have multiple service implementation classes and only one services.xml file to describe all the services. The only difference here is that root element of services.xml is changed to serviceGroup instead of service. As an example, say you want to deploy two services together in a single service archive file and further assume that names of them are MyService1 and MyService2 respectively. The services.xml file can be written as follows:

<serviceGroup>
   <service name="MyService1">
      ........................
   </service>
   <service name="MyService2">
      .......................
   </service>
</serviceGroup>

The only difference in the service element compared to HelloWorld's services.xml is that here the service element has an additional attribute called name. If you want to have multiple service elements in the services.xml file, you must have the name attribute in each and every service element.

Contract first approach: Starting from WSDL

The easiest way to create a service is to start from WSDL; that is what happens in most production environments. When it comes to production, they have business scenarios and corresponding business contracts or the WSDL file, so why not start from there? The interesting thing is that once they have the WSDL file, both client and producer (service) are given the WSDL and they have to act according to that.

Axis2 has built-in support of the generation service code once you have the WSDL. In this case, as a service author, you have only to do the following few steps:

  • Generate service code (service skeleton)
  • Fill the service skeleton according to the business agreement
  • Run the generated Ant build file
  • Deploy the Ant-created service archive file into your application server where Axis2 is running
Generating code

Axis2 came with a set of tools and IDE plug-ins for code generation (WSDL2Code) to make the work easier. So, you can choose any kind of code generation tool to generate a service skeleton. In the meantime, there is a set of databinding framework support; you can select one of them as your databinding. As an example, you can select xmlbeans, adb, or any other available databinding framework (jibx, jaxme, and so forth). Once you generate server side code, it generates:

  • Service skeleton class
  • Message receivers (most of the time, one or two)
  • services.xml
  • services.wsdl
  • Ant build file
Filling the service skeleton

Axis2 generates a service skeleton class to throw UnSupportOperation from each method. You have to implement the service skeleton class as you want.

Running ant build file

After completing the service skeleton, the next step is to create a service archive file using generated code. To make the job simple, Axis2 generates an Ant build file to create service archive file for you; you have to open the command line console, go to the folder where you generated code, and then type ant build there in the console to run the ant build file. Then, it creates the service archive file for you.

Summary

Making a Java class into a Web service is very straightforward in Axis2. Once you know how to write services.xml correctly, deploying a service is just a matter of creating a service archive file and dropping it into the services directory in the repository. WSDL's first approach is the easiest way to creating a service because Axis2 has built-in support for code generation and a set of tools to make the job easier.





Page 2 of 2



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel