OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel-spec-edit message

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

Subject: RE: [wsbpel-spec-edit] Issue 33: proposed change to the specification

Title: Message
Thanks for the feedback. sorry for the late reply I've been  in a f2f this week and no mail access during days.  Will try to come up with some new wording tomorrow. of course,  please let me know if you have wording in mind.
in the mean time, please do not let this hold other editing work. the pen is yours for now.  after you are done, I will checkin another version for the new wording

Best Regards,

-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com]
Sent: Tuesday, May 11, 2004 09:06 AM
To: Liu, Kevin; bpel spec
Subject: RE: [wsbpel-spec-edit] Issue 33: proposed change to the specification

I am concerned that the wording implies that the normal expectation is that a message will be received after the corresponding receive activity is waiting for it, unless there is some sort of overload problem.  The specification makes no such statement.  For instance it is perfectly reasonable to receive a series of messages in a while loop where all the messages have the same correlation as in Alex's example for the correlation initiation issue.  Clearly, the messages will arrive independent of the iterations of the loop.  But the fact that the correlation is already initiated should enable the runtime engine and messaging platform to recognize that these messages are correlated to the process instance.  In this case the iteration may loop too few or too many times relative to the number of messages received, and that is a protocol error that the specification cannot do anything about.


From: Liu, Kevin [mailto:kevin.liu@sap.com]
Sent: Monday, May 10, 2004 10:31 PM
To: Satish Thatte; bpel spec
Subject: RE: [wsbpel-spec-edit] Issue 33: proposed change to the specification


Since I haven't heard anything from the editors, I assume you are all ok with the proposed changes below. I have checked in to CVS the changes as below.  


I hand off the pen.

Best Regards,

-----Original Message-----
From: Liu, Kevin
Sent: Friday, May 07, 2004 02:45 PM
To: 'Prasad Yendluri'; Satish Thatte
Cc: bpel spec; 'Eckenfels. Bernd'; Trickovic, Ivana
Subject: [wsbpel-spec-edit] Issue 33: proposed change to the specification

Hi all,


Since the resolution of  issue 33 doesn't include concrete proposal of changes to the spec, the editors have a lot of leeway about where to change and what to actually say. Here is what I am thinking to implement the resolution. Please let me know your thoughts. If it looks OK with all of us, I will check in the changes end of Monday.   


since the race conditions could occur to more than one activities, I am considering to add a subsection under "Defining Business Process". The TOC will look like:



the wording will be:


6.3. Handling Race Conditions

As a caveat, it's worth to point out that run time race conditions may occur in certain occasions of executing a business process.  For example, messages may arrive before their targeting "receive" activity is instantiated because the runtime engine is too overloaded to receive fast enough.  Process engines may employ different mechanisms to handle race conditions. This specification doesn't mandate a particular mechanism, but it assumes that the engines take care of race conditions in a way that the process behaves as if no race condition was encountered . For example, in case a message  arrives before a "receive" is activated, the engine may queue the message or store it in some other manners and make it available to the "receive" activity as soon as it becomes active, but to the message sender, the message always appears being processed as if it was received after the "receive" is activated.

Best Regards,

-----Original Message-----
From: Prasad Yendluri [mailto:pyendluri@webmethods.com]
Sent: Wednesday, May 05, 2004 02:09 PM
To: Satish Thatte
Cc: Liu, Kevin; bpel spec
Subject: Re: [wsbpel-spec-edit] issues to assign for editorial update

Works for me..

Satish Thatte wrote:

I suggest the following order.  Prasad fixes 101 and 117.  Then Kevin fixes 33.  Then I fix 25 and 53.  How does that sound?



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