[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue - 126 - Event Handlers with local partnerLinks & Correlation Sets
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 version of the document entitled in the "Issues" folder of the WSBPEL TC document list - the next posting as a TC document will include this issue. The list editor's working copy, which will normally include an issue when it is announced, is available at this constant URL.
Part A
Example: A factory consists of manufacturing machines and a system of heat monitors. A BPEL process receives updates from the heat monitors and uses the updates to configure the manufacturing machines so they operate at their ideal temperature. The BPEL process does not know at deployment time what heat monitors are available and the number of available monitors is constantly changed anyway as new ones are added, old ones are replaced, etc. Additionally since the updates can indicate emergency situations its important that the updates be accepted asynchronously and on-demand so that emergency action can be taken if necessary. Therefore an event handler is used to deal with these messages.
Problem Description: The BPEL process wants to create an event handler which can accept incoming heat status updates. All heat status messages are received on the same operation on the same portType. The BPEL code looks like:
process
partnerLinks
partnerLink name="monitor" ...
scope
eventHandlers
onEvent partnerLink="monitor" portType="tempEvents"
operation="tempUpdate" ...
...
...
Time 0 - Scope is entered and onEvent is activated
Time 1 - Monitor A sends a "tempUpdate" message that is caught by the onEvent handler. partnerLink monitor is initialized to point at Monitor A.
Time 2 - Monitor B sends a "tempUpdate" message but the message is thrown on the floor because partnerLink monitor is already initialized to point to monitor A.
Part B
Example: A BPEL process places an order for a set of items with a known partner. The BPEL process then expects to receive asynchronous notifications of the status of the shipment. Each notification will contain the orderID used on the initial order. However it is possible for a single order to be broken up into multiple shipments. Therefore each update message contains a shippingID. Upon receiving a shipping update the BPEL process is expected to send back a response confirming receipt of the update that contains both the orderID and the shippingID.
Problem Description:
process
partnerLinks
partnerLink name="partner" ...
correlationSets
correlationSet name="orderID"
scope
<!-- Init partnerLink & orderID, place order -->
...
scope
correlationSets
correlationSet name="shippingID"
onEvent partnerLink="partner" ...
correlations
correlation set="orderID" initiate="no"
correlation set="shippingID" initiate="yes"
scope
...
reply partnerLink="partner" ...
correlation set="orderID" initiate="no"
correlation set="shippingID" initiate="no"
...
...
Time 0 - The parent scope is entered, the partnerLink pointing at the partner is initialized and the order is placed.
Time 1 - The inner scope is entered, the onEvent handler becomes active and waits for a message from the partner.
Time 2 - The first status message arrives and initiates the shippingID. A response is sent to the partner indicating receipt of the status message.
Time 3 - The second status message arrives. But it turns out that the order has been split and so this second status message has a different shippingID then the first status message. Since the shippingID has already been initialized to a different value the second status message is dropped on the floor.
Note, btw, that strictly speaking all messages after the first one no
matter what correlation set they had would have been rejected because
initiate="yes" would cause an error after the first message. While this
may appear to argue for initiate="maybe" this fault isn't actually
relevant to this issue.
Submitter's proposal:
Part A
The partnerLink attribute on the onEvent element be made optional and a partnerLink element be added as an optional child of the onEvent element. The optional partnerLink element would be used to declare a partnerLink that was local to each instance of the onEvent handler. It would be mandatory that all onEvent handlers either use the partnerLink attribute or the partnerLink element but not both.
In other words:
process
scope
eventHandlers
onEvent portType="tempEvents" operation="tempUpdate" ...
partnerLink name="monitor" ...
...
...
Part B
Add the correlationSet element as an optional child of the onEvent element. Any correlation set values defined on the onEvent element are only available within the scope of the onEvent.
process
partnerLinks
partnerLink name="partner" ...
correlationSets
correlationSet name="orderID"
scope
<!-- Init partnerLink & orderID, place order -->
...
scope
onEvent partnerLink="partner" ...
correlationSets
correlationSet name="shippingID"
correlations
correlation set="orderID" initiate="no"
correlation set="shippingID" initiate="yes"
scope
...
reply partnerLink="partner" ...
correlation set="orderID" initiate="no"
correlation set="shippingID" initiate="no"
...
...
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 - 126 - [anything]" or is a reply to such a message. If you want to formally propose a resolution, please start the subject line "Issue - 126 - Proposed resolution", without any Re: or similar.
To add a new issue, see the issues procedures document (but the address for new issue submission is the sender of this announcement).
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]