[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue - 33 - Race condition before correlation set is established
This issue has been added to the wsbpel issue list. The issues list is posted as a Technical Committee document to the OASIS WSBPEL TC pages on a regular basis. The current edition, as a TC document, is the most recent document with the name wsbpel_issues_list.html in the "Issues" folder of the WSBPEL TC document list - the next posting will include this issue.
Handling Callbacks in a Business Process (especially if it is done as suggested in the Initial Example of the 1.1 Spec) is depending on unspecified runtime engine behavior.
If we assume, that a new entry for a correlation set is entered on activation of the receive, and we also assume, that incoming web service requests on ports which have no matching correlation are rejected, we have a small window in the system, where a particular information was requested, but the related receive activity was not yet activated. This could be, because the requested party will answer, before the SOAP communication was finished, it could also be, because the runtime engine is loaded, to not enable the receive fast enough. It could also be because the runtime engine was putting the process to sleep because or priority issues.
The specification should either enforce a semantic which will allow <sequence><invoke><receive></sequence> process, and force implementers to keep that case in mind, or the specification should endorse (and then actually use in its own samples) an alternative way.
Please keep in mind, that it might not be enough to assure, that implementations can handle the response to an invoke of the directly following activity. Flows and sub process could be involved, too. In the case of flows, the current spec does not assume any implementations, which is good for implementing conforming engines, but it is also bad for specific modeling techniques which may be unsafe to use. A good sample would be a <flow><receive /><invoke /></flow> which also has the same (maybe even bigger) race condition window to allow callbacks.
A process which creates a correlation id, waits for the response and then invokes the service is a typical use case. Issue 31 is a feature request which would depend on this, and will suffers from the same unspecified behavior.
Alternative solution (which is a bit overhead, unfortunately): allow a new link type "ready to receive" from receive components to invoke components, which will be enabled, as soon as the corresponding correlation entry is made, and the system is listening for the callback. Brainstorming welcome.
Links: issue 31 : Unique identifier for establishing new correlation
Changes: 9 Jul 2003 - new issue
To comment on this issue, please follow-up to this announcement on the wsbpel@lists.oasis-open.org list (replying to this message should automatically send your message to that list), or ensure the subject line as you send it starts "Issue - 33 - [anything]".
To add a new issue, see the issues procedures document.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]