[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]