[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [dsdp-mtj-dev] MTJ Model
- From: <Arto.Laurila@xxxxxxxxx>
- Date: Fri, 16 Nov 2007 12:33:52 +0200
- Delivered-to: email@example.com
- Thread-index: AcgnjWd5OJ0ESDQLRV61asgqcxVZdAAkNaIg
- Thread-topic: [dsdp-mtj-dev] MTJ Model
As regarding to the EMF model editing, there is a related
document, which is a bit outdated but still showing the
You can also edit directly the EMF ecore model by
downloading the EMF SDK into your Eclipse and then editing it with the EMF
see, the datamodel (aka MTJ objects) is presented though the
object model definition is visible there and with help with the EMF code
generation, you can create the data model java
you can use the EMF persisting services or use the data integrity services
(aka enable to propagate the changes to
do not like to use the EMF, then the work is to remove it and code
the similar object services again.
I think that you are right that there is
the persistence model, and then the java objects that we convert them into to
use within the code. However, this division is fuzzy in some places of
the code, and the java representation is not shared across some of our service
components. So, we represent the device during SDK definition using one
java object representation, and then retrieve it for compilation/library use
using a different object representation to match the IDE requirements.
One of the things that we did during
creation was to not provide utility access to the EMF calls to store and
retrieve data across different implementations within the same service.
This meant that we duplicated the java object model representations as
we wrote code, while never formalizing them as a model representation.
There was an initial decision to do it this way so that the user was
exposed to the model. I think, in retrospect, that this was wrong, and
introduced to much complexity to the platform extender. In writing the
generic SDK provider, I hid all of the EMF calls in the implementation, and
wrote it to serve as a reference that could be extended without needing to
understand the calls in the future. If we stay with the EMF model, we
need to work to bury the EMF calls in a similar manner, and use the java
object representation within the code. Over time, that would allow us to
change the persistence model if desired.
Expeditor Tools Development
Portal and Collaboration Software
IBM - Boca Raton,
||11/15/2007 02:12 AM
||RE: [dsdp-mtj-dev] MTJ
I would disagree that there are two
models, as the EMF based model
publishes the objects that the UI is using.
"EMF itself is not a object model, merely it's provides add-on
services to the object model".
If you go and take a look to the UML
model, it describes the MTJ
Object structure and then the EMF publishes it
into a Object model.
When taking any those objects in detail analysis, you
see that the
object is a typical java object, which has a EMF
When tinking that what the EMF provides, it is the persistence
integrity services. So, if you take the EMF out, you would have to
code those by your self.
There is a manually written API layer on
top of the Object model,
that is used to access the Objects.
when analyzing the MTJ Object structure and API, the base model
seen from the UML model and the API is visible through the
>[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of ext Craig Setera
>Sent: 15 November, 2007
>To: Mobile Tools for The Java Platform mailing
>Subject: 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.
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
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
>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
>> 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
>> 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
>> to discuss that does team members have
experience on EMF or not.
>> In case of that would be replaced, it
pretty much means that
>> MTJ internal
architecture have to be recoded also.
comparing to other Eclipse based projects, some of those are not
using EMF at all and they do model their data model e.g.
>> As it is e.g. with EclipseME (Craig, correct me if I'm
>> 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
to participate to create the same functionality again from
point of view.