ISSUE 52: @ImplementationRef on Service or Reference to identify appropriate parts of the implementation

[Scott Vorthmann <scottv@tibco.com>]

http://www.osoa.org/jira/browse/ASSEMBLY-52

On Feb 21, 2008, at 11:53 AM, Michael Rowley wrote:

>
> 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.
>
>
>