Re: [wsbpel] Issue - 139 - A first attempt at a proposal for partnerLinksemantics

["Yaron Y. Goland" <ygoland@bea.com>]

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