Hello
Alex,
I like
that very much. Perhaps we can aline that with the roles in the partnerLinks,
which are currently somewhat unused in BPEL?
Mit freundlichen Grüßen Bernd
Eckenfels Chief Architect -- SEEBURGER
AG - Edisonstr.1 , D-75015 Bretten, Germany Fax: +49 (0)7252 96-2400 - Phone:
+49 (0)7252 96-1256 mailto:b.eckenfels@seeburger.de - http://www.seeburger.de
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
|