Manage sessions in Web Services

Managing the session using the service client

Managing the session on the client side involves bit of a work. as mentioned above, both in a soap session and transport session a client has to send the session-related data if he wants to live in the same session. maybe he can do that for a soap session by coping with required reference parameters, but with a transport session a user must get access to the transport to copy and send cookies.

To make life easier, axis2 has the built-in capability of managing sessions in the client session by just setting a flag. then, depending on the service side session, it will send the corresponding data as long as you use the same service client. so, the main requirement is to use the same service client to invoke the service if you want to live in the same session.

If you want to live in the same session, you can create service client as shown below and re-use the created service client object to invoke the service.

 
Options = new options ();Options. setmanagesession (true );Serviceclient sender = new serviceclient (); Sender. setoptions (options );
 

Once you create the service client as shown above, if the Service deploys in a soap session it will copy the servicegroupid and send that from the second invocation onwards. if the server sends the session ID, such as HTTP cookies, it will copy that to the service context (on the client side) and send it back to the server when the client invokes the service for a second time.

Manage sessions in Web Services

(Server)Http://www.apusic.com/article/article15.htm

In Web Services, two accepted technologies are used to manage sessions. One is to use HTTP and HTTP cookies, and the other is to use SOAP Headers. Axis can help you implement these two technologies.

There is no standard method for session management in Web Services, and there are only two accepted technologies, one being relying on HTTP and HTTP cookies, and the other being, perhaps the most important method is to use SOAP Headers. Axis can help developers implement these two technologies.

HTTP managed sessions is used by default in axis. It is very easy to do this on a server, because most of the management of the Axis web service is completed through an instance of org. Apache. axis. messagecontext. In an Axis web service, you can call the static method in the messagecontext class to obtain an instance of messagecontext:

Public class sessionservice { Public String echo (string in) { Messagecontext MC = Messagecontext. getcurrentcontext ();

Messagecontext contains a method named setmaintainsession, which can be called to activate the session. However, when writing (axis 1.1 RC2), the session object can be activated only when it is accessed, as shown in the followingCodeAs shown in:

Public class sessionservice { Public String echo (string in) { Messagecontext MC = messagecontext. Getcurrentcontext (); Session session = mc. getsession (); String name = (string) Session. Get ("name "); Return in; } }

This will cause the axis architecture to generate a set-Cookie header:

Set-COOKIE: JSESSIONID = 49ebbb19a1b2f8d10ee075f6f14cb8c9; Path =/axissessions

The client needs to return the cookie in the cookie header to maintain the session. To enable the client in the running state of axis to achieve this, you must call the setmaintainsession method of the org. Apache. axis. Client. Service Interface. This interface is implemented by the locator class generated by the wsdl2java generation tool. After this method is called, the Axis architecture automatically returns the cookie to the server:

Public static void main (string ["> ARGs) { Usesessionsservicelocator locator = new Usesessionsservicelocator (); Locator. setmaintainsession (true );

The header looks like this:

COOKIE: JSESSIONID = 49ebbb19a1b2f8d10ee075f6f14cb8c9

There is no problem in transmitting cookies over HTTP. However, if the client or server does not pass HTTP, or the multihop service called through multiple Web Services is used, this method is not so effective. A better method is to use SOAP Headers to load session IDs.

The Axis architecture supports multiple handlers. By calling the call stack in a web service request process, handlers can be placed in many places. It can be combined with the transfer process or used together with a web service. Handlers can be inserted to process requests and/or response statements in Web Service requests.

Axis carries a handler named org. Apache. axis. Handlers. simplesessionhandler, which is used to provide SOAP Headers Based on session management. To use this simple session handler with Web service, you must inform the axis architecture to add the handler to the handler chain. You can do this by adding the handler information to the server-config.wsdd; a simple way to do this is to define a WSDD file that includes additional configuration required for the Web service, then use the axis deployment tool to deploy the configuration file.

The WSDD file looks like this:

Http://xml.apache.org/axis/wsdd" Xmlns: Java = Http://xml.apache.org/axis/wsdd/ Providers/Java "> Type = "Java: org. Apache. axis. handlers. Simplesessionhandler "/> "Java: RPC" style = "wrapped"> URN: kevinj: Sessions "Kevinj. usesessions"/>

The handler is defined and referenced separately from the service, although you can define it within the service. Note that this handler is defined for both request and response. This ensures that these headers can be read in the request and added to the response. You can use this management tool to deploy it:

Java-CP [classpath to axis bits here ">/ Org. Apache. axis. Client. adminclient/ -Lhttp: // localhost/myservice/axisservlet Deploy. WSDD

Now the server can run. When using the handler, the server does not need to handle anything. headers can be automatically added, as shown in the following figure:

Soapenv: mustunderstand = "0" Xsi: TYPE = "XSD: long" Xmlns: NS1 = Http://xml.apache.org/axis/ Session "> -1919645576528915916

To use this header, the Web service client must be able to read it and understand its syntax. The axis client can solve this problem.

To create an axis client that uses this simple session, you need to configure the axis client framework to use this handler. The process is similar to that on the server, but not deployed on the server. Instead, the config file is created locally. You can achieve this by running org. Apache. axis. utils. admin. Run the following code:

Org. Apache. axis. utils. Admin Client deploy. WSDD

As a result, a client-config.wsdd file is created, which also contains the handler code.

Http://xml.apache.org/axis/wsdd" Xmlns: Java = "http://xml.apache.org/axis/ WSDD/providers/Java "> Value = "admin"/> Value = "Org. Apache. axis. attachments. Attachmentsimpl "/> "Sendmultirefs" value = "true"/> "True"/> "Sendxmldeclaration" value = "true"/> Value = "true"/> "Java: org. Apache. axis. handlers. Simplesessionhandler "/> "Java: org. Apache. axis. handlers. Simplesessionhandler "/> "Java: org. Apache. axis. handlers. Simplesessionhandler "/> "Java: RPC" style = "wrapped" use = "literal"> "Kevinj. usesessions"/> URN: kevinj: Sessions "Java: org. Apache. axis. Transport. Java. ENDER "/> "Java: org. Apache. axis. Transport. HTTP. httpsender "/> "Java: org. Apache. axis. Transport. Local. localsender "/>

to enable the client to exploit this handler, you must add the client-config.wsdd file to the client's classpath. Then, the Axis framework reads and responds to these headers on behalf of the client. Similarly, the client code can be used without processing anything.