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>


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]