RE: [wsdm] Requirement to support long-lived interactions

["Sedukhin, Igor S" <Igor.Sedukhin@ca.com>]

I looked through this and here is our (CA) stance.

[
the manager will need to get hold of all the messages (assuming the correlation ID is in a SOAP header, if it's at the transport level it's a whole other problem) and understand the syntax of this correlation mechanism.
]

We do not see anything wrong with doing exactly that.

[
One of the key reasons why we are working to standardize MOWS is so that a generic manager can do something useful to manage a Web service (ping it, monitor its state, get performance info, etc...)
]

And I guess that's where we may differ slightly. We want to enable a GENERIC Web Service to expose minimum sufficient set of manageability capabilities so that an INTELLIGENT manager can do the job. The least impact MUST be on the resource. If a generic client wants to consume manageability, then it may talk to a mid-level manager/aggregator which may expose its understanding of long-running transactions, etc. That is clearly future work from our stand point.

[
- the web service already has to analyze and persist the correlation information. Sharing this with the manager is very little extra work in most cases if a standard interface to do so is defined.
]

In case of ASP.NET, for instance, .NET framework takes care of sessioning and correlation, etc. It is quite tricky for a ShoppingCart service to normalize and expose that information. I would not count on service itself knowing and being able to expose that. In case of Grid (e.g. Globus) that is also part of supporting infrastructure. I would not assume that actual service has to "analyze and persist the correlation information".

-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788


-----Original Message-----
From: VAMBENEPE,WILLIAM (HP-Cupertino,ex1) [mailto:vbp@hp.com] 
Sent: Thursday, August 28, 2003 9:55 PM
To: wsdm@lists.oasis-open.org
Subject: [wsdm] Requirement to support long-lived interactions



Hi all

After the discussion on the phone this morning, we have an open issue to decide whether we want to support services that engage in long-lived interactions in the first phase of our work or leave it to the "future work" section. As requested, I am sending this email to explain why I believe that it should be in the first phase and therefore moved to section 2 of the MOWS requirements.

Let's define a long-lived interaction from the point of view of one web services as an interaction composed of several messages that are somehow correlated (whether the actual correlation happens through SOAP headers, at the transport level or any other mechanism is irrelevant). Many realistic uses for web services require such long-lived interactions. When a message arrives, this message is associated to a context that contains information about previous messages that are part of this interaction. The typical example is a shopping cart of course. In order to process the message in this kind of situation, the service has to process the correlation information and retrieve the context that this message should be processed in. The question is, do we want to allow the service to share information about these contexts with the manager.

If we don't, the manager will see messages coming back and forth and will have no idea of how they relate to one another. If it wants to know more, the manager will need to get hold of all the messages (assuming the correlation ID is in a SOAP header, if it's at the transport level it's a whole other problem) and understand the syntax of this correlation mechanism. Both requirements (that the manager understand the correlation mechanism used by the application and that the manager processes all the messages going back and forth) are unreasonable in many cases. One of the key reasons why we are working to standardize MOWS is so that a generic manager can do something useful to manage a Web service (ping it, monitor its state, get performance info, etc...) without having to understand the business logic of this service.

Similarly, the manager should be able to access information such as:
- notify me when a new long-lived transaction is initiated
- how many long-lived transactions are currently in progress
- how many messages has this long-lived transaction included so far without understanding the business logic of the service. Obviously you can always do a lot more if the manager knows more about the resource, but in general it is the managed object that is intimately aware of what the resource is about, not the manager.

A few closing points:

- the web service already has to analyze and persist the correlation information. Sharing this with the manager is very little extra work in most cases if a standard interface to do so is defined.

- the WSMF Conversation managed object is one approach to supporting this requirement. It demonstrates that it can be done pretty easily. But it's not the only approach, you can meet this requirement without creating a new managed object if this is preferred by the group.

- of course this interface would be optional like any other. We allow services to share this information if they want to but no service would be required to, whether their interactions are long-lived or short-lived.

- another step after this is to provide additional management features in the case where the long-lived interaction is described by a standard language such as BPEL. This can be left in the "future work" section. The requirement I describe above is useful without such process languages and provides a good foundation on which to extend later to support process languages.

Regards,

William

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leave_workgroup.php.