OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[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]