[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 123 - Matching <reply> with <receive>
Hi,
Will do so.
It will be easier for Satish to catch the email also.
Regards,
Alex Yiu
Yaron Y. Goland wrote:
> Alex, your proposal has now been incrementally modified a number of
> times in a number of different e-mails. I can't track anymore exactly
> what you are proposing. Could you please send a new e-mail with a full
> proposal with all the modifications rolled in?
>
> Thanks,
>
> Yaron
>
> Alex Yiu wrote:
>
>>
>>
>> Hi,
>>
>> Just want to clarify a few points:
>>
>> (1)
>> In my latest email, there is NO scope associated with "name"/"usage"
>> identifer any more. The identifier is not a MEP instance. It is merely a
>> supplementary string, which has no lifecycle / lifetime / scope.
>>
>> (2)
>> AFAIU, the original matching semantics of R1/R1A is just to match the
>> "messageExchange" regardless of partnerLink and operation.
>> http://www.oasis-open.org/archives/wsbpel/200407/msg00148.html
>> "If a message exchange instance is specified for a reply, outstanding
>> receives for which the same instance is specified are searched."
>> This semantics kind of force us to decide the scope of messageElement,
>> because partnerLink is not in the picture.
>> The matching tuple for receive-reply is:
>> (name_of_messageElement) ; if messageElement is used
>> (partnerLink, operation, CS) ; if messageElement is not used. [the CS
>> part is still under discussion under part (B)]
>>
>> (3)
>> It is always legal to have the following sequence operation.
>> <receive partnerLink="p1" operation="op1" />
>> <receive partnerLink="p1" operation="op2" />
>> <reply partnerLink="p1" operation="op1" />
>> <reply partnerLink="p1" operation="op2" />
>>
>> The matching tuple for receive-reply has always been:
>> (partnerLink, operation) [maybe with CS also, depending on the part (B)
>> discussion]
>>
>> All I suggest now is:
>> (partnerLink, operation, name) when the name is used.
>> As you can see it is a very natural extension.
>>
>> If we want to define the matching tuple as (partnerLink, name),
>> basically the name replace operation for matching. That is not the end
>> of world from my viewpoint. It's a bit odd.
>>
>> I hope the picture is clear now.
>> I apologize that I expose too much of my thinking-out-loud details into
>> mailing list. That create a bit of confusion.
>>
>> Thanks for reading my emails!
>>
>>
>>
>> Regards,
>> Alex Yiu
>>
>>
>>
>>
>> Yaron Y. Goland wrote:
>>
>> > I would like to +1 both of Paco's mails on this thread. I think that
>> > the increasing complexity of R1B as it moves from a tuple
>> (partnerLink
>> > + name) to a triple (partnerLink+ name + operation) model argues that
>> > we should just use R1 where the scoping issues go away.
>> >
>> > Francisco Curbera wrote:
>> >
>> >>
>> >>
>> >>
>> >>
>> >> Alex,
>> >>
>> >> Thanks for the clarifications. It seems that the stronger argument
>> >> you are
>> >> making is the modularity of scopes from within a process, but since
>> >> it is
>> >> not clear what is exactly the goal of that modularity (reuse?
>> support
>> >> of a
>> >> particular runtime architecture?) it is hard to assess the benefit.
>> >> On the
>> >> other hand there are now several identifiers that afaik are not
>> scoped
>> >> (link and activity names). Are you going to propose that we scope
>> >> those as
>> >> well?
>> >>
>> >> In also don't understand the point you make about adding partner
>> >> links to
>> >> reduce ambiguity. Are you saying that you will define two plinks
>> in BPEL
>> >> but map them to the same endpoint at runtime? Wouldn't that have the
>> >> effect
>> >> of obscuring the interaction protocol? That is, the fact that at
>> runtime
>> >> two messages are expected simultaneously from the same endpoint,
>> their
>> >> responses having to go back to that endpoint woud not be represented
>> >> in the
>> >> process definition.
>> >>
>> >> My main reason to insist on R1 is simplicity: no need to declare MEP
>> >> instances, no need to handle visibility rules. Scope level
>> >> declaration and
>> >> inside out visibility rules are great to solve many problems, but
>> are
>> >> totally unjustified in this case. We are trying to solve a very
>> simple
>> >> problem, let's try keep the solution simple as well.
>> >>
>> >> Paco
>> >>
>> >>
>> >>
>> >>
>>
>>
>> >>
>> >>
>> >> Alex
>> >>
>> Yiu
>>
>> >>
>> >>
>> >> <alex.yiu@oracle. To: Francisco
>> >> Curbera/Watson/IBM@IBMUS
>> >> com> cc: "Eckenfels.
>> >> Bernd" <B.Eckenfels@seeburger.de>, Satish Thatte
>> >> >>
>> <satisht@Microsoft.com>, wsbpel@lists.oasis-open.org,
>> >> ygoland@bea.com, Alex Yiu >>
>> 08/05/2004 02:41 >> <alex.yiu@oracle.com>, Maciej Szefler
>> >> <mbs@fivesight.com>
>> >> AM Subject: Re:
>> [wsbpel]
>> >> Issue - 123 - Matching <reply> with <receive>
>> >>
>>
>>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Hi, Paco, (and others),
>> >>
>> >> I guess we can consolidate the text from "lifetime"/"namespace"
>> into
>> >> "scope", if you prefer. I was just reusing those terms from on
>> Yuzo's
>> >> original proposal.
>> >>
>> >> Let me answer some of your questions and re-iterate some of points
>> >> expressed in the conf call today:
>> >> I am NOT proposing the usage id is required. They are used
>> only
>> >> when
>> >> we need to disambiguate multiple receive.
>> >> This usage id will NOT affect the actual existing partnerLink
>> >> behavior in anyway. It is a pure BPEL language feature,
>> which has
>> >> ZERO effects to the underlying WSDL layer. The usage id is
>> just a
>> >> supplementary qualifier for disambiguation.
>> >> The key part of this proposal is try to bring the
>> advantages of R1
>> >> and R1A under one proposal. Semantic-wise, the scope of the
>> usage
>> >> identifier can have the following choices:
>> >> (I) per BPEL process: Similar to "R1"
>> >> (II) per partnerLink: Each partnerLink has its own
>> namespace
>> >> for usage identifier. That is my CURRENT proposed
>> semantics.
>> >> As of my current proposed semantics, "Scope"/"namespace" is
>> per
>> >> partnerLink. That means:
>> >> The same identifier CANNOT be used for 2 receive/reply
>> >> pairs on
>> >> the same plink. That means the following is illegal.
>> >> <scope>
>> >> <partnerLink name="p1" ... />
>> >> <receive partnerLink="p1" operation="op1"
>> usage="u1" />
>> >> <receive partnerLink="p1" operation="op1"
>> usage="u1" />
>> >> <reply partnerLink="p1" operation="op1" usage="u1" />
>> >> <reply partnerLink="p1" operation="op1" usage="u1" />
>> >> </scope>
>> >> The usage identifier are not shared among
>> partnerLink. It is
>> >> legal to do the following:
>> >> <receive partnerLink="p1" operation="op1"
>> >> usage="handleCust"
>> >> />
>> >> <reply partnerLink="p1" operation="op1"
>> >> usage="handleCust"
>> >> />
>> >> <receive partnerLink="p2" operation="op1"
>> >> usage="handleCust"
>> >> />
>> >> <reply partnerLink="p2" operation="op1"
>> >> usage="handleCust"
>> >> />
>> >> (No matter whether p1 and p2 are declared in the same
>> >> scope or
>> >> not)
>> >> From the BPEL engine viewpoint, the first receive
>> >> operation is
>> >> now identified as the key tuple("p1"-"handCust",
>> "op1", >> cs).
>> >> "handCust" becomes a part of supplementary name of the
>> >> partnerLInk.
>> >> I totally agree with you that <receive> conflict / ambiguity
>> >> should
>> >> not happen that commonly. However, after passing Issue 75, I
>> >> tend to
>> >> think we want to make the <scope> construct as modular as
>> >> possible.
>> >> So, it will be easier for us to move / copy the <scope> around
>> >> from
>> >> one process to another process. A per-process namespace (I)
>> for
>> >> the
>> >> "usage" identifier is not good enough for this modularity
>> goal.
>> >> The <receive> conflict / ambiguity can be avoided in a large
>> >> extent
>> >> by using a locally scope partnerLink without using the "usage"
>> >> identifier already. Therefore, I suggest (II) semantics
>> where the
>> >> "usage" identifier fits as merely a supplement identifier to a
>> >> partnerLink.
>> >> I will send a separate email to illustrate how I see locally
>> >> scoped
>> >> partner can solve a majority of <receive> conflict / ambiguity
>> >> problems already.
>> >>
>> >> Thanks!
>> >>
>> >>
>> >> Regards,
>> >> Alex Yiu
>> >>
>> >>
>> >>
>> >> [P.S.: A third alternative semantics: (III) coincide with the
>> same scope
>> >> which the used partnerLink is declared: that is a macro version
>> of an
>> >> implicit declaration of "messageExchange" element in "R1B". (I
>> think
>> >> that
>> >> is what Maciej mentioned in the conf call. I said it is the current
>> >> semantics of my proposal by mistake. Sorry about that.) ]
>> >>
>> >>
>> >>
>> >> Francisco Curbera wrote:
>> >>
>> >>
>> >>
>> >> Hi Alex,
>> >>
>> >> I like the simplicity approach that your R1B shares with R1.
>> >> However,
>> >> I
>> >> don't really understand the following:
>> >>
>> >> Lifetime: you say the "lifetime" of an identifier is the
>> plink.
>> >> Does
>> >> that mean that the same identifier can be used for 2
>> >> receive/reply
>> >> pairs
>> >> on the same plink - supposedly non conflicting ones? This
>> >> seems to
>> >> open
>> >> the door for ambiguity or at least lack of clarity.
>> Making ids
>> >> unique
>> >> per MEP instance is a much simpler approach. Maybe you
>> >> really mean
>> >> "scope"...
>> >> "Namespace" (again I think this is actually "scope"): what
>> >> is good
>> >> about
>> >> enabling the language so two MEP instances in different
>> >> plinks can
>> >> share
>> >> the same usage id? The design looks particularly error
>> prone,
>> >> potentially misleading authors/consumers of process
>> >> definitions to
>> >> match
>> >> receives and replies incorrectly because their usage ids
>> match
>> >> (but
>> >> their plinks don't!). It certainly gives you flexibility
>> but I
>> >> don't
>> >> know if the potential confusion and lack of readability
>> >> makes it
>> >> worth.
>> >> I don't understand your last point about receive
>> >> identification.
>> >> Are you
>> >> proposing that the usage id be required? Or that it have a
>> >> runtime
>> >> representation in messages targeted at that receive?
>> >>
>> >> I am really skeptical that dealing with name collisions is
>> >> actually
>> >> necessary in this case, seems to me we're trying to attack a
>> >> problem
>> >> that
>> >> does not exist. The fact is that <receive> conflicts of this
>> >> kind are
>> >> probably going to be uncommon overall. Even when they happen I
>> >> doubt
>> >> that
>> >> we'll see so many conflicts in a single process that you
>> cannot
>> >> deal
>> >> with a
>> >> single process-wide naming scope for MEP instance ids. The
>> little
>> >> benefit
>> >> we can get out of the solutions proposed to deal with the id
>> >> collission
>> >> problem doesn't seem justify the additional complexity they
>> all
>> >> introduce.
>> >>
>> >> Paco
>> >>
>> >>
>> >>
>> >>
>> >> Alex Yiu
>> >>
>> >> <alex.yiu@oracle. To:
>> >> ygoland@bea.com
>> >>
>> >> com> cc:
>> Satish
>> >> Thatte <satisht@Microsoft.com>, Francisco
>> >> Curbera/Watson/IBM@IBMUS,
>> >>
>> >> "Eckenfels.
>> Bernd"
>> >> <B.Eckenfels@seeburger.de>, wsbpel@lists.oasis-open.org,
>> Alex Yiu
>> >> 08/03/2004 11:02 >>
>> <alex.yiu@oracle.com>
>> >>
>> >> PM Subject: Re:
>> >> [wsbpel]
>> >> Issue - 123 - Matching <reply> with <receive>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Hi, all,
>> >>
>> >> After reading all the emails on this thread, I guess "R1" and
>> >> "R1A"
>> >> have
>> >> its own pros and cons.
>> >>
>> >> I am think out loud again here to try to come up with a third
>> >> proposal (
>> >> "R1B") to address both simplicity and clarity of scope.
>> >>
>> >> (This is not my super firm position. The opinions polled
>> split as
>> >> 50-50 so
>> >> far. This is just yet another "thinking-out-loud" attempt
>> to merge
>> >> two
>> >> solutions into one):
>> >>
>> >> Proposal of "R1B":
>> >> Syntax-wise, it is similar to "R1". Except I would
>> >> suggest to
>> >> rename
>> >> to something like "usage" or "plinkUsage". E.g.:
>> >> <receive partnerLink="plink1"
>> usage="handleCustomer" ...>
>> >> ...
>> >> <receive partnerLink="plink1"
>> usage="handlerShipper" ...>
>> >> ...
>> >> <reply partnerLink="plink1"
>> usage="handlerCustomer" ...>
>> >> ...
>> >> <reply partnerLink="plink1" usage="handlerShipper"
>> ...>
>> >> The identifier used in the attribute does NOT need to be
>> >> declared
>> >> explicity in a scope beforehand. The identifier is
>> declared
>> >> implicitly in a sense. (This addresses the need of
>> >> simplicity.)
>> >> Semantics of the identifier used in the "usage"
>> attribute:
>> >> Lifetime: The lifetime of the "usage" identifier
>> >> shares
>> >> the the
>> >> lifetime of the partnerLink used in the operation.
>> >> This
>> >> addresses both the need of clarity of lifetime and
>> >> imposes a
>> >> tighter control and make sure the lifetime of the
>> >> identifier is
>> >> sync with the lifetime of the partnerLink.
>> >> Namespace: The namespace of the identifier is PER
>> >> partnerLink.
>> >> For examples: (all of the following are using
>> the same
>> >> operation and CS)
>> >> <receive partnerLink="plink1"
>> usage="handleCustomer"
>> >> .../>
>> >> <receive partnerLink="plink1"
>> usage="handlerShipper"
>> >> .../>
>> >> These two receive operations do NOT collide.
>> >> <receive partnerLink="plink1"
>> usage="handleCustomer"
>> >> .../>
>> >> <receive partnerLink="plink2"
>> >> usage="handlerCustomer"
>> >> .../>
>> >> These two receive operations do NOT collide.
>> >> <receive partnerLink="plink1"
>> usage="handleCustomer"
>> >> .../>
>> >> <receive partnerLink="plink1"
>> >> usage="handlerCustomer"
>> >> .../>
>> >> These two receive operations do collide. This
>> >> collision
>> >> MUST be caught by static analysis.
>> >> This addresses name collision prevention. And, it
>> >> actually
>> >> makes even easier to avoid any name collision.
>> >> Unique key to identify a receive operation: We
>> >> continue
>> >> to have
>> >> 3 components to uniquely identify a receive:
>> >> [a] partnerLink (+ "usage" attribute, if used)
>> >> [b] operation
>> >> [c] any CS (if used)
>> >>
>> >> I hope you guys like my proposal.
>> >> Thanks!
>> >>
>> >>
>> >> If you guys still want to read further, here is my analysis
>> on the
>> >> current
>> >> R1 and R1A proposal:
>> >> R1:
>> >> Advantage: simple syntax (just one attribute)
>> >> Disadvantage: scope of the identifier used in that
>> >> attribute is
>> >> NOT clear (i.e. leading to "unclear MEP
>> lifetime" and
>> >> "harder
>> >> name collision prevention" in Yuzo's previous
>> email)
>> >> R1A:
>> >> Advantage: scope of identifier used in that
>> >> attribute is
>> >> clear.
>> >> Disvantage:
>> >> A bit too verbose
>> >> An odd concept introduced:
>> >> As of current spec stands, we have 3
>> >> components to
>> >> uniquely identify a receive: [a]
>> >> partnerLink
>> >> [b]
>> >> operation [c] any CS (if used). With
>> >> R1A, we
>> >> now
>> >> introduce yet one more entity
>> >> ("messageExchange")
>> >> to the formula. Its lifetime can be
>> >> totally
>> >> in a
>> >> different scope compared with >>
>> partnerLink or
>> >> CS.
>> >> We are making a 2 dimensional
>> problem (two
>> >> disjoint
>> >> entities: partnerLink and CS) into 3
>> >> dimensional
>> >> one.
>> >> Apart from this disambiguating
>> usage, this
>> >> messageExchange entity does not
>> have other
>> >> usages
>> >> and meaning. Yet, it has the naming of
>> >> this
>> >> board
>> >> semantics. It may tempt vendors and
>> >> customers
>> >> to
>> >> overload and extend that term
>> >> signficantly in
>> >> a
>> >> totally unpredictable way.
>> >>
>> >> Thanks!
>> >>
>> >>
>> >>
>> >> Regards,
>> >> Alex Yiu
>> >>
>> >>
>> >>
>> >>
>> >> 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]