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

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

Exactly. Thanks Pankaj.

William

> -----Original Message-----
> From: KUMAR,PANKAJ (HP-Cupertino,ex1) 
> Sent: Sunday, August 31, 2003 10:15 AM
> To: 'Ben Bloch'; VAMBENEPE,WILLIAM (HP-Cupertino,ex1); 
> wsdm@lists.oasis-open.org
> Subject: RE: [wsdm] Requirement to support long-lived interactions
> 
> 
> 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/leav
> e_workgroup.php.
> >
> >
> 
> 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/leav
e_workgroup.php.