Title: Message
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:]
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,
Kevin
-----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:
6. Defining a Business Process
6.1. Initial Example
6.2. The Structure of a Business Process
6.3.
Handling Race Conditions
6.4. Language Extensibility
6.5. The Lifecycle of a Business Process
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,
Kevin
-----Original
Message-----
From: Prasad Yendluri
[mailto:]
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?
