[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
|
Hi
All,
After discussed with Satish and others who have provided feedback
to the initial proposed changes, we figured out that it is better to tie the
semantic closer with the related constructs, including receive, pick/onMessage
and message event handler. Concerns were raised
that the significance may be missed by putting the new
paragraph in a separate section. In addition, there are already
other things like simultaneous enablement of conflicting
receive actions
where we point to the receive semantics as being applicable
to the onMessage cases, so we should be consistent
here.
As
a result of the discussions, we have come up with the following
changes to the current draft ( changes marked
red):
First of all, we need to add a new paragraph as we discussed
(with minor modifications to fit into the context) after the
following paragraph in 11.4,
A business process instance MUST NOT simultaneously enable two or more receive activities for the same partnerLink, portType, operation and correlation set(s). Note that receive is a blocking activity in the sense that it will not complete until a matching message is received by the process instance. The semantics of a process in which two or more receive actions for the same partnerLink, portType, operation and correlation set(s) may be simultaneously enabled is undefined. For the purposes of this constraint, an onMessage clause in a pick and an onMessage event handler are equivalent to a receive (see Pick and Message Events). It is worth pointing out that race conditions may occur in business process execution. Messages that target a particular process instance may arrive before the corresponding receive activity is started. For example, it is perfectly reasonable to model a process that receives a series of messages in a while loop where all the messages use the same correlation. At run time, 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 and handle those messages appropriately. For another example, a process may invoke a remote service, initiate a correlation set for an expected callback message, and the callback message may arrive before the corresponding receive activity is started for a variety of reasons. The correlation data in the arriving message should enable the engine to recognize the message is targeted for this process instance and handle it appropriately. Process engines may employ different mechanisms to handle such race conditions. This specification does not mandate any specific mechanism. For the purposes of handling race conditions, an onMessage clause in a pick and an onMessage event handler are equivalent to a receive (see Pick and Message Events). Then in section 12.4, we need to modify the following paragraph: Each pick activity MUST include at least one onMessage event. The semantics of the onMessage event is identical to a receive activity regarding the optional nature of the variable attribute, the handling of race conditions, and the constraint regarding simultaneous enablement of conflicting receive actions. For the last case, recall that the semantics of a process in which two or more receive actions for the same partner link, portType, operation and correlation set(s) may be simultaneously enabled is undefined (see Providing Web Service Operations). Enablement of each onMessage handler is equivalent to enablement of the corresponding receive activity for the purposes of this constraint. and yet in section 13.5.1, similar changes are necessary: The semantics of the onMessage event is identical to a receive activity regarding the optional nature of the variable attribute, the handling of race conditions, and the constraint regarding simultaneous enablement of conflicting receive actions. For the last case, recall that the semantics of a process in which two or more receive actions for the same partner link, portType, operation and correlation set(s) may be simultaneously enabled is undefined (see Providing Web Service Operations). Enablement of each onMessage event handler is equivalent to enablement of the corresponding receive activity for the purposes of this constraint. Your comments are welcome, but please propose CONCRETE changes to the above l if you have better idea for implementing the issue 33 resolution. If no further comments are received, I will check in the changes to CVS end of this week.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@ 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----- 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 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----- Works for me.. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]