Session Scenario (Re: [ws-caf] Context example assignments)

This is meant to suggest a simple, illustrative use case for context.
It is in no sense
meant to be normative about anything.

In many scenarios, there is a desire for web services to manage context
at an infrastructure level to support interaction models that maintain
state between interactions. Today, this is achieved with several
proprietary models. One is to piggyback on the HTTP session of a
servlet engine (or equivalent). Obviously, this is undesireable as it
couples the service's conversational semantics to the application
protocol used to
shuttle SOAP messages around. There are also proprietary specs
(SOAPConversations) that provide stateful context for interactions with
a web service.
This discussion proposes a way to achieve session-oriented services
using WS-Context. To my way of thinking, WS-Context provides us with an
ideal framework for a session protocol that can be used to managed
client specific-sessions or fully distributed multi-service sessions. I
presume the latter would rely on WS-Coordination Framework to provide
coordinated termination across multiple session-oriented services, so I
won't dwell on that aspect here.

For the purposes of our discussions a session may be described as the
temporally-bounded maintenance of resources on behalf of a client or
activity. Sessions may involve one or more services, though a service
will typically require that clients initiate a session through a
particular port, as you might expect, this example treats that port as
described by the ActivityService
abstract wsdl defined in WS-Context. This means that clients may begin
and end sessions, and that sessions may be timed out by the
infrastructure.. How sessions are managed or restricted and how
resources are maintained between interactions is an implementation
detail of a service.

As we know from the F2F, WS-Context provides a lightweight mechanism
for allowing one or more Web services to share a common context. In the
present case, a context is used to represent a session, where sessions
are modeled as an activity. For the case of a simple client-server
model, there may be a one-to-one correspondence between the "stateful"
service and an activity service. Or it may be the case that the initial
interaction with a service returns as session context in some cases
without client demarcation. This would be very much similar to the way
web browsers and web servers manage session cookies. I think this helps
to illustrate the flexibile structuring mechanisms that WS-Context
allows.

To support a session protocol, the context as defined in the Schema for
WS-Context would probably need to be extended or augmented. While,
services may be able to use the context identifier as an
opaque session identifier to correlate requests to sessions, it might
be that services need to provide their own session identifiers within
an
activity. I can also imagine that services may externalize their state
to the context and expect it to be present in the context in subsequent
interactions to facilitate loose coupling and minimize resource
consumption in the stateful service (in some cases, this would mesh
very nicely with the "pass by reference" model in WS-Context, as it
would allow the ContextManager to act as a single point of truth for
the state). Both mechanisms might need to be
used within the same context. I'm not clear whether the best way to
extend the context is through schema extension or using extensibility
elements directly. CAF seems to follow the model of schema extension,
so this would probably be the way to go.

Anyway, the client should be responsible
for submitting contexts as headers during request interactions once a
session has been initiated, though how this might occur is an
implementation detail. You can imagine that the request association
with a session context could be entirely managed by a web services
platform.

A Scenario

1 )To start a session, the client application invokes begin on the
ActivityService supported by the session oriented service.

2)  The begin method will return a session context in the begun reply. 

3) The context is included as a header on subsequent requests to the
session-oriented service. During interactions the "stateful" service
maintains
conversational state.

4)  To terminate a session, the client invokes the complete method on
the ActivityService. This invalidates the session. Sessions may be
invalidated due to internal errors, administrative intervention,
resource conservation heuristics, timeout, etc.

I should note that there is a semantic mismatch between the
CompletionStatus mechanism and the requirements for session. Session
will not be able to make sense of FAIL_ONLY or FAIL. It's not clear to
me how this should be handled, but I suspect it will be common case
that with many protocols.

Also, note that while the scenario of a client to single session
oriented service is a degenerate case of multiparty sessions, I assume
that the session mechanism may be shared directly by the
ActivityService and the session oriented service in the interaction I
describe. More complicated interaction models can be supported in
WS-Coordination Framework is introduced.

Newcomer, Eric wrote:

  
  
  
Hi,

  
 

  
For
Monday's concall it would be great to have some of the context examples
circulated to the email list far enough in advance to be able to
discuss them on the call.

  
 

  
In
no particular order:

  
 

  
--
User Context example, Jan Alexander

  
--
Security context example, Eric Yuan

  
--
Database/File/Device example, Eric Newcomer

  
--
Cluster group membership example, Mark Little

  
--
Session state example, Greg Pavlik

  
 

  
I
think that's it, someone let me know if I've forgotten to include
them.  Apologies for the delay in getting the reminder out.

  
 

  
Eric       
  

  
 

  
 

  
 

  
 

  
Eric Newcomer

Chief Technology Officer

  

  
-------------------------------------------------------

IONA Technologies

200 West Street Waltham, MA 02451 USA

Tel: (781) 902-8366

Fax: (781) 902-8009

-------------------------------------------------------

  Making Software Work Together TM