RE: [wsrp-interfaces] Stateful Web Services discussions in WS-I

[Thomas Schaeck <SCHAECK@de.ibm.com>]

I guess we'll have to see how things turn out related to stateful web
services.

In any case we have the option to stick to passing the WSRP session ids
explicitly in the WSRP protocol.

If cookies in SOAP headers would be used for SOAP sessions between SOAP
clients and portals, passing the WSRP session ID would be required to
identify the right end user/client scope within the consumer scope.

Regarding WS-Security there is probably a similar issue ...

Best regards,

Thomas



Ugo Corda <UCorda@SeeBeyond.com> on 07/05/2002 08:20:12 PM

Please respond to Ugo Corda <UCorda@SeeBeyond.com>

To:    Thomas Schaeck/Germany/IBM@IBMDE
cc:    "'wsrp-interfaces@lists.oasis-open.org'"
       <wsrp-interfaces@lists.oasis-open.org>
Subject:    RE: [wsrp-interfaces] Stateful Web Services discussions in WS-I



Hi Thomas,

I understand the distinction you are making, but wouldn't it be possible to
tag information from different user sessions with different IDs (or
something similar) in the SOAP headers so that the producer could still
know
which one is which? (Of course, in case WS-I decides to go with cookies in
SOAP headers, we might still need to ask additional support for cases like
ours).

Also, if what you mention is a real difficulty, couldn't that also apply to
an approach like WS-Security, which assumes the SOAP client is the actual
client and not a multiplexing mediator?

Regards,
Ugo

-----Original Message-----
From: Thomas Schaeck [mailto:SCHAECK@de.ibm.com]
Sent: Friday, July 05, 2002 10:58 AM
To: Ugo Corda
Cc: 'wsrp-interfaces@lists.oasis-open.org'
Subject: Re: [wsrp-interfaces] Stateful Web Services discussions in WS-I



One thing to keep in mind is that WSRP sessions are not sessions between
SOAP clients and SOAP services - WSRP sessions are typically sessions
between end user's browsers and the WSRP SOAP service, mediated by the SOAP
client.

This means that it is probably impossible to handle the WSRP sessions at
the SOAP infrastructure level, since if there would be something like a
SOAP session between the portal as the SOAP client and the WSRP producer as
the SOAP service, typically many WSRP sessions would be multiplexed through
the session between the portal and the service, i.e. typically at least one
for each active portal user.

Best regards,

Thomas



Ugo Corda <UCorda@SeeBeyond.com> on 07/05/2002 07:50:37 PM

Please respond to Ugo Corda <UCorda@SeeBeyond.com>

To:    "'wsrp-interfaces@lists.oasis-open.org'"
       <wsrp-interfaces@lists.oasis-open.org>
cc:
Subject:    [wsrp-interfaces] Stateful Web Services discussions in WS-I





I recently started to follow the discussions on the WS-Interoperability
mailing lists, and I found one about stateful web services support that I
think is very relevant to WSRP. I enclosed an excerpt from the most recent
conversation below.

One interesting point raised is where 'cookie' information should be
maintained, the choices being in the transport, in SOAP headers, or in the
application parameters.

As I understand it, the agreement during our recent face to face was to
pass session state information as parameters in the WSRP protocol. But I
imagine the decision was meant only at a logical level, so that currently
there is no exact determination yet of where that information would be
physically kept. I suppose our options are to pass session state
information either in the SOAP envelope (i.e. as application parameters) or
in SOAP headers (i.e. as part of the SOAP infrastructure, like security
info in WS-Security). If we have strong feeling in either direction, I
would be happy to bring that input to the WS-I conversations.

Ugo

Dr. Ugo Corda
SeeBeyond Technology Corporation
Standards and Product Strategies
+1-626-471-6045 (US-Pacific)

============================================================
[excerpt from WS-I conversation]

Issue

Without state support web services becomes a one-time operation. In order
to support efficient, stateful conversation between a client and server
some kind of state support is required. Currently, no such support is
specified or mandated as part of web service 'compliance' leaving support
down to tools, or application vendors.

Observations

The best outcome for state support is one where all tools vendors support
the same agreed system in the same way or at least using the same
methodologies (like cookie support in HTTP today). While this may be
unworkable at least in the first spec, it would provide the best support
for application vendors and end users of web services.

From an application vendors standpoint, I think tool vendors support is the
most useful. They can code to a standard knowing clients will understand
how to pass the 'cookie' backwards and forwards as laid out in the spec
even if the client is hand coded and not for example .NET.  Assuming tool
use, end users need not be aware of, or need to take action to support the
use of 'cookies' in maintaining state.

If state support is left to application vendors, several routes are
possible:

        The application can handle state by passing a 'cookie' back as a
response element, and requiring it as a request element on subsequent
requests.

        'cookies' can be passed via the soap header, or the transport layer
assuming the vendor has control of both ends ( although I suspect they

                may then fall into the tools vendor category).

        I've actually run out of scenarios, although I'm sure there are
others (Anne - you guys map from http to soap header right?) ..

Different vendors do things differently and I think from a user (or app
vendor) perspective if you are trying to tie several web services together
(WSFL or XLANG perhaps) and they all use different methods of supporting
state things are going to get messy fast.  I also think that once we start
down the path of vendors doing it their way, it could take a lot longer to
get a spec agreed on and supported.

I don't think this should be out of scope given the interop issues it
raises, but perhaps it is too much for 1.0 spec. I'm not sure we can take a
middle ground, any suggestions?

Solutions?

I feel the best approach would be to support cookies in the soap header.
That makes this at least transport independent, and removes the requirement
on the end user to pass and maintain an element of the message for each
call. See my last 'other issues' bullet though. I don't see much wrong with
the way cookies work in HTTP headers today, the work for multiple apps on
the same server, the client piece handles sending/not sending cookies to
the relevant server (which could help in the WSFL / XLANG arena). Perhaps a
storage issue will prevent them working exactly the same as http cookies
today, but a similar system seems to be the most workable to me.

Other issues state support raises.

What happens if the user wishes to turn off 'cookie' support? How should an
application react? Should it work without state support in a limited
fashion? Should it fail to work at all? I've not seen anything from the
scenarios group on this, which is interesting. I'd have thought it would be
a big issue. Perhaps this is trying to guide vendors too much, rather than
addressing spec issues (I hope that makes sense).

        For example element v. type strikes me as more of a spec issue. How
to support state is more of vendor issue? Can we get this into a 1.0 spec,
and expect it to be supported?  Is relying on soap as the "wrapper" for web
services, and therefore the location for the cookies incorrect?





----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>