[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [stp-dev] SCA model: the "implementation", "component" and "componentType" elements...
|
Thanks Michael, it explains a
lot.
In term of naming is there a plan to try to sync up the
model and the APIs for the elements they have in common (while still keeping the
various abstractions and indirections you described of course)?
cheers,
d.
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
