[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Hi,
Comments inline.
Stéphane
If I understand correctly, it looks like you've tried to reconcile the
SCA XSDs with a logical model for SCA assembly. There are usually
multiple ways to do handle that kind of reconciliation, including:
- annotate the XSD with ecore annotations to add what's missing in the
XSD
- generate the XSD based model and tweak the generated Java by hand
- define your model using annotation java interfaces and additional
metadata for the feature map helping with the XSD mapping
- generate the XSD based model, then define UML classes representing
the logical view with additional logical relationships as subclasses of
the XSD generated classes
- have two different models one XSD-based physical model and a logical
one and map between the two.
Which approach did you take here?
The first one. I added "ecore:reference" annotations in the XSD
files.
Another relation question. In Tuscany we have defined Java interfaces
representing a logical model for SCA assembly. They are there:
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/assembly/src/main/java/org/apache/tuscany/sca/assembly/
These interfaces are plain Java interfaces without dependencies on EMF
or any other modeling or runtime technology.
How are your logical model interfaces different from these interfaces?
Quickly looking (later, I will look it deeper), I think there are
several similitudes. I see you have defined a composite reference
(service) and a component reference (service) as an extension of a
basic reference (service) type. We too.
Is there any interest in having tooling model classes implement the
Tuscany model interfaces as well? They are self contained and should be
really easy to reuse, with some interesting benefits like the ability
to hand a model instance directly to the Tuscany runtime if you did
that.
I agree with Bogdan answer.
Thoughts?
- Then, we generated the code and we added
some validation rules like "the component name must be unique in the
composite". I think this is important because these rules exist in the
specification document but they do not appear in the XSD scheme.
Did you use the EMF validation framework for that?
Yes.
Would these rules be usable outside of an EMF-enabled environment, as
long as the model they validate implement the expected logical model
interfaces?
No, because we use the EMF validation framework.
- Finally, we developed a first version of
our graphical designer. It works with Eclipse Europa, EMF 2.3 and GMF
2.0. This SCA Designer follows the SCA official specification to
represent composites, services, wires... See the screenshot.
It looks pretty good, nice to see that you even used the same colors
and shapes as the diagrams in the SCA spec :)
:)
Currently, we are following the procedure to
submit this graphical designer as an IP Zilla bug. If everyone is ok,
this will be the initial contribution of the SCA Designer project.
This work is part of the SCOrWare project (which is supported by the
French National Research Agency and OW2) that has two main goals:
- to develop a component-based implementation of the SCA specification
and
- to develop high-level tools to facilitate end users to adopt this
technology.
In this project, Obeo is leading the work concerning tools and
contributions for Eclipse. We are working on several tools: designers,
STP extensions, code generation, etc... We can discuss on them later.
Has anybody tried to run SCA assemblies produced by your editor using
the Tuscany runtime? Any issues?
Not yet. We must test it as soon as possible.
