In WS-CDL, choreography units can be defined as being isolated - so when 'performed' sub-choreographies bind variables from a parent choreography, changes to those variables are not made visible to sibling sub-choreographies until the isolated sub-choreography has completed.
When using a process engine, this type of behaviour can be controlled as part of the runtime infrastructure - but this is a coarse grained solution for trying to manage concurrent access to business information.
However, when an endpoint is implemented with a general programming language, it is the programmer's responsibility to code this behaviour - allowing for finer grained control.
With the Conversation based ESB action mechanism we have a middle ground solution - on one hand there will be infrastructure support for managing conversations, and the access to variables will be managed by this infrastructure.
On the other hand, having programmatic access to information in the child and parent sessions, means that the custom code could have finer grained control of concurrent access to the information for the overall session.
Therefore at present, I believe we should not attempt to add an explicit isolation mechanism into the conversation based actions - instead allow the custom code to deal with this issue. As we gain more experience, it may highlight a more appropriate mechanism (e.g. additional support in the infrastructure classes).
Any objections to this approach?
