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


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


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?


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

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.

Phew!  Time to take a week off :-)

Satish

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