[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dsdp-mtj-dev] MTJ Model
|
My two cents on the whole issue of the underlying model...
There are really two models with some amount of overlap between them.
There is the object model (Java) and the data model (EMF based in this
case). My understanding of the current MTJ implementation is that the
overlap between those two models is a very large percentage. Is this a
true statement?
Another alternative is to use the data model for a more limited subset
of functionality, primarily focusing on an Java based object model with
the ability to use an EMF data model for persistence when the Java
object chooses. To make this more clear, doing things this way makes
the model a potential for storage rather than a requirement for extension.
In my mind, I'd like to see the MTJ extension point implementations
defined purely by Java interfaces and PDE extension point definitions.
It should not be a requirement for an extension to implement or extend
the model in order to function in this environment. It should, however,
be possible for the extension implementation to take advantage of an EMF
model for persistence if they choose to do so. This seems to me to be
the best of both worlds.
Thanks,
Craig
Arto.Laurila@xxxxxxxxx wrote:
Hi,
The current MTJ services are using an EMF based model, that is
initially created with any EMF compatible tool.
The tools that Kevin is referring here and what e.g. I have used is
the a bit older Rational Rose tool to create the UML model.
I think that even some very old version of Rose can be used with this.
Thus the same model can be done with other tools, like IBM Rational
Architect or Modeler or what ever (or even directly with the EMF).
When thinking the current MTJ architecture, there is certainly needed
to discuss that does team members have experience on EMF or not.
In case of that would be replaced, it pretty much means that the whole
MTJ internal architecture have to be recoded also.
As comparing to other Eclipse based projects, some of those are not
using EMF at all and they do model their data model e.g. with plain java.
As it is e.g. with EclipseME (Craig, correct me if I'm wrong).
Why the EMF has been used here, well that enables to have a Eclipse
compatible and working data layer, where the initial design is done
with UML and the the MTJ related EMF layer is generated from the UML
file. That saves a lot of coding & testing time.
In my part I have to say that if the EMF layer is dropped, I may have
problems to participate to create the same functionality again from Nokia
point of view.
-Arto
