WebService Axis2 (5): Session Management

The most intuitive feeling of webservice is that it consists of a method that is called by the client through the SOAP protocol. These methods may have return values, or they may not have return values. While this can accomplish some of the tools, the invoked methods are isolated, and when a method is invoked, the state after the method invocation cannot be obtained in other methods, that is, the state cannot be preserved.

Readers can imagine that the inability to preserve state for a complete application means that it's hard to do all the work with WebService. For example, a complete application system needs to be logged in, which uses a session in the Web application to save the user's login status, and it is embarrassing to fail to save the login status if you use the WebService method for login processing. Of course, this can be done in other ways, such as using static variables on the server to save the user state, and sending an ID to the client to obtain the appropriate user status by passing this ID on the server and the client. This is very similar to managing user state through session and cookies in Web applications. But this requires a lot of work by developers, but luckily Axis2 provides us with the WebService state management function.

The state of using AXIS2 to manage WebService is basically transparent to developers. The WebService class requires the use of Org.apache.axis2.context.MessageContext and Org.apache.axis2.context.ServiceContext classes to preserve and obtain You have to save state information on the server side, which is somewhat like using the HttpSession interface's GetAttribute and setattribute methods to get and set the session domain properties.

In addition, you need to modify the contents of the Services.xml file and add a scope attribute to the <service> element, which has four desirable values: application, Soapsession, Transportsession, Please note, though, that although Axis2 's official document has written the initials and initials of the four-value words in uppercase, the author has tested that all lowercase must be valid, that is, the four values should be: application, soapsession, Transportsession, request, where request is the default value for the Scope property. Readers can choose to use transportsession and application to implement session management for the same WebService class and across WebService classes, respectively.

The session management feature needs to be opened on the client using Setmanagesession (TRUE).

To sum up, to achieve the same WebService session management requires the following three steps:

1. Use Messagecontext and Servicecontext to obtain and set key-value pairs.

2. Add a scope property for the <service> element corresponding to the WebService class to be managed by session and set the property value to Transportsession.

3. Use Setmanagesession (TRUE) on the client to open the Session management feature.

The following is an example of managing a session in the same WebService class.

First, create a WebService class with the following code:

Package service;
Import Org.apache.axis2.context.ServiceContext;
Import Org.apache.axis2.context.MessageContext;
public class Loginservice
{public
    Boolean login (string username, string password)
    {
        if ("Bill". Equals (username) && "1234". Equals (password))
        {
            //  1th step: Set Key-value to
            messagecontext MC = Messagecontext.getcurrentmessagecontext ();
            Servicecontext sc = Mc.getservicecontext ();
            Sc.setproperty ("Login", "successful Login");
            return true;
        }
        else
        {return
            false;
        }
    }
    Public String getloginmsg ()
    {
        //  step 1th: Get key-value value
        Messagecontext mc = Messagecontext.getcurrentmessagecontext ();
        Servicecontext sc = Mc.getservicecontext ();
        Return (String) sc.getproperty ("login");
    }