Re: [wsbpel] Issue - 123 - Matching <reply> with <receive>

[Alex Yiu <alex.yiu@oracle.com>]

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:
          o 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>
          o 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.
>
>  
>