RE: [wsbpel] Issue - 33 - proposal to vote for telco, reworded

["Liu, Kevin" <kevin.liu@sap.com>]

Sorry I missed the F2F discussion on this issue, but after reading issue 33 related email thread and the SAP F2F minutes, I am still not clear what's the actual resolution, in particular what's the compliant behavior of an engine when a message is received before the receive activity is activated. 

As Yaron pointed out before (quoted from a message sent by Bernd and dated 7/10/2003), there could be at least three different behaviors: 

>	#1 - Put in a queue that will hold messages for a predetermined period to
see if an operation that can accept them is activated and if not time the
message out and return an error.
>	#2 - Immediately return an error stating something like "That operation is
not available yet, please try again later."
>	#3 - Use a signaling system that lets the process send a signal to foo
confirming that the response to sendShippingPrice has been successfully

This is not a pure engine implementation issue because it effects the message exchange between participants. For example, if I send a message to two parties who both implement a same process,  if participant A's engine chooses to queue the message till the receive activity is available whereas participant B chooses to return an error immediately, I got totally different response to my request. I believe it's beneficial for the BPEL spec to clearly specify what should be the compliant behavior, independent of the implementation mechanism (such as queuing).

The proposed wording for closing this issue, either in this message or in the F2F minutes, is not clear. Does it intend to say that the compliant behavior is that the receiving engine takes care of the race condition and MUST assure the message will be received by the receive activity as if it was received after the receive activity is activated? 

I had to vote No on the ballot for issue 33 because I need clarification. However, if the above interpretation is correct, I will change my vote to yes. Please clarify. 

Best Regards,
Kevin
 

-----Original Message-----
From: Eckenfels. Bernd [mailto:B.Eckenfels@seeburger.de] 
Sent: Wednesday, Apr 14, 2004 11:00 AM
To: wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue - 33 - proposal to vote for telco, reworded


Hello,

we voted on the below proposal on the F2F and want to revote with a slightly less restrictive wording:

"The editing team is aksed to include an explanation, that processing of messages with legal outstanding correlations may be received after the correlation set is instantiated but before the actual receive is activated. Modellers can asume, that it is safe to rely on this (since there is no bpel onstruct to implement it otherwise)."



We agreed to not add a definition in which case it is legal/required for the engine to to look ahead and what timeouts to asume. Therefore it is not possible to include samples like "receive or a callback in a seuqnece directly after the invoke". I have also worded the recommendation to adress the modellers expectations and not to explicitely define requirements to the engine, since we are not yet down that conformance definition road in other places.

 There are other places where the bpel spec does not require a specific timing (e.g. invoke and receive in parallel in a flow), where the same expectations of the modeller should be acknolwledged.
Mit freundlichen Grüßen
Bernd Eckenfels
Chief Architect
--
SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany
Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256
mailto:b.eckenfels@seeburger.de - http://www.seeburger.de


-----Original Message-----
From: Eckenfels. Bernd 
Sent: Monday, March 29, 2004 5:20 PM
To: wsbpel@lists.oasis-open.org
Subject: [wsbpel] Issue - 33 - proposal to vote on F2F


Hello,

Diane collected some of the correlation related issues

33 - Bernd Eckenfels and 37 Yuzo Fujishima , 78 - Yaron Goland (correlation: 8, 26, 31, 66,  96) 

and I think we will discuss them a little bit.

For the issue 33 i propose the follwoing solution:

We accept, that the specification depends on behaviour of the engine implementation and transport protocols, which are
in reality hard to achieve (atomic send, real parallel execution, no delay between activities). Therefore it is good to mention in the specification, that implementors are required to handle this detail.

The proposed text should mean something like:

"The implementation should be able to deal with responses, which are received before the actual receive is activated. This is required to reduce the risk of race conditions, between requesting a service and receiving its response."

I suggest we give this suggestin to the editing team for incooperation.


On the other issues, I plan to have a short presentation "correlations in bpel - what is it and what is open".

Mit freundlichen Grüßen
Bernd Eckenfels
Chief Architect
--
SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany
Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256
mailto:b.eckenfels@seeburger.de - http://www.seeburger.de


-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com]
Sent: Tuesday, August 12, 2003 6:36 PM
To: Eckenfels. Bernd; Dieter Roller
Cc: wsbpel@lists.oasis-open.org
Subject: RE: Issue - 33 - invoke/receive-callback race conditions, even
in the 1.1 sample (p.22)


Bernd,

The grammar may have been challenging because it was constructed by a
non-native speaker ;-)

I was simply saying that I do not see how the use of <flow> creates any
special issues.  

As I read the thrust of your concern, it has to do with ensuring that
messages destined for a process instance are not lost due to races.  We
need to provide a clear statement of expectations from a compliant
implementation to ensure this.

Of course, in any async application protocol, the process cannot be
expected to immediately wait for the response to an async message.
Otherwise we may as well stay with RPC ;-)  So the statement will need
to be focused on the initialization of correlation sets, i.e.,
conversation keys.

Satish

 

-----Original Message-----
From: Eckenfels. Bernd [mailto:B.Eckenfels@seeburger.de] 
Sent: Tuesday, August 12, 2003 3:46 AM
To: Satish Thatte; Dieter Roller
Cc: wsbpel@lists.oasis-open.org
Subject: Issue - 33 - invoke/receive-callback race conditions, even in
the 1.1 sample (p.22)

Hello Satish and Dieter,

as the Champion for this issue I am preparing a somewhat cleaner
represenation of the problem, so I am refering to Satish's latest
comment on it:

> So I think it would be helpful to restate your problem making the
assumption of correlation.

I will definitely do this, (and maybe raise another issue, because it is
a rather trivial one).

But I am also interested in better understanding your second comment,
Satish. (which is somewhat gramatically challenging to a non native
speaker, can you clearyfy please?)

> Recasting the example using <flow> is compounding the confusion in my
humble opinion.

If you mean, the flow in the sample would be confusing, then you are
right, I would not introduce that in the sample, but it is another case
where the race condition issue raises its ugly head, thats why i have
mentioned this second (also not working) solution.

Dieter, on the Phone conference where we discussed this issue, you
sounded like you wanted to think of an solution. Anything in your mind,
yet?

I realy do not feel like it is best to force implementations to handle
this case, but on the other side, I do not want to introduce too much
complexity, also?

Greetings
Bernd


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.


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.