Lost Session at JWSP-Client

[Matthias B�hringer]

Hi!
It is a known Problem, that sometimes the session from an instance of an WebServiceClient Object (JWSDP) to the the Server Objects ist lost?

In my special case I have a webapplication that uses JWSDP-Clients to communicate with a middleware application (a very komplex service).

In the webapplication a request can cause a creation of a new Instance of a ClientObjekt with a new session to middleware. I save this Object in the session (= session to webuser) of the webserver.

Several requests can do the same.

Now, the webuser can use this clientobjekt in his session at further requests. The Clientobject is called from session and requests are send to middleware by using the old sessionID between webserver and middleware.
For Illustration:

Webuser <---- session -----> webserver <--- session --- > middleware

Here is my Problem:

If several requests of many webusers are landing at webserver for using the clientobjekts in the webuser's sessions, than the sessionIDs between clientobjekts and middleware are totally mixed. The sessionIDs in the JWSDP-clients are lost and exchanged between the running JWSDP-Clients on the Webserver.

Can somebody help me? Am I alone? I have nothing found in web. The Problem occurs with resin and tomcat server.

[Peer Reynders]

Originally posted by Matthias B�hringer:
If several requests of many webusers are landing at webserver for using the clientobjekts in the webuser's sessions, than the sessionIDs between clientobjekts and middleware are totally mixed. The sessionIDs in the JWSDP-clients are lost and exchanged between the running JWSDP-Clients on the Webserver.

Can somebody help me? Am I alone? I have nothing found in web. The Problem occurs with resin and tomcat server.

As a rule Web services do not use HTTP-Sessions, because it�s an HTTP concept, not a SOAP concept (which doesn't want to depend on its transport - in this case HTTP). If you need to maintain session information for web services it is recommended that your web methods require a correlation identifier (see page 95 and page 359 in Java BluePrints: Designing Web Services with the J2EE 1.4 Platform). Also

Chapter 3: Service Endpoint Design
3.4 Designing a Service�s Interaction Layer
3.4.1 Designing the Interface
3.4.1.1 Choice of the Interface Endpoint Type
page 70

However, generally HTTP session support is appropriate for
short duration conversational interactions, whereas Web services often
represent business processes with longer durations and hence need additional
mechanisms. See �Correlating Messages� on page 359 for one such strategy.

page 359 refers to

Chapter 8: Application Architecture and Design
8.4 Web Service Communication Patterns
8.4.1 Correlating Messages

A Web service client and a Web Service endpoint do not usually exchange HTTP-Cookie headers and the Web service Client does not send an HTTP-GET request with a query string (it sends a SOAP message via an HTTP-POST request) which eliminates both mechanisms by which session IDs are usually exchanged.

If you are using a JAX-RPC service endpoint (JSE) then as a short-term, non-portable hack you could have the web service place the jsessionid in a custom SOAP-Header in the SOAP-Response from the Web Service. A SOAP-Handler on the client side could then retrieve the jsessionid from the header. Once the client has the jsessionid it can place that jsessionid in a custom SOAP-header of all its subsequent SOAP-requests. Then the Web service may retrieve and use it to get access to the correct session.

Ultimately you will want to redesign your Web service interface to use correlation identifiers instead.
[ February 14, 2006: Message edited by: Peer Reynders ]

[Peer Reynders]

Addendum: It is possible for a JAX-RPC client stub to request a session, but it is not recommended:

    // Set the "javax.xml.rpc.session.maintain" property on javax.xml.rpc.Stub 
    stub._setProperty( javax.xml.rpc.Stub.SESSION_MAINTAIN_PROPERTY, java.lang.Boolean.TRUE );

Session tracking will be accomplished via Cookies or SSL/TLS session tracking (if using HTTPS transport).

Not interoperable as not all Web service clients/services support cookies.

Not even interoperable within J2EE. Servlet based JAX-RPC service endpoints have access to the HTTP session - EJB Service endpoints do not.

Usually discouraged as HTTP-based session/state management occurs outside the scope of the SOAP message, permanently binding the SOAP message to its transport. This is important as SOAP messages are supposed to be capable of traveling over "SOAP intermediaries" - HTTP Session management can only work between a "SOAP Sender" and "SOAP Receiver" that are directly connected, such an environment does not support "SOAP intermediaries".