[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 123 - Matching <reply> with <receive>
Alex, your proposal has now been incrementally modified a number of times in a number of different e-mails. I can't track anymore exactly what you are proposing. Could you please send a new e-mail with a full proposal with all the modifications rolled in? Thanks, Yaron Alex Yiu wrote: > > > 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]