[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]