[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
You don't need to say anything special to allow partnerLinks to be declared in scopes inside an event handler. There is nothing special about scopes local to an event handler. The current resolution of 75 already allows it. -----Original Message----- From: Yaron Y. Goland [mailto:ygoland@bea.com] Sent: Monday, June 14, 2004 3:34 PM To: Satish Thatte Cc: wsbpel@lists.oasis-open.org 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_workgr oup.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_workgr oup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]