In the conversation ESB action mechanism, it will be possible to specify an action that links to other service descriptors, followed by other conversation based actions.
With the exception of one situation, this will result in implicit concurrency being defined.
For example, if we have an IfAction, that is selecting one path out of many, based on conditions, this will result in another service descriptor being invoked to handle the path selected. If the IfAction is followed by other conversation based actions, then these subsequent actions are effectively being performed concurrently with the path selected in the IfAction.
My preference would be to prevent this situation being defined, during validation, as it is possible to specify concurrent paths explicitly using the ParallelAction. If these situations are not prevented, then it could inadvertantly lead to unexpected runtime behaviour.
The other viewpoint is that when conformance checking is available against a choreography, inadvertant concurrency should be detected as it would not match the expected behaviour. Although this is true, I still feel it is better to be explicit in the description, to ensure clarity when viewed by different users.
The exception to this situation is the PerformAction, when performing a sub-session asynchronously - in this case it should be valid to have subsequent conversation based actions.
