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

["KUMAR,PANKAJ (HP-Cupertino,ex1)" <pankaj_kumar@hp.com>]

As per my understanding, William is talking about supporting the management
view of such multi-message, long-running interactions through MOWS and not
about the infrastructure for making these interactions.

> One interesting aspect
> relevant to the WSDM TC may be the management of these LRT's (another
> Management Of vs Management Using debate).

This is exactly the point. Though I don't think we talked about using such
interactions for supporting manageability (MUWS).

My 2 cents.

Regards,
Pankaj Kumar.
-----Original Message-----
From: Ben Bloch [mailto:ben_b54@hotmail.com]
Sent: Sunday, August 31, 2003 6:49 AM
To: VAMBENEPE,WILLIAM (HP-Cupertino,ex1); wsdm@lists.oasis-open.org
Subject: Re: [wsdm] Requirement to support long-lived interactions


Bill,

Unfortunately I missed this discussion on the phone.  However, from what I
understand from your description, it sounds like existing LRT models,
including BTP at Oasis, WS-T Business Activity and WS-TXM Long Running
Actions (albeit proprietary for the latter 2), would be sufficient for most,
if not all, of the requirements you describe.  Or am I missing something
regarding possibly unique requirements within WSDM?   One interesting aspect
relevant to the WSDM TC may be the management of these LRT's (another
Management Of vs Management Using debate).

As you suggested regarding BPEL,  BPEL will in fact at looking at these 3 in
particular as part of its activities.  WSBPEL TC pages has info on these.

Ben

----- Original Message ----- 
From: "VAMBENEPE,WILLIAM (HP-Cupertino,ex1)" <vbp@hp.com>
To: <wsdm@lists.oasis-open.org>
Sent: Thursday, August 28, 2003 9:54 PM
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.ph
p.
>
>

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.ph
p.