Requirement to support long-lived interactions

["VAMBENEPE,WILLIAM (HP-Cupertino,ex1)" <vbp@hp.com>]

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