[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [dsdp-mtj-dev] MTJ Model

Hi,
 
As regarding to the EMF model editing, there is a related document, which is a bit outdated but still showing the idea:
http://www.telecom-lille1.eu/people/Vanwormhoudt/siteEMFOCL/tutoriel/TutorialEMFOCL1.htm
 
A good article about the EMF base functions can be found from http://www.eclipse.org/articles/Article-Using%20EMF/using-emf.html
 
Also EMF help can be found from http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.emf.doc/references/overview/EMF.Edit.html
 
You can also edit directly the EMF ecore model by downloading the EMF SDK into your Eclipse and then editing it with the EMF editor.
 
 
 
As you see, the datamodel (aka MTJ objects) is presented though the EMF.
The object model definition is visible there and with help with the EMF code generation, you can create the data model java classes directly.
Then you can use the EMF persisting services or use the data integrity services (aka enable to propagate the changes to relevant  listeners).
 
If you do not like to use the EMF, then the work is to remove it and code the similar object services again.
 
-Arto
 


From: dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of ext Kevin M Horowitz
Sent: 15 November, 2007 15:43
To: Mobile Tools for The Java Platform mailing list
Subject: RE: [dsdp-mtj-dev] MTJ Model


Craig,

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.

kevin
--
Kevin Horowitz
khorowit@xxxxxxxxxx
Expeditor Tools Development
Workplace Portal and Collaboration Software
IBM - Boca Raton, +1-561-862-2113



From: <Arto.Laurila@xxxxxxxxx>
To: <dsdp-mtj-dev@xxxxxxxxxxx>
Date: 11/15/2007 02:12 AM
Subject: RE: [dsdp-mtj-dev] MTJ Model





Craig,

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 wrapper.

When tinking that what the EMF provides, it is the persistence and
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.

So, when analyzing the MTJ Object structure and API, the base model
can be seen from the UML model and the API is visible through the
extension point API.

-Arto

>-----Original Message-----
>From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
>[
mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of ext Craig Setera
>Sent: 15 November, 2007 04:24
>To: Mobile Tools for The Java Platform mailing list
>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.  
>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
>>
>_______________________________________________
>dsdp-mtj-dev mailing list
>dsdp-mtj-dev@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
>
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev