RE: [dsdp-mtj-dev] MTJ Model

[Kevin M Horowitz <khorowit@xxxxxxxxxx>]

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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature