[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] RE: Questions (RE: [wsbpel] Proposed agenda for May28-29 WS BPEL TC face to face)
Satish Thatte wrote: >>Aspect#1: Assuming a session based communication protocol and >>WS-Addressing as a way of initiating the session using some form of >>handle explicit correlation might eventually become unnecessary. We >>should work out the details of what it would take to get this >>simplification. However, in general we probably cannot assume >>session-based communication. There are scenarios like multi-start >>activities (example in spec) where correlation is not avoidable. >> >> >> In my opinion using two different mechanisms would make it hard to guarantee consistency of the implementations which would hinder the portability/interoperability of the language. It may boil down to some installments of the process assuming sessions and others relying on correlation and neither working as expected. We need to make a decision one way or another to ensure that two processes deployed in different environments can in fact interoperate based on the definitions available to both of them. One possibility is to always use correlations include for handling sessions, e.g. by standardizing a propertyAlias for session identifiers where the protocol support it. I suggest we consider this the default option if we cannot find another solution. Another possibility is to always use sessions, but that clearly does not work. There are cases where you do need correlation. The two I have in mind is multiple start activities that need to receive correlated messages, and parallel activities that may use the same session but need to distinguish the different conversations going on. From all the use cases I have, I believe we can support these scenarios by reducing the complexity of the correlation mechanism to the bare minimum and always using it in addition to a session where a session already exists. The question arises, can you depend on the communication mechanism to always be session-based? The process definition would be more usable if it could remain protocol independent and so make the assumption that all communication mechanisms are always session-based. If we could handle sessions in the protocol binding that would allow us to define processes with the assumption of a session-based mechanism and support a variety of protocols and the different ways in which they handle sessions. I am looking into this right now, and my impression so far is that it can be done by standardizing on a set of properties that would be used for session handling, and then using either generic headers from session-based protocols, or addressing this in the protocol binding for specific protocols that do not support sessions natively. arkin
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]