[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: NEW ISSUE: @ImplementationRef on Service or Reference to identify appropriate parts of the implementation
RAISER: Michael Rowley TARGET: SCA Assembly Specification, “Component Type”
section DESCRIPTION: The OpenCSA BPEL TC encountered a situation that may also be
an issue for other implementation types, which should probably be solved by the
assembly TC, rather than through implementation-specific mechanisms. In BPEL, more than one “partner link” can have
the same name (when at least one of them is inside a <scope>). The
generated component type, in those situations, can’t use the partner link
name as the service or reference name in the component type. In this
situation, we expect that a user will create a component type by hand, which
will include appropriate unique names for each service and reference. So, the user will choose a name attribute for each service
and reference, but there also needs to be some way of referencing the partner
link that the service or reference is for. We believe that this situation will occur for other
implementation types (including implementation types that would never be
standardized). The implementation will have some means of identifying
what SCA would call services and references, but the original implementation
will have some way of identifying those things that would not translate well
into SCA’s names for services and references. In those cases, the
user should be able to create a component type side file, which names those
services and references, and also points to the implementation-specific
construct that is used for each. PROPOSAL: Introduced a new optional attribute on componentType/service
and componentType/reference, with a name of @implementationRef, whose contents
are a string, but where the interpretation of that string is specific to the
implementation type. For example, imagine a BPEL process with a partner link
named “MyPL” under a scope named “S”. In the case
of BPEL, the contents of the @implementationRef could be an XPath expression
that gets you at the right partner link element (these semantics would be
described in the SCA BPEL spec). The component type might look like the
following: <componentType> <implementation.bpel name=”acme:myProcess”/> <service name=”aGoodName” implementationRef=”//scope[@name=’S’]/partnerLink[@name=’MyPL’]”/> </componentType> Another scenario where this @implementationRef attribute
could be used is if the designer wants a different service name from the one
that would be generated from the implementation, even if there is no ambiguity
problem. One reason people might want to do this is that the names in the
implementation might use specific prefixes or suffixes according to their use
within the implementation, but where those special conventions don’t make
sense in the larger SCA setting. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]