[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 123 - Matching <reply> with <receive>
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. > > > > >
This is a digitally signed message part
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]