SCA/Components/SCA Meta Model

Next sections describe the SCA meta model used by the SCA Composite Designer. The meta model is based on the OSOA XSD files that were corrected, adapted and extended.

OSOA meta model corrections

Our SCA meta model is based on the OSOA scheme available in the OSOA web site (http://www.osoa.org/xmlns/sca/1.0/).

We modify these scheme to reflect properly the SCA Assembly Model Specification and to enable the validation of the XSD model. We corrected also some structural problems. See [1].

Meta model modifications

Some existing links between elements in the XSDs are not represented by EReference in the generated ecore meta model. For example, the SCA meta model element Service has a EAttribute promote that links it with a ComponentService. However, tools need to know explicitly that a reference exists between these two elements. Then, for each EAttribute representing a link between SCA elements we add, in the ecore meta model, an EReference as depicted in the following table. These new references are not serialized but calculated from the field representing the link.

SCA meta model modifications

The table's caption

SCA Element	EAttribute representing a link	EReference added
Service	The promote attribute identifies the promoted Service	promote2 that references the promoted ComponentService
Reference	The promote attribute identifies the promoted Reference	promote2 that references the promoted ComponentReference
Wire	The source attribute names the source component reference	source2 that references the promoted ComponentReference
Wire	The target attribute names the target component service	target2 that references the promoted ComponentService

New bindings, interfaces, and implementation

Tuscany

We add binding, interface and implementation types supported by Tuscany (nsUri: http://tuscany.apache.org/xmlns/sca/1.0):

• RMIBinding(host, port, serviceName, anyAttribute)
• AtomBinding(any)
• HTTPBinding(any)
• JSONRPCBinding(any)
• DWRBinding(any)
• NotificationBinding(any, modificationType, ntm)
• RSSBinding(any)
• BPELPartnerLinkType(serviceRole, type, any, anyAttribute)
• ScriptImplementation(mixed, any, language, script)
• XQueryImplementation(any, location)
• NotificationImplementation(name, any)
• ResourceImplementation (any, location)
• OSGiImplementation(any anyAttribute)

Frascati

nsUri:http://frascati.ow2.org

• JBIBinding(service-name,interface-name,endpoint-name)

• FractalImplementation(definition)

The FractalImplementation type describes components implemented with the Fractal component model (http://fractal.objectweb.org/). Using the definition attribute, the FraSCAti platform allows to create Fractal component instances and link them with components of the SCA composite.

Additional validation rules

Additional validation rules that appear in the SCA specification documents but that are not considered by the SCA XSD scheme. We distinguish 2 types of rules:

• The rules which apply on the SCA assembly description files and
• The rules which verify coherence between the SCA assembly description files and the implementation.

Rules which apply on the SCA assembly description files

• Uniqueness of names:
  • The component name must be unique across all the components in the composite (L142).
  • The name of a composite reference must be unique across all the composite references in the composite (L1325).
  • The name of a composite service must be unique across all the composite services in the composite (L1498).
  • The name attribute allows distinction between multiple binding elements on a single service or reference. The default value of the name attribute is the service or reference name. When a service or reference has multiple bindings, only one can have the default value; all others must have a value specified that is unique within the service or reference (L2319).

• Multiplicity:
  • Multiple target services (target is an attribute of a service) are valid when the reference has a multiplicity of 0..n or 1..n. (L1581) (L203) (L211).
  • The value specified for the multiplicity attribute of a composite reference has to be compatible with the multiplicity specified on the component reference, i.e. it has to be equal or further restrict (L1364).
  • The target attribute of a composite reference is a list of one or more target services, depending on multiplicity setting (L1342).
  • The same component reference may be promoted more than once, using different composite references, but only if the multiplicity defined on the component reference is 0..n or 1..n. The multiplicity on the composite reference can restrict accordingly (L1392).

• Visibility:
  • For a composite used as a component implementation, wires can only link sources and targets that are contained in the same composite (irrespective of which file or files are used to describe the composite). Wiring to entities outside the composite is done through services and references of the composite with wiring defined by the next higher composite (L1630).
  • Components within the composite cannot be referenced directly by the using component. The using component can only connect wires to the services and references of the used composite and set values for any properties of the composite. The internal construction of the composite is invisible to the using component (L1852).
  • Composite services involve the promotion of one service of one of the components within the composite (L1059).
  • Composite references involve the promotion of one or more references of one or more components (within the composite) (L1061).
  • When a component is constrained by a constrainingType (via the "constrainingType" attribute), the entire componentType associated with the component and its implementation is not visible to the containing composite. The containing composite can only see a projection of the compo nentType associated with the component and implementation as scoped by the constrainingType of the component. For example, an additional service provided by the implementation which is not in the constrainingType associated with the component cannot be promoted by the containing composite (L2188).

• Valid URI:
  • Valid URI schemes are <component-name>/<reference-name> for the attribute source of a wire. The specification of the reference name is optional if the source component only has one reference (L1621).
  • Valid URI schemes are <component-name>/<service-name> for the attribute target of a wire. The specification of the service name is optional if the target component only has one service with a compatible interface (L1625) .
  • The value of the promote attribute of a composite reference is a list of values of the form <componentname>/<reference-name> separated by spaces. The specification of the reference name is optional if the component has only one reference (L1328).
  • The promote attribute value of a composite service is of the form <component-name>/<service-name>. The service name is optional if the target component only has one service (L1501).

• Validity:
  • A composite used as a component implementation must honor a completeness contract. The concept of completeness of the composite implies that (L1857):
    • the composite must have at least one service or at least one reference.
    • each service offered by the composite must be wired to a service of a component or to a composite reference
  • Two or more component references may be promoted by one composite reference, but only when (L1395):
    • the interfaces of the component references are the same, or if the composite reference itself declares an interface then all the component references must have interfaces which are compatible with the composite reference interface
    • the multiplicities of the component references are compatible, i.e one can be the restricted form of the another, which also means that the composite reference carries the restricted form either implicitly or explicitly
    • the intents declared on the component references must be compatible – the intents which apply to the composite reference in this case are the union of the required intents specified for each of the promoted component references. If any intents contradict (e.g. mutually incompatible qualifiers for a particular intent) then there is an error.
  • If the attribute “WiredByImpl” of a reference is set to true, then the reference should not be wired statically within a composite, but left unwired (L220).
  • If the attribute “WiredByImpl” of a composite reference is set to true, then the reference should not be wired statically within a using composite,but left unwired (L1351).
  • uri attribute of a binding is optional for references defined in composites used as component implementations, but required for references defined in composites contributed to SCA domains (L2307).

Rules which verify coherence between the SCA assembly description files and the implementation

• Name and type matching with implementation:
  • The name of a service has to match a name of a service defined by the implementation (L164).
  • The name of a reference has to match a name of a reference defined by the implementation (L192)
  • The name of the property has to match a name of a property defined by the implementation (L279). The property type specified must be compatible with the type of the property declared by the implementation (L274).

• Compatible interface:
  • If an interface is specified for a service, it must provide a compatible subset of the interface provided by the implementation (L177).
  • If an interface is specified for a reference, it must provide a compatible subset of the interface provided by the implementation (L226).
  • If an interface is specified for a service composite it must be the same or a compatible subset of the interface provided by the promoted component service, i.e. provide a subset of the operations defined by the component service (L1512).
  • If an interface for a composite reference is specified it must provide an interface which is the same or which is a compatible superset of the interface declared by the promoted component reference (L1358).
  • A wire may only connect a source to a target if the target implements an interface that is compatible (see document) with the interface required by the source (L1634).
  • A wire can connect between different interface languages (e.g. Java interfaces and WSDL portTypes) in either direction, as long as the operations defined by the two interface types are equivalent. They are equivalent if the operation(s), parameter(s), return value(s) and faults/exceptions map to each other (L1648).

• Validity:
  • When an implementation is constrained by a constrainingType it must define all the services, references and properties specified in the corresponding constrainingType. The constraining type’s references and services will have interfaces specified and may have intents specified. An implementation may contain additional services, additional optional references and additional optional properties, but cannot contain additional non-optional references or additional non optional properties (a non-optional property is one with no default value applied) (L2182).
  • The constrainingType can include required intents on any element. Those intents are applied to any component that uses that constrainingType. In other words, if requires=”reliability” exists on a constrainingType, or its child service or reference elements, then a constrained component or its implementation must include requires=”reliability” on the component or implementation or on its corresponding service or reference. Note that the component or implementation may use a qualified form of an intent specified in unqualified form in the constrainingType, but if the constrainingType uses the qualified form, then the component or implementation must also use the qualified form, otherwise there is an error (L2196).
  • The rule which forbids mixing of wires specified with the target attribute with the specification of endpoints in binding sub elements of the reference also applies to wires specified via separate wire elements (L1592).

SCA meta model diagram

This figure represents the SCA meta model diagram used (OSOA meta model + corrections + added references + new bindings, interfaces and implementations).