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

[Ugo Corda <UCorda@SeeBeyond.com>]

Title: [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?