[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 126 - Event Handlers with local partnerLinks & CorrelationSets
Just one comment: Even the myRole part of a partnerLink must be allowed to
be changed (especially important for long-running processes). I.e. the
terms "fixed" and "statically bound" have to be interpreted accordingly.
Regards,
Frank
To: <wsbpel@lists.oasis-open.org>
cc:
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]
Sent: Thursday, June 10, 2004 11:14 AM
To: wsbpel@lists.oasis-open.org
Subject: [wsbpel] 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.
Issue - 126 - Event Handlers with local partnerLinks & Correlation Sets
Status: open
Categories: Correlation, Partner links, Event handling
Date added: 10 Jun 2004
Submitter: Yaron Y. Goland
Date submitted: 04 June 2004
Description: This issue has two closely related parts. For each part, an
example and a problem description are given. The submitter's proposal is
also in two parts.
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"
...
...
Changes: 10 Jun 2004 - 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 - 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).
To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php
.To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php
.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]