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

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

Hi,  Maciej,

[thinking out loud here again ...  thoughts and inputs are very welcome]

I think you raised a good question for clarification.
As mentioned in my previous email, I tend to think the usage id as a 
supplementary identifier.
Therefore, I consider the two usage examples are legal. Because, there 
are no outstanding receives sharing the same identifier tuple 
((p1,"handleCust"),"op1").

Your question actually leads me to provide one more clarification. 
Consider this example:

<sequence>
  <receive partnerLink="p1" operation="op1" usage="handleCust" />
  <receive partnerLink="p1" operation="op2" usage="handleCust" />
   ...
</sequence>

The above usage is also legal. Because, again the tuple that identifies 
two outstanding receive are not the same:
((p1,"handleCust"),"op1")
((p1,"handleCust"),"op2")


To sum up:
It is illegal to have more than one outstanding <receive> that shares 
the same identification tuple  value:
( (/partnerInstance/,"optional-usage-id"), "operation-name", 
/optional-CS-instances/)
Otherwise, they are legal.

A <reply> operation needs refer to one and only one outstanding 
<receive> operation by matching the tuple. If zero or more than one 
<receive> are matched, then it is illegal.

I hope it is OK for me to borrow the tuple term from relational db. From 
the pure relational tuple matching viewpoing, the scope of 
"optional-usage-id" actually does not matter upon retrospection, since 
partnerLink instance is always in the tuple. That is:
((p1,"handleCust"),"op1") ==  (p1,"handleCust","op1")

I guess we still need to refine what matching means. e.g.: whether / how 
we need to matchof CS-instances parts. My *gut feeling* so far that part 
of maching should be optional so far. That loops back to another hot 
sub-topic discussed among Paco, Satish and Yaron under Issue 123. (Which 
again I have not put too much thought in yet).


Thanks!



Regards,
Alex Yiu



Maciej Szefler wrote:

>Is "reuse" of the identifier allowed once the message exchange reaches a
>terminal state (i.e. there is no outstanding receive)?
>
>Is the following legal (or perhaps barely legal)?
><scope>
> <partnerLink name="p1" ... />
> <while ...>
>  <receive partnerLink="p1" operation="op1" usage="handleCust" />
>  <reply partnerLink="p1" operation="op1" usage="handleCust" />
>  <!-- p1.op1.handleCust  in terminal state (request/response MEP) -->
> </while>
></scope>
>
>or similarly:
>  <receive partnerLink="p1" operation="op1" usage="handleCust" />
>  <reply partnerLink="p1" operation="op1" usage="handleCust" />
>  <!-- p1.op1.handleCust  in terminal state (request/response MEP) -->
>  <receive partnerLink="p1" operation="op1" usage="handleCust" />
>  <reply partnerLink="p1" operation="op1" usage="handleCust" />
>
>-maciej
>        
>On Thu, 2004-08-05 at 01:41, Alex Yiu wrote:
>  
>
>>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.
>>>
>>>  
>>>      
>>>
>
>  
>