Hi Tim,

thanks for the input! Unfortunately I have to use multiple services and already I ran into the problem that setMaintainSession(true) does not really work for that scenario. I'll be looking into SOAP based sessions now, but I am rather sure I'll end up using your solution. Thanks a lot.

Regards,
Tom

Tim Dionne wrote:
Hi Tom --

If all of your calls will be in the same service, you can choose to have
MessageContext maintain the session using Stub.setMaintainSession(true).
If the calls will be in different services, you will have some troubles.
The only solution (that I've found) is to use something like this:

( (Stub) serviceB)._setProperty(HTTPConstants.HEADER_COOKIE,
           ( (Stub)
serviceA)._getCall().getMessageContext().getProperty("Cookie"));

This is what I'm currently doing to maintain the session across calls in
different services.
-----Original Message-----
From: Tom Ziemer [mailto:[EMAIL PROTECTED] Sent: Friday, July 15, 2005 12:34 AM
To: [email protected]
Subject: Concerning sessions

Hi everybody!

After browsing through the archive of this list and searching the web I
am still no quite sure, which session approach to use for my services. What I need to do is quite simple - let a user authenticate, then only
exchange a token/sessionid for all following calls. As far as I
understand it, I have three alternatives:

Option a) Use a http session
Option b) Use SOAP headers
Option c) Reimplement basic session handling

Obviously c) is not the method of choice, so I am left to choose between
a) and b). The most important issue for my web services is
interoperability, since I am writing only the services but the clients
will be implemented by another company and I have no idea what
programming language/tools they are going to use.

Any input would be appreciated,

Tom



**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply e-mail and destroy all copies of the original message.

Reply via email to