[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
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
<a class="moz-txt-link-rfc2396E" href="mailto:alex.yiu@oracle.To:ygoland@bea.comcom";><alex.yiu@oracle. To: ygoland@bea.com
com></a> cc: Satish Thatte <a class="moz-txt-link-rfc2396E" href="mailto:satisht@Microsoft.com";><satisht@Microsoft.com></a>, Francisco Curbera/Watson/IBM@IBMUS,
"Eckenfels. Bernd" <a class="moz-txt-link-rfc2396E" href="mailto:B.Eckenfels@seeburger.de";><B.Eckenfels@seeburger.de></a>, <a class="moz-txt-link-abbreviated" href="mailto:wsbpel@lists.oasis-open.org";>wsbpel@lists.oasis-open.org</a>, Alex Yiu
08/03/2004 11:02 <a class="moz-txt-link-rfc2396E" href="mailto:alex.yiu@oracle.com";><alex.yiu@oracle.com></a>
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 <a class="moz-txt-link-freetext" href="http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php";>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php</a>.
</pre>
</blockquote>
<br>
</body>
</html>
--------------010707040704090107070908--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]