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 - Matching <reply> with <receive>


good point, if that was your intention.  i only saw you calling out that
reply MUST reference a receive's correlation, and i had a knee-jerk
reaction.  withdrawn.

----- Original Message ----- 
From: "Assaf Arkin" <arkin@intalio.com>
To: "Danny van der Rijn" <dannyv@tibco.com>
Cc: "Yuzo Fujishima" <fujishima@bc.jp.nec.com>;
<wsbpel@lists.oasis-open.org>
Sent: Thursday, July 01, 2004 12:47 PM
Subject: Re: [wsbpel] Issue - 123 - Matching <reply> with <receive>


> Danny van der Rijn wrote:
>
> >this would not work for <receive>s that have no correlation.  i realize
that
> >this is bringing other issues in (as to whether such <receive>s are
useful),
> >but it should be noted nonetheless.
> >
> >
> As the spec currently stands you cannot have two outstanding receive
> activities on the same operation/partnerLink without the use of
> correlation. If they are for different operation/partnerLink, these two
> can be use to disambiguate the receive and match it to the reply.
>
> Assaf
>
>
> >danny
> >
> >----- Original Message ----- 
> >From: "Assaf Arkin" <arkin@intalio.com>
> >To: "Yuzo Fujishima" <fujishima@bc.jp.nec.com>
> >Cc: <wsbpel@lists.oasis-open.org>
> >Sent: Thursday, July 01, 2004 11:19 AM
> >Subject: Re: [wsbpel] Issue - 123 - Matching <reply> with <receive>
> >
> >
> >
> >
> >>Let's say that the spec was writting with this rule:
> >>".... the reply has to reference the same correlation set (name and
> >>scope) as the receive, if the receive has multiple correlation sets the
> >>reply only needs to reference one of them"
> >>To me this seems to be identical to R1 in that it proposes a naming
> >>mechanism that links the receive to the reply, and at first read it
> >>seems identical to the MEP idea.
> >>
> >>I'm leaning towards an understanding that the spec allows for a
> >>supserset of this behavior, but without precluding this usage. Of
> >>course, it all depends on how you read it. But if our concern is to make
> >>the simple case simple, I think that the spec currently allows us to do
> >>that, it's just not written to highlight the simple case.
> >>
> >>Assaf
> >>
> >>Yuzo Fujishima wrote:
> >>
> >>
> >>
> >>>Hi,
> >>>
> >>>The following are
> >>>  the summary of our discussion at the F2F and
> >>>  a few new ideas
> >>>on "Issue 123: Matching <reply> with <receive>".
> >>>
> >>>Please let me know what you think.
> >>>
> >>>==== Resolution Ideas ====
> >>>
> >>>We currently have four kinds of resolutions for Issue 123:
> >>>
> >>>R1: Explicit disambiguation through ID and REF (Bernd, Yaron)
> >>>R2: Restrict the use of correlation sets (Paco)
> >>>R3: Resolution-only correlation sets (Yuzo)
> >>>R4: Pattern attribute for reply correlation sets (Chris)
> >>>
> >>>For R1, R2, R3, please refer to 20040622-issue123.ppt, which is
> >>>available at the document page of the WSBPEL web site, in addition to
> >>>the email messages regarding Issue 123.
> >>>
> >>>R4 was proposed by Chris at the F2F. The idea is that we specify
> >>>
> >>>
> >pattern=
> >
> >
> >>>"in" for a correlation set specified for a <reply> to indicate that the
> >>>correlation set is actually for the incoming message, that is, the
> >>>message
> >>>received by <receive>, rather than the outgoing one to be sent by the
> >>><reply>. This way we can specify as many correlations sets for <reply>
> >>>
> >>>
> >as
> >
> >
> >>>necessary for disambiguation, while not requiring the reply message to
> >>>contain the correlation sets properties. R4 is similar to R3, but seems
> >>>to be better-aligned with the current BPEL specification.
> >>>
> >>>After all the discussion at the F2F, I still feel R1 or similar is
> >>>preferable to the rest because I guess that when writing <activity>,
the
> >>>process designer should have <receive>(s) in mind, rather than the
> >>>correlation set(s).
> >>>
> >>>Accordingly, I elaborate only on R1 below. If you prefer R2, R3, R4, or
> >>>something else, please elaborate on your choice and share the idea.
> >>>
> >>>==== Elaboration on R1 ====
> >>>
> >>>In a personal conversation, Satish has suggested that we should give an
> >>>ID to a MEP instance rather than to a <receive>. I think it is a good
> >>>idea.
> >>>It can naturally handle the cases where multiple <receive>s and
<reply>s
> >>>are written in the process definition for a single message exchange
> >>>pattern.
> >>>(At run-time, only one of each is executed.) I try to materialize the
> >>>suggestion below.
> >>>
> >>>1. Introduce <messageExchanges> element.
> >>>
> >>><scope or process>
> >>>  <messageExchanges>?
> >>>    <messageExchange name pattern?/>*
> >>>  </messageExchanges>
> >>></scope or process>
> >>>
> >>>2. Introduce messageExchange attribute.
> >>>
> >>><receive messageExchange? ...>
> >>><onMessage messageExchange? ...>
> >>><onEvent messageExchange? ...>
> >>>
> >>>3. Define the receive-reply matching rule as follows.
> >>>
> >>>Correlation sets of <reply> are not considered in matching at all.
> >>>
> >>>If messageExchange attribute is specified for <reply>, outstanding
> >>><receive>s (or <onMessage>s or <onEvent>s) that make reference to the
> >>>same
> >>>messageExchange are searched.
> >>>
> >>>If messageExchange attribute is NOT specified, outstanding <receive>s
> >>>that
> >>>have matching partnerLink, portType, and operation are searched.
> >>>
> >>>If there is only one such <receive>  (or <onMessage> or <onEvent>) and
> >>>
> >>>
> >it
> >
> >
> >>>has matching partnerLink, portType, and operation, then the <reply> is
> >>>matched to it. If not, a conflictingRequest fault is thrown. (Note: We
> >>>may
> >>>want to introduce another fault for zero <receive> case.)
> >>>
> >>>4. Example
> >>>
> >>><scope or process>
> >>>  <messageExchanges>
> >>>    <messageExchange name="rfq-quote" pattern="in-out"/>
> >>>  </messageExchanges>
> >>>
> >>>  ...
> >>>  <switch>
> >>>    <case>
> >>>      ...
> >>>      <receive messageExchange="rfq-quote" ...>
> >>>      ...
> >>>    </case>
> >>>    <otherwise>
> >>>      ...
> >>>      <receive messageExchange="rfq-quote" ...>
> >>>      ...
> >>>    </otherwise>
> >>>    ...
> >>>  </switch>
> >>>  ...
> >>>  <reply messageExchange="rfq-quote">
> >>>    ...
> >>>  </reply>
> >>>  ...
> >>></scope or process>
> >>>
> >>>5. Discussion
> >>>
> >>>I am not sure whether we really need the pattern attribute. It may be
> >>>useful for validation, but may be cumbersome to specify. Hence I make
it
> >>>an optional attribute.
> >>>
> >>>As pointed in 3, we may want to introduce a new fault for matching
> >>>failure.
> >>>
> >>>==== onMessage and onEvent ====
> >>>
> >>>As I already did above, I think onMessage and onEvent must be modified
> >>>such
> >>>that it can have messageExchange attribute if necessary.
> >>>
> >>>==== multiple receives in a loop ====
> >>>
> >>>During the F2F discussion, it was pointed out that we currently have no
> >>>means to express the correspondence between <receive>s in a loop and
> >>><reply>s outside of the loop.
> >>>
> >>><while>
> >>>  ...
> >>>  <receive ...>
> >>></while>
> >>>
> >>><while>
> >>>  ...
> >>>  <reply ...>
> >>></while>
> >>>
> >>>I think this is an important problem but too big to discuss in Issue
> >>>
> >>>
> >123.
> >
> >
> >>>We may need to introduce arrays of partner links, for example. Hence I
> >>>would like to consider it a separate issue.
> >>>
> >>>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/leave_workgroup
.php.
> >
> >
> >>>
> >>>
> >>-- 
> >>"Those who can, do; those who can't, make screenshots"
> >>
> >>----------------------------------------------------------------------
> >>Assaf Arkin                                          arkin@intalio.com
> >>Intalio Inc.                                           www.intalio.com
> >>The Business Process Management Company                 (650) 577 4700
> >>
> >>
> >>This message is intended only for the use of the Addressee and
> >>may contain information that is PRIVILEGED and CONFIDENTIAL.
> >>If you are not the intended recipient, dissemination of this
> >>communication is prohibited. If you have received this communication
> >>in error, please erase all copies of the message and its attachments
> >>and notify us immediately.
> >>
> >>
> >>
> >>
> >
> >
> >
>
>
> -- 
> "Those who can, do; those who can't, make screenshots"
>
> ----------------------------------------------------------------------
> Assaf Arkin                                          arkin@intalio.com
> Intalio Inc.                                           www.intalio.com
> The Business Process Management Company                 (650) 577 4700
>
>
> This message is intended only for the use of the Addressee and
> may contain information that is PRIVILEGED and CONFIDENTIAL.
> If you are not the intended recipient, dissemination of this
> communication is prohibited. If you have received this communication
> in error, please erase all copies of the message and its attachments
> and notify us immediately.
>
>



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