Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "SCA/Components/SCA Meta Model"
(→New bindings, interfaces, and implementation) |
(→SCA meta model diagram) |
||
Line 55: | Line 55: | ||
* OSGiImplementation(any anyAttribute) | * OSGiImplementation(any anyAttribute) | ||
+ | |||
+ | ==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. | ||
==SCA meta model diagram== | ==SCA meta model diagram== | ||
This figure [[Image:SCAMM.jpg||100px]] represents the SCA meta model diagram used (OSOA meta model + corrections + added references + new bindings, interfaces and implementations). | This figure [[Image:SCAMM.jpg||100px]] represents the SCA meta model diagram used (OSOA meta model + corrections + added references + new bindings, interfaces and implementations). |
Revision as of 06:22, 1 February 2008
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.
Contents
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 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
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)
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.
SCA meta model diagram
This figure represents the SCA meta model diagram used (OSOA meta model + corrections + added references + new bindings, interfaces and implementations).