Home » Modeling » Modeling (top-level project) » How to create extensible EMF model (via FeatureMaps) based on multiple XSDs (with substituion groups
| How to create extensible EMF model (via FeatureMaps) based on multiple XSDs (with substituion groups [message #594050] |
Thu, 21 June 2007 12:37 |
 Bogdan Vatkov
Messages: 16
Registered: July 2009 |
Junior Member |
|
|
Hi all,
Please, redirect to other mailing lists/newsgroups if this is not the
right newsgroup.
I would need some advice on how to implement extensible (pluggable) EMF
model based on multiple XSDs.
I would like to contribute the SCA v1.0 metamodel as chain of EMF models
based on corresponding XSDs. The XSDs are defined at
http://www.osoa.org/xmlns/sca/1.0 and the problem that I am currently
facing is that one and the same targetNamespace is used across all the
XSDs. In the sca-core.xsd we have several XML substitution groups which
end up as FeatureMaps in the EMF model. So on XSD level we have some
kind of "extensibility" defined already. Now I would like to "translate"
this "extensibility" into the EMF models.
If I get the sca.xsd schema that includes all the other XSDs then
everything works fine - I have my FeatureMaps for the substitution
groups, and the generated EMF API is just fine - provides the base
classes and inheritor classes for those "meta-model extension points"
(XML subs groups).
The problem is that if I do that I do not have this extensible pluggable
meta-models. For example in the sca-core definition we have the class
Implementation and in several other XSDs we have inheritors like
ImplementaionJava, ImplementationBPEL, ImplementationWeb, etc.
So, I do now want to create one EMF model based on one XSD that simply
aggregates several other XSDs. I would like to create as many EMF models
as XSD file we have, and the resulting EMF models/APIs to inherit from
each other (as defined by the XSD definitions).
I can't use the "referenced generated models" because all the XSDs are
with one and the same targetNamespace.
I would agree to make some cosmetic changes to the XSDs coming from
osoa.org if it would not result into XML elements with different namespaces.
You can see some more descriptions regarding the SCA metamodels in the
thread down bellow.
Thanks in advance!
Best regards,
Bogdan
------------------------------------------------------------ --------------------
RE: [stp-dev] SCA v1.0
From: "Vatkov, Bogdan" <bogdan.vatkov@xxxxxxx>
Date: Wed, 30 May 2007 13:18:58 +0200
Delivered-to: stp-dev@eclipse.org
Thread-index: AceiOozusjyS50ZRR6ypgWZgZyaLJwAZbpqg
Thread-topic: [stp-dev] SCA v1.0
------------------------------------------------------------ --------------------
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
|
|
|
Goto Forum:
Current Time: Thu Apr 25 17:05:37 GMT 2024
Powered by FUDForum. Page generated in 0.02935 seconds |
] 
Search
Help
Register
Login
Home
