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