Title: Message
Satish,
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,
Kevin
-----Original Message-----
From: Satish Thatte
[mailto:]
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:]
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?
