SCA Signatures

Introducing the need

SCA Tools provides meta-models of SCA specifications, implemented with Eclipse EMF.
These meta-models act as the basis for several Eclipse tools for SCA, including the SCA Composite Designers and the SCA builders. However, not all the tools are built upon this model, but rather use a usual XML/DOM model.

The first issue we met was that these tools had to work together, even if they were using different model representations. A second issue we met was related to the tracking of changes in an SCA model / composite file. This is in particular true with model transformations. Imagine one instance of a SCA model was transformed into something else. If the SCA model would change, what should be changed into this something else to keep the equivalence, without regenerating everything?

These issues led to the definition of a new concept: SCA signatures.

SCA Signatures

A SCA signature is an object which identifies a SCA element (a component, a service...) in a unique manner.
Or if you prefer another explanation, SCA signatures are computed element IDs, similar to a unique HashCode. They only make sense for SCA artifacts.

If you find two SCA elements with the same signature, there are only two possibilities. Either they are the same element, or the project contains errors. There is no other explanation. In a model instance, to find the element matching a given signature, you simply have to compute the signature of any element until you find one with the same signature. SCA signatures can be computed quickly and for any SCA element (in a composite, a constraining type - and soon for a component type). They can be created either from XML nodes or from EObjects.

SCA signatures in a concrete way

SCA signatures are computed from resource contents.
They look like a XPath expressions, using element and attributes names as identifiers.

Let's take an example by considering the composite below.

<?xml version="1.0" encoding="ISO-8859-15"?>
<sca:composite 
	xmlns:sca="http://www.osoa.org/xmlns/sca/1.0" 
	xmlns="http://www.osoa.org/xmlns/sca/1.0" 
	name="TestRestaurantServiceComponent" targetNamespace="http://eclipse.org/sample/sca">
 
  <!-- Test Component --> 
  <sca:component name="TestComponent">
    <sca:implementation.java class="org.eclipse.stp.sca.test.sample.impl.RestaurantServiceComponentRTSImpl"/>
 
   <sca:service name="RunTestService">
      <tuscany:binding.rmi xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.0" 
      	host="localhost" port="8098" serviceName="TestSca"/>
    </sca:service>
 
	<sca:service name="BillService"><sca:binding.sca/></sca:service>
    <sca:service name="MenuService"><sca:binding.sca/></sca:service>
 
   <sca:reference name="restaurantService">
      <tuscany:binding.rmi xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.0" 
      	host="localhost" port="8099" serviceName="RestaurantServiceRMI" />
    </sca:reference>
  </sca:component>
 
  <!-- Tested Component --> 
  <sca:component name="RestaurantServiceComponent">
    <sca:implementation.java class="restaurant_rmi_service.lib.RestaurantServiceImpl"/>
 
	<sca:service name="RestaurantService">
      <sca:interface.java interface="restaurant_rmi_service.api.RestaurantService"/>
      <tuscany:binding.rmi xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.0" 
      	host="localhost" port="8099" serviceName="RestaurantServiceRMI" />
    </sca:service>
 
	<sca:reference name="billService"><sca:binding.sca/></sca:reference>
    <sca:reference name="menuService"><sca:binding.sca/></sca:reference>
  </sca:component>
 
  <sca:wire source="TestComponent/restaurantService" target="RestaurantServiceComponent/RestaurantService"/>
  <sca:wire source="RestaurantServiceComponent/billService" target="TestComponent/BillService"/>
  <sca:wire source="RestaurantServiceComponent/menuService" target="TestComponent/MenuService"/>
  <sca:service name="RunTestService" promote="TestComponent/RunTestService"/>
</sca:composite>

• The signature of the composite itself is:

  composite[TestRestaurantServiceComponent,http://eclipse.org/sample/sca]

• The signature of the first component service is

  composite[TestRestaurantServiceComponent,http://eclipse.org/sample/sca]/component[TestComponent]/service[RunTestService]
  		

• The signature of the last wire is

  composite[TestRestaurantServiceComponent,http://eclipse.org/sample/sca]/wire[RestaurantServiceComponent/menuService -> TestComponent/MenuService]
  		

Although they are readable, you should rather see SCA signatures like a long string identifier.
As you may have noticed also, a SCA signature is made up of segments. Each segment corresponds to an element in the XML tree.

An element signature has the signature of its ancestor (eContainer) as prefix.
Parts between square brackets are attributes which identify the given element. If one of these attributes changes, the element signature changes too.

Computing an SCA signature

SCA signature segments are computed in the following way:

• For a composite, it is the element name "composite", followed by the two attributes that identify in a unique way a composite in a project scope: the name and the target namespace. In a project, you can't have two composites with the same name and target namespace. Otherwise, SCA composite inclusions can't work.
• For a component, a service, a reference and a property, it is the element name and the name attribute.
• For an include, it is the element name (include) and the name and target namespace of the included composite.
• For a wire, it is the element name (wire) and the source and target attributes (two wires can't have the same ones).
• For interfaces, implementations and bindings, the element name is enough. You can't have one of their ancestor having two such elements. That would be an invalid SCA application.
• For other elements, by default, only the element name is taken. It may change if new requirements appear.

To compute the signature of an SCA element, use one of the following:

new ScaSignature( EObject scaEObject ).toString();

new ScaSignature( Node scaNode ).toString();