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

Title: Message

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:] 
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:]
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