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,

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
      .






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