[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 139 - A first attempt at a proposal for partnerLinksemantics
Please see below Satish Thatte wrote: > > > "When a message activity is initiated the current value of the > partnerLink's roles are copied for use by that activity. Therefore the > message activity will be unaffected if, during the execution of the > message activity, the value of the roles on the partnerLink are changed, > e.g. by another flow in the process or by the administrator." > > There are any number of infrastructure wierdnesses that will affect > process behavior. We cannot anticipate and legislate behavior regarding > them all, especially when, as in this case, there are very reasonable > implementation choices where this is difficult to conform to. IMHO this > is a case where we must follow Wittgenstein's dictum of "whereof one > cannot speak, thereof one must be silent"; otherwise known as "out of > scope" :-) > > My major concern is with adding any language that is not enforced by > semantics. Identifying every place where the implementation MAY choose > to do something particular/peculiar that is consistent with but not > mandated by BPEL semantics is not something we can undertake. On the > other hand, it is perfectly reasonable to call attention to it in a > discussion thread such as this one. > I think the fundamental issue the TC MUST answer is - Do we want it to be reasonably possible to write a BPEL without having to know the details of what EPRs are supported by a particular platform? If the answer is no then I suspect you are right, trying to define these behaviors is not a useful task. But if the answer is yes then we need to provide well enough defined behaviors so that a programmer can make some reasonable assumptions about the behavior of the BPEL during execution. Personally I think the answer to the previous question is - Yes. Therefore I'm interesting in finding a reasonable set of normative behaviors that programmers can rely upon when writing a BPEL and be reasonably sure the BPEL will work regardless of the EPR mechanism(s) used by the underlying engine. > > Regarding specific EPR faults, do we really know what these faults will > actually need to be? We are treating EPRs as being completely opaque. > I can imagine any number of very specific EPR faults that would be the > ones actually thrown in real scenarios. Why is clubbing them all under > "bpws:unacceptableEPR" with completely opaque semantics useful? > I tend to take a HTTP/SOAP inspired approach to errors. I believe that errors should be viewed as a hierarchy. By defining a high level error we provide both programs and loggers with some idea of what went wrong. I would then expect there to be additional information in the error itself providing platform/EPR specific data. This is part of the inspiration for issue 141. > > Why do we need to add the following para which you propose to add? The > fault is already mandated in 14.4 and the rest seems vacuous relative to > the current spec; it doesn't seem to be saying anything that really has > anything to do with the semantics of EPRs. > > "Similarly when a message is sent using an invoke or reply to a remote > end point defined by the EPR in partnerRole the message will only be > transmitted if it matches the values in the initialized correlation > set(s) on the invoke/reply activity. If the transmitted message does not > > match the initialized correlation set(s) then a > bpws:correlationViolation fault MUST be thrown." > I was just trying to show how the proposal fits within the current BPEL model. It wasn't proposing anything new. > Regarding the auction scenario, "This receive MUST only receive a > message sent by end point A" is obviously not the appropriate way to > express the constraint in your scenario since it is really a > security/authorization rather than communication constraint. It is > indeed my position that security authorization semantics is out of scope > for BPEL. Authorization MAY in some cases be dependent on an underlying > mechanism of an authenticated session attached to a partnerLink, which > again is not within our scope to specify since such policy > specifications apply to all service interfaces. > Indeed and the security/authorization information is quite likely to be associated with the EPR. In other words, someone says "I want to receive a message from this EPR" and the system then figures out the security/authorization consequences and enforces them. But the crux of the issue is - can a BPEL programmer identify who they wish to receive a message from by setting the partnerRole on a partnerLink and then executing a receive on that partnerLink? I believe the answer is unambiguously yes and the spec should reflect that. > Phew! Time to take a week off :-) > Have fun! We will have plenty of work for you when you get back. :) > Satish > Yaron > -----Original Message----- > From: Yaron Y. Goland [mailto:ygoland@bea.com] > Sent: Thursday, July 29, 2004 11:02 AM > To: Satish Thatte > Cc: wsbpeltc > Subject: Re: [wsbpel] Issue - 139 - A first attempt at a proposal for > partnerLink semantics > > Please see below > > Satish Thatte wrote: > > > > > Thanks for writing this stuff down in detail. Not surprisingly, I > have > > a number of concerns ;-) > > > > Throwing the NotInitialized faults you mention seems problematic for a > > > number of reasons. > > > > You wrote that " the system admin has the right to set the EPRs for a > > role, including un-initializing them, at any time during execution. > > Which roles the admin will initialize and when is out of scope of > BPEL". > > > > I agree with this. But then the implication is that role > initialization > > being out of scope is also somewhat unknowable. For instance, what if > I > > do a receive and then the admin uninitializes the myRole in the > > partnerLink I used. Too late to throow the fault. Similarly for the > > outbound case where there might be a race. > > > > These kind of race conditions already exist in BPEL even without my > proposal so one way or another we have to address them. [1] My proposed > solution is described by the sentence I have inserted at the beginning > of the section entitled "EPRs & Message Activities" > > "When a message activity is initiated the current value of the > partnerLink's roles are copied for use by that activity. Therefore the > message activity will be unaffected if, during the execution of the > message activity, the value of the roles on the partnerLink are changed, > > e.g. by another flow in the process or by the administrator." > > > Faults for "wrong types of EPRs" are in the same category as EPRs that > > > didn't work at the other end or are non-existent in reality. Again, > we > > cannot have a standard model for handling faults in the messaging > > infrastructure. This is out of scope for BPEL. For instance, with > SMTP > > we may never find out given certain kinds of spam filters. > > > > I assume you are referring to the text that says: > > "When copying to a partnerLink the copied value MUST follow the schema > specified by Issue 34. If the copied EPR, for any reason, is not > acceptable to the BPEL engine then a bpws:unacceptableEPR fault MUST be > thrown." > > This text deals with a number of scenarios. For example: > > 1) The system only supports EPRs of type A but the programmer submitted > an EPR of type B. > > 2) The programmer submitted an EPR of type A but it contains settings > (such as policy statements regarding security or feature requests) that > are unacceptable to the engine. > > In both cases the assign MUST fail because the value assigned cannot be > handled by the engine. The text does not specify how the engine decides > to reject an EPR assignment nor does it require the engine to describe > its reasons for rejecting the assignment. It just says "I am not going > to accept this EPR". > > In other words, if the engine can see that the EPR the programmer has > submitted isn't ever going to work then the engine has a well defined > way of rejecting it. This doesn't, however, address other EPR failure > scenarios. For example, if an EPR is a smtp address and it turns out > that a spam filter won't allow the message to ever reach its > destination. That scenario wouldn't be addressed by this fault. This > fault is exclusively reserved for use during an assign and only applies > to errors that are immediately obvious to the engine. > > > Regarding "Using Roles to Select Partners To Receive Messages From", > > there is no necessary connection between the currently initialized > > partner role and the EPR for myRole, which may be well-known and > > accessible to many partners. I may in fact be dynamically changing > the > > partner EPR without interrupting my ability to *listen* to many > partners > > simultaneously through the same link. In othjer words, a link is a > > mechanism for defining a two-way *interface* contract. It is not > > restricted to acting like a connection or session on the wire. > > > > Having said that, which messages to deliver to an instance is of > course > > ultimately the responsibility of the underlying infrastructure. And > > that infrastructure may choose to apply whatever additional criteria > it > > likes for filtering messages but in my opinion the semantics of that > > filtering is outside the scope of BPEL today. > > > > My understanding of the previous two paragraphs is that it is your > position that BPEL MUST NOT provide a standard mechanism by which a BPEL > > programmer can specify that a receive activity is to only receive a > message from a specific end point. > > For example, imagine a BPEL auction service. The auction service is not > allowed to start an auction until the seller authorizes it. The auction > service knows (from the registration message requesting that a new > auction be created for an item) that the seller is available on end > point A. So once the auction service has prepped the auction it will > execute a receive on the operation 'startAuction' with the explicit > semantics of "This receive MUST only receive a message sent by end point > A". > > If I understand your previous two paragraphs correctly then it is your > position that the previous scenario must not be standardized in BPEL. > Rather, the way you would model the situation is saying that the auction > > service would execute a receive on a 'startAuction' message and in so > far as the BPEL standard is concerned, modulo the correlation sets, any > endpoint is free to send a message to that receive. There may be some > voodoo happening outside of BPEL that may restrict who can send a > message to the receive but how that works and if it even occurs is > outside of BPEL. > > Does the previous accurately represent your position? > > > I don't understand the purpose of the MAY statements in your comments > > entitled "Initializing Roles using Messaging Activities". How is what > > > the engine MAY do to initialize EPRs different from what the admin MAY > > > do if BPEL does not enforce any semantics in either case? > > > > There are two scenarios covered in that section. In the first scenario > an incoming message is received. Systems such as ws-addressing have the > ability to send information such as reply-to headers on incoming > messages. The MAY allows the BPEL engine to use the content of the > reply-to header to initialize the partnerRole EPR so that if the receive > > is a one-way and part of an asynchronous one-way pair it will be > possible for the BPEL engine to use the partnerRole to send the > response. So there are enforced semantics but the semantics that are > used will depend on the type of EPR. BPEL isn't in the business of > defining EPR types so our job is to just leave the door open (in this > case by allowing the partnerRole to be initialized) so that EPR specific > > functionality can be implemented. > > The logic for the second scenario, dealing with outgoing messages, is > similar. > > > The comment "Similarly when a message is sent using an invoke or reply > > > to a remote end point defined by the EPR in partnerRole the message > will > > only be transmitted if it matches the values in the initialized > > correlation set(s) on the invoke/reply activity" contradicts current > > BPEL semantics, which requires a fault to be thrown when such a > mismatch > > occurs (section 14.4). > > > > No contradiction was intended. I have changed the paragraph to read: > > "Similarly when a message is sent using an invoke or reply to a remote > end point defined by the EPR in partnerRole the message will only be > transmitted if it matches the values in the initialized correlation > set(s) on the invoke/reply activity. If the transmitted message does not > > match the initialized correlation set(s) then a > bpws:correlationViolation fault MUST be thrown." > > > > I have the same reaction to "Handling Faults with EPRs". If there is > no > > BPEL defined semantics involved why should we discuss it? > > > > The logic used to include the features in Handling Faults with EPRs is > identical to the logic that led us to include the faultName attribute. > In order for the intention of the programmer to be properly carried out > by the BPEL engine a mechanism must be provided to make that intention > explicit. Just as request/responses require faultName to say if a > response is a fault or non-fault response so it is with asynchronous > combinations of one-ways. > > > Satish > > > > Yaron > > [1] At time 0 someone could start a receive on a partnerLink. A message > won't arrive until time 2. At time 1 another flow could do a receive on > the same partnerLink and as a consequence of receiving a message the > myRole on the partnerLink could change. The question then is - does this > > change alter the receive initiated at time 0? > > Similarly at time 0 someone could start an invoke on a partnerLink. A > message won't arrive until time 2. At time 1 another flow could use > assign to change the partnerRole on the partnerLink. Does this change > alter the invoke initiated at time 0? > > > *From:* Yaron Y. Goland [mailto:ygoland@bea.com] > > *Sent:* Tue 7/27/2004 4:45 PM > > *To:* wsbpeltc > > *Subject:* [wsbpel] Issue - 139 - A first attempt at a proposal for > > partnerLink semantics > > > > A first shot at a proposal for issue 139. > > Thanks, > > Yaron > > > > == A Concrete Model for PartnerLinks in BPEL == > > > > === PartnerLinks, Roles & EPRs === > > A partnerLink consists of two roles, myRole and partnerRole. Each role > > is either un-initialized or contains an end point reference (EPR). > > > > An EPR is a generic term for a data structure that describes an end > > point. An end point is a network accessible location which can send > > and/or receive messages. In other words, EPRs can point at a message > > sink, a message source or a combination of the two. All EPRs are > treated > > as pointing as a single 'partner' (in the BPEL sense) even if they are > > multicast/broadcast based. EPRs are only explicitly defined by BPEL to > > the extent supported by Issue 34. > > > > By default the EPRs of the roles in a partnerLink are un-initialized. > > However, the system admin has the right to set the EPRs for a role, > > including un-initializing them, at any time during execution. Which > > roles the admin will initialize and when is out of scope of BPEL. > > > > === EPRs & Messaging Activities === > > > > A bpws:partnerRoleNotInitialized fault MUST be thrown if an invoke > > activity is called on a partnerLink whose partnerRole is not > initialized > > or a partnerRole whose EPR doesn't point at a location that can accept > > messages (e.g. it may only define a message source, not a message > sink). > > > > The myRole on a partnerLink is not necessarily required to be > > initialized for a request/response invoke as the return communication > > channel may be implicitly defined as part of the partnerRole EPR. A > > classic example of this type of behavior would be a synchronous HTTP > > based request/response WSDL binding. But the exact behavior for any > > particular type of EPR is specific to that EPR and is not defined by > BPEL. > > > > A bpws:myRoleNotInitialized fault MUST be thrown if a pick, receive or > > onEvent handler is called with a partnerLink whose myRole is not > > initialized or whose EPR doesn't support accepting messages. > > > > However, in the same sense as invoke, it is possible for a reply > > activity to use a partnerLink whose partnerRole is not initialized if > > the myRole EPR implicitly defines the return communication channel. > > > > === Using Roles to Select Partners To Receive Messages From === > > > > If a pick/receive/onEvent has an initialized partnerRole then only > > messages from a partner identified by the EPR in the partnerRole MAY > be > > accepted on that messaging activity. > > > > === Initializing Roles using Messaging Activities === > > > > When a message is received on a pick/receive/onEvent the BPEL engine > MAY > > initialize/redefine the partnerRole EPR using information from the > > incoming message. How this is accomplished is out of scope for BPEL. > > > > Similarly just before sending a message using an invoke the BPEL > engine > > MAY initialized/redefine the myRole EPR to point at the return > address, > > if any, for the response (if any) to the message. > > > > === Assign and PartnerLinks === > > When copying to a partnerLink the copied value MUST follow the schema > > specified by Issue 34. If the copied EPR, for any reason, is not > > acceptable to the BPEL engine then a bpws:unacceptableEPR fault MUST > be > > thrown. > > > > === Roles & Correlation Sets === > > > > A correlation set acts as a filter on an EPR. > > > > For example, when a receive/pick/onEvent is outstanding, by > definition, > > there must be an end point waiting to receive an incoming message. The > > EPR in myRole points at the end point. However, if the > > receive/pick/onEvent has an initialized correlation set(s) on it then > > any message that arrives at the identified end point will only be let > > through if the message matches the values in the initialized > correlation > > set(s). > > > > Similarly when a message is sent using an invoke or reply to a remote > > end point defined by the EPR in partnerRole the message will only be > > transmitted if it matches the values in the initialized correlation > > set(s) on the invoke/reply activity. > > > > === Handling Faults with EPRs === > > > > It is common in EPR systems (e.g. both WS-Addressing and > > WS-MessageDelivery) to differentiate between 'normal' and 'fault' > EPRs. > > Rather than explicitly modeling this difference in BPEL it is proposed > > that an EPR MAY have a compound format (whose exact structure is > outside > > the scope of the BPEL standard but complies with the Issue 34 syntax) > > that can contain multiple sub-EPRs to be used for specific purposes. > In > > this case one can readily imagine an EPR which contains two children, > a > > 'normal' EPR and a 'fault' EPR. > > > > If a reply is sent with a faultName attribute and if the EPR for the > > partnerRole contains a 'fault' EPR child then the fault EPR would be > > used. Otherwise the normal EPR would be used. > > > > In order to enable fault management across paired one-ways a new > > optional 'Fault' attribute with a Boolean value, is introduced for use > > with one-way invoke activities. If the Fault attribute is set to True > > then if a fault EPR is available it MUST be used otherwise the normal > > EPR is to be used. If the Fault attribute is set to False then a fault > > EPR MUST NOT be used. The default value of the Fault attribute is > False. > > > > 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]