Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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
>


Back to the top