[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Hi Oisin,
The SCA metamodel is defined as follows (each metamodel corresponds to
one XSD published in the spec):
SCA Assembly metamodel [sca-core.sxd] (defines the SCA assembly concepts
like: composite, composite service/reference/property, component,
component service/reference/property, wire)
As already mentioned in the STP Core project docs the SCA shema defines
several XML Substitution Groups which are in turn represented by
FeatureMaps in EMF - it is a place in the model where you can say for
example "I have a relation here to the class MyClass and any other sub
class of MyClass that is defined later on". So the SCA spec by
definition is prepared to be extensible in non-intrusive way. You can
add service interface, implementation and binding definitions.
Then based on the substitution groups in the assembly part there are
several types of additional (non-required) metamodels defined:
Interface
WSDL Port type [sca-interface-wsdl.xsd]
Java Interface [sca-interface-java.xsd]
Implementation
BPEL impl type [sca-implementation-bpel.xsd]
SCA Composite impl type [sca-implementation-composite.xsd]
Java (POJO) impl type [sca-implementation-java.xsd]
EJB impl type [sca-implementation-ejb.xsd]
Web (EE) impl type [sca-implementation-web.xsd]
Binding
WS binding [sca-binding-webservice.xsd]
EJB binding [sca-binding-ejb.xsd]
JMS binding [sca-binding-jms.xsd]
SCA binding (translated to native binding?)
[sca-binding-sca.xsd]
Those metamodels define the extension of SCA with the corresponding
interface description language, implementation technology, or
communication technology (binding).
There is one more metamodel:
Policy (defines policy sets, intents, etc.) [sca-policy.xsd]
These are also some other XSDs that will be good to be represented by
EMF meta-model (models are stored in XML documents compliant with the
source XSDs) eg. The contribution definition (defines contribution type,
deployable type, import type, export type, etc.) [sca-contribution.xsd]
- this particular one does not have relation to the assembly xsd like
all the others do.
So what I propose is to take the chance to preserve the extensibility
idea the SCA spec already defined through XML substitution groups and
use the FeatureMaps in EMF - AND in the same time to have a separate
metamodel in EMF whenever a substitution groups is defined and
inheritors are defined though separate XSD document in the spec. The
idea of subs groups/feature maps is already used in the current STP Core
Model plugin but all the XSDs are joined in a single monolithic EMF
metamodel definition.
If I now want to add new SCA impl type ... <implementation.php .../> for
example I would need to recreate the EMF metamodel in the core project
and if we switch to multiple EMF metamodels (corresponding to the XSDs
from the spec) I would need to create one _additional_ EMF metamodel for
the PHP implementation type. Or for example upgrading some of the SCA
client & impl specs is also a similar usecase.
Hope this clarifies the granularities in the current sca metamodel.
Best regards,
Bogdan
-----Original Message-----
From: stp-dev-bounces@xxxxxxxxxxx [mailto:stp-dev-bounces@xxxxxxxxxxx]
On Behalf Of Oisin Hurley
Sent: Wednesday, May 30, 2007 12:44 AM
To: STP Dev list
Subject: Re: [stp-dev] SCA v1.0
Hi Bogdan,
> I would need one short technical discussion with the community on
> the topic first.
>
> What I currently have is a particular set (the complete one for
> now) of the SCA XSDs imported as one monolithic EMF model. It is
> completely ok for me right now but I see problems in the future
> when somebody decides to define new SCA implementation or binding
> type. Then if we go with the current approach each extension of the
> SCA spec/standard will force us to recreate the metamodel (EMF
> model). I would recommend to discontinue the monolitic approach and
> define separate metamodels (with some references between them)
> based on a single XSD from the SCA spec. This would lead to a set
> of EMF models (15 for now).
> It is not a challenge to define 15 EMF models (the XSDs are
> defined) but I would like to ask whether the community would be
> comfortable with such an approach.
> I would like to discuss that point, make the proper changes if
> decided, and then to attaching the code to bugzilla entry.
Having a monolithic approach that causes maintenance difficulties
as extensions are added is probably not suitable if we have the
goal of making it easy for extenders to use our code. So an approach
that allows people to easile define an extension to a base model,
or set of base models, would be much better.
15 models seems to be a lot! I know that there is quite some flexibility
in the SCA assembly - can you give us an example of the granularity of
each model?
On contribution, there's a few things to take into account. If you are
proposing a patch to the existing core sub-project, then it is ok to
just add the patch to bugzilla and we can all take a look at it. If this
is new code, to be released to EPL by SAP (or individually as yourself),
then we need to bring it into the Eclipse IP process - and we are as
well
to get started asap!
best regards
Oisin
_______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev
