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

Title: Message

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,
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?