Proposal for Issue 6:
Original text under section 2.4:
---------------------------
- When these
partnerLinks are exposed to SCA assembly,
these partnerLinks will given aliases from "_orginalName_1" to
"_orginalName_N" regardless of how partnerLink participate in SCA
assembly (i.e. services vs references)
- If any
"_orginalName_i" (where 1 <=
i <= N) is already taken by existing
partnerLink declaration in the process definition, additional
underscore
characters may be added at the beginning of the aliases to avoid
collision.
---------------------------
New text:
---------------------------
- When these
partnerLinks are exposed to SCA assembly,
these partnerLinks will given aliases from "_orginalName_1" to
"_orginalName_N" regardless of how partnerLink participate in SCA
assembly (i.e. services vs references) and the
number suffixes are based on the document order of the corresponding
partnerLink occurrence in
the process definition.
- If any
"_orginalName_i" (where 1 <=
i <= N) is already taken by existing
partnerLink declaration in the process definition, additional
underscore
characters may be added at the beginning of all
aliases consistently to avoid
collision.
---------------------------
Thanks!
Regards,
Alex Yiu
Alex Yiu wrote:
47051198.3060901@oracle.com" type="cite">
Issue entered
http://www.osoa.org/jira/browse/BPEL-6
Alex Yiu wrote:
Danny,
Thanks for raising this issue.
The only under-specified part of the alias logic that I can think of so
far is: the numbering order.
I think clarifying the numbering order should be the document order in
the process definition. That should be sufficient.
Any other under-specified part of the logic?
Regards,
Alex Yiu
Danny van der Rijn wrote:
TARGET: SCA C+I WS-BPEL spec, General
DESCRIPTION: Section 2.4 lists some rules for deriving
service/reference alias names for partnerLinks when there is a
name-hiding in a scope. The rules, though are non-deterministic. This
will leave the algorithm that derives a component type from a BPEL file
as implementation-dependent. The goal of the algorithm is to produce a
component type from a BPEL file in a deterministic way, with no
external dependencies.
PROPOSAL: none
|