OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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]