Title: Message
Bryan,
I
think the scenario you outline is correct for context management, i.e. passing
the ID on each call is a good way to do it. In WS-Context we also define a
service to manage the context. The application can pass the ID to the
service to access the context, and the service can take care of timeouts,
ensuring the context is up to date, and so forth.
One
question I have in general about the use of context is whether it may make sense
to try to model it as a generic Web resource, meaning the ID could be the same
as a URI pointing to the context data structure that lives on the Web
somewhere.
Are
you also suggesting that the WS-CAF team should work more closely with the WSDM
TC to see whether it makes sense for WSMF to include or reference
WS-Context?
Eric
-----Original Message-----
From: MURRAY,BRYAN
(HP-Seattle,ex1) [mailto:]
Sent: Thursday,
December 11, 2003 7:35 PM
To: 'Greg Pavlik'; Newcomer,
Eric
Cc: ws-caf
Subject: RE: [ws-caf] Session Scenario
(Re: [ws-caf] Context example assignments)
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
