Re: [wsbpel] RE: Questions (RE: [wsbpel] Proposed agenda for May28-29 WS BPEL TC face to face)

[Assaf Arkin <arkin@intalio.com>]

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