Hello, I'm trying to understand what is the correct behavior in the way session scope is handled by JAX-RPC providers such as Axis.
Unfortunately, I find the JAX-RPC specification unclear in
this matter, so I can't defiantly claim that there is a bug in
current Axis implementation.
In particular, should there be a new session created per each
different PortType? In Axis case, there is one-to-one mapping
between a URL and a Transport instance which currently
contains session information, i.e. cookies.
I wish it wasn't so and here is why. I believe that there is a
need to be able to share state information among PortType
instances. Such information would ideally be stored in a
Session container.
Here is an example. I want to be able to mimic returning
object instances back to a SOAP client. Upon client's request
the server would instantiate an object and return a handle, or
a token in XML schema vocabulary, to such an instance. On
subsequent invocations, the client could refer to that
instance when invoking methods on other PortType instances,
like this:
A stands for a stub for PortType A
B stands for a stub for PortType B
On the client side:
// create on the server a PortType instance
// and get a handle to it
handle_to_instance_A = A -> newInstanceOfSelf();
// use this handle in another PortType instance
B -> useInstanceAinB(handle_to_instance_A);
If both PortType instances A and B shared the same session,
such invocation scenario would be easy to achieve. B's
useInstanceAinB method would use the handle_to_instance_A to
locate the particular instance of A within the session container.
I hope my example above was illustrative enough.
I would be very interested in hearing your opinion on this matter.
Regards,
Slawomir Lisznianski
PS. Attached is my HTTPTransport.java file that shows one
possible implementation of such an enhancement to the Axis
session handling approach. I'm currently using it in my Axis
client app by putting session.jar ahead of Axis jars.
In the future, it would be more optimal to completely take out
any session information from the transport object and put it
elsewhere.
---- Original message ----
>Date: Tue, 01 Oct 2002 10:04:47 -0700
>From: Ricky Ho <[EMAIL PROTECTED]>
>Subject: Re: MessageContext.setMaintainSession
>To: [EMAIL PROTECTED]
>
>I think your SOAP service is depending on the "cookie"
mechanism as well as
>the HTTP transport. And you also restricting the session
variables to ONE
>client. But no doubt this approach is the easiest.
>
>I think a better approach is to have the message itself carry
some data
>that maps into an existing service instances using some
correlation mechanism.
>
>Best regards,
>Ricky
>
>At 09:12 AM 10/1/2002 -0600, Grant Echols \(JanusLogix\) wrote:
>>Alex,
>>
>>I've been playing with sessions all day and found what I
really wanted
>>after a bit of muddling around. I realize that with
"scope"="session" that
>>I'd be getting a new instance of my SOAP service and would
therefore be
>>able to store local variables unique to the session, etc.
However, this
>>isn't what I'd been trying to achieve. I was looking for
something more
>>like the HttpSession concept in servlets and was able to
achieve this with
>>the "scope"="application" and by having the Axis client and
service call
>>the MessageContext.setMaintainSession(true). Then the server
can use the
>>MessageContext.getSession() to retrieve the session for the
particular
>>client. So far this is working the way I'd wanted. I hope
that this is not
>>relying on an unexpected behavior in Axis.
>>
>>Thanks again for your help. Your explanations (especially
about the client
>>enabling sessions) made a big difference.
>>
>>Grant
>>----- Original Message -----
>>From: <mailto:[EMAIL PROTECTED]>Volanis, Alexander
>>To:
<mailto:'[EMAIL PROTECTED]'>'[EMAIL PROTECTED]'
>>Sent: Monday, September 30, 2002 4:05 PM
>>Subject: RE: MessageContext.setMaintainSession
>>
>>Grant,
>>
>>As the name implies "scope"="session" is the way to enable
session
>>tracking in Axis services. It is really up to the client to
maintain the
>>session by caching the HTTP cookies returned by the server.
Most clients
>>would either do this by default or require a flag to enable
it like Axis
>>clients do. As far as HTTP sessions go this is all you need
to support them.
>>
>>Alex
>>-----Original Message-----
>>From: Grant Echols (JanusLogix) [mailto:[EMAIL PROTECTED]]
>>Sent: Friday, September 27, 2002 3:48 PM
>>To: [EMAIL PROTECTED]
>>Subject: Re: MessageContext.setMaintainSession
>>
>>Alex,
>>
>>Thank you for your explanation. It has helped clear up some
misconceptions
>>on my part.
>>
>>I gather from your comments and the doc that I cannot use
>>"scope"="Application" if I want to maintain session oriented
information
>>for a SOAP client? Is this the extent of the session
management in Axis?
>>
>>Thanks,
>>
>>Grant
>>
>>----- Original Message -----
>>From: <mailto:[EMAIL PROTECTED]>Volanis, Alexander
>>To:
<mailto:'[EMAIL PROTECTED]'>'[EMAIL PROTECTED]'
>>Sent: Friday, September 27, 2002 8:48 AM
>>Subject: RE: MessageContext.setMaintainSession
>>
>>The correct way to enable session management is in your
deploy.wsdd file.
>>Add <parameter name="scope" value="Session"/> to your
service deployment.
>>To get the desired effect your clients have to enable
session management
>>as well. Use ((org.apache.axis.client.Stub)
ws).setMaintainSession(true)
>>where "ws" is your service client instance returned by the
ServiceLocator
>>class implementation in Axis client generated code terms.
>>
>>Alex
>>-----Original Message-----
>>From: Grant Echols (JanusLogix) [mailto:[EMAIL PROTECTED]]
>>Sent: Thursday, September 26, 2002 3:12 PM
>>To: [EMAIL PROTECTED]
>>Subject: MessageContext.setMaintainSession
>>
>>I'm trying to understand the MessageContext session
management and I'm
>>confused by what its supposed to do. On the first request
from a client I
>>see that the session management is not turned on so I turn
it on. On the
>>second request the session management is still not turned
on. Is there
>>some other requirement I don't know about?
>>
>>Thanks,
>>
>>Grant
>>
session.jar
Description: application/compressed
