December 19, 2014
Hot Topics:

Avoiding Mistakes Made Using Axis2

  • March 3, 2006
  • By Deepal Jayasinghe
  • Send Email »
  • More Articles »

8 — Getting Access to MessageContext From Service Classes

In Axis2 the last handler of the incoming execution chain is the message receiver. One of the main jobs of Axis2 is to deliver message to MessageReceiver. It is then its up to the MessageReceiver to hand the message to the application or do the processing by itself. Axis2 come with set of default MessageReceivers so that if you want, you can use them for your services. In the mean time you can write your own message receivers for your service and use them for their services.

If you, as the service author, are trying to write a MessageReceiver for a service then you can write it the way you want. The advantage in this case is that you should know about the service implementation class and thus you can program a message receiver so that it can pump message context into the service implementation class.

Most of the time service authors are not going to write their own MessageReceiver (it is not require to do so in all the cases) and they try to use default message receivers (depending on his requirement). In that case a service author does not have any control on the message receivers, and it will be getting either OMElement or Java object(s). But there can be many instances where a service author is required to access a Message Context inside the service implementation class (say for an instance to access HTTP headers needed to get the message context). To solve this problem, Axis2 has given an indirect path that is not incorrect. If you want to access incoming message context inside your service implementation class add the following method to service implementation class;

public void init(MessageContext msgctx){
  // store the message context 
}

And if you want to access both incoming and outgoing message contexts then add the following method to service implementation class.

public void init(MessageContext inMessge, MessageContext outMessage) {
 // store the message contexts 
}

9 — Trying to invoke two channel invocations without engaging Addressing

One of the key features in Axis2 is its asynchronous invocation capability. There are two level of asynchronous that Axis2 support:

  1. Asynchronous behavior in client programming model
    A client program does hang, but there is blocking in the transport senders (transport blocking).
  2. Actual transport asynchronous behavior
    Two transports are used for incoming and outgoing (transport non-blocking).

In the first case there is no real asynchronous invocation as far as transport is concerned, where the transport sender sends the request and then listens to the input stream to get the response. When it gets the response, the client program will be notify (client has to give callback object , so that it will be called whenever transport gets the response ).

In the second case one there are two transports for both sending and receiving, so transport sender sends the request and finishes its work. There has to be another transport listener to get the response. The most important thing in this case is that outgoing message has to have wsa:ReplyTo header; otherwise, the server does not way to send the response. In the incoming message server will send the response to wsa:ReaplyTo (which is the address of the initiator) addressing and it will send wsa:relatesTo and the other addressing headers as well. This implies that the addressing module should be available in the system to process the request. Therefore Axis2 has constraint saying that no one can invoke any service using two channels unless he has engaged addressing.

10 — Session Management and Service Scope Problem

Axis2 session management was introduced very recently, and it supports four levels of service scope or the session scopes:

  1. Application scope
  2. SOAP session scope
  3. Transport session scope
  4. Request scope

The basic rule is if you deploy some service in one of the above scope then you will be able to get session corresponding to that scope. For example if a service author deploys his service in application scope, then that service gets application session.

A service author can specify the service scope in the optional services.xml file. If the service author does not specify scope, then the default scope would be Request scope. The right way of specifying the scope is as follows:

<service name="MyService" scope="application"> 
</service>

Then the deployment person can deploy the service in the right scope. Note that one service cannot be deployed with two scopes.

Application session takes the longest lifetime and is equivalent to the lifetime of the system. If a service is deployed in application scope, then to manage session client need not to do any thing (no need to send any session data). The most important thing with application scope is that there will be only one instance of the service implementation class throughout the lifetime of the server instance.

In the case of SOAP session, it has a shorter lifetime than application session. In Axis2 the definition of SOAP session is to access set of service in a service group or to manage session across all the services belong to service group. To get into correct SOAP session user has to send a specific SOAP header called service group id. SOAP session corresponding to some service invocation will be removed from the system if that does not get touch for period of 30s. It should be note that if service is deployed in SOAP session scope, then each session will have its own service class instances that implies that if some service is deployed in SOAP session scope there can be multiple instance of the service implementation class.

In the case of Transport session, session management or finding the correct session object is achieved using some transport specific data such as in the case of HTTP it is HTTP cookies. If a service is deployed in transport session, then there will be services instance for each transport sessions. The interesting thing with this approach is that a user can have multiple SOAP sessions in one transport session. To get into the correct SOAP session (which is stored in Transport session), you have to send the service group id SOAP header in addition to cookies.

There is no any session management for request session scope, that’s only for one request so no need to have any session around it.

In Conclusion

As you can see, there are a number of major areas where users can get into trouble when using Axis2. Hopefully you have gain some insights into how to avoiding such mistakes as you work with Axis2.

# # #





Page 3 of 3



Comment and Contribute

 


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

 

 


Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Rocket Fuel