[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 126 - Event Handlers with local partnerLinks & Correlation Sets
A comment and a question. Comment: a partnerLink does not “point
at” a partner for its inbound (myRole) part. That part can be statically
bound to a fixed endpoint that is communicated to all actual partners. Thus the
example in Part A is at least partially mistaken Question: how is this issue distinct from
issue 75? Satish From: ws-bpel issues
list editor [mailto:peter.furniss@choreology.com] 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. Issue
- 126 - Event Handlers with local partnerLinks & Correlation Sets
Status: open 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. 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]