[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
Please see below Satish Thatte wrote: > > 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 > I certainly agree with the statement that 'myRole' can be statically bound. What I don't understand is how that applies to part A. What, specifically, is specified in part A that would require any 'myRole' to not be statically bound? The problem part A refers to has to do with 'partnerRole' not 'myRole'. > > Question: how is this issue distinct from issue 75? > Issue 75 only allows partnerLinks to be declared as children of scopes but that doesn't solve the issue brought up in part A since the event handler still inherits the partnerLink from outside itself. I did think about proposing that we allow the partnerLink to be declared in a scope in the event handler but when I worked through the standards wording on that it turned really ugly. It turned out to be much simpler just to allow the partnerLink to be defined directly as a child of the event handler rather than as a child of a scope which is itself a child of the event handler. > > > > > 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 > <http://www.oasis-open.org/apps/org/workgroup/wsbpel> 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 > <http://www.oasis-open.org/apps/org/workgroup/wsbpel/documents.php> - > 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 > <http://www.choreology.com/external/WS_BPEL_issues_list.html>. > > > * Issue - 126 - Event Handlers with local partnerLinks & Correlation > Sets * > > * Status: * open > *Categories:* Correlation <#category_correlation>, Partner links > <#category_partner_links>, Event handling <#category_event_handling> > *Date added:* 10 Jun 2004 > *Submitter:* Yaron Y. Goland <mailto:ygoland@bea.com> > *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]