I don't know if this is terribly useful, but here is my $.02:

1. I am using an applet as a SOAP client. This works fine, as long as the applet is downloaded from the same server that is hosting SOAP. I am using Tomcat, Apache-SOAP, and Java plugin

2. I would think, although I don't know for sure, than since Apache SOAP uses a servlet, then it would use the servlet method of maintaing sessions, which is cookies if supported, otherwise a modification of the POST data. Core Servlets & JSP discusses this intelligently.

3. I am also using a login system. It operates like this: client makes a call to a SOAP method, passing user name and password as arguments. SOAP server is running with application scope, including some singleton classes for managing user lists, etc. If the server likes the user name and password, it generates and returns a timestamped key to the client and stores the key in a list. For all other requests from the client, the key must be included as one of the parameters. Keys are deleted from the list when the client calls a logout method or after a certain period of time.

Mark


At 11:22 AM 10/9/01 -0700, you wrote:
I guess the problem is otherway round. "SOAPHTTPConnection" class of SOAP
v2.2 has a method "setMaintainSession(boolean)" for maintaining session, but
it doesn't have support for "Keep-Alive".
Did anyone try using SOAP from applet? Since applet can't open socket to any
host(even if the protocol is "HTTP"), I am currently using a servlet as a
conduit. Is there any direct way of doing this?

thanks,
vishu

-----Original Message-----
From: Roger L. Costello [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 09, 2001 5:34 AM
To: [EMAIL PROTECTED]
Subject: Re: sessions


> Naresh Agarwal wrote:
>
> Apache Soap supports session maintenace. It uses
> underlying HTTP mechanism (cookie based) for session
> maintenace.
>
> You can find more details on it at the following link.
>
> http://xml.apache.org/soap/docs/guide/migration.html

I took a look at this document.  It seems to be addressing the issue of
creating a persistent network connection between between a SOAP client
and server.  I do not believe that that is the type of session which
Oleg is interested in.  I believe that Oleg is interested in an HTTP
session (i.e., a virtual session).  That is, he is interested in
establishing a pesistent "virtual connection" between the SOAP client
and the server, as is commonly used by web sites that implement the
shopping cart paradigm.

Many web sites today implement HTTP sessions using cookies.  The server
sends to the client a cookie (containing typically a session ID), which
the client's browser stores.  Each time the client hits that web site
the browser automatically sends along the cookie to the server.

Naresh, I must admit to being confused by your statement "It uses the
underlying HTTP mechanism (cookie based) for session maintenance".
First, the document you reference seems to be merely addressing how to
set the HTTP header to Connection: Keep-Alive.  Second, I see nothing in
Apache SOAP which allows a server method to set cookies.  Third, I see
nothing in the Apache SOAP spec for storing cookies on the client side.

The SOAP spec seems to suggest that things such as sessions,
authentication, etc can be enabled by placing elements in the SOAP
header section.  This raises several questions in my mind:

1. Has anyone used the header section?  Can you show an example?

2. Since the SOAP spec doesn't define anything in the SOAP header
section then each SOAP implementation is left to define their own way of
implementing sessions, authentication, etc.  Right?  Consequently,
Apache SOAP will not work with MS SOAP, etc.  Right?

/Roger


"MMS <firstam.com>" made the following
 annotations on 10/09/01 11:22:52
------------------------------------------------------------------------------
"THIS E-MAIL MESSAGE AND ANY FILES TRANSMITTED HEREWITH, ARE INTENDED SOLELY FOR THE USE OF THE INDIVIDUAL(S) ADDRESSED AND MAY CONTAIN CONFIDENTIAL, PROPRIETARY OR PRIVILEGED INFORMATION.  IF YOU ARE NOT THE ADDRESSEE INDICATED IN THIS MESSAGE (OR RESPONSIBLE FOR DELIVERY OF THIS MESSAGE TO SUCH PERSON) YOU MAY NOT REVIEW, USE, DISCLOSE OR DISTRIBUTE THIS MESSAGE OR ANY FILES TRANSMITTED HEREWITH.  IF YOU RECEIVE THIS MESSAGE IN ERROR, PLEASE CONTACT THE SENDER BY REPLY E-MAIL AND DELETE THIS MESSAGE AND ALL COPIES OF IT FROM YOUR SYSTEM."

==============================================================================

Reply via email to