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: RE: [wsbpel] Issue - 139 - A first attempt at a proposal for partnerLink semantics


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.
 
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.
 
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. 

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?
 
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).
 
I have the same reaction to "Handling Faults with EPRs".  If there is no BPEL defined semantics involved why should we discuss it?
 
Satish

________________________________

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_workgroup.php.





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]