[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 123 - Matching <reply> with <receive>
I think Yuzo's question #1 is the same as issue 26. I suggest we close 26
as it is contained in 123.
I don't like Bernd's proposal of limiting to one the number of replies per
receive; the loss of expressiveness is too great. I happen to agree with
the view that correlation sets should be used to disambiguate replies,
since we already use correlation sets to disambiguate receives. I also
agree that if there are no conflicting receives there should be no
restriction of course.
The only problem is how to define a match and keep all the flexibility. For
example, I would like to have one synchronous receive-reply pair which does
not need correlation, as long a other conflicting pairs can be matched
based on one or more sets. The initial pair matches then on the "empty"
set. However, I may also want to use the reply of the synch pair to
transmit a correlation value back to the invoker (the cset could have been
initialized in a prior interaction with a different partner for example).
In that case we have an ambiguous match since this time the reply has an
empty match with more than one receive. Likewise, a reply may match two
different subsets of its csets with two different receives.
I think the only way out is to restrict the use of correlation sets on the
conflicting receive/reply pairs; after all, the case of conflicting
receives is possibly an uncommon one. Introducing additional syntax to
match receive and replies is also an option if the restrictions seem unduly
severe, but I'd prefer to avoid new syntax if possible.
A possible restriction is this: in the presence of conflicting receives,
every reply activity must include at least one cset that matches a cset
present in one of the conflicting receives, and it may not contain csets
matching more than one of them. We can extend this rule by allowing one
receive and one or more matching replies that carry no correlation set at
all; this allows simple synchronous interactions but limits the ambiguity
of the "empty" set match.
I guess other variations are possible; the difficult part is keeping the
rule simple while avoiding ambiguity.
Paco
"Eckenfels.
Bernd" To: <wsbpel@lists.oasis-open.org>
<B.Eckenfels@seeb cc:
urger.de> Subject: [wsbpel] Issue - 123 - Matching <reply> with <receive>
05/18/2004 10:37
AM
Hello Satish,
yes, exactly. as i said this is a bit less flexible as the current
sematics, but a lot less confusing. Basically it forces the modeller to
explicitely model every possible execution path which can lead to a result.
I think this is a good restriction.
It better captures the intend of a process description.
Another possible option would be to make a receive operation for an two-way
request an container, which returns the result on leaving this container.
Thats another way of strictly binding and even more structures the process,
but it also is even more inflexible, I think it fails short for concurrent
processing.
<sequence>
<receive pl="pl" pt="pt" op="op" id="123" variable="request" />
...
<reply ref="#123" variable="response" />
</sequence>
In fact I think it is quite uncommon to have different possible recieves
terminated with the same reply.
Mit freundlichen Grüßen
Bernd Eckenfels
Chief Architect
--
SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany
Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256
mailto:b.eckenfels@seeburger.de - http://www.seeburger.de
-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com]
Sent: Tuesday, May 18, 2004 12:45 AM
To: Eckenfels. Bernd; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Q: Matching <reply> with <receive>
I don't see how id/ref is generally usable. Are you assuming that a reply
is always bound to a syntactically unique receive?
-----Original Message-----
From: Eckenfels. Bernd [mailto:B.Eckenfels@seeburger.de]
Sent: Monday, May 17, 2004 3:22 AM
To: wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Q: Matching <reply> with <receive>
Personally I like a tighter binding of the reply to the receive. For
example using a id/idref scheme. That way not all the currently legal reply
stuff is possible, but on the other hand, it is much cleaner to implement,
and perhaps even to understand.
Mit freundlichen Grüßen
Bernd Eckenfels
Chief Architect
--
SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany
Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256
mailto:b.eckenfels@seeburger.de - http://www.seeburger.de
-----Original Message-----
From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
Sent: Thursday, May 13, 2004 8:26 PM
To: Satish Thatte; Yuzo Fujishima; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Q: Matching <reply> with <receive>
I would assume that it should be fine as long as the reply has enough CS
information to disambiguate. So, in Yuzo's example,
reply name="rep1" partnerLink="pl" portType="pt" operation="op"
correlation set="cs3" initiate="no"
should be acceptable.
If, on the other hand, the reply does not have enough CS information to
disambiguate, "the semantics of the process is undefined", the same way
it happens when two identical receive's are outstanding (so that we
don't know which one to respond to).
Ugo
> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com]
> Sent: Thursday, May 13, 2004 9:22 AM
> To: Yuzo Fujishima; wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Q: Matching <reply> with <receive>
>
>
> Yuzo,
>
> Synchronous reply does not need correlation unless there is a
> problem of disambiguating the matching receive. This I
> believe answers your second question.
>
> Your first question is interesting in that we have not
> clearly stated what the minimum requirements for
> disambiguation are. Thus having the two outstanding receives
> you showed is legal because they are differentiated by csets.
> But what is needed in a reply if, for instance, both
> receives correspond to synchronous operations? The easy
> answer is that it should be one of the csets that is not
> common with the others. But what if the reply message does
> not contain the corresponding properties? We need to think
> about this more.
>
> Thanks for bringing it up.
>
> Satish
>
> -----Original Message-----
> From: Yuzo Fujishima [mailto:fujishima@bc.jp.nec.com]
> Sent: Thursday, May 13, 2004 12:51 AM
> To: wsbpel@lists.oasis-open.org
> Subject: [wsbpel] Q: Matching <reply> with <receive>
>
> Hi,
>
> I have a few questions about the rule of matching <reply>
> with <receive>.
>
>
> [Q1] Must <reply> always specify all the correlation sets
> specified by the corresponding <receive>?
>
> For example, if there are two <receive>'s outstanding as follows,
>
> receive name="rec1" partnerLink="pl" portType="pt" operation="op"
> correlation set="cs1" initiate="no"
> correlation set="cs2" initiate="no"
> correlation set="cs3" initiate="yes"
> correlation set="cs4" initiate="yes"
>
> receive name="rec2" partnerLink="pl" portType="pt" operation="op"
> correlation set="cs1" initiate="no"
> correlation set="cs2" initiate="no"
> correlation set="cs5" initiate="yes"
> correlation set="cs6" initiate="yes"
>
> Must a <reply> specify all of the corresponding <receive>'s
> CS's? That is, for rec1,
> reply name="rep1" partnerLink="pl" portType="pt" operation="op"
> correlation set="cs1" initiate="no"
> correlation set="cs2" initiate="no"
> correlation set="cs3" initiate="no"
> correlation set="cs4" initiate="no"
>
> Or only as many as necessary to disambiguate the matching?
> reply name="rep1" partnerLink="pl" portType="pt" operation="op"
> correlation set="cs3" initiate="no"
>
> [Q2] Does it follow that if a <receive> specify a correlation
> set, the corresponding reply can only send a message that
> contains the correlation set?
>
> If it does, then the rule seems to be too restrictive. For
> example, the following process will be illegal.
>
> 1. receive a Purchase Order and initialize correlation set
> CS-PO. 2. synchronously reply with an acknowledge message not
> containing CS-PO.
> <- Illegal
> 3. receive and/or invoke using CS-PO to perform the rest of
> the PO process.
>
> Yuzo Fujishima
> NEC Corporation
>
>
>
> To unsubscribe from this mailing list (and be removed from
> the roster of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
ave_workgr
oup.php.
To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
oup.php.
To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php
.
To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php
.
To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php
.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]