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



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