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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

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


Subject: Re: [wsbpel] Issue 123 - Proposal to Vote



Hi Satish,


Satish Thatte wrote:

To be clear, as I said on the call, I would prefer to make the messageExchange story general enough to apply to multi-message MEPs which are much more like implicit correlation.  But that may be asking for too much.

 

 


[AYIU]: When you say "multi-message MEPs", do you mean the same messageExchange handle being reused multiple time serially? If so, I am agreeing with you. :-)


Satish Thatte wrote:

Well, in theory I could receive a request in a scope and then use an eventHandler for the reply because the reply is dependent on another message which occurs non-deterministically relative to the scope.  I know, we may then exit the scope prematurely and there may be better options J

 

S.


[AYIU]: Yes, that pattern is still supported, even after we restrict that the messageExchange used onEvent resolves to the directly associated scope only. Because, that restriction applies only on <onEvent>. The messageExchange of a <reply> activity can be still resolved to an enclosing scope.

Thanks!


Regards,
Alex Yiu



From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Wednesday, November 09, 2005 9:26 AM
To: chris.keller@active-endpoints.com; Satish Thatte
Cc: Alex Yiu; 'ws bpel tc'; Danny van der Rijn
Subject: Re: [wsbpel] Issue 123 - Proposal to Vote

 


Hi,

Just want to relay some of the differences between CS and messageExchange:
-- CS can be declared and init-ed outside of an event handler, before the execution of <onEvent>.
-- On the other hand, when the messageExchange is being used by <onEvent>, the "life cycle"/"state" of messageExchange is tied with "life cycle"/"state". That is, for <onEvent>,
I cannot find a use case where an <onEvent> would refer to a messageExchange outside of a <eventHandler>. If that reference happens, the only results that I can foresee are some non-deterministic bwps:conflictingRequest fault.


Thanks!


Regards,
Alex Yiu


Alex Yiu wrote:


In my previous email, I meant <onEvent>, instead of <onMessage>. Sorry for the mixup.

Regards,
Alex Yiu


Alex Yiu wrote:


Hi Chris,

Thank you for working this proposal out.

A number of suggestions:

(1) Captialize one of the "must" words
(2) Adding some more scope resolution wordings

A reply activity is associated with an inbound message activity (IMA), such as, <receive>, <onMessage> and <onEvent> based on the tuple - partnerLink, operation, and messageExchange.  The name used in the optional messageExchange attribute MUST resolves to a messageExchange declared in a scope (where the process is considered the root scope) which encloses the reply activity and its corresponding IMA. The messageExchange resolution follows follows common lexical scoping rules, similar to variable resolution. A messageExchange resolves to the nearest enclosing scope.


Since messageExchange is scope-based, most likely I would request an additional paragraph of messageExchange resolution within a <onMessage> in the context of Issue 204 resolution. (I would send out more emails later).

Thanks!


Regards,
Alex Yiu



Chris Keller wrote:

Issue 123 - Proposed changes to the current draft for scoped messageEchange:

 

In section 6.2 add to the informal syntax describing the XML grammar for both the process element and the scope element between partnerLinks and variables the following:

 

<messageExchanges>?

     <messageExchange name="ncname"/>+

</messageExchanges>

 

 

Change the following paragraphs from Section 11.4:

 

The optional messageExchange attribute is used to associate a <reply> activity with an inbound message activity, such as, <receive>, <onMessage> and <onEvent>, when there are multiple simultaneously incomplete inbound message activities which requires a reply message to complete.

 

A reply activity is associated with a inbound message activity based on the tuple - partnerLink, operation, and messageExchange. The value defined in messageExchange is scoped to the combination of partnerLink and operation. That is, it is legal to use the same messageExchange value in multiple simultaneously incomplete receive activities so long as the combination of partnerLink and operation on the receives are all different from each other. An incomplete inbound message activity describes the state of a BPEL process from the point that a request/response receive activity starts execution until its associated reply begins execution.

 

If there should ever be multiple simultaneous incomplete inbound message activities which have the same partnerLink, operation and messageExchange tuple then the bpws:conflictingRequest fault MUST be thrown within the BPEL process on the conflicting inbound message activities subsequent to the execution of the successful incomplete receive.

 

If a reply activity cannot be associated with an incomplete receive activity by matching the tuples and this error situation is not caught during static analysis,  then bpws:missingRequest fault MUST be thrown within the BPEL process on the reply activity. Because conflicting requests should have been rejected at the time inbound message activity is executed, there cannot be more than one corresponding inbound message activity at the time <reply> is executed.

 

If the messageExchange attribute is not specified on a receive then its value is taken to be empty. For matching purposes two empty messageExchange values with the same partnerLink and operation values are said to match. Empty value does not match with other non-empty values.

 

To the following:

 

A reply activity is associated with an inbound message activity (IMA), such as, <receive>, <onMessage> and <onEvent> based on the tuple - partnerLink, operation, and messageExchange.  The name used in the optional messageExchange attribute must correspond to a messageExchange declared in a scope (where the process is considered the root scope) which encloses the reply activity and its corresponding IMA.

 

An open IMA describes the state of a Web service operation from the point that a request/response IMA starts execution until an associated reply begins execution. It is illegal to have multiple simultaneous open IMAs, which have the same partnerLink, operation and messageExchange tuple.  A BPEL process MUST throw a bpws:conflictingRequest fault when the conflicting IMA begins execution.  Note that it is legal to use the same messageExchange in multiple simultaneously open IMAs so long as the combination of partnerLink and operation on the IMAs are all different from each other.

 

If a reply activity cannot be associated with an open IMA by matching the tuples (partnerLink, operation, and messageExchange) then a bpws:missingRequest fault MUST be thrown within the BPEL process on the reply activity. Because conflicting requests MUST be rejected at the time the IMA begins execution there cannot be more than one corresponding IMA at the time a reply activity is executed. Further if an open IMA goes out of scope prior to being closed by a reply activity then the scope MUST throw a bpws:missingReply fault.  In other words a scope which declares a partnerLink or messageExchange used by an IMA will not complete normally if that IMA is open when the scope is to complete.

 

If the messageExchange attribute is not specified on an IMA or reply then the activity's messageExchange is said to be null. For matching purposes two null messageExchanges are said to match. However a null messageExhange does not match a non-null messageExchange.

 

 

 

 




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