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);
>
> 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:]
> Sent: Sunday, August 31, 2003 6:49 AM
> To: VAMBENEPE,WILLIAM (HP-Cupertino,ex1);
> 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)" <>
> To: <>
> 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.
