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>


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]