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

["Sedukhin, Igor S" <Igor.Sedukhin@ca.com>]

William,

[
In some case it might be an acceptable approach but in the general case it is very limiting. If only for the performance overhead.
] 

That depends very much on how you implemented the manager and the manageability "helper". I claim it can be done very efficiently in general case, but we don't have to standardize an approach to implemetation, do we...

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

And I'm sayng that there are sufficient technologies out there to make it work without having to customize the manager to the correlation mechanism of the resource. 

[
Not to mention the case where the messages are encrypted, you now have to entrust the manager with they keys and decrypt twice?
]

Again, this depends on how the manageability "helper" is implemented. For example if it is part of the WS platform, encyption is non-issue.

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

I haven't seen any ratified specifications that would make long-lived interactions part of a generic web service. This is becoming very similar to "stateful vs. stateless" argument. Points can be made "esoterically" to in favour of both right now. This is not very practical. It seems that we're pushing the cart before the horse, and this is exactly why we want this to be part of the future work. I don't think it is reasonable to get on to manage something that has not solidified yet. It'll be something we will have to redo later. It won't help anybody now.

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

Why is there so much worry to make it useful enough for a generic (read low intelligence) manager? Why push it to the resource? There are a handful of managers and zillions of resources. Why can't we do a good job with a manager and make the least possible requirements on the resources.

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

How can we be sure now (in our January 2004 delivery) that we can create a sensible "base" for BP/TX management now?
Why don't we address first things first. Our goal is to address the "pain points" that our clients had so far. And there are a lot more fundamental things than that right now.

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

Yes, exactly, but implement sufficiently for an *intelligent* manager :).

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

Can we be sure that there is a common way in which all implementations do this? Can we be sure that if we spend time analysing it today it'll still be reasoable after Jan 2004? Can we first address things that we can be sure won't change?

Regards,
Igor