Re: [stp-dev] SCA model: the "implementation", "component" and "componen

[Michael Elder <mdelder@xxxxxxxxxx>]

Hi David,

        Comments
are <mde>inline like this</mde>.
-------------------------------------------------------------------------
Kind Regards,

Michael D. Elder
Rational Studio / Services Tools Development     
IBM RTP Lab 
Ext: (919) 543-8356
T/L:  441-8356
mdelder@xxxxxxxxxx

"Beaurpere, David" <David.Beaurpere@xxxxxxxx>
Sent by: stp-dev-bounces@xxxxxxxxxxx

04/18/2006 10:25 AM

Please respond to
STP Dev list <stp-dev@xxxxxxxxxxx>

To	"STP Dev list" <stp-dev@xxxxxxxxxxx>
cc
Subject	[stp-dev] SCA model: the "implementation",        "component" and "componentType" elements...

Hi,
 
In order to get a better understanding of
the SCA model, I have spent the past few days looking at the 0.9 SCA specs
from the IBM web site as well as the ecore model and the unit tests available
in the STP CVS.
 
At this stage, I have some trouble understanding
the relationship between the "implementation", "component"
and "componentType" elements of the actual SCA model and was
hoping for some assistance from those familiar with the code.
 
According to my understanding of the written
specs:
  - a "componentType" is basically the public interface
layer of an "Implementation" with which it has a one to one relationship.
<mde>
One subtlety about the ComponentType
is that it is the contract between the Component (a configured implementation)
and the actual Implementation. It is not the contract between the Component
and clients of that Component. The set of Services provided in the ComponentType
make up the contract for the clients of the Component. 
</mde>
  - a "component" is a configured instance of an "implementation"
for which it provides the necessary values for the relevant config points
of its "componentType" layer.
<mde>
Correct. Keep in mind that the
ComponentType is mostly (if not completely) derived from the Implementation;
ComponentType is the "standard way" of talking about the configuration
points in any arbitrary Implementation.
</mde>
 
My problem is that I do not see this reflected
by the schema snippets provided with the specs document or the ecore model
in CVS:
  - Neither the "implementation", nor the "componentType"
elements reference the other in any way. In fact the only point of interaction
I found is with the element "AbstractImplementation" which extends
"implementation" and contains a "componentType". (Other
extensions of "implementation" don not even care about "componentType"
at all)
  - In the same fashion, the model doesn't establish any direct relationship
between "component" and either "componentType” or "implementation"
elements. Again the only point of interaction I found is an extension of
"component" called "ImplementationComponent" which
is meant to contain an "Implementation" element.

<mde>
In the schemas, the relationship
comes because an sca:component has an sca:implementation element. There's
some indirection in the generated form of the schema for various reasons,
so the relationships are more easily discerned looking through the Java
API. Here you'll find that org.eclipse.stp.core.sca.Component has
the method "getImplementation()" that returns an Implementation
(base interface type, not that fancy).

For this to be useful, you would
really need to know what type the implementation is; so to avoid alot of
casting down, most of the work with an Implementation is facilitated through
the Component Type Introspection framework; so let's look at that. 

A ComponentType is an abstraction
that is derived (as in extracted or computed and _not_ subclassed)
from the Implementation. An Implementation may use the ComponentType
schema to describe its services, references, and properties (like AbstractImplementation),
but in general we will want to derive these completely from the actual
Implementation (for instance there are annotations that describe
the Java ComponentType which are embedded in a Java *.java source
file. So for a Java component, we'd have something like:

<sca:component>  
     
       
<sca:implementation.java ... />
       
... configuration ...
</sca:component>

So we can get to the actual implementation
element (e.g. sca:implementation.java) through:

Component.getImplementation();

However, it would be more useful
to get the ComponentType through:

Component.resolveComponentType();

The infrastructure is smart enough
to share the ComponentType for re-useable implementations (like
two Components CA and CB that reference the same Java implementation
JI; they will have the same, shared ComponentType instance
-- the same in-memory model of the ComponentType derived from the
JI implementation). 

The ImplementationComponent
is broken out to allow Component to be extended by ModuleComponent;
We can then share a common abstract type between Module and Subsystem
(Module and Subsystem both extend Composite --
a common abstraction used only by the API and not part of the spec, and
not persisted). 

The following diagram shows this
relationship. 

Composite contains Components.

However, to allow Composite
to be the common super class for Module and Subsystem, the
type called Component cannot have an Implementation element
(since ModuleComponent uses a attribute that indicates a URI instead
of an Implementation element). 

So the abstraction here has:
+ a type named ImplementComponent
(which is the <sca:component /> element).
+ a type named ModuleComponent
(which is the <sca:moduleComponent /> element).
+ a type named Component
(which is the <sca:abstractComponent/> element which is never
serialized, non-spec, only for the purposes of the API)

When we made these changes, we
choose to leave the base type name as "Component" instead of
something like "AbstractComponent". We layer in the getImplementation()
API by hand since the calculation for a "simple" implementation
(like Java or BPEL) is different than the calculation for a "deployable"
implementation (like Module). 

In addition to this machinery,
the API supports three important subclasses of Implementation out
of the box. Remember all of these are the types of XML elements which use
substitution groups from standard, spec elements; for an XML element named
"implementation.xxx", it is a substitution for the spec-element
"sca:implementation" and has a generated type of XXXImplementation.

+ AbstractImplementation
: A simple substitution group for Implementation that contains an <sca:componentType
/> element. This element can be used for top-down development, before
a real implementation is specified. An AbstractImplementation can be:
         "untyped"
(no intended implementation expressed), 
         
"typed" (the user has indicated they eventually want this to
be a xxx implementation, but no real implementation has been associated
yet) or 
         
 "implemented" (e.g. no more AbstractImpelmentation)
+ ModuleImplementation
: An abstraction that carries along the URI from the ModuleComponent. While
the XML element is a substitution for sca:implementation; it is never serialized.
+ JavaImplementation :
The type for <sca:implementation.java /> element. 

There's also UnknownImplementation
and PropertiesImplementation which are used when the Implementation
cannot be determined and for testing; respectively. 

So to recap: 

A Component has an Implementation,
and the relationship is best expressed through the API. To allow for commonality
in tooling that works with Component and ModuleComponent alike, Module
and Subsystem alike, there is indirection the generated form of the schema
to provide a more usable API. The Component type doesn't correspond
to any spec-level type (remember this is the <sca:abstractComponent
/> in the generated schemas), but instead the ImplementationComponent
is the <sca:component /> element, and ModuleComponent is the
<sca:moduleComponent /> element. 

An Implementation derives its
ComponentType; the API is exposed on the Component (Component.resolveComponentType()).

</mde>

 
It almost looks like the concepts and relationships
established by the written specs aren't implemented by the model artefacts
the specs said it should but by children of those artefacts. Is there something
I missed? Is it intended? If it is, why?

 

Looking at the code in CVS and the "ComponentTests" class in particular, I got even more confused:
 
 - Line 74: an Instance of a class named "component" is produce from a factory but unlike the "component" element of the ecore model this class contains an "Implementation" attribute like the "ImplementationComponent" of the ecore model. So:
  1- was the "Component" class generated off the "ImplementationComponent" or "Component" element of the ecore model?
  2- why the confusing naming?
<mde>
I hope these questions are answered above. Please let me know if it's still unclear ...
</mde>
 - Line 103: the Component instance has a method named "setAbstractImplementation" which accept a "ComponentType" object as parameter. Again:
  1- this establish a relationship between the "component" and the "componentType" as I understood it in the written specs but that I didn't see reflected in the model.
  2- the naming of the method also seems to establish a 1 to 1 relationship between the concepts of "ComponentType" and "implementation" (or at least an extension of it) which again reflect my understanding of the written specs but which I didn't see in the model (both the schema snippets provided with the specs and the ecore model in CVS).
<mde>
The API for Component.setAbstractImplementation(ComponentType) supports top-down design. It will create an <sca:implementation.abstract /> element as a child of the <sca:component /> element in the Module file.

There is a 1:1 relationship between ComponentType and Implementation. Remember that Components can share Implementations and therefore share the same ComponentType. But each Component is its own configured instance of the Implementation. (So a Java implementation that requires a reference R of type T may have that reference resolved differently in two Components CA, CB that configure the implementation, but the ComponentType that describes reference R of type T will be the same in-memory model).
</mde>
 

It almost looks like the stp.core APIs are more in synch with the written specs but still with some of the naming convention used by the model. I have seen the mention of the added abstraction in the STP online docs but this section of the models isn't mentioned.
 
The bottom line is that there seems to be some syncing issues between the written specs, the ecore model and the code in stp.core.
If it's the case, is there any plan to bring all of them in sync? Until that happens, what should I relate to? The code only?
If it's not the case, and that's very possible since both SCA and EMF are 2 very new things for me, what do I miss?

<mde>
In general, I'd recommend to always to to the Java API before the generated *.ecore or the transformed specs. It is better documented, and the abstractions are easier to navigate than the schema substitution groups.
</mde>

 
Thanks for the help.
D.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 _______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev