Title: Message
The
sessions you describe here are similar to the Conversations we defined in Web
Services Management Framework (WSMF). In WSMF we did not try to define how
sessions were created or maintained - but we recognized the need to manage them
and defined interfaces to do this.
We
defined a Conversation as one services view of a set of related messages. This
definition allows a conversation to exist without defining a formal language for
it such as BPEL, and it allows a service to be aware of related messages,
without necessarily knowing all of the other participating services in the
conversation.
As you
explained WS-Context offers a nice way to define the identity of the context
through the context identifier. This same ID could be used by a manageability
consumer to monitor and control the session resource (context). In WSMF we
defined a number of metrics that a manager might want to monitor as well as the
ability to terminate the Conversation if it proved
troublesome.
The
OASIS WSDM TC has also discussed manageability representations and interfaces
for sessions.
More
information about WSMF and Conversations can be found at:
http://devresource.hp.com/wsmf
The
Conversation managed object is described in the "web services management" spec,
and there is a use case in the "overview".
Regarding the scenario you suggest: I think there is an alternative set
of steps:
1)
client makes first-contact with a service
2)
service calls begin, receives begun message, getting back a context
id
3)
service optionally calls other services, passing the context
id
4) any
response the service makes to the client will include the context
id
5) if
the client makes subsequent calls to the service, it must include the context
id
6) if
the service can recognize that the session is complete, it can send the complete
message, if not the client should do so.
These
steps work somewhat like a web session might. For instance, a shopping site
might have a shopping cart that needs to be maintained as context. In a web
session, the client is not responsible for creating or maintaining the context,
only in passing it back to the service. Usually the service will recognize when
a session is complete and can terminate the session on its own. At least a
service will need to recognize that a client is not coming back and timeout the
session.
Bryan
-----Original Message-----
From: Greg Pavlik
[mailto:]
Sent: Thursday, December 11, 2003
2:27 PM
To: Newcomer, Eric
Cc: ws-caf
Subject: [ws-caf] 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
