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>



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]