[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 123 - Matching <reply> with <receive>
Hi Yuzo,
You make a good point. One would think that matching replies to receives is
a sort of "internal" correlation (consumed by the process engine only?)
that does not need to be visible in the message, and thus requires
different kind of support. I am in general reluctant to add ad hoc syntax
when the problem is conceptually similar to one we have already solved but
maybe in this case it is the simplest solution. I would like to think a bit
more about the proposal you make here.
Paco
Yuzo Fujishima
<fujishima@bc.jp. To: wsbpel@lists.oasis-open.org
nec.com> cc:
Subject: Re: [wsbpel] Issue - 123 - Matching <reply> with <receive>
06/06/2004 10:59
PM
Paco,
Should we make it a rule that the message sent by <reply>
must contain the correlation set(s) specified?
In my opinion, the rule is too restrictive because
the client may not require correlation sets embedded
in the message, especially in synchronous request/response
cases; there's no ambiguity for the client.
Currently, there are two overloaded usages for reply c-set:
U1: To identify corresponding receive.
U2: To enable message correlation.
I am afraid sometimes the two usages conflict with each other.
I think this overload is (a part of) the source of the
difficulty.
In my view, Bernd's proposal is one way to resolve the overload.
Another may be introducing a new attribute for correlation set
to express that the c-set is only for request disambiguation
and not for message properties restriction, e.g.,
<correlation set="cs1" type="requestResolution">
Yuzo Fujishima
NEC Corporation
Francisco Curbera wrote:
>
>
>
> 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
> .
>
>
>
>
> 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]