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

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

Hi Igor,

Thanks for your response. Please see comments inlined below.

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

In some case it might be an acceptable approach but in the general case it
is very limiting. If only for the performance overhead. Also because if I
want to set up a proprietary correlation mechanism with my partner I am
prepared to write a custom app to handle this but I'd rather not have to
also get a custom manager if there is a way to allow my standard manager to
manage this interaction. Not to mention the case where the messages are
encrypted, you now have to entrust the manager with they keys and decrypt
twice?

> [
> 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.

My view is that long-lived interactions are part of a generic web service.
We are not talking about a specific correlation mechanism here, a specific
business process language or a specific application. We are talking about
the generic notion of a service engaging in a long-lived interaction,
independently of the semantics of this interaction. If we support this, a
generic manager will be able to understand and manage a web service that is
involved in long-lived interactions. You can add more intelligence on either
side if more knowledge about specifics (such as what this service actually
provides) is available, but this is not what I am proposing. We are still
talking about generic web services, I am just trying to make sure that our
generic framework is complete enough to be useful.

Of course I am not talking about requiring web service to support long-lived
interactions, just allowing those who do to expose this information to the
manager. And this would make it a lot easier later to add support for other
specifications in the business process/transaction space since there will be
a common base to extend from.

> [
> - 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".

In both cases (ASP.NET and Grid) the best would be if the plumbing code
(respectively ASP.NET and the Grid Toolkit) implemented the part of the
management interface that it is able to implement. For example, if I call
"getLastMessage" on a service managed object it would be great if as a
service implementer I don't need to implement that and my web service stack
(WebLogic, .NET, Axis...) implements this for me. Similarly, this underlying
plumbing could implement the management functionalities that relate to
long-lived interactions since this is the place where the correlation is
handled. The value of WSDM providing a standard interface that supports
exposing services engaged in long-lived interactions is that the web service
platform people like BEA, the Axis folks and Microsoft know what to
implement and end users benefit from having their tools and management apps
already talking. This is how we achieve interoperability among the platform
vendors and among the management applications.

Regards,

William


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