[
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...
|
I also want to point out that the SCA
specification was written with a runtime in mind. It was not written
in order to support tools. So as a tool provider it is our desire
to build a platform that promotes the concepts that we want exposed in
the tooling. This is not necessarily a one to one match with the
concepts described in the specification. Mind you they are close
and the serialization is compatible (i.e., what is produced by the tool
is valid based on the published schemas). If we would simply generate
an EMF model from the published SCA 0.9 schemas you would have found one
of the ugliest object models that you have ever seen. In order to
provide a better object model and to provide an API layer that could be
managed by the platform it is necessary to customize the generated code
either directly or through the use of transforming the published schemas
to a something that does generate a nice EMF object model.
For example you will not see AbstractImplementation
in the specification. This is due to the fact that the specification
wasn't written with the thought that a Component could hold the ComponentType
contract even without an Implementation being defined first (i.e., top-down
development). This is, however, a requirement for the tooling. Also
the notion of WireSource and WireTarget elements are not defined in the
specification but they make the creation of wires much easier within the
model.
I'll be the first to admit that some
of the terms used for the types in the model are not the best but this
is also true of the SCA specification in general. The specification
will be changing and evolving before it is finalized at the end of this
year. Our tooling model will need to react to these changes and evolve
as well. However we can buffer the impact of these changes to clients
by defining a set of APIs that is not necessarily a direct match with the
specification. Then when the specification changes our internal model
needs to change to react but it may be possible to keep the same set of
exposed APIs. I would be lying if I said the APIs defined in the
model would not change (or even disappear) because they are evolving as
we decide what is needed and what is not.
We have all built tools that conformed
to a specification in the past. One thing that I hope that everyone
has learned is that tools built that are exposing all concepts one-to-one
with the specification are typically not that usable and easy to consume.
Regards,
Dan
Michael Elder/Cambridge/IBM@IBMUS
Sent by: stp-dev-bounces@xxxxxxxxxxx
04/18/2006 02:35 PM
|
Please respond to
STP Dev list <stp-dev@xxxxxxxxxxx> |
|
|
To
| STP Dev list <stp-dev@xxxxxxxxxxx>
|
|
cc
| "STP Dev list" <stp-dev@xxxxxxxxxxx>,
stp-dev-bounces@xxxxxxxxxxx
|
|
Subject
| Re: [stp-dev] SCA model: the "implementation",
"component" and "componentType"
elements... |
|
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
_______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev
