Bogdan Vatkov wrote:
> 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@xxxxxxxxxxx> 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