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
