RE: [ws-caf] Session Scenario (Re: [ws-caf] Context example assig nments)

[Mark Little <Mark.Little@arjuna.com>]

It would seem like an example of how WSDM could use WS-Context would help to 
illustrate that WS-Context is general enough, or illuminate those areas where 
we need to do more work. If we go back to the example Greg outlined, would you 
say there's anything missing from the *model* aspects that WSDM has, i.e., is 
this a good starting point to then get into specifics for?

Mark.

>===== Original Message From "MURRAY,BRYAN (HP-Seattle,ex1)" 
<bryan.murray@hp.com> =====
>WSDM has not yet decided whether to address management for sessions yet.
>This decision is not likely to be made until later this spring due to other
>priorities.
>
>I suspect that WSDM will not require WS-Context for use in managing sessions
>because the WSDM view of a session includes ad hoc exchanges of related
>messages independent of any specific method of identifying that they are
>related. Messages all referencing the same WS-Context would certainly be
>thought of as a session, but WSDM is likely to want to remain open to other
>methods of identifying related messages and be able to manage those sessions
>as well.
>
>If WSDM decides to specify how to manage sessions, it will be important to
>work with WSDM in order to ensure that WS-Context sessions can be managed.
>
>Bryan
>
>These opinions are my own and do not reflect any official statement from the
>WSDM WG.
>
>
>-----Original Message-----
>From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com]
>Sent: Tuesday, December 30, 2003 4:53 AM
>To: MURRAY,BRYAN (HP-Seattle,ex1); Greg Pavlik
>Cc: ws-caf
>Subject: RE: [ws-caf] Session Scenario (Re: [ws-caf] Context example
>assignments)
>
>
>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:bryan.murray@hp.com]
>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 <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:greg.pavlik@oracle.com]
>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
>eric.newcomer@iona.com <mailto:eric.newcomer@iona.com>
>-------------------------------------------------------
>IONA Technologies
>200 West Street Waltham, MA 02451 USA
>Tel: (781) 902-8366
>Fax: (781) 902-8009
>-------------------------------------------------------
>Making Software Work Together TM