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


As we discussed on the call today, here are some thoughts on this issue that are swimming around it my head.  (I wish they would respect the swimlanes, and stop crashing into each other).

An example (in extremely abbreviated syntax) of a problem that we haven't worked out yet:

<scope>
    <partnerlink name="pl"/>
    <eventHandler partnerLink="pl" operation="op">
</scope>

"op" is a request-reply operation.
To note:  no partnerLink or messageExchange is declared on the eventHandler associated scope.

Timeline:
Time 1: The eventHandler receives a message.  For reply-resolution purposes, its identifying triple is {pl, op, null}
Time 2:  No reply to the above triple has occurred, and another messages comes in on partnerLink pl and op.  If it were to be received, its triple would be {pl, op, null}.  Thus a conflictingReceive should be thrown.  At least it would be reasonable to infer that from the current spec (with or without 123?)

I see 2 ways of solving this:

Option [1]
Rationale:  Makes writing the spec easier.

[A] Require that onEvent either define at least one of partnerLink, messageExchange locally.
- or -
[B] Specify that in the case that an onEvent does not specify a local partnerLink or messageExchange, the onEvent can not run concurrently with itself.  Either the messages must be queued, or conflictingReceive will be thrown any time a message is received on a request/reply operation for an onEvent that has an outstanding request.

I do not favor Option [1].

Option [2]
Rationale:  messageExchange should be reserved for the 20% (or less) cases.  The user of only 80% cases should never have to know about messageExchanges.

Specify that an IMA that does not specify a messageExchange resolves to a "default messageExchange declaration (DMD)."  (This is a howler of a name, and needs to be changed)  In this way, not specifying a messageExchange in an onEvent resolves replies to the onEvent, as most users would expect.  DMDs can be thought of as present on each onEvent whether they are "used" or not.

I favor this option.

Question [A]
Should a DMD be present on a parallel forEach (PFE)? 

The argument against having it present is that PFE is not inherently a web-service operation, and it could be confusing to have it there.  The argument for having it there is that in the 80% case, IMAs within a PFE will have replies that are in the same PFE.  Specifying a DMD on a PFE allows the 80% case to not use messageExchange.

I favor having a DMD on PFEs.

Question [B]
Should a DMD be present on the process?

The argument against having it present is that there is no need for it to be present - we already define how to match IMAs with replies if there is no messageExchange.  The argument in favor of having it present is that if it is present, we can get rid of that exact language.  There are no activities with no messageExchange, there is just a default value.

I favor having a DMD on processes.

Danny
   

Alex Yiu wrote:

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]