Session Management in Axis

There are different types of sessions, and the lifetime of the session may vary from one to another. Some sessions last for a few seconds while others last for the lifetime of the whole system. Axis2 architecture has been designed to support four types of sessions, and we observe that there are minor differences between one type and another. By considering the different types of use cases, Axis2 has the following four types of session scopes:

1.Request

4.Transport

There are five types of contexts in the hierarchy, which have been listed below with a brief explanation:

ConfigurationContext: This is the run-time representation of whole system. To start an Axis2 system, we need to have configuration context. The lifetime of configuration context will be the lifetime of the system. So, if we store some state (a property) it will last forever (until system shutdown).
ServiceGroupContext: In Axis2, we can deploy multiple services together as a service group. Then, the run-time representation of that is called ServiceGroupContext.
ServiceContext: This represents the run time of one service. The context lifetime will be the lifetime of the session. There can be one or many service contexts in the system, depending on the session scope of the corresponding service.
OperationContext: This context represents the lifetime of an MEP (Message Exchange Pattern). The lifetime of an operation context is, usually less than the lifetime of the ServiceContext.
MessageContext: The lifetime of an incoming message is represented by the message context. If two handlers in a given execution chain want to share data, then the best way to store them is in message context. One OperationContext may have one or more MessageContexts.

Request Session Scope

Request session scope is the default session scope in Axis2. When we deploy a service without knowing anything about session management, then our service will be deployed in request session scope. The lifetime of this session is limited to the method invocation lifetime, or request processing time. When we deploy a service in request scope, it simply means that we are not going to worry about the session management at all. So it is not like session management at all.

SOAP Session Scope

The idea of a SOAP session is to have a transport-independent way of managing session between two SOAP nodes, obviously between the client and the server. Here, Axis2 uses SOAP headers in order to manage the session. SOAP session scope has slightly longer lifetime as compared to a request session scope, and deploying a service in a SOAP session requires changing services.xml as well. Managing SOAP session requires both the client and the service to be aware of the sessions, that is, the client has to send the session-related data if it wants to access the same session, and the service has to validate the user using session-related data.

Transport Session Scope

In the case of Transport Session, Axis2 uses transport-related session management techniques to manage session. As an example, in the case of HTTP, it uses HTTP cookies to manage session. Then the lifetime of the session is controlled by the transport session and not by Axis2. What Axis2 does is store service context and ServiceGroupContext in the transport session object so that the service can access those contexts, as long as the session lives.

One of the key advantages that the Transport Session has over other sessions is that we can talk to multiple service groups within one transport session. In a SOAP session, we don’t have a way to communicate between two service groups, but with the transport session, we have that capability too. In this case, the number of service instances created depends on the number of transport sessions created.

Application Scope

Application scope has the longest lifetime as compared to all the others, and the lifetime of the application session is equal to the lifetime of the system. If we deploy a service in application scope, we will find that there is only one instance of the service implementation class. In addition to that, there will be only one ServiceContext for the deployed service. Considering the memory footprint, in the Axis2 world, it is better to deploy the service in application scope, if we don’t want to manage the session.

Reference : Quickstart Apache Axis2
by Deepal Jayasinghe