[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Hi,
Comments inline.
Vatkov, Bogdan wrote:
Hi Jean-Sebastien,
It is not that I want to start a fight on EMF vs. non-EMF ;)
Me neither :) I was a tooling developer in a past life and I'm actually
a fan of EMF. I just like to use it for what it's good at.
but I am curious why are you not using EMF based model for reading SCDL (SCA) artifacts?
EMF could be easily used in headless mode - its needs several small jars and then you get tons of benefits.
It depends on what you mean by small :)
Tuscany is a light-weight SCA runtime.
Tuscany base assembly models incl XML handling = 150k
The whole Tuscany core runtime = approx 1Mb
Woodstox (replaceable as we only use the standard StAX API) = 500 k
EMF alone: ecore + common + change = approx 1Mb, bigger than the Tuscany
runtime.
We are actually using EMF in a different Tuscany subproject - Tuscany /
SDO - as our current SDO implementation is built on top of EMF (an SDO
DataObjectImpl is an EMF EObject).
I suggest you are first of all reading models and not manipulating them - so you won't make use of the powerful EMF features like Transactioning, OCL, but you could still use some very useful functions (except parsing the SCDL artifact) like Validations and Query.
What are you using for instantiating of SCA interfaces out of the SCDL resource, what parser are you using in the Tuscany?
The Tuscany SCA models are plain Java classes and interfaces, with no
dependency on any tooling or runtime framework.
For XML processing Tuscany uses StAX / Woodstox + handwritten logic to
read / write the XML elements.
About your question for implementing Tuscany SCA model interfaces by the tool side -
I would support sharing of meta-models/APIs and in general thighter cooperation with other projects like Tuscany or Fabric3 and I would like to know a little bit more about the scenarios where you use SCDL artifacts.
Here are some Tuscany model usage scenarios:
- Deployment tools and code generators read SCA XML assemblies to
determine what to deploy and generate.
- The runtime reads an SCA assembly XML files into a logical model in
memory, then works off the model directly.
- An administrative service allows an assembler / administrator to edit
his SCA domain, deploy, rewire, reconfigure etc.
- In a distributed service network, runtime nodes communicate
information on their composites, components, bindings, basically some
representation of these models.
- At deployment, runtime time, admin time, SCA assemblies are validated,
meaningful error messages are produced, and relate to the SCA
development artifacts.
Is it that you just read those? I some design-time tool could provide you an instance of your SCA model interfaces what would be the benefit? Do you think of something like restartless redeploy? Or something like post-deploy modifications of the SCA model? (e.g. changing a reference of a component to point to a different service)
Do you think of a scenario where the SCA editor could be used not only as design-time tool but also as runtime (re)configuration tool?
I can imagine a number of scenarios where tooling / runtime model
integration could be useful:
- Run a composite directly from an editor
- A debugger or component mock test tool
- Point an SCA editor to a running SCA domain and reconfigure / rewire
its components.
So it would be nice to have:
- POJO models for runtimes
- EMF models for tools
- common (or a common subset of) logical model interfaces.
More generally, IMO using common models in tooling and runtime gives the
application developer a more consistent story over the usual design /
code / build / deploy / run / fail / test / debug / back to design... as
it places all tooling and runtime parties on common ground, terminology,
feedback, error messages etc. I think that's important to provide a good
application development experience, but that's just my opinion...
Best regards,
Bogdan
-----Original Message-----
From: stp-dev-bounces@xxxxxxxxxxx [mailto:stp-dev-bounces@xxxxxxxxxxx] On Behalf Of Jean-Sebastien Delfino
Sent: Wednesday, June 27, 2007 6:27 PM
To: STP Dev list
Subject: Re: [stp-dev] SCA v1.0
Hi,
Nice tool! I work on the Apache Tuscany/SCA project and have a few
comments and questions inline.
Stéphane DRAPEAU wrote:
Hi Bogdan, all,
At Obeo we are also very interested in the graphical designer for SCA.
Actually, we have a first prototype that allows to define an assembly
(attached there is a screenshot of the prototype).
To develop this graphical designer, we started from scheme available
in the OSOA web site (http://www.osoa.org/xmlns/sca/1.0/
<http://www.osoa.org/xmlns/sca/1.0/>). In the following I'll give you
some details of the way we are working.
- As a first step we revised the OSOA scheme to reflect properly the
SCA Assembly Model Specification and to enable the validation of the
XSD model. We corrected also some structural problems. This work was
done with the INRIA laboratory (ADAM team).
- As a second step, we generated the ecore models and made some
modifications. For example, in the Wire EClass, we define source and
target as EReference (in the initial model, target and source are
EAttribute).
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?
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?
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.
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?
Would these rules be usable outside of an EMF-enabled environment, as
long as the model they validate implement the expected logical model
interfaces?
- 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?
It will be great if we can work together in the graphical designer.
Franco Scavuzzo told me that he is interested in working with us.
To continue with this work, we are interested in creating a new STP
subproject (as an incubation project if necessary). We are ok to lead it.
Who is interested in this work? What do you think about all this?
Best regards
Stéphane Drapeau
Obeo
Vatkov, Bogdan a écrit :
Hi Adrian,
I saw you have been assigned to the issue
https://bugs.eclipse.org/bugs/show_bug.cgi?id=181693.
Do you have any progress on that? Is it possible for me to help you
with this issue?
Actually I have the SCA v1.0 metamodel already imported (from XSD) as
EMF model and I am using it locally for our SCA design-time
implementation.
Do you think it is meaningful to send you what I have for the sca1.0
emf based meta-model?
This particular problem is the key point for us to start extending
the STP framework. Currently we do not extend (or even re-use on API
basis) any STP part but we would like to do so.
(Un)fortunatelly we needed SCA v1.0 for our SCA design-time support
for the SCA runtime that we are implementing and I had to create the
sca 1.0 metamodel.
Now I would like to have it inside STP and actually start using the
entire platform, extend extension points, propose new extension
points etc.
Best regards,
Bogdan
------------------------------------------------------------------------
--
Jean-Sebastien
