Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [Net4J] Bluetooth and/or comm port connectivity
| [Net4J] Bluetooth and/or comm port connectivity [message #104437] |
Mon, 10 December 2007 21:21  |
Eclipse User |
|
|
|
Originally posted by: jconlon.apache.org
Hi,
Is there any current technical documentation on the Net4J effort that I
can refer to, so I may to come up to speed on it's technical use-cases,
architecture, features and benefits?
I am trying to update my EMF model based on data received from remote
sensors attached via Bluetooth. While it maybe nice to deal with
Bluetooth I think a connectivity solution to comm ports maybe all I
need. Can Net4J establish connectivity to a comm port?
thanks for any help,
John Conlon
Verticon, Inc.
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #104506 is a reply to message #104437] |
Wed, 12 December 2007 12:32  |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Hi John,
Comments below...
John E. Conlon schrieb:
> Hi,
>
> Is there any current technical documentation on the Net4J effort that
> I can refer to, so I may to come up to speed on it's technical
> use-cases, architecture, features and benefits?
I'm currently working on the documentation of CDO and Net4j. Since I
started top-down I haven't arrived at the Net4j parts. Although the CDO
docs are not fully complete I could start with some high-level Net4j
docs to aid your evaluations. Have you already had a look at the
sources. They are clearly structured so that you should be able to
rather easily get an overview. Could you describe in a bit more detail
which kind of information would be helpful for your matter?
> I am trying to update my EMF model based on data received from remote
> sensors attached via Bluetooth.
Have you had a look at the CDO project as well? It integrates your EMF
model with the Net4j communications platform on client and on server
side (repository). So if we manage to create a Net4j connector for comm
ports (see below) you might already have a complete solution for your
problem.
> While it maybe nice to deal with Bluetooth I think a connectivity
> solution to comm ports maybe all I need. Can Net4J establish
> connectivity to a comm port?
For each kind of transport you'll need an implementation of IConnector
http://download.eclipse.org/modeling/emft/net4j/javadoc/0.8. 0/org/eclipse/net4j/IConnector.html
.. Net4j does currently not come with a connector implementation that
uses comm ports. Only (NIO) sockets (tcp) and in process transport (jvm)
are currently provided by me.
That said, a connector implementation for comm ports should be easy, as
easy as the usage of comm ports is in Java (which I have no idea of). As
the docs of IConnector state you'll have to subclass Connector (
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j/src/org/eclipse /internal/net4j/Connector.java?root=Modeling_Project&vie w=log)
.. I suggest to look at the implementation of TCPConnector (
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j.tcp/src/org/ecl ipse/net4j/internal/tcp/TCPConnector.java?root=Modeling_Proj ect&view=log
).
As I said above, if you succeed in providing a comm port implementation
of IConnector (and the supporting factories) you'll get EMF integration
for free ;-)
Regards,
Eike Stepper
----
http://wiki.eclipse.org/?title=CDO
http://wiki.eclipse.org/?title=Net4j
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #104531 is a reply to message #104506] |
Wed, 12 December 2007 18:37 |
| Eclipse User |
|
|
|
Originally posted by: jconlon.apache.org
Hi Eike,
Eike Stepper wrote:
> Hi John,
>
> Comments below...
>
>
>
> John E. Conlon schrieb:
>> Hi,
>>
>> Is there any current technical documentation on the Net4J effort that
>> I can refer to, so I may to come up to speed on it's technical
>> use-cases, architecture, features and benefits?
> I'm currently working on the documentation of CDO and Net4j. Since I
> started top-down I haven't arrived at the Net4j parts. Although the CDO
> docs are not fully complete I could start with some high-level Net4j
> docs to aid your evaluations. Have you already had a look at the
> sources.
No I haven't looked at the sources to date, but I have seen what appears
to be documentation but maybe out of date at www.sympedia.org. Are these
documents the ones you are updating?
They are clearly structured so that you should be able to
> rather easily get an overview. Could you describe in a bit more detail
> which kind of information would be helpful for your matter?
At this point I an just surveying the available options for how I can
add sensor data to my EMF models, and eventually
offer EMF model to EMF model synchronization across distributed
systems.
In other words, my goal is to ascertain the direction the overall
Eclipse Modeling 'movement' will be taking for these two ways of
integrating and synchronizing data. Will it be CDO/Net4j or another
technology like STP?
Have some familiarity with NIO and have done some minor contributions to
the Apache Mina project. How does Net4j compare to Mina?
>> I am trying to update my EMF model based on data received from remote
>> sensors attached via Bluetooth.
> Have you had a look at the CDO project as well? It integrates your EMF
> model with the Net4j communications platform on client and on server
> side (repository). So if we manage to create a Net4j connector for comm
> ports (see below) you might already have a complete solution for your
> problem.
Yes I have seen the Sympedia CDO documentation and it looks very
interesting.
How does CDO compare to Teneo?
Does CDO use the EMF transaction framework?
Can I use CDO to synchronize two EMF resources in a peer to peer fashion
for example two instances of a model that are persisted as two XMI
documents running in two different computers?
>
>> While it maybe nice to deal with Bluetooth I think a connectivity
>> solution to comm ports maybe all I need. Can Net4J establish
>> connectivity to a comm port?
> For each kind of transport you'll need an implementation of IConnector
> http://download.eclipse.org/modeling/emft/net4j/javadoc/0.8. 0/org/eclipse/net4j/IConnector.html
Nice javadoc!
> . Net4j does currently not come with a connector implementation that
> uses comm ports. Only (NIO) sockets (tcp) and in process transport (jvm)
> are currently provided by me.
This was done at the Mina project so I expect it could be done with
Net4J as well.
> That said, a connector implementation for comm ports should be easy, as
> easy as the usage of comm ports is in Java (which I have no idea of).
I have not done this myself, so I don't know how easy the lower layer
will be. Would probably do the http://www.rxtx.org/ versus Sun's impl.
As
> the docs of IConnector state you'll have to subclass Connector (
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j/src/org/eclipse /internal/net4j/Connector.java?root=Modeling_Project&vie w=log)
> . I suggest to look at the implementation of TCPConnector (
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j.tcp/src/org/ecl ipse/net4j/internal/tcp/TCPConnector.java?root=Modeling_Proj ect&view=log
> ).
>
> As I said above, if you succeed in providing a comm port implementation
> of IConnector (and the supporting factories) you'll get EMF integration
> for free ;-)
Sounds good, but will I need to also install a database to get EMF
integration?
kind regards,
John
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #104545 is a reply to message #104531] |
Thu, 13 December 2007 05:45 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
John E. Conlon schrieb:
> Hi Eike,
>
> Eike Stepper wrote:
>> Hi John,
>>
>> Comments below...
>>
>>
>>
>> John E. Conlon schrieb:
>>> Hi,
>>>
>>> Is there any current technical documentation on the Net4J effort
>>> that I can refer to, so I may to come up to speed on it's technical
>>> use-cases, architecture, features and benefits?
>> I'm currently working on the documentation of CDO and Net4j. Since I
>> started top-down I haven't arrived at the Net4j parts. Although the
>> CDO docs are not fully complete I could start with some high-level
>> Net4j docs to aid your evaluations. Have you already had a look at
>> the sources.
> No I haven't looked at the sources to date, but I have seen what
> appears to be documentation but maybe out of date at www.sympedia.org.
> Are these documents the ones you are updating?
No, the docs are at http://wiki.eclipse.org/?title=CDO and will be at
http://wiki.eclipse.org/?title=Net4j .
The overall design (connectors, acceptors, selectors and channels)
described at sympedia.org is still valid for Net4j but the architecture
(no Spring at the moment) and the implementation (more asynchronous,
faster, more reliable) changed completely.
I'll have to remove the old docs from sympedia.org and add links to
wiki.eclipse.org...
> They are clearly structured so that you should be able to
>> rather easily get an overview. Could you describe in a bit more
>> detail which kind of information would be helpful for your matter?
>
> At this point I an just surveying the available options for how I can
> add sensor data to my EMF models, and eventually
> offer EMF model to EMF model synchronization across distributed
> systems.
>
> In other words, my goal is to ascertain the direction the overall
> Eclipse Modeling 'movement' will be taking for these two ways of
> integrating and synchronizing data. Will it be CDO/Net4j or another
> technology like STP?
>
> Have some familiarity with NIO and have done some minor contributions
> to the Apache Mina project. How does Net4j compare to Mina?
I haven't heard of Mina before but I just browsed a bit through the
presentation material. It looks as if Mina has doubled some of the
efforts I released with Net4j v1.0 in year 2003 ;-)
Net4j has always had an additional concept of channels which are
multiplexed through connections. In other words the application protocol
logic in Net4j is always capable of sharing a single connection with
other instances of the same or other protocols. And Net4j has an
optional layer on top of the buffered, non-blocking transport layer that
provides for stream-based request/response signals and work threading
strategies. May be Mina provides for something similar, you seem to be
the expert ;-)
>> Have you had a look at the CDO project as well? It integrates your
>> EMF model with the Net4j communications platform on client and on
>> server side (repository). So if we manage to create a Net4j connector
>> for comm ports (see below) you might already have a complete solution
>> for your problem.
> I am trying to update my EMF model based on data received from remote
> sensors attached via Bluetooth.
> Yes I have seen the Sympedia CDO documentation and it looks very
> interesting.
The docs at http://wiki.eclipse.org/?title=CDO are better for the
Eclipse.org hosted version of CDO (the only one maintained).
> How does CDO compare to Teneo?
I'd say the main difference is the deployment strategy. While Teneo (I'm
not a Teneo expert!) is mainly used on the client side (with
hibernate/jpox generated JDBC on the wire) CDO is is used on the client
side for EMF model integration and on the server side for the storage
integration (O/R mapping, OODB integration). CDO uses an own (Net4j
based) wire protocol which is tailored to transactional semantics in the
context of objects (not SQL). Since CDO clients rely on a dedicated CDO
server they can offer some additional functions not available with
Teneo, like automatic model update on all clients if one client commits
a transaction (distributed shared model semantics).
>
> Does CDO use the EMF transaction framework?
No, CDO acts directly on the model level. EMF Transaction acts on the
higher edit/command framework level which, in my opinion, has at least
two disadvantages:
1) Not all clients want to use a command stack to interact with models
(especially non-UI clients like batch clients). With CDO these clients
can remain unchanged (are not forced to use a command stack) and since
CDO transactions are transparent to the command stack UI clients can be
used, too.
2) Worse, command stack based transactions rely on the cooperation of
*all* clients of a model. If only one client doesn't use a command stack
or uses a non-transactional command stack all transactions might become
corrupt! Since CDO integrates with EMF models at their core none of
these restrictions apply.
>
> Can I use CDO to synchronize two EMF resources in a peer to peer
> fashion for example two instances of a model that are persisted as two
> XMI documents running in two different computers?
>>
>>> While it maybe nice to deal with Bluetooth I think a connectivity
>>> solution to comm ports maybe all I need. Can Net4J establish
>>> connectivity to a comm port?
>> For each kind of transport you'll need an implementation of
>> IConnector
>> http://download.eclipse.org/modeling/emft/net4j/javadoc/0.8. 0/org/eclipse/net4j/IConnector.html
>
> Nice javadoc!
>
>> . Net4j does currently not come with a connector implementation that
>> uses comm ports. Only (NIO) sockets (tcp) and in process transport
>> (jvm) are currently provided by me.
>
> This was done at the Mina project so I expect it could be done with
> Net4J as well.
Good point! Would you be willing to contribute such a connector? If so,
please open an enhancement request in Bugzilla and attach a patch (since
Net4j is already extensible in the dimension of transports a patch might
not be needed and you can simply attach the extension bundle project).
I'd be happy to maintain the code after ;-)
> That said, a connector implementation for comm ports should be easy,
> as easy as the usage of comm ports is in Java (which I have no idea of).
> I have not done this myself, so I don't know how easy the lower layer
> will be. Would probably do the http://www.rxtx.org/ versus Sun's impl.
>
> As
>> the docs of IConnector state you'll have to subclass Connector (
>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j/src/org/eclipse /internal/net4j/Connector.java?root=Modeling_Project&vie w=log)
>> . I suggest to look at the implementation of TCPConnector (
>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j.tcp/src/org/ecl ipse/net4j/internal/tcp/TCPConnector.java?root=Modeling_Proj ect&view=log
>> ).
>>
>> As I said above, if you succeed in providing a comm port
>> implementation of IConnector (and the supporting factories) you'll
>> get EMF integration for free ;-)
>
> Sounds good, but will I need to also install a database to get EMF
> integration?
Good question! According to the 'normal' setup of a CDO deployment, yes.
But CDO should be open and layered enuogh to find a solution that uses
only the model integration parts. I haven't thought about such usage so far.
Regards,
Eike Stepper
----
http://wiki.eclipse.org/?title=CDO
http://wiki.eclipse.org/?title=Net4j
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #104761 is a reply to message #104545] |
Sun, 16 December 2007 17:25 |
| Eclipse User |
|
|
|
Originally posted by: jconlon.apache.org
Eike Stepper wrote:
> John E. Conlon schrieb:
>> Hi Eike,
>>
>> Eike Stepper wrote:
>>> Hi John,
>>>
>>> Comments below...
>>>
>>>
>>>
>>> John E. Conlon schrieb:
>>>> Hi,
>>>>
>>>> Is there any current technical documentation on the Net4J effort
>>>> that I can refer to, so I may to come up to speed on it's technical
>>>> use-cases, architecture, features and benefits?
>>> I'm currently working on the documentation of CDO and Net4j. Since I
>>> started top-down I haven't arrived at the Net4j parts. Although the
>>> CDO docs are not fully complete I could start with some high-level
>>> Net4j docs to aid your evaluations. Have you already had a look at
>>> the sources.
>> No I haven't looked at the sources to date, but I have seen what
>> appears to be documentation but maybe out of date at www.sympedia.org.
>> Are these documents the ones you are updating?
> No, the docs are at http://wiki.eclipse.org/?title=CDO and will be at
> http://wiki.eclipse.org/?title=Net4j
Ah! Looks comprehensive. Will start digging in next week.
> The overall design (connectors, acceptors, selectors and channels)
> described at sympedia.org is still valid for Net4j but the architecture
> (no Spring at the moment) and the implementation (more asynchronous,
> faster, more reliable) changed completely.
> I'll have to remove the old docs from sympedia.org and add links to
> wiki.eclipse.org...
Look forward to seeing docs for Net4J.
>
>> They are clearly structured so that you should be able to
>>> rather easily get an overview. Could you describe in a bit more
>>> detail which kind of information would be helpful for your matter?
>>
>> At this point I an just surveying the available options for how I can
>> add sensor data to my EMF models, and eventually
>> offer EMF model to EMF model synchronization across distributed
>> systems.
>>
>> In other words, my goal is to ascertain the direction the overall
>> Eclipse Modeling 'movement' will be taking for these two ways of
>> integrating and synchronizing data. Will it be CDO/Net4j or another
>> technology like STP?
>>
>> Have some familiarity with NIO and have done some minor contributions
>> to the Apache Mina project. How does Net4j compare to Mina?
> I haven't heard of Mina before but I just browsed a bit through the
> presentation material. It looks as if Mina has doubled some of the
> efforts I released with Net4j v1.0 in year 2003 ;-)
Common problems often manifest duplicate effort.
> Net4j has always had an additional concept of channels which are
> multiplexed through connections. In other words the application protocol
> logic in Net4j is always capable of sharing a single connection with
> other instances of the same or other protocols. And Net4j has an
> optional layer on top of the buffered, non-blocking transport layer that
> provides for stream-based request/response signals and work threading
> strategies. May be Mina provides for something similar, you seem to be
> the expert ;-)
No, I am not a Mina expert, only a user who wanted to help OSGi
'bundlize' the Mina and it's original parent Apache Directory Server. I
helped in this regard, but not at the core development of either
efforts. (They were the mechanics, I merely attached the license plates.)
>
>>> Have you had a look at the CDO project as well? It integrates your
>>> EMF model with the Net4j communications platform on client and on
>>> server side (repository). So if we manage to create a Net4j connector
>>> for comm ports (see below) you might already have a complete solution
>>> for your problem.
>> I am trying to update my EMF model based on data received from remote
>> sensors attached via Bluetooth. Yes I have seen the Sympedia CDO
>> documentation and it looks very interesting.
> The docs at http://wiki.eclipse.org/?title=CDO are better for the
> Eclipse.org hosted version of CDO (the only one maintained).
>
>> How does CDO compare to Teneo?
> I'd say the main difference is the deployment strategy. While Teneo (I'm
> not a Teneo expert!) is mainly used on the client side (with
> hibernate/jpox generated JDBC on the wire) CDO is is used on the client
> side for EMF model integration and on the server side for the storage
> integration (O/R mapping, OODB integration). CDO uses an own (Net4j
> based) wire protocol which is tailored to transactional semantics in the
> context of objects (not SQL). Since CDO clients rely on a dedicated CDO
> server they can offer some additional functions not available with
> Teneo, like automatic model update on all clients if one client commits
> a transaction (distributed shared model semantics).
So Teneo is more of a client side persistence alternative and CDO is a
model repository server!
Is CDO the only Eclipse Modeling project making this claim?
Side question:
Since models are persisted to a repository server (a rdbms) has anyone
experimented with plugging in BIRT to this rdbms so end user's could be
given reporting support? In other words are the final relational
schemas human readable and understandable enough for report designers to
work with?
>>
>> Does CDO use the EMF transaction framework?
> No, CDO acts directly on the model level. EMF Transaction acts on the
> higher edit/command framework level which, in my opinion, has at least
> two disadvantages:
> 1) Not all clients want to use a command stack to interact with models
> (especially non-UI clients like batch clients). With CDO these clients
> can remain unchanged (are not forced to use a command stack) and since
> CDO transactions are transparent to the command stack UI clients can be
> used, too.
> 2) Worse, command stack based transactions rely on the cooperation of
> *all* clients of a model. If only one client doesn't use a command stack
> or uses a non-transactional command stack all transactions might become
> corrupt! Since CDO integrates with EMF models at their core none of
> these restrictions apply.
>
When you say CDO works at the model level, does that mean entire models
are moved from client to server? Is there facilities for plugging in
Model to Model translation facilities so that one could sync
heterogeneous models to one repository? My mind has not been expanded
as of yet to all the possibilities with CDO, but I am wondering if CDO
may be able to offer an infrastructure for models what XProc
http://www.w3.org/TR/2007/WD-xproc-20071129/
is offering for XML docs?
>>
>> Can I use CDO to synchronize two EMF resources in a peer to peer
>> fashion for example two instances of a model that are persisted as two
>> XMI documents running in two different computers?
>>>
>>>> While it maybe nice to deal with Bluetooth I think a connectivity
>>>> solution to comm ports maybe all I need. Can Net4J establish
>>>> connectivity to a comm port?
>>> For each kind of transport you'll need an implementation of
>>> IConnector
>>> http://download.eclipse.org/modeling/emft/net4j/javadoc/0.8. 0/org/eclipse/net4j/IConnector.html
>>
>>
>> Nice javadoc!
>>
>>> . Net4j does currently not come with a connector implementation that
>>> uses comm ports. Only (NIO) sockets (tcp) and in process transport
>>> (jvm) are currently provided by me.
>>
>> This was done at the Mina project so I expect it could be done with
>> Net4J as well.
> Good point! Would you be willing to contribute such a connector? If so,
> please open an enhancement request in Bugzilla and attach a patch (since
> Net4j is already extensible in the dimension of transports a patch might
> not be needed and you can simply attach the extension bundle project).
> I'd be happy to maintain the code after ;-)
Have several activities scheduled right now, but I am interested enough
to contribute with either a comm port transport or a Bluetooth one. The
problem I for see with either one of these solutions is that I expect
there will be OS library dependencies that will have to be bundled with
the code. This is something I have not done before.
Will start looking into this next month.
>
>> That said, a connector implementation for comm ports should be easy,
>> as easy as the usage of comm ports is in Java (which I have no idea of).
>> I have not done this myself, so I don't know how easy the lower layer
>> will be. Would probably do the http://www.rxtx.org/ versus Sun's impl.
>>
>> As
>>> the docs of IConnector state you'll have to subclass Connector (
>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j/src/org/eclipse /internal/net4j/Connector.java?root=Modeling_Project&vie w=log)
>>> . I suggest to look at the implementation of TCPConnector (
>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j.tcp/src/org/ecl ipse/net4j/internal/tcp/TCPConnector.java?root=Modeling_Proj ect&view=log
>>> ).
>>>
>>> As I said above, if you succeed in providing a comm port
>>> implementation of IConnector (and the supporting factories) you'll
>>> get EMF integration for free ;-)
>>
>> Sounds good, but will I need to also install a database to get EMF
>> integration?
> Good question! According to the 'normal' setup of a CDO deployment, yes.
> But CDO should be open and layered enuogh to find a solution that uses
> only the model integration parts. I haven't thought about such usage so
> far.
kind regards,
John Conlon
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #104775 is a reply to message #104761] |
Mon, 17 December 2007 03:35 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
John E. Conlon schrieb:
>> [stuff deleted]
>>> How does CDO compare to Teneo?
>> I'd say the main difference is the deployment strategy. While Teneo
>> (I'm not a Teneo expert!) is mainly used on the client side (with
>> hibernate/jpox generated JDBC on the wire) CDO is is used on the
>> client side for EMF model integration and on the server side for the
>> storage integration (O/R mapping, OODB integration). CDO uses an own
>> (Net4j based) wire protocol which is tailored to transactional
>> semantics in the context of objects (not SQL). Since CDO clients rely
>> on a dedicated CDO server they can offer some additional functions
>> not available with Teneo, like automatic model update on all clients
>> if one client commits a transaction (distributed shared model
>> semantics).
>
> So Teneo is more of a client side persistence alternative and CDO is a
> model repository server!
Right.
> Is CDO the only Eclipse Modeling project making this claim?
AFAIK, yes.
> Side question:
> Since models are persisted to a repository server (a rdbms) has anyone
> experimented with plugging in BIRT to this rdbms so end user's could
> be given reporting support? In other words are the final relational
> schemas human readable and understandable enough for report designers
> to work with?
Interesting question because I just discussed that topic with a friend
of mine. I cc'ed Philipp for this purpose.
1) A CDO server mainly consists of three parts/layers: A protocol peer
(Net4j based), a model repository framework (storage agnostic) and a
storage framework. It depends on the storage implementation (IStore) how
the model data is actually persisted to a storage backend. This *can* be
an RDBMS via plain JDBC (default) but a user has also implemented an
Objectivity store (OODBMS) and plans to implement a Hibernate based store.
2) In case the default JDBC store is used with a repository I'd say yes,
the generated schema is human readable and understandable enough for
report designers to work with but that is my own opinion. Currently CDO
always uses its own generated primary keys (long id values) and
references are mostly always stored in a fixed format that allows for
transparent versioning.
3) I'd prefer to see a model/BIRT integration at the model side (CDO
client) rather than at the DB side (one of several possible CDO storage
backends and highly implementation dependent). I'm neither a BIRT nor an
ODA expert but is it not possible to use an EMF ResourceSet, a Resource
or an EObject as an ODA data source? That'd be much closer to the
semantics of the model than querying the mapped DB.
>>> Does CDO use the EMF transaction framework?
>> No, CDO acts directly on the model level. EMF Transaction acts on the
>> higher edit/command framework level which, in my opinion, has at
>> least two disadvantages:
>> 1) Not all clients want to use a command stack to interact with
>> models (especially non-UI clients like batch clients). With CDO these
>> clients can remain unchanged (are not forced to use a command stack)
>> and since CDO transactions are transparent to the command stack UI
>> clients can be used, too.
>> 2) Worse, command stack based transactions rely on the cooperation of
>> *all* clients of a model. If only one client doesn't use a command
>> stack or uses a non-transactional command stack all transactions
>> might become corrupt! Since CDO integrates with EMF models at their
>> core none of these restrictions apply.
>>
>
>
> When you say CDO works at the model level, does that mean entire
> models are moved from client to server?
I'm not sure if I correctly understand the intend of your question. The
scope of a CDO transaction is always an EMF ResourceSet (no command
stack needed). This ResourceSet can contain multiple CDO Resources (and
possibly other types of Resources). At the time of committing the
transaction no CDO Resource is allowed to contain references to non-CDO
Resources. In other words a CDO repository is always guaranteed to
contain a consistent state of an object graph that can be partitioned
into CDO Resources. Looking from the other side a CDO-prepared
ResourceSet acts like a partial but self-populating view onto the whole
object graph of the repository.
So in this sense, yes, entire models are (initially) moved from client
to server. Once a model is committed into the repository subsequent
reads and writes (commits) act at least at an object granularity. A
recent effort of a user added support for sending only deltas for
changed objects to the server, see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=201266 .
I guess I should stop saying "at the model level" because the word
"model" is one of the only four terms we have available in modern
software engineering, ambiguities granted ;-)
The reason I used it is the following. When you kick the EMF generator
for an ecore model it typically produces 3 plugins:
1) model plugin
2) edit plugin (command framework integration)
3) editor plugin (Eclipse UI)
When I say "at the model level" I really mean that only 1) is needed for
integration. AFAIK EMF Transaction needs 1) plus 2) for its integration
because it intercepts commands of the command framework.
> Is there facilities for plugging in Model to Model translation
> facilities so that one could sync heterogeneous models to one
> repository?
I'm lost. Could you please elaborate on "Model to Model translation
facilities" and "heterogeneous models"?
> My mind has not been expanded as of yet to all the possibilities with
> CDO, but I am wondering if CDO may be able to offer an infrastructure
> for models what XProc http://www.w3.org/TR/2007/WD-xproc-20071129/
> is offering for XML docs?
I'm really not familiar with XProc. The abstract says "[...] a language
for describing operations to be performed on XML documents". From this
I'd say, no, CDO focusses more on the static aspects of a model than on
the possible operations that could modeify a model over time. May be you
can list some specific details of the XProc spec (which I've not read as
a whole) that you're interested in?
>>> [stuff deleted]
>> Good point! Would you be willing to contribute such a connector? If
>> so, please open an enhancement request in Bugzilla and attach a patch
>> (since Net4j is already extensible in the dimension of transports a
>> patch might not be needed and you can simply attach the extension
>> bundle project). I'd be happy to maintain the code after ;-)
>
> Have several activities scheduled right now, but I am interested
> enough to contribute with either a comm port transport or a Bluetooth
> one. The problem I for see with either one of these solutions is that
> I expect there will be OS library dependencies that will have to be
> bundled with the code. This is something I have not done before.
OSGi should be prepared for this ;-)
>
> Will start looking into this next month.
That'd be great! Please tell me when you need my assistance...
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
>>> That said, a connector implementation for comm ports should be easy,
>>> as easy as the usage of comm ports is in Java (which I have no idea
>>> of).
>>> I have not done this myself, so I don't know how easy the lower
>>> layer will be. Would probably do the http://www.rxtx.org/ versus
>>> Sun's impl.
>>>
>>> As
>>>> the docs of IConnector state you'll have to subclass Connector (
>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j/src/org/eclipse /internal/net4j/Connector.java?root=Modeling_Project&vie w=log)
>>>> . I suggest to look at the implementation of TCPConnector (
>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j.tcp/src/org/ecl ipse/net4j/internal/tcp/TCPConnector.java?root=Modeling_Proj ect&view=log
>>>> ).
>>>>
>>>> As I said above, if you succeed in providing a comm port
>>>> implementation of IConnector (and the supporting factories) you'll
>>>> get EMF integration for free ;-)
>>>
>>> Sounds good, but will I need to also install a database to get EMF
>>> integration?
>> Good question! According to the 'normal' setup of a CDO deployment,
>> yes. But CDO should be open and layered enuogh to find a solution
>> that uses only the model integration parts. I haven't thought about
>> such usage so far.
>
>
> kind regards,
> John Conlon
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #104788 is a reply to message #104775] |
Mon, 17 December 2007 08:34 |
 Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Eike, John,
Just to add my thoughts about Teneo :-).
Teneo is very much focused on being a persistence solution for persisting (complex) models to a
relational store. This focus means that Teneo has broad support for most complex modeling constructs
(for example feature maps, xml schema anytype, mixed type, etc.) and support for jpa annotations in
the model. On the other hand this focus also means that Teneo does not include specific
client-server functionality, this is outside of the scope of Teneo.
So I would not say that Teneo is a client side solution (I use Teneo server side in a web app).
Teneo can also be used server side (in a rcp app) but then you need to implement your own
client-server layer (using other tools).
Btw, it would be interesting to integrate the client-server capabilities of CDO/net4j with the
mapping capabilities of Teneo. I think this can be a powerfull combination...
gr. Martin
Eike Stepper wrote:
> John E. Conlon schrieb:
>>> [stuff deleted]
>>>> How does CDO compare to Teneo?
>>> I'd say the main difference is the deployment strategy. While Teneo
>>> (I'm not a Teneo expert!) is mainly used on the client side (with
>>> hibernate/jpox generated JDBC on the wire) CDO is is used on the
>>> client side for EMF model integration and on the server side for the
>>> storage integration (O/R mapping, OODB integration). CDO uses an own
>>> (Net4j based) wire protocol which is tailored to transactional
>>> semantics in the context of objects (not SQL). Since CDO clients rely
>>> on a dedicated CDO server they can offer some additional functions
>>> not available with Teneo, like automatic model update on all clients
>>> if one client commits a transaction (distributed shared model
>>> semantics).
>>
>> So Teneo is more of a client side persistence alternative and CDO is a
>> model repository server!
> Right.
>
>> Is CDO the only Eclipse Modeling project making this claim?
> AFAIK, yes.
>
>> Side question:
>> Since models are persisted to a repository server (a rdbms) has anyone
>> experimented with plugging in BIRT to this rdbms so end user's could
>> be given reporting support? In other words are the final relational
>> schemas human readable and understandable enough for report designers
>> to work with?
> Interesting question because I just discussed that topic with a friend
> of mine. I cc'ed Philipp for this purpose.
>
> 1) A CDO server mainly consists of three parts/layers: A protocol peer
> (Net4j based), a model repository framework (storage agnostic) and a
> storage framework. It depends on the storage implementation (IStore) how
> the model data is actually persisted to a storage backend. This *can* be
> an RDBMS via plain JDBC (default) but a user has also implemented an
> Objectivity store (OODBMS) and plans to implement a Hibernate based store.
>
> 2) In case the default JDBC store is used with a repository I'd say yes,
> the generated schema is human readable and understandable enough for
> report designers to work with but that is my own opinion. Currently CDO
> always uses its own generated primary keys (long id values) and
> references are mostly always stored in a fixed format that allows for
> transparent versioning.
>
> 3) I'd prefer to see a model/BIRT integration at the model side (CDO
> client) rather than at the DB side (one of several possible CDO storage
> backends and highly implementation dependent). I'm neither a BIRT nor an
> ODA expert but is it not possible to use an EMF ResourceSet, a Resource
> or an EObject as an ODA data source? That'd be much closer to the
> semantics of the model than querying the mapped DB.
>
>>>> Does CDO use the EMF transaction framework?
>>> No, CDO acts directly on the model level. EMF Transaction acts on the
>>> higher edit/command framework level which, in my opinion, has at
>>> least two disadvantages:
>>> 1) Not all clients want to use a command stack to interact with
>>> models (especially non-UI clients like batch clients). With CDO these
>>> clients can remain unchanged (are not forced to use a command stack)
>>> and since CDO transactions are transparent to the command stack UI
>>> clients can be used, too.
>>> 2) Worse, command stack based transactions rely on the cooperation of
>>> *all* clients of a model. If only one client doesn't use a command
>>> stack or uses a non-transactional command stack all transactions
>>> might become corrupt! Since CDO integrates with EMF models at their
>>> core none of these restrictions apply.
>>>
>>
>>
>> When you say CDO works at the model level, does that mean entire
>> models are moved from client to server?
> I'm not sure if I correctly understand the intend of your question. The
> scope of a CDO transaction is always an EMF ResourceSet (no command
> stack needed). This ResourceSet can contain multiple CDO Resources (and
> possibly other types of Resources). At the time of committing the
> transaction no CDO Resource is allowed to contain references to non-CDO
> Resources. In other words a CDO repository is always guaranteed to
> contain a consistent state of an object graph that can be partitioned
> into CDO Resources. Looking from the other side a CDO-prepared
> ResourceSet acts like a partial but self-populating view onto the whole
> object graph of the repository.
>
> So in this sense, yes, entire models are (initially) moved from client
> to server. Once a model is committed into the repository subsequent
> reads and writes (commits) act at least at an object granularity. A
> recent effort of a user added support for sending only deltas for
> changed objects to the server, see
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=201266 .
>
> I guess I should stop saying "at the model level" because the word
> "model" is one of the only four terms we have available in modern
> software engineering, ambiguities granted ;-)
> The reason I used it is the following. When you kick the EMF generator
> for an ecore model it typically produces 3 plugins:
> 1) model plugin
> 2) edit plugin (command framework integration)
> 3) editor plugin (Eclipse UI)
>
> When I say "at the model level" I really mean that only 1) is needed for
> integration. AFAIK EMF Transaction needs 1) plus 2) for its integration
> because it intercepts commands of the command framework.
>
>> Is there facilities for plugging in Model to Model translation
>> facilities so that one could sync heterogeneous models to one
>> repository?
> I'm lost. Could you please elaborate on "Model to Model translation
> facilities" and "heterogeneous models"?
>
>> My mind has not been expanded as of yet to all the possibilities with
>> CDO, but I am wondering if CDO may be able to offer an infrastructure
>> for models what XProc http://www.w3.org/TR/2007/WD-xproc-20071129/
>> is offering for XML docs?
> I'm really not familiar with XProc. The abstract says "[...] a language
> for describing operations to be performed on XML documents". From this
> I'd say, no, CDO focusses more on the static aspects of a model than on
> the possible operations that could modeify a model over time. May be you
> can list some specific details of the XProc spec (which I've not read as
> a whole) that you're interested in?
>
>>>> [stuff deleted]
>>> Good point! Would you be willing to contribute such a connector? If
>>> so, please open an enhancement request in Bugzilla and attach a patch
>>> (since Net4j is already extensible in the dimension of transports a
>>> patch might not be needed and you can simply attach the extension
>>> bundle project). I'd be happy to maintain the code after ;-)
>>
>> Have several activities scheduled right now, but I am interested
>> enough to contribute with either a comm port transport or a Bluetooth
>> one. The problem I for see with either one of these solutions is that
>> I expect there will be OS library dependencies that will have to be
>> bundled with the code. This is something I have not done before.
> OSGi should be prepared for this ;-)
>>
>> Will start looking into this next month.
> That'd be great! Please tell me when you need my assistance...
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
>>>> That said, a connector implementation for comm ports should be easy,
>>>> as easy as the usage of comm ports is in Java (which I have no idea
>>>> of).
>>>> I have not done this myself, so I don't know how easy the lower
>>>> layer will be. Would probably do the http://www.rxtx.org/ versus
>>>> Sun's impl.
>>>>
>>>> As
>>>>> the docs of IConnector state you'll have to subclass Connector (
>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j/src/org/eclipse /internal/net4j/Connector.java?root=Modeling_Project&vie w=log)
>>>>> . I suggest to look at the implementation of TCPConnector (
>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j.tcp/src/org/ecl ipse/net4j/internal/tcp/TCPConnector.java?root=Modeling_Proj ect&view=log
>>>>> ).
>>>>>
>>>>> As I said above, if you succeed in providing a comm port
>>>>> implementation of IConnector (and the supporting factories) you'll
>>>>> get EMF integration for free ;-)
>>>>
>>>> Sounds good, but will I need to also install a database to get EMF
>>>> integration?
>>> Good question! According to the 'normal' setup of a CDO deployment,
>>> yes. But CDO should be open and layered enuogh to find a solution
>>> that uses only the model integration parts. I haven't thought about
>>> such usage so far.
>>
>>
>> kind regards,
>> John Conlon
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #104801 is a reply to message #104788] |
Mon, 17 December 2007 10:25 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Hi Martin,
comments below...
Martin Taal schrieb:
> Hi Eike, John,
> Just to add my thoughts about Teneo :-).
> Teneo is very much focused on being a persistence solution for
> persisting (complex) models to a relational store. This focus means
> that Teneo has broad support for most complex modeling constructs (for
> example feature maps, xml schema anytype, mixed type, etc.) and
> support for jpa annotations in the model. On the other hand this focus
> also means that Teneo does not include specific client-server
> functionality, this is outside of the scope of Teneo.
> So I would not say that Teneo is a client side solution (I use Teneo
> server side in a web app). Teneo can also be used server side (in a
> rcp app) but then you need to implement your own client-server layer
> (using other tools).
These client/server things are so ambiguous like the model/meta model
things depending on the start point ;-)
But with your clarification the main difference between CDO and Teneo
should be clear now.
> Btw, it would be interesting to integrate the client-server
> capabilities of CDO/net4j with the mapping capabilities of Teneo. I
> think this can be a powerfull combination...
That'd be of course an interesting effort. What do you think could be
the result of such an effort?
Simon (cc'ed) and I often discussed this topic and I seem to remember
that we (you and I) also spoke about such integration.
The result that I'd wish from such an integration would clearly be a CDO
storage framework implementation that uses Hibernate as O/R mapper. I
fear that your general experience with Hibernate can be more helpful
than your actual product Teneo. But I'd be glad to be proven wrong here.
The following is the reason (correct me if I'm wrong):
- Teneos main purpose (with respect to Hibernate) is the integration of
EMF Resources and EObjects with a Hibernate mapped database. In other
words you directly map EMF concepts to/from Hibernate concepts in one
deployment node (client or server).
- CDO wishes Hibernate mapping at its server side
- At the server side of CDO there are no EMF concepts. The CDO (network)
protocol doesn't deal with EMF concepts. The state of EObjects is
translated into non-EMF data structures at client side.
- The non-EMF data structures that represent EObject state at the server
can't easily mapped by Teneo (since Teneo deals with EMF concepts).
Would you agree?
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
>
> gr. Martin
>
> Eike Stepper wrote:
>> John E. Conlon schrieb:
>>>> [stuff deleted]
>>>>> How does CDO compare to Teneo?
>>>> I'd say the main difference is the deployment strategy. While Teneo
>>>> (I'm not a Teneo expert!) is mainly used on the client side (with
>>>> hibernate/jpox generated JDBC on the wire) CDO is is used on the
>>>> client side for EMF model integration and on the server side for
>>>> the storage integration (O/R mapping, OODB integration). CDO uses
>>>> an own (Net4j based) wire protocol which is tailored to
>>>> transactional semantics in the context of objects (not SQL). Since
>>>> CDO clients rely on a dedicated CDO server they can offer some
>>>> additional functions not available with Teneo, like automatic model
>>>> update on all clients if one client commits a transaction
>>>> (distributed shared model semantics).
>>>
>>> So Teneo is more of a client side persistence alternative and CDO is
>>> a model repository server!
>> Right.
>>
>>> Is CDO the only Eclipse Modeling project making this claim?
>> AFAIK, yes.
>>
>>> Side question:
>>> Since models are persisted to a repository server (a rdbms) has
>>> anyone experimented with plugging in BIRT to this rdbms so end
>>> user's could be given reporting support? In other words are the
>>> final relational schemas human readable and understandable enough
>>> for report designers to work with?
>> Interesting question because I just discussed that topic with a
>> friend of mine. I cc'ed Philipp for this purpose.
>>
>> 1) A CDO server mainly consists of three parts/layers: A protocol
>> peer (Net4j based), a model repository framework (storage agnostic)
>> and a storage framework. It depends on the storage implementation
>> (IStore) how the model data is actually persisted to a storage
>> backend. This *can* be an RDBMS via plain JDBC (default) but a user
>> has also implemented an Objectivity store (OODBMS) and plans to
>> implement a Hibernate based store.
>>
>> 2) In case the default JDBC store is used with a repository I'd say
>> yes, the generated schema is human readable and understandable enough
>> for report designers to work with but that is my own opinion.
>> Currently CDO always uses its own generated primary keys (long id
>> values) and references are mostly always stored in a fixed format
>> that allows for transparent versioning.
>>
>> 3) I'd prefer to see a model/BIRT integration at the model side (CDO
>> client) rather than at the DB side (one of several possible CDO
>> storage backends and highly implementation dependent). I'm neither a
>> BIRT nor an ODA expert but is it not possible to use an EMF
>> ResourceSet, a Resource or an EObject as an ODA data source? That'd
>> be much closer to the semantics of the model than querying the mapped
>> DB.
>>
>>>>> Does CDO use the EMF transaction framework?
>>>> No, CDO acts directly on the model level. EMF Transaction acts on
>>>> the higher edit/command framework level which, in my opinion, has
>>>> at least two disadvantages:
>>>> 1) Not all clients want to use a command stack to interact with
>>>> models (especially non-UI clients like batch clients). With CDO
>>>> these clients can remain unchanged (are not forced to use a command
>>>> stack) and since CDO transactions are transparent to the command
>>>> stack UI clients can be used, too.
>>>> 2) Worse, command stack based transactions rely on the cooperation
>>>> of *all* clients of a model. If only one client doesn't use a
>>>> command stack or uses a non-transactional command stack all
>>>> transactions might become corrupt! Since CDO integrates with EMF
>>>> models at their core none of these restrictions apply.
>>>>
>>>
>>>
>>> When you say CDO works at the model level, does that mean entire
>>> models are moved from client to server?
>> I'm not sure if I correctly understand the intend of your question.
>> The scope of a CDO transaction is always an EMF ResourceSet (no
>> command stack needed). This ResourceSet can contain multiple CDO
>> Resources (and possibly other types of Resources). At the time of
>> committing the transaction no CDO Resource is allowed to contain
>> references to non-CDO Resources. In other words a CDO repository is
>> always guaranteed to contain a consistent state of an object graph
>> that can be partitioned into CDO Resources. Looking from the other
>> side a CDO-prepared ResourceSet acts like a partial but
>> self-populating view onto the whole object graph of the repository.
>>
>> So in this sense, yes, entire models are (initially) moved from
>> client to server. Once a model is committed into the repository
>> subsequent reads and writes (commits) act at least at an object
>> granularity. A recent effort of a user added support for sending only
>> deltas for changed objects to the server, see
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=201266 .
>>
>> I guess I should stop saying "at the model level" because the word
>> "model" is one of the only four terms we have available in modern
>> software engineering, ambiguities granted ;-)
>> The reason I used it is the following. When you kick the EMF
>> generator for an ecore model it typically produces 3 plugins:
>> 1) model plugin
>> 2) edit plugin (command framework integration)
>> 3) editor plugin (Eclipse UI)
>>
>> When I say "at the model level" I really mean that only 1) is needed
>> for integration. AFAIK EMF Transaction needs 1) plus 2) for its
>> integration because it intercepts commands of the command framework.
>>
>>> Is there facilities for plugging in Model to Model translation
>>> facilities so that one could sync heterogeneous models to one
>>> repository?
>> I'm lost. Could you please elaborate on "Model to Model translation
>> facilities" and "heterogeneous models"?
>>
>>> My mind has not been expanded as of yet to all the possibilities
>>> with CDO, but I am wondering if CDO may be able to offer an
>>> infrastructure for models what XProc
>>> http://www.w3.org/TR/2007/WD-xproc-20071129/
>>> is offering for XML docs?
>> I'm really not familiar with XProc. The abstract says "[...] a
>> language for describing operations to be performed on XML documents".
>> From this I'd say, no, CDO focusses more on the static aspects of a
>> model than on the possible operations that could modeify a model over
>> time. May be you can list some specific details of the XProc spec
>> (which I've not read as a whole) that you're interested in?
>>
>>>>> [stuff deleted]
>>>> Good point! Would you be willing to contribute such a connector? If
>>>> so, please open an enhancement request in Bugzilla and attach a
>>>> patch (since Net4j is already extensible in the dimension of
>>>> transports a patch might not be needed and you can simply attach
>>>> the extension bundle project). I'd be happy to maintain the code
>>>> after ;-)
>>>
>>> Have several activities scheduled right now, but I am interested
>>> enough to contribute with either a comm port transport or a
>>> Bluetooth one. The problem I for see with either one of these
>>> solutions is that I expect there will be OS library dependencies
>>> that will have to be bundled with the code. This is something I have
>>> not done before.
>> OSGi should be prepared for this ;-)
>>>
>>> Will start looking into this next month.
>> That'd be great! Please tell me when you need my assistance...
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>>>>> That said, a connector implementation for comm ports should be
>>>>> easy, as easy as the usage of comm ports is in Java (which I have
>>>>> no idea of).
>>>>> I have not done this myself, so I don't know how easy the lower
>>>>> layer will be. Would probably do the http://www.rxtx.org/ versus
>>>>> Sun's impl.
>>>>>
>>>>> As
>>>>>> the docs of IConnector state you'll have to subclass Connector (
>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j/src/org/eclipse /internal/net4j/Connector.java?root=Modeling_Project&vie w=log)
>>>>>> . I suggest to look at the implementation of TCPConnector (
>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j.tcp/src/org/ecl ipse/net4j/internal/tcp/TCPConnector.java?root=Modeling_Proj ect&view=log
>>>>>> ).
>>>>>>
>>>>>> As I said above, if you succeed in providing a comm port
>>>>>> implementation of IConnector (and the supporting factories)
>>>>>> you'll get EMF integration for free ;-)
>>>>>
>>>>> Sounds good, but will I need to also install a database to get EMF
>>>>> integration?
>>>> Good question! According to the 'normal' setup of a CDO deployment,
>>>> yes. But CDO should be open and layered enuogh to find a solution
>>>> that uses only the model integration parts. I haven't thought about
>>>> such usage so far.
>>>
>>>
>>> kind regards,
>>> John Conlon
>
>
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #104865 is a reply to message #104801] |
Mon, 17 December 2007 22:09 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Eike,
Just to continue on your last points (otherwise the post becomes unreadable to me):
- Teneos main purpose (with respect to Hibernate) is the integration of EMF Resources and EObjects
with a Hibernate mapped database. In other words you directly map EMF concepts to/from Hibernate
concepts in one deployment node (client or server).
MT>> Almost :-), Teneo consists of two main parts:
1) Mapping functionality: maps a model to a relational schema (in fact maps a model to a java
persistence api annotated model which is then translated to a hibernate mapping). The user can
override standard mapping behavior by adding jpa annotations in the model.
2) At runtime provide easy integration between EMF and hibernate (or jpox). This part is mainly to
support automatic mapping (so using the above functionality 1) when initializing and support emf
specifics such as featuremaps, elists and emf resources.
Currently Teneo has 2 runtime layers one for jpox and one for hibernate. It would be interesting to
add other runtime layers.
Btw, I use the mapping functionality of Teneo also outside of EMF: I map the model using Teneo and
then at runtime I have non-emf objects.
- CDO wishes Hibernate mapping at its server side
- At the server side of CDO there are no EMF concepts. The CDO (network) protocol doesn't deal with
EMF concepts. The state of EObjects is translated into non-EMF data structures at client side.
MT>> But still because you currently also create a relational schema, I assume that the server also
has knowledge of the ecore model. I can imagine also that your non-emf data structure refer to this
model?
- The non-EMF data structures that represent EObject state at the server can't easily mapped by
Teneo (since Teneo deals with EMF concepts).
MT>> Not sure if this is an obstacle. I assume that also for the CDO non-emf datastructures there is
a relation to the application model expressed in ecore. Teneo also uses the ecore model as its basis
for mapping to hibernate. So as long as there is a relation between your non-emf datastructure and
the ecore model then a runtime layer which uses the Teneo mapping logic should be pretty doable.
For example next to Teneo I am working on generating seam web applications from ecore models. To
support the persistence side I use Teneo for the mapping and as runtime I have a dynamic-emf-like
object (basically a type-safe hashmap). The runtime layer is about 15 classes.
gr. Martin
Eike Stepper wrote:
> Hi Martin,
>
> comments below...
>
>
> Martin Taal schrieb:
>> Hi Eike, John,
>> Just to add my thoughts about Teneo :-).
>> Teneo is very much focused on being a persistence solution for
>> persisting (complex) models to a relational store. This focus means
>> that Teneo has broad support for most complex modeling constructs (for
>> example feature maps, xml schema anytype, mixed type, etc.) and
>> support for jpa annotations in the model. On the other hand this focus
>> also means that Teneo does not include specific client-server
>> functionality, this is outside of the scope of Teneo.
>> So I would not say that Teneo is a client side solution (I use Teneo
>> server side in a web app). Teneo can also be used server side (in a
>> rcp app) but then you need to implement your own client-server layer
>> (using other tools).
> These client/server things are so ambiguous like the model/meta model
> things depending on the start point ;-)
> But with your clarification the main difference between CDO and Teneo
> should be clear now.
>
>> Btw, it would be interesting to integrate the client-server
>> capabilities of CDO/net4j with the mapping capabilities of Teneo. I
>> think this can be a powerfull combination...
> That'd be of course an interesting effort. What do you think could be
> the result of such an effort?
>
> Simon (cc'ed) and I often discussed this topic and I seem to remember
> that we (you and I) also spoke about such integration.
> The result that I'd wish from such an integration would clearly be a CDO
> storage framework implementation that uses Hibernate as O/R mapper. I
> fear that your general experience with Hibernate can be more helpful
> than your actual product Teneo. But I'd be glad to be proven wrong here.
> The following is the reason (correct me if I'm wrong):
> - Teneos main purpose (with respect to Hibernate) is the integration of
> EMF Resources and EObjects with a Hibernate mapped database. In other
> words you directly map EMF concepts to/from Hibernate concepts in one
> deployment node (client or server).
> - CDO wishes Hibernate mapping at its server side
> - At the server side of CDO there are no EMF concepts. The CDO (network)
> protocol doesn't deal with EMF concepts. The state of EObjects is
> translated into non-EMF data structures at client side.
> - The non-EMF data structures that represent EObject state at the server
> can't easily mapped by Teneo (since Teneo deals with EMF concepts).
>
> Would you agree?
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
>>
>> gr. Martin
>>
>> Eike Stepper wrote:
>>> John E. Conlon schrieb:
>>>>> [stuff deleted]
>>>>>> How does CDO compare to Teneo?
>>>>> I'd say the main difference is the deployment strategy. While Teneo
>>>>> (I'm not a Teneo expert!) is mainly used on the client side (with
>>>>> hibernate/jpox generated JDBC on the wire) CDO is is used on the
>>>>> client side for EMF model integration and on the server side for
>>>>> the storage integration (O/R mapping, OODB integration). CDO uses
>>>>> an own (Net4j based) wire protocol which is tailored to
>>>>> transactional semantics in the context of objects (not SQL). Since
>>>>> CDO clients rely on a dedicated CDO server they can offer some
>>>>> additional functions not available with Teneo, like automatic model
>>>>> update on all clients if one client commits a transaction
>>>>> (distributed shared model semantics).
>>>>
>>>> So Teneo is more of a client side persistence alternative and CDO is
>>>> a model repository server!
>>> Right.
>>>
>>>> Is CDO the only Eclipse Modeling project making this claim?
>>> AFAIK, yes.
>>>
>>>> Side question:
>>>> Since models are persisted to a repository server (a rdbms) has
>>>> anyone experimented with plugging in BIRT to this rdbms so end
>>>> user's could be given reporting support? In other words are the
>>>> final relational schemas human readable and understandable enough
>>>> for report designers to work with?
>>> Interesting question because I just discussed that topic with a
>>> friend of mine. I cc'ed Philipp for this purpose.
>>>
>>> 1) A CDO server mainly consists of three parts/layers: A protocol
>>> peer (Net4j based), a model repository framework (storage agnostic)
>>> and a storage framework. It depends on the storage implementation
>>> (IStore) how the model data is actually persisted to a storage
>>> backend. This *can* be an RDBMS via plain JDBC (default) but a user
>>> has also implemented an Objectivity store (OODBMS) and plans to
>>> implement a Hibernate based store.
>>>
>>> 2) In case the default JDBC store is used with a repository I'd say
>>> yes, the generated schema is human readable and understandable enough
>>> for report designers to work with but that is my own opinion.
>>> Currently CDO always uses its own generated primary keys (long id
>>> values) and references are mostly always stored in a fixed format
>>> that allows for transparent versioning.
>>>
>>> 3) I'd prefer to see a model/BIRT integration at the model side (CDO
>>> client) rather than at the DB side (one of several possible CDO
>>> storage backends and highly implementation dependent). I'm neither a
>>> BIRT nor an ODA expert but is it not possible to use an EMF
>>> ResourceSet, a Resource or an EObject as an ODA data source? That'd
>>> be much closer to the semantics of the model than querying the mapped
>>> DB.
>>>
>>>>>> Does CDO use the EMF transaction framework?
>>>>> No, CDO acts directly on the model level. EMF Transaction acts on
>>>>> the higher edit/command framework level which, in my opinion, has
>>>>> at least two disadvantages:
>>>>> 1) Not all clients want to use a command stack to interact with
>>>>> models (especially non-UI clients like batch clients). With CDO
>>>>> these clients can remain unchanged (are not forced to use a command
>>>>> stack) and since CDO transactions are transparent to the command
>>>>> stack UI clients can be used, too.
>>>>> 2) Worse, command stack based transactions rely on the cooperation
>>>>> of *all* clients of a model. If only one client doesn't use a
>>>>> command stack or uses a non-transactional command stack all
>>>>> transactions might become corrupt! Since CDO integrates with EMF
>>>>> models at their core none of these restrictions apply.
>>>>>
>>>>
>>>>
>>>> When you say CDO works at the model level, does that mean entire
>>>> models are moved from client to server?
>>> I'm not sure if I correctly understand the intend of your question.
>>> The scope of a CDO transaction is always an EMF ResourceSet (no
>>> command stack needed). This ResourceSet can contain multiple CDO
>>> Resources (and possibly other types of Resources). At the time of
>>> committing the transaction no CDO Resource is allowed to contain
>>> references to non-CDO Resources. In other words a CDO repository is
>>> always guaranteed to contain a consistent state of an object graph
>>> that can be partitioned into CDO Resources. Looking from the other
>>> side a CDO-prepared ResourceSet acts like a partial but
>>> self-populating view onto the whole object graph of the repository.
>>>
>>> So in this sense, yes, entire models are (initially) moved from
>>> client to server. Once a model is committed into the repository
>>> subsequent reads and writes (commits) act at least at an object
>>> granularity. A recent effort of a user added support for sending only
>>> deltas for changed objects to the server, see
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=201266 .
>>>
>>> I guess I should stop saying "at the model level" because the word
>>> "model" is one of the only four terms we have available in modern
>>> software engineering, ambiguities granted ;-)
>>> The reason I used it is the following. When you kick the EMF
>>> generator for an ecore model it typically produces 3 plugins:
>>> 1) model plugin
>>> 2) edit plugin (command framework integration)
>>> 3) editor plugin (Eclipse UI)
>>>
>>> When I say "at the model level" I really mean that only 1) is needed
>>> for integration. AFAIK EMF Transaction needs 1) plus 2) for its
>>> integration because it intercepts commands of the command framework.
>>>
>>>> Is there facilities for plugging in Model to Model translation
>>>> facilities so that one could sync heterogeneous models to one
>>>> repository?
>>> I'm lost. Could you please elaborate on "Model to Model translation
>>> facilities" and "heterogeneous models"?
>>>
>>>> My mind has not been expanded as of yet to all the possibilities
>>>> with CDO, but I am wondering if CDO may be able to offer an
>>>> infrastructure for models what XProc
>>>> http://www.w3.org/TR/2007/WD-xproc-20071129/
>>>> is offering for XML docs?
>>> I'm really not familiar with XProc. The abstract says "[...] a
>>> language for describing operations to be performed on XML documents".
>>> From this I'd say, no, CDO focusses more on the static aspects of a
>>> model than on the possible operations that could modeify a model over
>>> time. May be you can list some specific details of the XProc spec
>>> (which I've not read as a whole) that you're interested in?
>>>
>>>>>> [stuff deleted]
>>>>> Good point! Would you be willing to contribute such a connector? If
>>>>> so, please open an enhancement request in Bugzilla and attach a
>>>>> patch (since Net4j is already extensible in the dimension of
>>>>> transports a patch might not be needed and you can simply attach
>>>>> the extension bundle project). I'd be happy to maintain the code
>>>>> after ;-)
>>>>
>>>> Have several activities scheduled right now, but I am interested
>>>> enough to contribute with either a comm port transport or a
>>>> Bluetooth one. The problem I for see with either one of these
>>>> solutions is that I expect there will be OS library dependencies
>>>> that will have to be bundled with the code. This is something I have
>>>> not done before.
>>> OSGi should be prepared for this ;-)
>>>>
>>>> Will start looking into this next month.
>>> That'd be great! Please tell me when you need my assistance...
>>>
>>> Regards,
>>> Eike Stepper
>>> ----
>>> http://wiki.eclipse.org/CDO
>>> http://wiki.eclipse.org/Net4j
>>>
>>>
>>>>>> That said, a connector implementation for comm ports should be
>>>>>> easy, as easy as the usage of comm ports is in Java (which I have
>>>>>> no idea of).
>>>>>> I have not done this myself, so I don't know how easy the lower
>>>>>> layer will be. Would probably do the http://www.rxtx.org/ versus
>>>>>> Sun's impl.
>>>>>>
>>>>>> As
>>>>>>> the docs of IConnector state you'll have to subclass Connector (
>>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j/src/org/eclipse /internal/net4j/Connector.java?root=Modeling_Project&vie w=log)
>>>>>>> . I suggest to look at the implementation of TCPConnector (
>>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j.tcp/src/org/ecl ipse/net4j/internal/tcp/TCPConnector.java?root=Modeling_Proj ect&view=log
>>>>>>> ).
>>>>>>>
>>>>>>> As I said above, if you succeed in providing a comm port
>>>>>>> implementation of IConnector (and the supporting factories)
>>>>>>> you'll get EMF integration for free ;-)
>>>>>>
>>>>>> Sounds good, but will I need to also install a database to get EMF
>>>>>> integration?
>>>>> Good question! According to the 'normal' setup of a CDO deployment,
>>>>> yes. But CDO should be open and layered enuogh to find a solution
>>>>> that uses only the model integration parts. I haven't thought about
>>>>> such usage so far.
>>>>
>>>>
>>>> kind regards,
>>>> John Conlon
>>
>>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #104873 is a reply to message #104865] |
Tue, 18 December 2007 10:32 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Martin Taal schrieb:
> Hi Eike,
> Just to continue on your last points (otherwise the post becomes
> unreadable to me):
> - Teneos main purpose (with respect to Hibernate) is the integration
> of EMF Resources and EObjects with a Hibernate mapped database. In
> other words you directly map EMF concepts to/from Hibernate concepts
> in one deployment node (client or server).
> MT>> Almost :-), Teneo consists of two main parts:
> 1) Mapping functionality: maps a model to a relational schema (in fact
> maps a model to a java persistence api annotated model which is then
> translated to a hibernate mapping). The user can override standard
> mapping behavior by adding jpa annotations in the model.
> 2) At runtime provide easy integration between EMF and hibernate (or
> jpox). This part is mainly to support automatic mapping (so using the
> above functionality 1) when initializing and support emf specifics
> such as featuremaps, elists and emf resources.
That makes sense ;-)
> Currently Teneo has 2 runtime layers one for jpox and one for
> hibernate. It would be interesting to add other runtime layers.
Ok, there I can see a chance for CDO. It would be completely covered by
your runtime framework, right?
> Btw, I use the mapping functionality of Teneo also outside of EMF: I
> map the model using Teneo and then at runtime I have non-emf objects.
>
> - CDO wishes Hibernate mapping at its server side
> - At the server side of CDO there are no EMF concepts. The CDO
> (network) protocol doesn't deal with EMF concepts. The state of
> EObjects is translated into non-EMF data structures at client side.
> MT>> But still because you currently also create a relational schema,
> I assume that the server also has knowledge of the ecore model.
Right, at the client there are bijective conversions between:
EPackage <-> CDOPackage
EClass <-> CDOClass
EStructuralFeature <-> CDOFeature
So I'd say a simplified version of the Ecore model arrives at the server
and is usually stored in an IStore of the CDO storage framework (can be
RDB). BTW. it's even possible to retrieve the XMI string of the original
Ecore model from a CDOPackage.
> I can imagine also that your non-emf data structure refer to this model?
Right, there's a method CDORevision.getCDOClass().
> - The non-EMF data structures that represent EObject state at the
> server can't easily mapped by Teneo (since Teneo deals with EMF
> concepts).
> MT>> Not sure if this is an obstacle. I assume that also for the CDO
> non-emf datastructures there is a relation to the application model
> expressed in ecore. Teneo also uses the ecore model as its basis for
> mapping to hibernate. So as long as there is a relation between your
> non-emf datastructure and the ecore model then a runtime layer which
> uses the Teneo mapping logic should be pretty doable.
That's great to hear. But we have to double check:
CDO (at client side) converts in both directions between an Ecore model
and its internal representation of this model. I think this is the
relation you mean. At CDO's server side there's usually no such
conversion because there's simply no EMF (required).
BUT: since the Ecore XMI string can be retrieved from the repository via
CDOPackage I think a Teneo based IStore implementation could add EMF to
its dependencies, deserialize the original Ecore model and apply the
same E<->CDO conversion as the CDO client.
That sounds reasonable to me. Agreed so far?
I'd have to factor out the conversion mechanism into a separate plugin...
> For example next to Teneo I am working on generating seam web
> applications from ecore models. To support the persistence side I use
> Teneo for the mapping and as runtime I have a dynamic-emf-like object
> (basically a type-safe hashmap). The runtime layer is about 15 classes.
That sounds similar to the CDO server although it has one or two more
classes ;-)
To sum up:
- It seems as we we (out products) could both profit from working together.
- There could be a Teneo with CDO under the runtime hood [A]
- There could be a CDO server with a Teneo-based IStore [B]
- We are willing to spend effort for this ;-)
If you agree up to here we should discuss how we start and who should do
what. I had a similar integration story with Net4j <-> ECF and I learned
that it is often easier to *use* foreign API than to *extend* it. That
also results in the author of the integration being the maintainer.
For [A] that would mean that primarily you would extend your runtime
framework by using CDO API (with my help of course).
For [B] that would mean that primarily I would extend my storage
framework by implementing the above conversions at server side and then
using Teneo API (with your help).
I guess that on the way we'll discover some more challenges ;-)
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
>
> gr. Martin
>
> Eike Stepper wrote:
>> Hi Martin,
>>
>> comments below...
>>
>>
>> Martin Taal schrieb:
>>> Hi Eike, John,
>>> Just to add my thoughts about Teneo :-).
>>> Teneo is very much focused on being a persistence solution for
>>> persisting (complex) models to a relational store. This focus means
>>> that Teneo has broad support for most complex modeling constructs
>>> (for example feature maps, xml schema anytype, mixed type, etc.) and
>>> support for jpa annotations in the model. On the other hand this
>>> focus also means that Teneo does not include specific client-server
>>> functionality, this is outside of the scope of Teneo.
>>> So I would not say that Teneo is a client side solution (I use Teneo
>>> server side in a web app). Teneo can also be used server side (in a
>>> rcp app) but then you need to implement your own client-server layer
>>> (using other tools).
>> These client/server things are so ambiguous like the model/meta model
>> things depending on the start point ;-)
>> But with your clarification the main difference between CDO and Teneo
>> should be clear now.
>>
>>> Btw, it would be interesting to integrate the client-server
>>> capabilities of CDO/net4j with the mapping capabilities of Teneo. I
>>> think this can be a powerfull combination...
>> That'd be of course an interesting effort. What do you think could be
>> the result of such an effort?
>>
>> Simon (cc'ed) and I often discussed this topic and I seem to remember
>> that we (you and I) also spoke about such integration.
>> The result that I'd wish from such an integration would clearly be a
>> CDO storage framework implementation that uses Hibernate as O/R
>> mapper. I fear that your general experience with Hibernate can be
>> more helpful than your actual product Teneo. But I'd be glad to be
>> proven wrong here. The following is the reason (correct me if I'm
>> wrong):
>> - Teneos main purpose (with respect to Hibernate) is the integration
>> of EMF Resources and EObjects with a Hibernate mapped database. In
>> other words you directly map EMF concepts to/from Hibernate concepts
>> in one deployment node (client or server).
>> - CDO wishes Hibernate mapping at its server side
>> - At the server side of CDO there are no EMF concepts. The CDO
>> (network) protocol doesn't deal with EMF concepts. The state of
>> EObjects is translated into non-EMF data structures at client side.
>> - The non-EMF data structures that represent EObject state at the
>> server can't easily mapped by Teneo (since Teneo deals with EMF
>> concepts).
>>
>> Would you agree?
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>>>
>>> gr. Martin
>>>
>>> Eike Stepper wrote:
>>>> John E. Conlon schrieb:
>>>>>> [stuff deleted]
>>>>>>> How does CDO compare to Teneo?
>>>>>> I'd say the main difference is the deployment strategy. While
>>>>>> Teneo (I'm not a Teneo expert!) is mainly used on the client side
>>>>>> (with hibernate/jpox generated JDBC on the wire) CDO is is used
>>>>>> on the client side for EMF model integration and on the server
>>>>>> side for the storage integration (O/R mapping, OODB integration).
>>>>>> CDO uses an own (Net4j based) wire protocol which is tailored to
>>>>>> transactional semantics in the context of objects (not SQL).
>>>>>> Since CDO clients rely on a dedicated CDO server they can offer
>>>>>> some additional functions not available with Teneo, like
>>>>>> automatic model update on all clients if one client commits a
>>>>>> transaction (distributed shared model semantics).
>>>>>
>>>>> So Teneo is more of a client side persistence alternative and CDO
>>>>> is a model repository server!
>>>> Right.
>>>>
>>>>> Is CDO the only Eclipse Modeling project making this claim?
>>>> AFAIK, yes.
>>>>
>>>>> Side question:
>>>>> Since models are persisted to a repository server (a rdbms) has
>>>>> anyone experimented with plugging in BIRT to this rdbms so end
>>>>> user's could be given reporting support? In other words are the
>>>>> final relational schemas human readable and understandable enough
>>>>> for report designers to work with?
>>>> Interesting question because I just discussed that topic with a
>>>> friend of mine. I cc'ed Philipp for this purpose.
>>>>
>>>> 1) A CDO server mainly consists of three parts/layers: A protocol
>>>> peer (Net4j based), a model repository framework (storage agnostic)
>>>> and a storage framework. It depends on the storage implementation
>>>> (IStore) how the model data is actually persisted to a storage
>>>> backend. This *can* be an RDBMS via plain JDBC (default) but a user
>>>> has also implemented an Objectivity store (OODBMS) and plans to
>>>> implement a Hibernate based store.
>>>>
>>>> 2) In case the default JDBC store is used with a repository I'd say
>>>> yes, the generated schema is human readable and understandable
>>>> enough for report designers to work with but that is my own
>>>> opinion. Currently CDO always uses its own generated primary keys
>>>> (long id values) and references are mostly always stored in a fixed
>>>> format that allows for transparent versioning.
>>>>
>>>> 3) I'd prefer to see a model/BIRT integration at the model side
>>>> (CDO client) rather than at the DB side (one of several possible
>>>> CDO storage backends and highly implementation dependent). I'm
>>>> neither a BIRT nor an ODA expert but is it not possible to use an
>>>> EMF ResourceSet, a Resource or an EObject as an ODA data source?
>>>> That'd be much closer to the semantics of the model than querying
>>>> the mapped DB.
>>>>
>>>>>>> Does CDO use the EMF transaction framework?
>>>>>> No, CDO acts directly on the model level. EMF Transaction acts on
>>>>>> the higher edit/command framework level which, in my opinion, has
>>>>>> at least two disadvantages:
>>>>>> 1) Not all clients want to use a command stack to interact with
>>>>>> models (especially non-UI clients like batch clients). With CDO
>>>>>> these clients can remain unchanged (are not forced to use a
>>>>>> command stack) and since CDO transactions are transparent to the
>>>>>> command stack UI clients can be used, too.
>>>>>> 2) Worse, command stack based transactions rely on the
>>>>>> cooperation of *all* clients of a model. If only one client
>>>>>> doesn't use a command stack or uses a non-transactional command
>>>>>> stack all transactions might become corrupt! Since CDO integrates
>>>>>> with EMF models at their core none of these restrictions apply.
>>>>>>
>>>>>
>>>>>
>>>>> When you say CDO works at the model level, does that mean entire
>>>>> models are moved from client to server?
>>>> I'm not sure if I correctly understand the intend of your question.
>>>> The scope of a CDO transaction is always an EMF ResourceSet (no
>>>> command stack needed). This ResourceSet can contain multiple CDO
>>>> Resources (and possibly other types of Resources). At the time of
>>>> committing the transaction no CDO Resource is allowed to contain
>>>> references to non-CDO Resources. In other words a CDO repository is
>>>> always guaranteed to contain a consistent state of an object graph
>>>> that can be partitioned into CDO Resources. Looking from the other
>>>> side a CDO-prepared ResourceSet acts like a partial but
>>>> self-populating view onto the whole object graph of the repository.
>>>>
>>>> So in this sense, yes, entire models are (initially) moved from
>>>> client to server. Once a model is committed into the repository
>>>> subsequent reads and writes (commits) act at least at an object
>>>> granularity. A recent effort of a user added support for sending
>>>> only deltas for changed objects to the server, see
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=201266 .
>>>>
>>>> I guess I should stop saying "at the model level" because the word
>>>> "model" is one of the only four terms we have available in modern
>>>> software engineering, ambiguities granted ;-)
>>>> The reason I used it is the following. When you kick the EMF
>>>> generator for an ecore model it typically produces 3 plugins:
>>>> 1) model plugin
>>>> 2) edit plugin (command framework integration)
>>>> 3) editor plugin (Eclipse UI)
>>>>
>>>> When I say "at the model level" I really mean that only 1) is
>>>> needed for integration. AFAIK EMF Transaction needs 1) plus 2) for
>>>> its integration because it intercepts commands of the command
>>>> framework.
>>>>
>>>>> Is there facilities for plugging in Model to Model translation
>>>>> facilities so that one could sync heterogeneous models to one
>>>>> repository?
>>>> I'm lost. Could you please elaborate on "Model to Model translation
>>>> facilities" and "heterogeneous models"?
>>>>
>>>>> My mind has not been expanded as of yet to all the possibilities
>>>>> with CDO, but I am wondering if CDO may be able to offer an
>>>>> infrastructure for models what XProc
>>>>> http://www.w3.org/TR/2007/WD-xproc-20071129/
>>>>> is offering for XML docs?
>>>> I'm really not familiar with XProc. The abstract says "[...] a
>>>> language for describing operations to be performed on XML
>>>> documents". From this I'd say, no, CDO focusses more on the static
>>>> aspects of a model than on the possible operations that could
>>>> modeify a model over time. May be you can list some specific
>>>> details of the XProc spec (which I've not read as a whole) that
>>>> you're interested in?
>>>>
>>>>>>> [stuff deleted]
>>>>>> Good point! Would you be willing to contribute such a connector?
>>>>>> If so, please open an enhancement request in Bugzilla and attach
>>>>>> a patch (since Net4j is already extensible in the dimension of
>>>>>> transports a patch might not be needed and you can simply attach
>>>>>> the extension bundle project). I'd be happy to maintain the code
>>>>>> after ;-)
>>>>>
>>>>> Have several activities scheduled right now, but I am interested
>>>>> enough to contribute with either a comm port transport or a
>>>>> Bluetooth one. The problem I for see with either one of these
>>>>> solutions is that I expect there will be OS library dependencies
>>>>> that will have to be bundled with the code. This is something I
>>>>> have not done before.
>>>> OSGi should be prepared for this ;-)
>>>>>
>>>>> Will start looking into this next month.
>>>> That'd be great! Please tell me when you need my assistance...
>>>>
>>>> Regards,
>>>> Eike Stepper
>>>> ----
>>>> http://wiki.eclipse.org/CDO
>>>> http://wiki.eclipse.org/Net4j
>>>>
>>>>
>>>>>>> That said, a connector implementation for comm ports should be
>>>>>>> easy, as easy as the usage of comm ports is in Java (which I
>>>>>>> have no idea of).
>>>>>>> I have not done this myself, so I don't know how easy the lower
>>>>>>> layer will be. Would probably do the http://www.rxtx.org/
>>>>>>> versus Sun's impl.
>>>>>>>
>>>>>>> As
>>>>>>>> the docs of IConnector state you'll have to subclass Connector
>>>>>>>> (
>>>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j/src/org/eclipse /internal/net4j/Connector.java?root=Modeling_Project&vie w=log)
>>>>>>>> . I suggest to look at the implementation of TCPConnector (
>>>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j.tcp/src/org/ecl ipse/net4j/internal/tcp/TCPConnector.java?root=Modeling_Proj ect&view=log
>>>>>>>> ).
>>>>>>>>
>>>>>>>> As I said above, if you succeed in providing a comm port
>>>>>>>> implementation of IConnector (and the supporting factories)
>>>>>>>> you'll get EMF integration for free ;-)
>>>>>>>
>>>>>>> Sounds good, but will I need to also install a database to get
>>>>>>> EMF integration?
>>>>>> Good question! According to the 'normal' setup of a CDO
>>>>>> deployment, yes. But CDO should be open and layered enuogh to
>>>>>> find a solution that uses only the model integration parts. I
>>>>>> haven't thought about such usage so far.
>>>>>
>>>>>
>>>>> kind regards,
>>>>> John Conlon
>>>
>>>
>
>
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #104975 is a reply to message #104873] |
Wed, 19 December 2007 10:53 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Eike,
I pasted your comments back up to make the post readable:
ES>> CDO (at client side) converts in both directions between an Ecore model and its internal
representation of this model. I think this is the relation you mean. At CDO's server side there's
usually no such conversion because there's simply no EMF (required).
BUT: since the Ecore XMI string can be retrieved from the repository via CDOPackage I think a Teneo
based IStore implementation could add EMF to its dependencies, deserialize the original Ecore model
and apply the same E<->CDO conversion as the CDO client.
MT>> Yes that would surely work afaics. The ecore model is also important for Teneo because it can
contain annotations which influence the persistence strategy.
ES>>
To sum up:
- It seems as we we (out products) could both profit from working together.
- There could be a Teneo with CDO under the runtime hood [A]
- There could be a CDO server with a Teneo-based IStore [B]
- We are willing to spend effort for this ;-)
MT>>
I fully agree, hopefully the teneo based istore would offer the same api as you currently use within
cdo server so that the changes in the cdo server are not that large.
I am willing to spend the effort in doing this (but not before the new year :-).
ES>>
If you agree up to here we should discuss how we start and who should do what. I had a similar
integration story with Net4j <-> ECF and I learned that it is often easier to *use* foreign API than
to *extend* it. That also results in the author of the integration being the maintainer.
For [A] that would mean that primarily you would extend your runtime framework by using CDO API
(with my help of course).
For [B] that would mean that primarily I would extend my storage framework by implementing the above
conversions at server side and then using Teneo API (with your help).
MT>> No problem we can see how we can divide the work. I am willing to spend time on this and also
maintain the runtime layer afterwards. I can start looking at CDO and see how the persistence works
currently (using IStore). Can I download/test cdo separately without net4j? Do you have some
hyperlinks with the docs?
ES>>
I guess that on the way we'll discover some more challenges ;-)
MT>>
For sure, it makes all this 'unpaid' work interesting and worthwhile doesn't it :-).
One last question for my interest, does the non-emf cdo server side support the emf featuremap and
other emf/xml schema specialities such as mixed or anytype?
gr. Martin
Eike Stepper wrote:
> Martin Taal schrieb:
>> Hi Eike,
>> Just to continue on your last points (otherwise the post becomes
>> unreadable to me):
>> - Teneos main purpose (with respect to Hibernate) is the integration
>> of EMF Resources and EObjects with a Hibernate mapped database. In
>> other words you directly map EMF concepts to/from Hibernate concepts
>> in one deployment node (client or server).
>> MT>> Almost :-), Teneo consists of two main parts:
>> 1) Mapping functionality: maps a model to a relational schema (in fact
>> maps a model to a java persistence api annotated model which is then
>> translated to a hibernate mapping). The user can override standard
>> mapping behavior by adding jpa annotations in the model.
>> 2) At runtime provide easy integration between EMF and hibernate (or
>> jpox). This part is mainly to support automatic mapping (so using the
>> above functionality 1) when initializing and support emf specifics
>> such as featuremaps, elists and emf resources.
> That makes sense ;-)
>
>> Currently Teneo has 2 runtime layers one for jpox and one for
>> hibernate. It would be interesting to add other runtime layers.
> Ok, there I can see a chance for CDO. It would be completely covered by
> your runtime framework, right?
>
>> Btw, I use the mapping functionality of Teneo also outside of EMF: I
>> map the model using Teneo and then at runtime I have non-emf objects.
>>
>> - CDO wishes Hibernate mapping at its server side
>> - At the server side of CDO there are no EMF concepts. The CDO
>> (network) protocol doesn't deal with EMF concepts. The state of
>> EObjects is translated into non-EMF data structures at client side.
>> MT>> But still because you currently also create a relational schema,
>> I assume that the server also has knowledge of the ecore model.
> Right, at the client there are bijective conversions between:
> EPackage <-> CDOPackage
> EClass <-> CDOClass
> EStructuralFeature <-> CDOFeature
>
> So I'd say a simplified version of the Ecore model arrives at the server
> and is usually stored in an IStore of the CDO storage framework (can be
> RDB). BTW. it's even possible to retrieve the XMI string of the original
> Ecore model from a CDOPackage.
>
>> I can imagine also that your non-emf data structure refer to this model?
> Right, there's a method CDORevision.getCDOClass().
>
>> - The non-EMF data structures that represent EObject state at the
>> server can't easily mapped by Teneo (since Teneo deals with EMF
>> concepts).
>> MT>> Not sure if this is an obstacle. I assume that also for the CDO
>> non-emf datastructures there is a relation to the application model
>> expressed in ecore. Teneo also uses the ecore model as its basis for
>> mapping to hibernate. So as long as there is a relation between your
>> non-emf datastructure and the ecore model then a runtime layer which
>> uses the Teneo mapping logic should be pretty doable.
> That's great to hear. But we have to double check:
> CDO (at client side) converts in both directions between an Ecore model
> and its internal representation of this model. I think this is the
> relation you mean. At CDO's server side there's usually no such
> conversion because there's simply no EMF (required).
> BUT: since the Ecore XMI string can be retrieved from the repository via
> CDOPackage I think a Teneo based IStore implementation could add EMF to
> its dependencies, deserialize the original Ecore model and apply the
> same E<->CDO conversion as the CDO client.
>
> That sounds reasonable to me. Agreed so far?
> I'd have to factor out the conversion mechanism into a separate plugin...
>
>> For example next to Teneo I am working on generating seam web
>> applications from ecore models. To support the persistence side I use
>> Teneo for the mapping and as runtime I have a dynamic-emf-like object
>> (basically a type-safe hashmap). The runtime layer is about 15 classes.
> That sounds similar to the CDO server although it has one or two more
> classes ;-)
>
> To sum up:
> - It seems as we we (out products) could both profit from working together.
> - There could be a Teneo with CDO under the runtime hood [A]
> - There could be a CDO server with a Teneo-based IStore [B]
> - We are willing to spend effort for this ;-)
>
> If you agree up to here we should discuss how we start and who should do
> what. I had a similar integration story with Net4j <-> ECF and I learned
> that it is often easier to *use* foreign API than to *extend* it. That
> also results in the author of the integration being the maintainer.
>
> For [A] that would mean that primarily you would extend your runtime
> framework by using CDO API (with my help of course).
> For [B] that would mean that primarily I would extend my storage
> framework by implementing the above conversions at server side and then
> using Teneo API (with your help).
>
> I guess that on the way we'll discover some more challenges ;-)
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
>>
>> gr. Martin
>>
>> Eike Stepper wrote:
>>> Hi Martin,
>>>
>>> comments below...
>>>
>>>
>>> Martin Taal schrieb:
>>>> Hi Eike, John,
>>>> Just to add my thoughts about Teneo :-).
>>>> Teneo is very much focused on being a persistence solution for
>>>> persisting (complex) models to a relational store. This focus means
>>>> that Teneo has broad support for most complex modeling constructs
>>>> (for example feature maps, xml schema anytype, mixed type, etc.) and
>>>> support for jpa annotations in the model. On the other hand this
>>>> focus also means that Teneo does not include specific client-server
>>>> functionality, this is outside of the scope of Teneo.
>>>> So I would not say that Teneo is a client side solution (I use Teneo
>>>> server side in a web app). Teneo can also be used server side (in a
>>>> rcp app) but then you need to implement your own client-server layer
>>>> (using other tools).
>>> These client/server things are so ambiguous like the model/meta model
>>> things depending on the start point ;-)
>>> But with your clarification the main difference between CDO and Teneo
>>> should be clear now.
>>>
>>>> Btw, it would be interesting to integrate the client-server
>>>> capabilities of CDO/net4j with the mapping capabilities of Teneo. I
>>>> think this can be a powerfull combination...
>>> That'd be of course an interesting effort. What do you think could be
>>> the result of such an effort?
>>>
>>> Simon (cc'ed) and I often discussed this topic and I seem to remember
>>> that we (you and I) also spoke about such integration.
>>> The result that I'd wish from such an integration would clearly be a
>>> CDO storage framework implementation that uses Hibernate as O/R
>>> mapper. I fear that your general experience with Hibernate can be
>>> more helpful than your actual product Teneo. But I'd be glad to be
>>> proven wrong here. The following is the reason (correct me if I'm
>>> wrong):
>>> - Teneos main purpose (with respect to Hibernate) is the integration
>>> of EMF Resources and EObjects with a Hibernate mapped database. In
>>> other words you directly map EMF concepts to/from Hibernate concepts
>>> in one deployment node (client or server).
>>> - CDO wishes Hibernate mapping at its server side
>>> - At the server side of CDO there are no EMF concepts. The CDO
>>> (network) protocol doesn't deal with EMF concepts. The state of
>>> EObjects is translated into non-EMF data structures at client side.
>>> - The non-EMF data structures that represent EObject state at the
>>> server can't easily mapped by Teneo (since Teneo deals with EMF
>>> concepts).
>>>
>>> Would you agree?
>>>
>>> Regards,
>>> Eike Stepper
>>> ----
>>> http://wiki.eclipse.org/CDO
>>> http://wiki.eclipse.org/Net4j
>>>
>>>
>>>>
>>>> gr. Martin
>>>>
>>>> Eike Stepper wrote:
>>>>> John E. Conlon schrieb:
>>>>>>> [stuff deleted]
>>>>>>>> How does CDO compare to Teneo?
>>>>>>> I'd say the main difference is the deployment strategy. While
>>>>>>> Teneo (I'm not a Teneo expert!) is mainly used on the client side
>>>>>>> (with hibernate/jpox generated JDBC on the wire) CDO is is used
>>>>>>> on the client side for EMF model integration and on the server
>>>>>>> side for the storage integration (O/R mapping, OODB integration).
>>>>>>> CDO uses an own (Net4j based) wire protocol which is tailored to
>>>>>>> transactional semantics in the context of objects (not SQL).
>>>>>>> Since CDO clients rely on a dedicated CDO server they can offer
>>>>>>> some additional functions not available with Teneo, like
>>>>>>> automatic model update on all clients if one client commits a
>>>>>>> transaction (distributed shared model semantics).
>>>>>>
>>>>>> So Teneo is more of a client side persistence alternative and CDO
>>>>>> is a model repository server!
>>>>> Right.
>>>>>
>>>>>> Is CDO the only Eclipse Modeling project making this claim?
>>>>> AFAIK, yes.
>>>>>
>>>>>> Side question:
>>>>>> Since models are persisted to a repository server (a rdbms) has
>>>>>> anyone experimented with plugging in BIRT to this rdbms so end
>>>>>> user's could be given reporting support? In other words are the
>>>>>> final relational schemas human readable and understandable enough
>>>>>> for report designers to work with?
>>>>> Interesting question because I just discussed that topic with a
>>>>> friend of mine. I cc'ed Philipp for this purpose.
>>>>>
>>>>> 1) A CDO server mainly consists of three parts/layers: A protocol
>>>>> peer (Net4j based), a model repository framework (storage agnostic)
>>>>> and a storage framework. It depends on the storage implementation
>>>>> (IStore) how the model data is actually persisted to a storage
>>>>> backend. This *can* be an RDBMS via plain JDBC (default) but a user
>>>>> has also implemented an Objectivity store (OODBMS) and plans to
>>>>> implement a Hibernate based store.
>>>>>
>>>>> 2) In case the default JDBC store is used with a repository I'd say
>>>>> yes, the generated schema is human readable and understandable
>>>>> enough for report designers to work with but that is my own
>>>>> opinion. Currently CDO always uses its own generated primary keys
>>>>> (long id values) and references are mostly always stored in a fixed
>>>>> format that allows for transparent versioning.
>>>>>
>>>>> 3) I'd prefer to see a model/BIRT integration at the model side
>>>>> (CDO client) rather than at the DB side (one of several possible
>>>>> CDO storage backends and highly implementation dependent). I'm
>>>>> neither a BIRT nor an ODA expert but is it not possible to use an
>>>>> EMF ResourceSet, a Resource or an EObject as an ODA data source?
>>>>> That'd be much closer to the semantics of the model than querying
>>>>> the mapped DB.
>>>>>
>>>>>>>> Does CDO use the EMF transaction framework?
>>>>>>> No, CDO acts directly on the model level. EMF Transaction acts on
>>>>>>> the higher edit/command framework level which, in my opinion, has
>>>>>>> at least two disadvantages:
>>>>>>> 1) Not all clients want to use a command stack to interact with
>>>>>>> models (especially non-UI clients like batch clients). With CDO
>>>>>>> these clients can remain unchanged (are not forced to use a
>>>>>>> command stack) and since CDO transactions are transparent to the
>>>>>>> command stack UI clients can be used, too.
>>>>>>> 2) Worse, command stack based transactions rely on the
>>>>>>> cooperation of *all* clients of a model. If only one client
>>>>>>> doesn't use a command stack or uses a non-transactional command
>>>>>>> stack all transactions might become corrupt! Since CDO integrates
>>>>>>> with EMF models at their core none of these restrictions apply.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> When you say CDO works at the model level, does that mean entire
>>>>>> models are moved from client to server?
>>>>> I'm not sure if I correctly understand the intend of your question.
>>>>> The scope of a CDO transaction is always an EMF ResourceSet (no
>>>>> command stack needed). This ResourceSet can contain multiple CDO
>>>>> Resources (and possibly other types of Resources). At the time of
>>>>> committing the transaction no CDO Resource is allowed to contain
>>>>> references to non-CDO Resources. In other words a CDO repository is
>>>>> always guaranteed to contain a consistent state of an object graph
>>>>> that can be partitioned into CDO Resources. Looking from the other
>>>>> side a CDO-prepared ResourceSet acts like a partial but
>>>>> self-populating view onto the whole object graph of the repository.
>>>>>
>>>>> So in this sense, yes, entire models are (initially) moved from
>>>>> client to server. Once a model is committed into the repository
>>>>> subsequent reads and writes (commits) act at least at an object
>>>>> granularity. A recent effort of a user added support for sending
>>>>> only deltas for changed objects to the server, see
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=201266 .
>>>>>
>>>>> I guess I should stop saying "at the model level" because the word
>>>>> "model" is one of the only four terms we have available in modern
>>>>> software engineering, ambiguities granted ;-)
>>>>> The reason I used it is the following. When you kick the EMF
>>>>> generator for an ecore model it typically produces 3 plugins:
>>>>> 1) model plugin
>>>>> 2) edit plugin (command framework integration)
>>>>> 3) editor plugin (Eclipse UI)
>>>>>
>>>>> When I say "at the model level" I really mean that only 1) is
>>>>> needed for integration. AFAIK EMF Transaction needs 1) plus 2) for
>>>>> its integration because it intercepts commands of the command
>>>>> framework.
>>>>>
>>>>>> Is there facilities for plugging in Model to Model translation
>>>>>> facilities so that one could sync heterogeneous models to one
>>>>>> repository?
>>>>> I'm lost. Could you please elaborate on "Model to Model translation
>>>>> facilities" and "heterogeneous models"?
>>>>>
>>>>>> My mind has not been expanded as of yet to all the possibilities
>>>>>> with CDO, but I am wondering if CDO may be able to offer an
>>>>>> infrastructure for models what XProc
>>>>>> http://www.w3.org/TR/2007/WD-xproc-20071129/
>>>>>> is offering for XML docs?
>>>>> I'm really not familiar with XProc. The abstract says "[...] a
>>>>> language for describing operations to be performed on XML
>>>>> documents". From this I'd say, no, CDO focusses more on the static
>>>>> aspects of a model than on the possible operations that could
>>>>> modeify a model over time. May be you can list some specific
>>>>> details of the XProc spec (which I've not read as a whole) that
>>>>> you're interested in?
>>>>>
>>>>>>>> [stuff deleted]
>>>>>>> Good point! Would you be willing to contribute such a connector?
>>>>>>> If so, please open an enhancement request in Bugzilla and attach
>>>>>>> a patch (since Net4j is already extensible in the dimension of
>>>>>>> transports a patch might not be needed and you can simply attach
>>>>>>> the extension bundle project). I'd be happy to maintain the code
>>>>>>> after ;-)
>>>>>>
>>>>>> Have several activities scheduled right now, but I am interested
>>>>>> enough to contribute with either a comm port transport or a
>>>>>> Bluetooth one. The problem I for see with either one of these
>>>>>> solutions is that I expect there will be OS library dependencies
>>>>>> that will have to be bundled with the code. This is something I
>>>>>> have not done before.
>>>>> OSGi should be prepared for this ;-)
>>>>>>
>>>>>> Will start looking into this next month.
>>>>> That'd be great! Please tell me when you need my assistance...
>>>>>
>>>>> Regards,
>>>>> Eike Stepper
>>>>> ----
>>>>> http://wiki.eclipse.org/CDO
>>>>> http://wiki.eclipse.org/Net4j
>>>>>
>>>>>
>>>>>>>> That said, a connector implementation for comm ports should be
>>>>>>>> easy, as easy as the usage of comm ports is in Java (which I
>>>>>>>> have no idea of).
>>>>>>>> I have not done this myself, so I don't know how easy the lower
>>>>>>>> layer will be. Would probably do the http://www.rxtx.org/
>>>>>>>> versus Sun's impl.
>>>>>>>>
>>>>>>>> As
>>>>>>>>> the docs of IConnector state you'll have to subclass Connector
>>>>>>>>> (
>>>>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j/src/org/eclipse /internal/net4j/Connector.java?root=Modeling_Project&vie w=log)
>>>>>>>>> . I suggest to look at the implementation of TCPConnector (
>>>>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j.tcp/src/org/ecl ipse/net4j/internal/tcp/TCPConnector.java?root=Modeling_Proj ect&view=log
>>>>>>>>> ).
>>>>>>>>>
>>>>>>>>> As I said above, if you succeed in providing a comm port
>>>>>>>>> implementation of IConnector (and the supporting factories)
>>>>>>>>> you'll get EMF integration for free ;-)
>>>>>>>>
>>>>>>>> Sounds good, but will I need to also install a database to get
>>>>>>>> EMF integration?
>>>>>>> Good question! According to the 'normal' setup of a CDO
>>>>>>> deployment, yes. But CDO should be open and layered enuogh to
>>>>>>> find a solution that uses only the model integration parts. I
>>>>>>> haven't thought about such usage so far.
>>>>>>
>>>>>>
>>>>>> kind regards,
>>>>>> John Conlon
>>>>
>>>>
>>
>>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #104978 is a reply to message #104775] |
Wed, 19 December 2007 16:29 |
| Eclipse User |
|
|
|
Originally posted by: jconlon.apache.org
Eike Stepper wrote:
> John E. Conlon schrieb:
>>> [stuff deleted]
>>>> How does CDO compare to Teneo?
>>> I'd say the main difference is the deployment strategy. While Teneo
>>> (I'm not a Teneo expert!) is mainly used on the client side (with
>>> hibernate/jpox generated JDBC on the wire) CDO is is used on the
>>> client side for EMF model integration and on the server side for the
>>> storage integration (O/R mapping, OODB integration). CDO uses an own
>>> (Net4j based) wire protocol which is tailored to transactional
>>> semantics in the context of objects (not SQL). Since CDO clients rely
>>> on a dedicated CDO server they can offer some additional functions
>>> not available with Teneo, like automatic model update on all clients
>>> if one client commits a transaction (distributed shared model
>>> semantics).
>>
>> So Teneo is more of a client side persistence alternative and CDO is a
>> model repository server!
> Right.
>
>> Is CDO the only Eclipse Modeling project making this claim?
> AFAIK, yes.
That makes the choice clear.
>
>> Side question:
>> Since models are persisted to a repository server (a rdbms) has anyone
>> experimented with plugging in BIRT to this rdbms so end user's could
>> be given reporting support? In other words are the final relational
>> schemas human readable and understandable enough for report designers
>> to work with?
> Interesting question because I just discussed that topic with a friend
> of mine. I cc'ed Philipp for this purpose.
>
> 1) A CDO server mainly consists of three parts/layers: A protocol peer
> (Net4j based), a model repository framework (storage agnostic) and a
> storage framework. It depends on the storage implementation (IStore) how
> the model data is actually persisted to a storage backend. This *can* be
> an RDBMS via plain JDBC (default) but a user has also implemented an
> Objectivity store (OODBMS) and plans to implement a Hibernate based store.
>
> 2) In case the default JDBC store is used with a repository I'd say yes,
> the generated schema is human readable and understandable enough for
> report designers to work with but that is my own opinion. Currently CDO
> always uses its own generated primary keys (long id values) and
> references are mostly always stored in a fixed format that allows for
> transparent versioning.
>
> 3) I'd prefer to see a model/BIRT integration at the model side (CDO
> client) rather than at the DB side (one of several possible CDO storage
> backends and highly implementation dependent). I'm neither a BIRT nor an
> ODA expert but is it not possible to use an EMF ResourceSet, a Resource
> or an EObject as an ODA data source? That'd be much closer to the
> semantics of the model than querying the mapped DB.
Glad to here you agree with an approach now ongoing: see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=132958
Jeff Ramsdale is heading this effort.
See also topic 'Help with Ecore ODA Driver - Need MindMap data' in the
eclipse.dtp newsgroup.
>
>>>> Does CDO use the EMF transaction framework?
>>> No, CDO acts directly on the model level. EMF Transaction acts on the
>>> higher edit/command framework level which, in my opinion, has at
>>> least two disadvantages:
>>> 1) Not all clients want to use a command stack to interact with
>>> models (especially non-UI clients like batch clients). With CDO these
>>> clients can remain unchanged (are not forced to use a command stack)
>>> and since CDO transactions are transparent to the command stack UI
>>> clients can be used, too.
>>> 2) Worse, command stack based transactions rely on the cooperation of
>>> *all* clients of a model. If only one client doesn't use a command
>>> stack or uses a non-transactional command stack all transactions
>>> might become corrupt! Since CDO integrates with EMF models at their
>>> core none of these restrictions apply.
>>>
>>
>>
>> When you say CDO works at the model level, does that mean entire
>> models are moved from client to server?
> I'm not sure if I correctly understand the intend of your question. The
> scope of a CDO transaction is always an EMF ResourceSet (no command
> stack needed). This ResourceSet can contain multiple CDO Resources (and
> possibly other types of Resources). At the time of committing the
> transaction no CDO Resource is allowed to contain references to non-CDO
> Resources. In other words a CDO repository is always guaranteed to
> contain a consistent state of an object graph that can be partitioned
> into CDO Resources. Looking from the other side a CDO-prepared
> ResourceSet acts like a partial but self-populating view onto the whole
> object graph of the repository.
>
> So in this sense, yes, entire models are (initially) moved from client
> to server. Once a model is committed into the repository subsequent
> reads and writes (commits) act at least at an object granularity. A
> recent effort of a user added support for sending only deltas for
> changed objects to the server, see
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=201266 .
>
> I guess I should stop saying "at the model level" because the word
> "model" is one of the only four terms we have available in modern
> software engineering, ambiguities granted ;-)
> The reason I used it is the following. When you kick the EMF generator
> for an ecore model it typically produces 3 plugins:
> 1) model plugin
> 2) edit plugin (command framework integration)
> 3) editor plugin (Eclipse UI)
>
> When I say "at the model level" I really mean that only 1) is needed for
> integration. AFAIK EMF Transaction needs 1) plus 2) for its integration
> because it intercepts commands of the command framework.
>
Thanks that answered my question.
>> Is there facilities for plugging in Model to Model translation
>> facilities so that one could sync heterogeneous models to one
>> repository?
> I'm lost. Could you please elaborate on "Model to Model translation
> facilities" and "heterogeneous models"?
Caveat: Based on no experience with CDO/Net4J ...
I was referring to the M2M work done as part of:
http://www.eclipse.org/m2m/
If a specific model in CDO is persisted in the model repository and this
model can be synchronized to one or more client views of the model, I
was speculating that a CDO client view could be created on one side of a
M2M transformation service and on the other side of the M2M service a
different or heterogeneous model could be attached. Then as the
heterogeneous model changed the transformer would map it to changes on
the CDO client side of the transformer.
>> My mind has not been expanded as of yet to all the possibilities with
>> CDO, but I am wondering if CDO may be able to offer an infrastructure
>> for models what XProc http://www.w3.org/TR/2007/WD-xproc-20071129/
>> is offering for XML docs?
> I'm really not familiar with XProc. The abstract says "[...] a language
> for describing operations to be performed on XML documents". From this
> I'd say, no, CDO focusses more on the static aspects of a model than on
> the possible operations that could modeify a model over time. May be you
> can list some specific details of the XProc spec (which I've not read as
> a whole) that you're interested in?
This question was expanding on the previous one related to M2M. It was
referring to XProc merely as an analogy not so much for a language but
for a pipeline infrastructure that I was thinking might already be
something implemented, designed or thought about for the CDO/Net4J
client server model repo infrastructure.
The idea is CDO as pipeline infrastructure where Model A (Ma) could be
persisted in the repository but then have instances of another Model B
(Mb) part of the synchronization. Where <-> represents the linkage.
Ma Source as a CDO Client <->
Ma Repo as CDO server <->
Ma Target Client <->
M2M transformer<->
Mb Target as a CDO Client
>>>> [stuff deleted]
>>> Good point! Would you be willing to contribute such a connector? If
>>> so, please open an enhancement request in Bugzilla and attach a patch
>>> (since Net4j is already extensible in the dimension of transports a
>>> patch might not be needed and you can simply attach the extension
>>> bundle project). I'd be happy to maintain the code after ;-)
>>
>> Have several activities scheduled right now, but I am interested
>> enough to contribute with either a comm port transport or a Bluetooth
>> one. The problem I for see with either one of these solutions is that
>> I expect there will be OS library dependencies that will have to be
>> bundled with the code. This is something I have not done before.
> OSGi should be prepared for this ;-)
>>
>> Will start looking into this next month.
> That'd be great! Please tell me when you need my assistance...
Will do.
kind regards,
John Conlon
jconlon@verticon.com
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #104981 is a reply to message #104801] |
Wed, 19 December 2007 16:32 |
| Eclipse User |
|
|
|
Originally posted by: jconlon.apache.org
Eike Stepper wrote:
> Hi Martin,
>
> comments below...
>
>
> Martin Taal schrieb:
>> Hi Eike, John,
>> Just to add my thoughts about Teneo :-).
>> Teneo is very much focused on being a persistence solution for
>> persisting (complex) models to a relational store. This focus means
>> that Teneo has broad support for most complex modeling constructs (for
>> example feature maps, xml schema anytype, mixed type, etc.) and
>> support for jpa annotations in the model. On the other hand this focus
>> also means that Teneo does not include specific client-server
>> functionality, this is outside of the scope of Teneo.
>> So I would not say that Teneo is a client side solution (I use Teneo
>> server side in a web app). Teneo can also be used server side (in a
>> rcp app) but then you need to implement your own client-server layer
>> (using other tools).
> These client/server things are so ambiguous like the model/meta model
> things depending on the start point ;-)
> But with your clarification the main difference between CDO and Teneo
> should be clear now.
Yes it is, thank you Martin and Eike for clarifying.
kind regards,
John Conlon
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #104992 is a reply to message #104975] |
Thu, 20 December 2007 08:01 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Martin Taal schrieb:
> Hi Eike,
> I pasted your comments back up to make the post readable:
Hmm, I found it more readable before ;-)
> ES>> CDO (at client side) converts in both directions between an Ecore
> model and its internal representation of this model. I think this is
> the relation you mean. At CDO's server side there's usually no such
> conversion because there's simply no EMF (required).
> BUT: since the Ecore XMI string can be retrieved from the repository
> via CDOPackage I think a Teneo based IStore implementation could add
> EMF to its dependencies, deserialize the original Ecore model and
> apply the same E<->CDO conversion as the CDO client.
>
> MT>> Yes that would surely work afaics. The ecore model is also
> important for Teneo because it can contain annotations which influence
> the persistence strategy.
Annotations in the model have been the original trigger to make the
model string available on the server.
> ES>>
> To sum up:
> - It seems as we we (out products) could both profit from working
> together.
> - There could be a Teneo with CDO under the runtime hood [A]
> - There could be a CDO server with a Teneo-based IStore [B]
> - We are willing to spend effort for this ;-)
>
> MT>>
> I fully agree, hopefully the teneo based istore would offer the same
> api as you currently use within cdo server so that the changes in the
> cdo server are not that large.
The goal is to not change the repository framework but just plug in the
new IStore implementation. Since we have already two implementations
with quite different backends (OO and relational) there is a chance that
we catch the goal.
> I am willing to spend the effort in doing this (but not before the new
> year :-).
That's great!
> ES>>
> If you agree up to here we should discuss how we start and who should
> do what. I had a similar integration story with Net4j <-> ECF and I
> learned that it is often easier to *use* foreign API than to *extend*
> it. That also results in the author of the integration being the
> maintainer.
>
> For [A] that would mean that primarily you would extend your runtime
> framework by using CDO API (with my help of course).
> For [B] that would mean that primarily I would extend my storage
> framework by implementing the above conversions at server side and
> then using Teneo API (with your help).
>
> MT>> No problem we can see how we can divide the work. I am willing to
> spend time on this and also maintain the runtime layer afterwards. I
> can start looking at CDO and see how the persistence works currently
> (using IStore). Can I download/test cdo separately without net4j?
No, not if you want to compile CDO without errors. Please use "All.psf"
from http://wiki.eclipse.org/CDO_Project_Resources#Sources
> Do you have some hyperlinks with the docs?
Hehe, after years without automatic signature I recently installed a
Thunderbird plugin to get this dignified signature:
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
There's some (hopefully) useful information in the CDO wiki ;-)
That said, it's not yet fully complete so I guess we will have to
discuss after you got a general overview.
> ES>>
> I guess that on the way we'll discover some more challenges ;-)
> MT>>
> For sure, it makes all this 'unpaid' work interesting and worthwhile
> doesn't it :-).
Really addictive!
> One last question for my interest, does the non-emf cdo server side
> support the emf featuremap and other emf/xml schema specialities such
> as mixed or anytype?
I'm not an expert myself in neither feature maps nor xsd details ;-(
BUT I believe feature maps have already been reported to be used.
More important, CDO/EMF integration is based on the EStore interface
which I'd expect to support all EObject functionality including feature
maps.
For xml schema specialities such as mixed or anytype I'm not sure. Do
they rely on EAnnotations? The only thing I can say is that I never
thought about xsd in the context of CDO.
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO ;-)
http://wiki.eclipse.org/Net4j
>
> gr. Martin
>
> Eike Stepper wrote:
>> Martin Taal schrieb:
>>> Hi Eike,
>>> Just to continue on your last points (otherwise the post becomes
>>> unreadable to me):
>>> - Teneos main purpose (with respect to Hibernate) is the integration
>>> of EMF Resources and EObjects with a Hibernate mapped database. In
>>> other words you directly map EMF concepts to/from Hibernate concepts
>>> in one deployment node (client or server).
>>> MT>> Almost :-), Teneo consists of two main parts:
>>> 1) Mapping functionality: maps a model to a relational schema (in
>>> fact maps a model to a java persistence api annotated model which is
>>> then translated to a hibernate mapping). The user can override
>>> standard mapping behavior by adding jpa annotations in the model.
>>> 2) At runtime provide easy integration between EMF and hibernate (or
>>> jpox). This part is mainly to support automatic mapping (so using
>>> the above functionality 1) when initializing and support emf
>>> specifics such as featuremaps, elists and emf resources.
>> That makes sense ;-)
>>
>>> Currently Teneo has 2 runtime layers one for jpox and one for
>>> hibernate. It would be interesting to add other runtime layers.
>> Ok, there I can see a chance for CDO. It would be completely covered
>> by your runtime framework, right?
>>
>>> Btw, I use the mapping functionality of Teneo also outside of EMF: I
>>> map the model using Teneo and then at runtime I have non-emf objects.
>>>
>>> - CDO wishes Hibernate mapping at its server side
>>> - At the server side of CDO there are no EMF concepts. The CDO
>>> (network) protocol doesn't deal with EMF concepts. The state of
>>> EObjects is translated into non-EMF data structures at client side.
>>> MT>> But still because you currently also create a relational
>>> schema, I assume that the server also has knowledge of the ecore model.
>> Right, at the client there are bijective conversions between:
>> EPackage <-> CDOPackage
>> EClass <-> CDOClass
>> EStructuralFeature <-> CDOFeature
>>
>> So I'd say a simplified version of the Ecore model arrives at the
>> server and is usually stored in an IStore of the CDO storage
>> framework (can be RDB). BTW. it's even possible to retrieve the XMI
>> string of the original Ecore model from a CDOPackage.
>>
>>> I can imagine also that your non-emf data structure refer to this
>>> model?
>> Right, there's a method CDORevision.getCDOClass().
>>
>>> - The non-EMF data structures that represent EObject state at the
>>> server can't easily mapped by Teneo (since Teneo deals with EMF
>>> concepts).
>>> MT>> Not sure if this is an obstacle. I assume that also for the CDO
>>> non-emf datastructures there is a relation to the application model
>>> expressed in ecore. Teneo also uses the ecore model as its basis for
>>> mapping to hibernate. So as long as there is a relation between your
>>> non-emf datastructure and the ecore model then a runtime layer which
>>> uses the Teneo mapping logic should be pretty doable.
>> That's great to hear. But we have to double check:
>> CDO (at client side) converts in both directions between an Ecore
>> model and its internal representation of this model. I think this is
>> the relation you mean. At CDO's server side there's usually no such
>> conversion because there's simply no EMF (required).
>> BUT: since the Ecore XMI string can be retrieved from the repository
>> via CDOPackage I think a Teneo based IStore implementation could add
>> EMF to its dependencies, deserialize the original Ecore model and
>> apply the same E<->CDO conversion as the CDO client.
>>
>> That sounds reasonable to me. Agreed so far?
>> I'd have to factor out the conversion mechanism into a separate
>> plugin...
>>
>>> For example next to Teneo I am working on generating seam web
>>> applications from ecore models. To support the persistence side I
>>> use Teneo for the mapping and as runtime I have a dynamic-emf-like
>>> object (basically a type-safe hashmap). The runtime layer is about
>>> 15 classes.
>> That sounds similar to the CDO server although it has one or two more
>> classes ;-)
>>
>> To sum up:
>> - It seems as we we (out products) could both profit from working
>> together.
>> - There could be a Teneo with CDO under the runtime hood [A]
>> - There could be a CDO server with a Teneo-based IStore [B]
>> - We are willing to spend effort for this ;-)
>>
>> If you agree up to here we should discuss how we start and who should
>> do what. I had a similar integration story with Net4j <-> ECF and I
>> learned that it is often easier to *use* foreign API than to *extend*
>> it. That also results in the author of the integration being the
>> maintainer.
>>
>> For [A] that would mean that primarily you would extend your runtime
>> framework by using CDO API (with my help of course).
>> For [B] that would mean that primarily I would extend my storage
>> framework by implementing the above conversions at server side and
>> then using Teneo API (with your help).
>>
>> I guess that on the way we'll discover some more challenges ;-)
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>>>
>>> gr. Martin
>>>
>>> Eike Stepper wrote:
>>>> Hi Martin,
>>>>
>>>> comments below...
>>>>
>>>>
>>>> Martin Taal schrieb:
>>>>> Hi Eike, John,
>>>>> Just to add my thoughts about Teneo :-).
>>>>> Teneo is very much focused on being a persistence solution for
>>>>> persisting (complex) models to a relational store. This focus
>>>>> means that Teneo has broad support for most complex modeling
>>>>> constructs (for example feature maps, xml schema anytype, mixed
>>>>> type, etc.) and support for jpa annotations in the model. On the
>>>>> other hand this focus also means that Teneo does not include
>>>>> specific client-server functionality, this is outside of the scope
>>>>> of Teneo.
>>>>> So I would not say that Teneo is a client side solution (I use
>>>>> Teneo server side in a web app). Teneo can also be used server
>>>>> side (in a rcp app) but then you need to implement your own
>>>>> client-server layer (using other tools).
>>>> These client/server things are so ambiguous like the model/meta
>>>> model things depending on the start point ;-)
>>>> But with your clarification the main difference between CDO and
>>>> Teneo should be clear now.
>>>>
>>>>> Btw, it would be interesting to integrate the client-server
>>>>> capabilities of CDO/net4j with the mapping capabilities of Teneo.
>>>>> I think this can be a powerfull combination...
>>>> That'd be of course an interesting effort. What do you think could
>>>> be the result of such an effort?
>>>>
>>>> Simon (cc'ed) and I often discussed this topic and I seem to
>>>> remember that we (you and I) also spoke about such integration.
>>>> The result that I'd wish from such an integration would clearly be
>>>> a CDO storage framework implementation that uses Hibernate as O/R
>>>> mapper. I fear that your general experience with Hibernate can be
>>>> more helpful than your actual product Teneo. But I'd be glad to be
>>>> proven wrong here. The following is the reason (correct me if I'm
>>>> wrong):
>>>> - Teneos main purpose (with respect to Hibernate) is the
>>>> integration of EMF Resources and EObjects with a Hibernate mapped
>>>> database. In other words you directly map EMF concepts to/from
>>>> Hibernate concepts in one deployment node (client or server).
>>>> - CDO wishes Hibernate mapping at its server side
>>>> - At the server side of CDO there are no EMF concepts. The CDO
>>>> (network) protocol doesn't deal with EMF concepts. The state of
>>>> EObjects is translated into non-EMF data structures at client side.
>>>> - The non-EMF data structures that represent EObject state at the
>>>> server can't easily mapped by Teneo (since Teneo deals with EMF
>>>> concepts).
>>>>
>>>> Would you agree?
>>>>
>>>> Regards,
>>>> Eike Stepper
>>>> ----
>>>> http://wiki.eclipse.org/CDO
>>>> http://wiki.eclipse.org/Net4j
>>>>
>>>>
>>>>>
>>>>> gr. Martin
>>>>>
>>>>> Eike Stepper wrote:
>>>>>> John E. Conlon schrieb:
>>>>>>>> [stuff deleted]
>>>>>>>>> How does CDO compare to Teneo?
>>>>>>>> I'd say the main difference is the deployment strategy. While
>>>>>>>> Teneo (I'm not a Teneo expert!) is mainly used on the client
>>>>>>>> side (with hibernate/jpox generated JDBC on the wire) CDO is is
>>>>>>>> used on the client side for EMF model integration and on the
>>>>>>>> server side for the storage integration (O/R mapping, OODB
>>>>>>>> integration). CDO uses an own (Net4j based) wire protocol which
>>>>>>>> is tailored to transactional semantics in the context of
>>>>>>>> objects (not SQL). Since CDO clients rely on a dedicated CDO
>>>>>>>> server they can offer some additional functions not available
>>>>>>>> with Teneo, like automatic model update on all clients if one
>>>>>>>> client commits a transaction (distributed shared model semantics).
>>>>>>>
>>>>>>> So Teneo is more of a client side persistence alternative and
>>>>>>> CDO is a model repository server!
>>>>>> Right.
>>>>>>
>>>>>>> Is CDO the only Eclipse Modeling project making this claim?
>>>>>> AFAIK, yes.
>>>>>>
>>>>>>> Side question:
>>>>>>> Since models are persisted to a repository server (a rdbms) has
>>>>>>> anyone experimented with plugging in BIRT to this rdbms so end
>>>>>>> user's could be given reporting support? In other words are the
>>>>>>> final relational schemas human readable and understandable
>>>>>>> enough for report designers to work with?
>>>>>> Interesting question because I just discussed that topic with a
>>>>>> friend of mine. I cc'ed Philipp for this purpose.
>>>>>>
>>>>>> 1) A CDO server mainly consists of three parts/layers: A protocol
>>>>>> peer (Net4j based), a model repository framework (storage
>>>>>> agnostic) and a storage framework. It depends on the storage
>>>>>> implementation (IStore) how the model data is actually persisted
>>>>>> to a storage backend. This *can* be an RDBMS via plain JDBC
>>>>>> (default) but a user has also implemented an Objectivity store
>>>>>> (OODBMS) and plans to implement a Hibernate based store.
>>>>>>
>>>>>> 2) In case the default JDBC store is used with a repository I'd
>>>>>> say yes, the generated schema is human readable and
>>>>>> understandable enough for report designers to work with but that
>>>>>> is my own opinion. Currently CDO always uses its own generated
>>>>>> primary keys (long id values) and references are mostly always
>>>>>> stored in a fixed format that allows for transparent versioning.
>>>>>>
>>>>>> 3) I'd prefer to see a model/BIRT integration at the model side
>>>>>> (CDO client) rather than at the DB side (one of several possible
>>>>>> CDO storage backends and highly implementation dependent). I'm
>>>>>> neither a BIRT nor an ODA expert but is it not possible to use an
>>>>>> EMF ResourceSet, a Resource or an EObject as an ODA data source?
>>>>>> That'd be much closer to the semantics of the model than querying
>>>>>> the mapped DB.
>>>>>>
>>>>>>>>> Does CDO use the EMF transaction framework?
>>>>>>>> No, CDO acts directly on the model level. EMF Transaction acts
>>>>>>>> on the higher edit/command framework level which, in my
>>>>>>>> opinion, has at least two disadvantages:
>>>>>>>> 1) Not all clients want to use a command stack to interact with
>>>>>>>> models (especially non-UI clients like batch clients). With CDO
>>>>>>>> these clients can remain unchanged (are not forced to use a
>>>>>>>> command stack) and since CDO transactions are transparent to
>>>>>>>> the command stack UI clients can be used, too.
>>>>>>>> 2) Worse, command stack based transactions rely on the
>>>>>>>> cooperation of *all* clients of a model. If only one client
>>>>>>>> doesn't use a command stack or uses a non-transactional command
>>>>>>>> stack all transactions might become corrupt! Since CDO
>>>>>>>> integrates with EMF models at their core none of these
>>>>>>>> restrictions apply.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> When you say CDO works at the model level, does that mean entire
>>>>>>> models are moved from client to server?
>>>>>> I'm not sure if I correctly understand the intend of your
>>>>>> question. The scope of a CDO transaction is always an EMF
>>>>>> ResourceSet (no command stack needed). This ResourceSet can
>>>>>> contain multiple CDO Resources (and possibly other types of
>>>>>> Resources). At the time of committing the transaction no CDO
>>>>>> Resource is allowed to contain references to non-CDO Resources.
>>>>>> In other words a CDO repository is always guaranteed to contain a
>>>>>> consistent state of an object graph that can be partitioned into
>>>>>> CDO Resources. Looking from the other side a CDO-prepared
>>>>>> ResourceSet acts like a partial but self-populating view onto the
>>>>>> whole object graph of the repository.
>>>>>>
>>>>>> So in this sense, yes, entire models are (initially) moved from
>>>>>> client to server. Once a model is committed into the repository
>>>>>> subsequent reads and writes (commits) act at least at an object
>>>>>> granularity. A recent effort of a user added support for sending
>>>>>> only deltas for changed objects to the server, see
>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=201266 .
>>>>>>
>>>>>> I guess I should stop saying "at the model level" because the
>>>>>> word "model" is one of the only four terms we have available in
>>>>>> modern software engineering, ambiguities granted ;-)
>>>>>> The reason I used it is the following. When you kick the EMF
>>>>>> generator for an ecore model it typically produces 3 plugins:
>>>>>> 1) model plugin
>>>>>> 2) edit plugin (command framework integration)
>>>>>> 3) editor plugin (Eclipse UI)
>>>>>>
>>>>>> When I say "at the model level" I really mean that only 1) is
>>>>>> needed for integration. AFAIK EMF Transaction needs 1) plus 2)
>>>>>> for its integration because it intercepts commands of the command
>>>>>> framework.
>>>>>>
>>>>>>> Is there facilities for plugging in Model to Model translation
>>>>>>> facilities so that one could sync heterogeneous models to one
>>>>>>> repository?
>>>>>> I'm lost. Could you please elaborate on "Model to Model
>>>>>> translation facilities" and "heterogeneous models"?
>>>>>>
>>>>>>> My mind has not been expanded as of yet to all the possibilities
>>>>>>> with CDO, but I am wondering if CDO may be able to offer an
>>>>>>> infrastructure for models what XProc
>>>>>>> http://www.w3.org/TR/2007/WD-xproc-20071129/
>>>>>>> is offering for XML docs?
>>>>>> I'm really not familiar with XProc. The abstract says "[...] a
>>>>>> language for describing operations to be performed on XML
>>>>>> documents". From this I'd say, no, CDO focusses more on the
>>>>>> static aspects of a model than on the possible operations that
>>>>>> could modeify a model over time. May be you can list some
>>>>>> specific details of the XProc spec (which I've not read as a
>>>>>> whole) that you're interested in?
>>>>>>
>>>>>>>>> [stuff deleted]
>>>>>>>> Good point! Would you be willing to contribute such a
>>>>>>>> connector? If so, please open an enhancement request in
>>>>>>>> Bugzilla and attach a patch (since Net4j is already extensible
>>>>>>>> in the dimension of transports a patch might not be needed and
>>>>>>>> you can simply attach the extension bundle project). I'd be
>>>>>>>> happy to maintain the code after ;-)
>>>>>>>
>>>>>>> Have several activities scheduled right now, but I am interested
>>>>>>> enough to contribute with either a comm port transport or a
>>>>>>> Bluetooth one. The problem I for see with either one of these
>>>>>>> solutions is that I expect there will be OS library dependencies
>>>>>>> that will have to be bundled with the code. This is something I
>>>>>>> have not done before.
>>>>>> OSGi should be prepared for this ;-)
>>>>>>>
>>>>>>> Will start looking into this next month.
>>>>>> That'd be great! Please tell me when you need my assistance...
>>>>>>
>>>>>> Regards,
>>>>>> Eike Stepper
>>>>>> ----
>>>>>> http://wiki.eclipse.org/CDO
>>>>>> http://wiki.eclipse.org/Net4j
>>>>>>
>>>>>>
>>>>>>>>> That said, a connector implementation for comm ports should be
>>>>>>>>> easy, as easy as the usage of comm ports is in Java (which I
>>>>>>>>> have no idea of).
>>>>>>>>> I have not done this myself, so I don't know how easy the
>>>>>>>>> lower layer will be. Would probably do the
>>>>>>>>> http://www.rxtx.org/ versus Sun's impl.
>>>>>>>>>
>>>>>>>>> As
>>>>>>>>>> the docs of IConnector state you'll have to subclass
>>>>>>>>>> Connector (
>>>>>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j/src/org/eclipse /internal/net4j/Connector.java?root=Modeling_Project&vie w=log)
>>>>>>>>>> . I suggest to look at the implementation of TCPConnector (
>>>>>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j.tcp/src/org/ecl ipse/net4j/internal/tcp/TCPConnector.java?root=Modeling_Proj ect&view=log
>>>>>>>>>> ).
>>>>>>>>>>
>>>>>>>>>> As I said above, if you succeed in providing a comm port
>>>>>>>>>> implementation of IConnector (and the supporting factories)
>>>>>>>>>> you'll get EMF integration for free ;-)
>>>>>>>>>
>>>>>>>>> Sounds good, but will I need to also install a database to get
>>>>>>>>> EMF integration?
>>>>>>>> Good question! According to the 'normal' setup of a CDO
>>>>>>>> deployment, yes. But CDO should be open and layered enuogh to
>>>>>>>> find a solution that uses only the model integration parts. I
>>>>>>>> haven't thought about such usage so far.
>>>>>>>
>>>>>>>
>>>>>>> kind regards,
>>>>>>> John Conlon
>>>>>
>>>>>
>>>
>>>
>
>
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #104995 is a reply to message #104978] |
Thu, 20 December 2007 11:26 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
[stuff deleted]
>>> Is there facilities for plugging in Model to Model translation
>>> facilities so that one could sync heterogeneous models to one
>>> repository?
>> I'm lost. Could you please elaborate on "Model to Model translation
>> facilities" and "heterogeneous models"?
>
> Caveat: Based on no experience with CDO/Net4J ...
>
> I was referring to the M2M work done as part of:
> http://www.eclipse.org/m2m/
>
> If a specific model in CDO is persisted in the model repository and
> this model can be synchronized to one or more client views of the
> model, I was speculating that a CDO client view could be created on
> one side of a M2M transformation service and on the other side of the
> M2M service a different or heterogeneous model could be attached.
> Then as the heterogeneous model changed the transformer would map it
> to changes on the CDO client side of the transformer.
>
>
>>> My mind has not been expanded as of yet to all the possibilities
>>> with CDO, but I am wondering if CDO may be able to offer an
>>> infrastructure for models what XProc
>>> http://www.w3.org/TR/2007/WD-xproc-20071129/
>>> is offering for XML docs?
>> I'm really not familiar with XProc. The abstract says "[...] a
>> language for describing operations to be performed on XML documents".
>> From this I'd say, no, CDO focusses more on the static aspects of a
>> model than on the possible operations that could modeify a model over
>> time. May be you can list some specific details of the XProc spec
>> (which I've not read as a whole) that you're interested in?
>
> This question was expanding on the previous one related to M2M. It was
> referring to XProc merely as an analogy not so much for a language but
> for a pipeline infrastructure that I was thinking might already be
> something implemented, designed or thought about for the CDO/Net4J
> client server model repo infrastructure.
>
> The idea is CDO as pipeline infrastructure where Model A (Ma) could be
> persisted in the repository but then have instances of another Model B
> (Mb) part of the synchronization. Where <-> represents the linkage.
>
> Ma Source as a CDO Client <->
> Ma Repo as CDO server <->
> Ma Target Client <->
> M2M transformer<->
> Mb Target as a CDO Client
Basically you can establish chains like
Client1 <-> CDOView1 <---> CDORepository <---> CDOView2 <->Client2
Where client1 and client2 can be any sort of process deployed on any
node in the network. Either client is able to detect the changes of all
other clients and see the result of the changes immediately.
I don't think that the number of models used plays an important role
with respect to feasibility. A CDO repository can be dynamically
populated with multiple models which are loaded by the clients as
needed. This is all transparent and automatic, i.e. when client1
registered a new model (EPackage) and committed a transaction that
actually contains objects with EClasses of this EPackage then this
EPackage is stored in the repository and delivered to other clients when
they need it. If the source package was generated and the target clients
don't have the generated model plugin installed they try to create a
dynamic model for it.
Does this help?
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #104997 is a reply to message #104995] |
Thu, 20 December 2007 15:11 |
| Eclipse User |
|
|
|
Originally posted by: jconlon.apache.org
Hi Eike,
Yes your explanation was helpful, thanks for the clarification.
Ok enough of the a priori questions it's time for me to download and
experiment with the code...
kind regards,
John
Eike Stepper wrote:
> [stuff deleted]
>> The idea is CDO as pipeline infrastructure where Model A (Ma) could be
>> persisted in the repository but then have instances of another Model B
>> (Mb) part of the synchronization. Where <-> represents the linkage.
>>
>> Ma Source as a CDO Client <->
>> Ma Repo as CDO server <->
>> Ma Target Client <->
>> M2M transformer<->
>> Mb Target as a CDO Client
> Basically you can establish chains like
>
> Client1 <-> CDOView1 <---> CDORepository <---> CDOView2 <->Client2
>
> Where client1 and client2 can be any sort of process deployed on any
> node in the network. Either client is able to detect the changes of all
> other clients and see the result of the changes immediately.
>
> I don't think that the number of models used plays an important role
> with respect to feasibility. A CDO repository can be dynamically
> populated with multiple models which are loaded by the clients as
> needed. This is all transparent and automatic, i.e. when client1
> registered a new model (EPackage) and committed a transaction that
> actually contains objects with EClasses of this EPackage then this
> EPackage is stored in the repository and delivered to other clients when
> they need it. If the source package was generated and the target clients
> don't have the generated model plugin installed they try to create a
> dynamic model for it.
>
> Does this help?
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
|
|
| |
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #105000 is a reply to message #104999] |
Thu, 20 December 2007 17:11 |
| Eclipse User |
|
|
|
Originally posted by: jconlon.apache.org
Hi Eike,
I read the docs at http://wiki.eclipse.org/?title=CDO
and your right with just two clicks (and a couple of steps) my repo is
running on my windows box! That was easy.
Now for preparing my existing models. I've been bad and have added a
lot of code to support various EMF editor tweaks to meet various
customer requirements. (This has kept me up at night as I am concerned
I have veered from the true path of MDE;-)
Do the .edit and .editor project gui artifacts generated with CDO,
create very different editors than the standard ones the EMF generators
do? In other words can I expect my coded tweaks to the EMF editors to
still work when I generate my CDO models?
kind regards,
John
Eike Stepper wrote:
> John E. Conlon schrieb:
>> Hi Eike,
>>
>> Yes your explanation was helpful, thanks for the clarification.
>>
>> Ok enough of the a priori questions it's time for me to download and
>> experiment with the code...
> Have fun and I'm here ;-)
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #105001 is a reply to message #105000] |
Thu, 20 December 2007 19:39 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
John E. Conlon schrieb:
> Hi Eike,
>
> I read the docs at http://wiki.eclipse.org/?title=CDO
> and your right with just two clicks (and a couple of steps) my repo is
> running on my windows box! That was easy.
Great!
> Now for preparing my existing models. I've been bad and have added a
> lot of code to support various EMF editor tweaks to meet various
> customer requirements. (This has kept me up at night as I am
> concerned I have veered from the true path of MDE;-)
>
> Do the .edit and .editor project gui artifacts generated with CDO,
> create very different editors than the standard ones the EMF
> generators do? In other words can I expect my coded tweaks to the EMF
> editors to still work when I generate my CDO models?
Ok, some details to the three generated plugins:
model: The only things that change when generating for CDO are the
superclass and the reflective feature delegation. If you have changes in
your model (other than the aforementioned ones) they should still work.
edit: The item providers are not changed by CDO (except for a
performance optimization of the hasChildren method that I currently
discuss with Ed).
editor: CDO doesn't generate an editor. Instead CDO comes with an own
editor implementation that works with your generated item providers. I
don't think that you can use a generated (and unchanged) editor with
CDO. If you have a look at the CDOEditor you get a clue what's
necessary. I've marked all additions with @ADDED. You won't be able (or
willing) to make all your editors CDO capable! Nevertheless it'd be an
intereting task to come up with a JET solution for CDO editors. That
said, I'm not a fan of model dependent changes to an editor, i.e. and to
generate model editors at all. Latest when you start mixing different
models within one resource you'll get a headache if your extra logic is
located in model dependent editors. I guess not everyone agrees here so
this is clearly not the reason why I don't provide JET templates for CDO
editors - it's only a matter of time and priorities.
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
>
> kind regards,
> John
>
> Eike Stepper wrote:
>> John E. Conlon schrieb:
>>> Hi Eike,
>>>
>>> Yes your explanation was helpful, thanks for the clarification.
>>>
>>> Ok enough of the a priori questions it's time for me to download and
>>> experiment with the code...
>> Have fun and I'm here ;-)
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #105005 is a reply to message #105001] |
Thu, 20 December 2007 21:43 |
| Eclipse User |
|
|
|
Originally posted by: jconlon.apache.org
Eike Stepper wrote:
> John E. Conlon schrieb:
>> Hi Eike,
>>
>> I read the docs at http://wiki.eclipse.org/?title=CDO
>> and your right with just two clicks (and a couple of steps) my repo is
>> running on my windows box! That was easy.
> Great!
>
>> Now for preparing my existing models. I've been bad and have added a
>> lot of code to support various EMF editor tweaks to meet various
>> customer requirements. (This has kept me up at night as I am
>> concerned I have veered from the true path of MDE;-)
>>
>> Do the .edit and .editor project gui artifacts generated with CDO,
>> create very different editors than the standard ones the EMF
>> generators do? In other words can I expect my coded tweaks to the EMF
>> editors to still work when I generate my CDO models?
> Ok, some details to the three generated plugins:
>
> model: The only things that change when generating for CDO are the
> superclass and the reflective feature delegation. If you have changes in
> your model (other than the aforementioned ones) they should still work.
Cool.
> edit: The item providers are not changed by CDO (except for a
> performance optimization of the hasChildren method that I currently
> discuss with Ed).
Also good.
> editor: CDO doesn't generate an editor. Instead CDO comes with an own
> editor implementation that works with your generated item providers. I
> don't think that you can use a generated (and unchanged) editor with
> CDO. If you have a look at the CDOEditor you get a clue what's
> necessary. I've marked all additions with @ADDED. You won't be able (or
> willing) to make all your editors CDO capable! Nevertheless it'd be an
> intereting task to come up with a JET solution for CDO editors.
Or to make the CDO editor flexible enough to handle the kind of tasks
one has normally customized the generated editors to do. For example
Tree viewers with movable, hidable, sortable columns and filters for
row focusing for example.
Like:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=207324
I guess any gui customization necessary could also be done externally
via views.
That
> said, I'm not a fan of model dependent changes to an editor, i.e. and to
> generate model editors at all. Latest when you start mixing different
> models within one resource you'll get a headache if your extra logic is
> located in model dependent editors. I guess not everyone agrees here so
> this is clearly not the reason why I don't provide JET templates for CDO
> editors - it's only a matter of time and priorities.
Right.
cheers,
John
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #105010 is a reply to message #104992] |
Fri, 21 December 2007 07:58 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Eike,
Then I think it is clear. I will start looking at how cdo operates currently and see how it can be
integrated with Teneo. Probably I will start doing this right in the new year.
gr. Martin
Eike Stepper wrote:
> Martin Taal schrieb:
>> Hi Eike,
>> I pasted your comments back up to make the post readable:
> Hmm, I found it more readable before ;-)
>
>> ES>> CDO (at client side) converts in both directions between an Ecore
>> model and its internal representation of this model. I think this is
>> the relation you mean. At CDO's server side there's usually no such
>> conversion because there's simply no EMF (required).
>> BUT: since the Ecore XMI string can be retrieved from the repository
>> via CDOPackage I think a Teneo based IStore implementation could add
>> EMF to its dependencies, deserialize the original Ecore model and
>> apply the same E<->CDO conversion as the CDO client.
>>
>> MT>> Yes that would surely work afaics. The ecore model is also
>> important for Teneo because it can contain annotations which influence
>> the persistence strategy.
> Annotations in the model have been the original trigger to make the
> model string available on the server.
>
>> ES>>
>> To sum up:
>> - It seems as we we (out products) could both profit from working
>> together.
>> - There could be a Teneo with CDO under the runtime hood [A]
>> - There could be a CDO server with a Teneo-based IStore [B]
>> - We are willing to spend effort for this ;-)
>>
>> MT>>
>> I fully agree, hopefully the teneo based istore would offer the same
>> api as you currently use within cdo server so that the changes in the
>> cdo server are not that large.
> The goal is to not change the repository framework but just plug in the
> new IStore implementation. Since we have already two implementations
> with quite different backends (OO and relational) there is a chance that
> we catch the goal.
>
>> I am willing to spend the effort in doing this (but not before the new
>> year :-).
> That's great!
>
>> ES>>
>> If you agree up to here we should discuss how we start and who should
>> do what. I had a similar integration story with Net4j <-> ECF and I
>> learned that it is often easier to *use* foreign API than to *extend*
>> it. That also results in the author of the integration being the
>> maintainer.
>>
>> For [A] that would mean that primarily you would extend your runtime
>> framework by using CDO API (with my help of course).
>> For [B] that would mean that primarily I would extend my storage
>> framework by implementing the above conversions at server side and
>> then using Teneo API (with your help).
>>
>> MT>> No problem we can see how we can divide the work. I am willing to
>> spend time on this and also maintain the runtime layer afterwards. I
>> can start looking at CDO and see how the persistence works currently
>> (using IStore). Can I download/test cdo separately without net4j?
> No, not if you want to compile CDO without errors. Please use "All.psf"
> from http://wiki.eclipse.org/CDO_Project_Resources#Sources
>
>> Do you have some hyperlinks with the docs?
> Hehe, after years without automatic signature I recently installed a
> Thunderbird plugin to get this dignified signature:
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
> There's some (hopefully) useful information in the CDO wiki ;-)
> That said, it's not yet fully complete so I guess we will have to
> discuss after you got a general overview.
>
>> ES>>
>> I guess that on the way we'll discover some more challenges ;-)
>> MT>>
>> For sure, it makes all this 'unpaid' work interesting and worthwhile
>> doesn't it :-).
> Really addictive!
>
>> One last question for my interest, does the non-emf cdo server side
>> support the emf featuremap and other emf/xml schema specialities such
>> as mixed or anytype?
> I'm not an expert myself in neither feature maps nor xsd details ;-(
> BUT I believe feature maps have already been reported to be used.
> More important, CDO/EMF integration is based on the EStore interface
> which I'd expect to support all EObject functionality including feature
> maps.
> For xml schema specialities such as mixed or anytype I'm not sure. Do
> they rely on EAnnotations? The only thing I can say is that I never
> thought about xsd in the context of CDO.
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO ;-)
> http://wiki.eclipse.org/Net4j
>
>
>>
>> gr. Martin
>>
>> Eike Stepper wrote:
>>> Martin Taal schrieb:
>>>> Hi Eike,
>>>> Just to continue on your last points (otherwise the post becomes
>>>> unreadable to me):
>>>> - Teneos main purpose (with respect to Hibernate) is the integration
>>>> of EMF Resources and EObjects with a Hibernate mapped database. In
>>>> other words you directly map EMF concepts to/from Hibernate concepts
>>>> in one deployment node (client or server).
>>>> MT>> Almost :-), Teneo consists of two main parts:
>>>> 1) Mapping functionality: maps a model to a relational schema (in
>>>> fact maps a model to a java persistence api annotated model which is
>>>> then translated to a hibernate mapping). The user can override
>>>> standard mapping behavior by adding jpa annotations in the model.
>>>> 2) At runtime provide easy integration between EMF and hibernate (or
>>>> jpox). This part is mainly to support automatic mapping (so using
>>>> the above functionality 1) when initializing and support emf
>>>> specifics such as featuremaps, elists and emf resources.
>>> That makes sense ;-)
>>>
>>>> Currently Teneo has 2 runtime layers one for jpox and one for
>>>> hibernate. It would be interesting to add other runtime layers.
>>> Ok, there I can see a chance for CDO. It would be completely covered
>>> by your runtime framework, right?
>>>
>>>> Btw, I use the mapping functionality of Teneo also outside of EMF: I
>>>> map the model using Teneo and then at runtime I have non-emf objects.
>>>>
>>>> - CDO wishes Hibernate mapping at its server side
>>>> - At the server side of CDO there are no EMF concepts. The CDO
>>>> (network) protocol doesn't deal with EMF concepts. The state of
>>>> EObjects is translated into non-EMF data structures at client side.
>>>> MT>> But still because you currently also create a relational
>>>> schema, I assume that the server also has knowledge of the ecore model.
>>> Right, at the client there are bijective conversions between:
>>> EPackage <-> CDOPackage
>>> EClass <-> CDOClass
>>> EStructuralFeature <-> CDOFeature
>>>
>>> So I'd say a simplified version of the Ecore model arrives at the
>>> server and is usually stored in an IStore of the CDO storage
>>> framework (can be RDB). BTW. it's even possible to retrieve the XMI
>>> string of the original Ecore model from a CDOPackage.
>>>
>>>> I can imagine also that your non-emf data structure refer to this
>>>> model?
>>> Right, there's a method CDORevision.getCDOClass().
>>>
>>>> - The non-EMF data structures that represent EObject state at the
>>>> server can't easily mapped by Teneo (since Teneo deals with EMF
>>>> concepts).
>>>> MT>> Not sure if this is an obstacle. I assume that also for the CDO
>>>> non-emf datastructures there is a relation to the application model
>>>> expressed in ecore. Teneo also uses the ecore model as its basis for
>>>> mapping to hibernate. So as long as there is a relation between your
>>>> non-emf datastructure and the ecore model then a runtime layer which
>>>> uses the Teneo mapping logic should be pretty doable.
>>> That's great to hear. But we have to double check:
>>> CDO (at client side) converts in both directions between an Ecore
>>> model and its internal representation of this model. I think this is
>>> the relation you mean. At CDO's server side there's usually no such
>>> conversion because there's simply no EMF (required).
>>> BUT: since the Ecore XMI string can be retrieved from the repository
>>> via CDOPackage I think a Teneo based IStore implementation could add
>>> EMF to its dependencies, deserialize the original Ecore model and
>>> apply the same E<->CDO conversion as the CDO client.
>>>
>>> That sounds reasonable to me. Agreed so far?
>>> I'd have to factor out the conversion mechanism into a separate
>>> plugin...
>>>
>>>> For example next to Teneo I am working on generating seam web
>>>> applications from ecore models. To support the persistence side I
>>>> use Teneo for the mapping and as runtime I have a dynamic-emf-like
>>>> object (basically a type-safe hashmap). The runtime layer is about
>>>> 15 classes.
>>> That sounds similar to the CDO server although it has one or two more
>>> classes ;-)
>>>
>>> To sum up:
>>> - It seems as we we (out products) could both profit from working
>>> together.
>>> - There could be a Teneo with CDO under the runtime hood [A]
>>> - There could be a CDO server with a Teneo-based IStore [B]
>>> - We are willing to spend effort for this ;-)
>>>
>>> If you agree up to here we should discuss how we start and who should
>>> do what. I had a similar integration story with Net4j <-> ECF and I
>>> learned that it is often easier to *use* foreign API than to *extend*
>>> it. That also results in the author of the integration being the
>>> maintainer.
>>>
>>> For [A] that would mean that primarily you would extend your runtime
>>> framework by using CDO API (with my help of course).
>>> For [B] that would mean that primarily I would extend my storage
>>> framework by implementing the above conversions at server side and
>>> then using Teneo API (with your help).
>>>
>>> I guess that on the way we'll discover some more challenges ;-)
>>>
>>> Regards,
>>> Eike Stepper
>>> ----
>>> http://wiki.eclipse.org/CDO
>>> http://wiki.eclipse.org/Net4j
>>>
>>>
>>>>
>>>> gr. Martin
>>>>
>>>> Eike Stepper wrote:
>>>>> Hi Martin,
>>>>>
>>>>> comments below...
>>>>>
>>>>>
>>>>> Martin Taal schrieb:
>>>>>> Hi Eike, John,
>>>>>> Just to add my thoughts about Teneo :-).
>>>>>> Teneo is very much focused on being a persistence solution for
>>>>>> persisting (complex) models to a relational store. This focus
>>>>>> means that Teneo has broad support for most complex modeling
>>>>>> constructs (for example feature maps, xml schema anytype, mixed
>>>>>> type, etc.) and support for jpa annotations in the model. On the
>>>>>> other hand this focus also means that Teneo does not include
>>>>>> specific client-server functionality, this is outside of the scope
>>>>>> of Teneo.
>>>>>> So I would not say that Teneo is a client side solution (I use
>>>>>> Teneo server side in a web app). Teneo can also be used server
>>>>>> side (in a rcp app) but then you need to implement your own
>>>>>> client-server layer (using other tools).
>>>>> These client/server things are so ambiguous like the model/meta
>>>>> model things depending on the start point ;-)
>>>>> But with your clarification the main difference between CDO and
>>>>> Teneo should be clear now.
>>>>>
>>>>>> Btw, it would be interesting to integrate the client-server
>>>>>> capabilities of CDO/net4j with the mapping capabilities of Teneo.
>>>>>> I think this can be a powerfull combination...
>>>>> That'd be of course an interesting effort. What do you think could
>>>>> be the result of such an effort?
>>>>>
>>>>> Simon (cc'ed) and I often discussed this topic and I seem to
>>>>> remember that we (you and I) also spoke about such integration.
>>>>> The result that I'd wish from such an integration would clearly be
>>>>> a CDO storage framework implementation that uses Hibernate as O/R
>>>>> mapper. I fear that your general experience with Hibernate can be
>>>>> more helpful than your actual product Teneo. But I'd be glad to be
>>>>> proven wrong here. The following is the reason (correct me if I'm
>>>>> wrong):
>>>>> - Teneos main purpose (with respect to Hibernate) is the
>>>>> integration of EMF Resources and EObjects with a Hibernate mapped
>>>>> database. In other words you directly map EMF concepts to/from
>>>>> Hibernate concepts in one deployment node (client or server).
>>>>> - CDO wishes Hibernate mapping at its server side
>>>>> - At the server side of CDO there are no EMF concepts. The CDO
>>>>> (network) protocol doesn't deal with EMF concepts. The state of
>>>>> EObjects is translated into non-EMF data structures at client side.
>>>>> - The non-EMF data structures that represent EObject state at the
>>>>> server can't easily mapped by Teneo (since Teneo deals with EMF
>>>>> concepts).
>>>>>
>>>>> Would you agree?
>>>>>
>>>>> Regards,
>>>>> Eike Stepper
>>>>> ----
>>>>> http://wiki.eclipse.org/CDO
>>>>> http://wiki.eclipse.org/Net4j
>>>>>
>>>>>
>>>>>>
>>>>>> gr. Martin
>>>>>>
>>>>>> Eike Stepper wrote:
>>>>>>> John E. Conlon schrieb:
>>>>>>>>> [stuff deleted]
>>>>>>>>>> How does CDO compare to Teneo?
>>>>>>>>> I'd say the main difference is the deployment strategy. While
>>>>>>>>> Teneo (I'm not a Teneo expert!) is mainly used on the client
>>>>>>>>> side (with hibernate/jpox generated JDBC on the wire) CDO is is
>>>>>>>>> used on the client side for EMF model integration and on the
>>>>>>>>> server side for the storage integration (O/R mapping, OODB
>>>>>>>>> integration). CDO uses an own (Net4j based) wire protocol which
>>>>>>>>> is tailored to transactional semantics in the context of
>>>>>>>>> objects (not SQL). Since CDO clients rely on a dedicated CDO
>>>>>>>>> server they can offer some additional functions not available
>>>>>>>>> with Teneo, like automatic model update on all clients if one
>>>>>>>>> client commits a transaction (distributed shared model semantics).
>>>>>>>>
>>>>>>>> So Teneo is more of a client side persistence alternative and
>>>>>>>> CDO is a model repository server!
>>>>>>> Right.
>>>>>>>
>>>>>>>> Is CDO the only Eclipse Modeling project making this claim?
>>>>>>> AFAIK, yes.
>>>>>>>
>>>>>>>> Side question:
>>>>>>>> Since models are persisted to a repository server (a rdbms) has
>>>>>>>> anyone experimented with plugging in BIRT to this rdbms so end
>>>>>>>> user's could be given reporting support? In other words are the
>>>>>>>> final relational schemas human readable and understandable
>>>>>>>> enough for report designers to work with?
>>>>>>> Interesting question because I just discussed that topic with a
>>>>>>> friend of mine. I cc'ed Philipp for this purpose.
>>>>>>>
>>>>>>> 1) A CDO server mainly consists of three parts/layers: A protocol
>>>>>>> peer (Net4j based), a model repository framework (storage
>>>>>>> agnostic) and a storage framework. It depends on the storage
>>>>>>> implementation (IStore) how the model data is actually persisted
>>>>>>> to a storage backend. This *can* be an RDBMS via plain JDBC
>>>>>>> (default) but a user has also implemented an Objectivity store
>>>>>>> (OODBMS) and plans to implement a Hibernate based store.
>>>>>>>
>>>>>>> 2) In case the default JDBC store is used with a repository I'd
>>>>>>> say yes, the generated schema is human readable and
>>>>>>> understandable enough for report designers to work with but that
>>>>>>> is my own opinion. Currently CDO always uses its own generated
>>>>>>> primary keys (long id values) and references are mostly always
>>>>>>> stored in a fixed format that allows for transparent versioning.
>>>>>>>
>>>>>>> 3) I'd prefer to see a model/BIRT integration at the model side
>>>>>>> (CDO client) rather than at the DB side (one of several possible
>>>>>>> CDO storage backends and highly implementation dependent). I'm
>>>>>>> neither a BIRT nor an ODA expert but is it not possible to use an
>>>>>>> EMF ResourceSet, a Resource or an EObject as an ODA data source?
>>>>>>> That'd be much closer to the semantics of the model than querying
>>>>>>> the mapped DB.
>>>>>>>
>>>>>>>>>> Does CDO use the EMF transaction framework?
>>>>>>>>> No, CDO acts directly on the model level. EMF Transaction acts
>>>>>>>>> on the higher edit/command framework level which, in my
>>>>>>>>> opinion, has at least two disadvantages:
>>>>>>>>> 1) Not all clients want to use a command stack to interact with
>>>>>>>>> models (especially non-UI clients like batch clients). With CDO
>>>>>>>>> these clients can remain unchanged (are not forced to use a
>>>>>>>>> command stack) and since CDO transactions are transparent to
>>>>>>>>> the command stack UI clients can be used, too.
>>>>>>>>> 2) Worse, command stack based transactions rely on the
>>>>>>>>> cooperation of *all* clients of a model. If only one client
>>>>>>>>> doesn't use a command stack or uses a non-transactional command
>>>>>>>>> stack all transactions might become corrupt! Since CDO
>>>>>>>>> integrates with EMF models at their core none of these
>>>>>>>>> restrictions apply.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> When you say CDO works at the model level, does that mean entire
>>>>>>>> models are moved from client to server?
>>>>>>> I'm not sure if I correctly understand the intend of your
>>>>>>> question. The scope of a CDO transaction is always an EMF
>>>>>>> ResourceSet (no command stack needed). This ResourceSet can
>>>>>>> contain multiple CDO Resources (and possibly other types of
>>>>>>> Resources). At the time of committing the transaction no CDO
>>>>>>> Resource is allowed to contain references to non-CDO Resources.
>>>>>>> In other words a CDO repository is always guaranteed to contain a
>>>>>>> consistent state of an object graph that can be partitioned into
>>>>>>> CDO Resources. Looking from the other side a CDO-prepared
>>>>>>> ResourceSet acts like a partial but self-populating view onto the
>>>>>>> whole object graph of the repository.
>>>>>>>
>>>>>>> So in this sense, yes, entire models are (initially) moved from
>>>>>>> client to server. Once a model is committed into the repository
>>>>>>> subsequent reads and writes (commits) act at least at an object
>>>>>>> granularity. A recent effort of a user added support for sending
>>>>>>> only deltas for changed objects to the server, see
>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=201266 .
>>>>>>>
>>>>>>> I guess I should stop saying "at the model level" because the
>>>>>>> word "model" is one of the only four terms we have available in
>>>>>>> modern software engineering, ambiguities granted ;-)
>>>>>>> The reason I used it is the following. When you kick the EMF
>>>>>>> generator for an ecore model it typically produces 3 plugins:
>>>>>>> 1) model plugin
>>>>>>> 2) edit plugin (command framework integration)
>>>>>>> 3) editor plugin (Eclipse UI)
>>>>>>>
>>>>>>> When I say "at the model level" I really mean that only 1) is
>>>>>>> needed for integration. AFAIK EMF Transaction needs 1) plus 2)
>>>>>>> for its integration because it intercepts commands of the command
>>>>>>> framework.
>>>>>>>
>>>>>>>> Is there facilities for plugging in Model to Model translation
>>>>>>>> facilities so that one could sync heterogeneous models to one
>>>>>>>> repository?
>>>>>>> I'm lost. Could you please elaborate on "Model to Model
>>>>>>> translation facilities" and "heterogeneous models"?
>>>>>>>
>>>>>>>> My mind has not been expanded as of yet to all the possibilities
>>>>>>>> with CDO, but I am wondering if CDO may be able to offer an
>>>>>>>> infrastructure for models what XProc
>>>>>>>> http://www.w3.org/TR/2007/WD-xproc-20071129/
>>>>>>>> is offering for XML docs?
>>>>>>> I'm really not familiar with XProc. The abstract says "[...] a
>>>>>>> language for describing operations to be performed on XML
>>>>>>> documents". From this I'd say, no, CDO focusses more on the
>>>>>>> static aspects of a model than on the possible operations that
>>>>>>> could modeify a model over time. May be you can list some
>>>>>>> specific details of the XProc spec (which I've not read as a
>>>>>>> whole) that you're interested in?
>>>>>>>
>>>>>>>>>> [stuff deleted]
>>>>>>>>> Good point! Would you be willing to contribute such a
>>>>>>>>> connector? If so, please open an enhancement request in
>>>>>>>>> Bugzilla and attach a patch (since Net4j is already extensible
>>>>>>>>> in the dimension of transports a patch might not be needed and
>>>>>>>>> you can simply attach the extension bundle project). I'd be
>>>>>>>>> happy to maintain the code after ;-)
>>>>>>>>
>>>>>>>> Have several activities scheduled right now, but I am interested
>>>>>>>> enough to contribute with either a comm port transport or a
>>>>>>>> Bluetooth one. The problem I for see with either one of these
>>>>>>>> solutions is that I expect there will be OS library dependencies
>>>>>>>> that will have to be bundled with the code. This is something I
>>>>>>>> have not done before.
>>>>>>> OSGi should be prepared for this ;-)
>>>>>>>>
>>>>>>>> Will start looking into this next month.
>>>>>>> That'd be great! Please tell me when you need my assistance...
>>>>>>>
>>>>>>> Regards,
>>>>>>> Eike Stepper
>>>>>>> ----
>>>>>>> http://wiki.eclipse.org/CDO
>>>>>>> http://wiki.eclipse.org/Net4j
>>>>>>>
>>>>>>>
>>>>>>>>>> That said, a connector implementation for comm ports should be
>>>>>>>>>> easy, as easy as the usage of comm ports is in Java (which I
>>>>>>>>>> have no idea of).
>>>>>>>>>> I have not done this myself, so I don't know how easy the
>>>>>>>>>> lower layer will be. Would probably do the
>>>>>>>>>> http://www.rxtx.org/ versus Sun's impl.
>>>>>>>>>>
>>>>>>>>>> As
>>>>>>>>>>> the docs of IConnector state you'll have to subclass
>>>>>>>>>>> Connector (
>>>>>>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j/src/org/eclipse /internal/net4j/Connector.java?root=Modeling_Project&vie w=log)
>>>>>>>>>>> . I suggest to look at the implementation of TCPConnector (
>>>>>>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j.tcp/src/org/ecl ipse/net4j/internal/tcp/TCPConnector.java?root=Modeling_Proj ect&view=log
>>>>>>>>>>> ).
>>>>>>>>>>>
>>>>>>>>>>> As I said above, if you succeed in providing a comm port
>>>>>>>>>>> implementation of IConnector (and the supporting factories)
>>>>>>>>>>> you'll get EMF integration for free ;-)
>>>>>>>>>>
>>>>>>>>>> Sounds good, but will I need to also install a database to get
>>>>>>>>>> EMF integration?
>>>>>>>>> Good question! According to the 'normal' setup of a CDO
>>>>>>>>> deployment, yes. But CDO should be open and layered enuogh to
>>>>>>>>> find a solution that uses only the model integration parts. I
>>>>>>>>> haven't thought about such usage so far.
>>>>>>>>
>>>>>>>>
>>>>>>>> kind regards,
>>>>>>>> John Conlon
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #612792 is a reply to message #104437] |
Wed, 12 December 2007 12:32 |
|
Hi John,
Comments below...
John E. Conlon schrieb:
> Hi,
>
> Is there any current technical documentation on the Net4J effort that
> I can refer to, so I may to come up to speed on it's technical
> use-cases, architecture, features and benefits?
I'm currently working on the documentation of CDO and Net4j. Since I
started top-down I haven't arrived at the Net4j parts. Although the CDO
docs are not fully complete I could start with some high-level Net4j
docs to aid your evaluations. Have you already had a look at the
sources. They are clearly structured so that you should be able to
rather easily get an overview. Could you describe in a bit more detail
which kind of information would be helpful for your matter?
> I am trying to update my EMF model based on data received from remote
> sensors attached via Bluetooth.
Have you had a look at the CDO project as well? It integrates your EMF
model with the Net4j communications platform on client and on server
side (repository). So if we manage to create a Net4j connector for comm
ports (see below) you might already have a complete solution for your
problem.
> While it maybe nice to deal with Bluetooth I think a connectivity
> solution to comm ports maybe all I need. Can Net4J establish
> connectivity to a comm port?
For each kind of transport you'll need an implementation of IConnector
http://download.eclipse.org/modeling/emft/net4j/javadoc/0.8. 0/org/eclipse/net4j/IConnector.html
.. Net4j does currently not come with a connector implementation that
uses comm ports. Only (NIO) sockets (tcp) and in process transport (jvm)
are currently provided by me.
That said, a connector implementation for comm ports should be easy, as
easy as the usage of comm ports is in Java (which I have no idea of). As
the docs of IConnector state you'll have to subclass Connector (
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j/src/org/eclipse /internal/net4j/Connector.java?root=Modeling_Project&vie w=log)
.. I suggest to look at the implementation of TCPConnector (
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j.tcp/src/org/ecl ipse/net4j/internal/tcp/TCPConnector.java?root=Modeling_Proj ect&view=log
).
As I said above, if you succeed in providing a comm port implementation
of IConnector (and the supporting factories) you'll get EMF integration
for free ;-)
Regards,
Eike Stepper
----
http://wiki.eclipse.org/?title=CDO
http://wiki.eclipse.org/?title=Net4j
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #612796 is a reply to message #104506] |
Wed, 12 December 2007 18:37 |
| Eclipse User |
|
|
|
Originally posted by: jconlon.apache.org
Hi Eike,
Eike Stepper wrote:
> Hi John,
>
> Comments below...
>
>
>
> John E. Conlon schrieb:
>> Hi,
>>
>> Is there any current technical documentation on the Net4J effort that
>> I can refer to, so I may to come up to speed on it's technical
>> use-cases, architecture, features and benefits?
> I'm currently working on the documentation of CDO and Net4j. Since I
> started top-down I haven't arrived at the Net4j parts. Although the CDO
> docs are not fully complete I could start with some high-level Net4j
> docs to aid your evaluations. Have you already had a look at the
> sources.
No I haven't looked at the sources to date, but I have seen what appears
to be documentation but maybe out of date at www.sympedia.org. Are these
documents the ones you are updating?
They are clearly structured so that you should be able to
> rather easily get an overview. Could you describe in a bit more detail
> which kind of information would be helpful for your matter?
At this point I an just surveying the available options for how I can
add sensor data to my EMF models, and eventually
offer EMF model to EMF model synchronization across distributed
systems.
In other words, my goal is to ascertain the direction the overall
Eclipse Modeling 'movement' will be taking for these two ways of
integrating and synchronizing data. Will it be CDO/Net4j or another
technology like STP?
Have some familiarity with NIO and have done some minor contributions to
the Apache Mina project. How does Net4j compare to Mina?
>> I am trying to update my EMF model based on data received from remote
>> sensors attached via Bluetooth.
> Have you had a look at the CDO project as well? It integrates your EMF
> model with the Net4j communications platform on client and on server
> side (repository). So if we manage to create a Net4j connector for comm
> ports (see below) you might already have a complete solution for your
> problem.
Yes I have seen the Sympedia CDO documentation and it looks very
interesting.
How does CDO compare to Teneo?
Does CDO use the EMF transaction framework?
Can I use CDO to synchronize two EMF resources in a peer to peer fashion
for example two instances of a model that are persisted as two XMI
documents running in two different computers?
>
>> While it maybe nice to deal with Bluetooth I think a connectivity
>> solution to comm ports maybe all I need. Can Net4J establish
>> connectivity to a comm port?
> For each kind of transport you'll need an implementation of IConnector
> http://download.eclipse.org/modeling/emft/net4j/javadoc/0.8. 0/org/eclipse/net4j/IConnector.html
Nice javadoc!
> . Net4j does currently not come with a connector implementation that
> uses comm ports. Only (NIO) sockets (tcp) and in process transport (jvm)
> are currently provided by me.
This was done at the Mina project so I expect it could be done with
Net4J as well.
> That said, a connector implementation for comm ports should be easy, as
> easy as the usage of comm ports is in Java (which I have no idea of).
I have not done this myself, so I don't know how easy the lower layer
will be. Would probably do the http://www.rxtx.org/ versus Sun's impl.
As
> the docs of IConnector state you'll have to subclass Connector (
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j/src/org/eclipse /internal/net4j/Connector.java?root=Modeling_Project&vie w=log)
> . I suggest to look at the implementation of TCPConnector (
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j.tcp/src/org/ecl ipse/net4j/internal/tcp/TCPConnector.java?root=Modeling_Proj ect&view=log
> ).
>
> As I said above, if you succeed in providing a comm port implementation
> of IConnector (and the supporting factories) you'll get EMF integration
> for free ;-)
Sounds good, but will I need to also install a database to get EMF
integration?
kind regards,
John
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #612798 is a reply to message #104531] |
Thu, 13 December 2007 05:45 |
|
John E. Conlon schrieb:
> Hi Eike,
>
> Eike Stepper wrote:
>> Hi John,
>>
>> Comments below...
>>
>>
>>
>> John E. Conlon schrieb:
>>> Hi,
>>>
>>> Is there any current technical documentation on the Net4J effort
>>> that I can refer to, so I may to come up to speed on it's technical
>>> use-cases, architecture, features and benefits?
>> I'm currently working on the documentation of CDO and Net4j. Since I
>> started top-down I haven't arrived at the Net4j parts. Although the
>> CDO docs are not fully complete I could start with some high-level
>> Net4j docs to aid your evaluations. Have you already had a look at
>> the sources.
> No I haven't looked at the sources to date, but I have seen what
> appears to be documentation but maybe out of date at www.sympedia.org.
> Are these documents the ones you are updating?
No, the docs are at http://wiki.eclipse.org/?title=CDO and will be at
http://wiki.eclipse.org/?title=Net4j .
The overall design (connectors, acceptors, selectors and channels)
described at sympedia.org is still valid for Net4j but the architecture
(no Spring at the moment) and the implementation (more asynchronous,
faster, more reliable) changed completely.
I'll have to remove the old docs from sympedia.org and add links to
wiki.eclipse.org...
> They are clearly structured so that you should be able to
>> rather easily get an overview. Could you describe in a bit more
>> detail which kind of information would be helpful for your matter?
>
> At this point I an just surveying the available options for how I can
> add sensor data to my EMF models, and eventually
> offer EMF model to EMF model synchronization across distributed
> systems.
>
> In other words, my goal is to ascertain the direction the overall
> Eclipse Modeling 'movement' will be taking for these two ways of
> integrating and synchronizing data. Will it be CDO/Net4j or another
> technology like STP?
>
> Have some familiarity with NIO and have done some minor contributions
> to the Apache Mina project. How does Net4j compare to Mina?
I haven't heard of Mina before but I just browsed a bit through the
presentation material. It looks as if Mina has doubled some of the
efforts I released with Net4j v1.0 in year 2003 ;-)
Net4j has always had an additional concept of channels which are
multiplexed through connections. In other words the application protocol
logic in Net4j is always capable of sharing a single connection with
other instances of the same or other protocols. And Net4j has an
optional layer on top of the buffered, non-blocking transport layer that
provides for stream-based request/response signals and work threading
strategies. May be Mina provides for something similar, you seem to be
the expert ;-)
>> Have you had a look at the CDO project as well? It integrates your
>> EMF model with the Net4j communications platform on client and on
>> server side (repository). So if we manage to create a Net4j connector
>> for comm ports (see below) you might already have a complete solution
>> for your problem.
> I am trying to update my EMF model based on data received from remote
> sensors attached via Bluetooth.
> Yes I have seen the Sympedia CDO documentation and it looks very
> interesting.
The docs at http://wiki.eclipse.org/?title=CDO are better for the
Eclipse.org hosted version of CDO (the only one maintained).
> How does CDO compare to Teneo?
I'd say the main difference is the deployment strategy. While Teneo (I'm
not a Teneo expert!) is mainly used on the client side (with
hibernate/jpox generated JDBC on the wire) CDO is is used on the client
side for EMF model integration and on the server side for the storage
integration (O/R mapping, OODB integration). CDO uses an own (Net4j
based) wire protocol which is tailored to transactional semantics in the
context of objects (not SQL). Since CDO clients rely on a dedicated CDO
server they can offer some additional functions not available with
Teneo, like automatic model update on all clients if one client commits
a transaction (distributed shared model semantics).
>
> Does CDO use the EMF transaction framework?
No, CDO acts directly on the model level. EMF Transaction acts on the
higher edit/command framework level which, in my opinion, has at least
two disadvantages:
1) Not all clients want to use a command stack to interact with models
(especially non-UI clients like batch clients). With CDO these clients
can remain unchanged (are not forced to use a command stack) and since
CDO transactions are transparent to the command stack UI clients can be
used, too.
2) Worse, command stack based transactions rely on the cooperation of
*all* clients of a model. If only one client doesn't use a command stack
or uses a non-transactional command stack all transactions might become
corrupt! Since CDO integrates with EMF models at their core none of
these restrictions apply.
>
> Can I use CDO to synchronize two EMF resources in a peer to peer
> fashion for example two instances of a model that are persisted as two
> XMI documents running in two different computers?
>>
>>> While it maybe nice to deal with Bluetooth I think a connectivity
>>> solution to comm ports maybe all I need. Can Net4J establish
>>> connectivity to a comm port?
>> For each kind of transport you'll need an implementation of
>> IConnector
>> http://download.eclipse.org/modeling/emft/net4j/javadoc/0.8. 0/org/eclipse/net4j/IConnector.html
>
> Nice javadoc!
>
>> . Net4j does currently not come with a connector implementation that
>> uses comm ports. Only (NIO) sockets (tcp) and in process transport
>> (jvm) are currently provided by me.
>
> This was done at the Mina project so I expect it could be done with
> Net4J as well.
Good point! Would you be willing to contribute such a connector? If so,
please open an enhancement request in Bugzilla and attach a patch (since
Net4j is already extensible in the dimension of transports a patch might
not be needed and you can simply attach the extension bundle project).
I'd be happy to maintain the code after ;-)
> That said, a connector implementation for comm ports should be easy,
> as easy as the usage of comm ports is in Java (which I have no idea of).
> I have not done this myself, so I don't know how easy the lower layer
> will be. Would probably do the http://www.rxtx.org/ versus Sun's impl.
>
> As
>> the docs of IConnector state you'll have to subclass Connector (
>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j/src/org/eclipse /internal/net4j/Connector.java?root=Modeling_Project&vie w=log)
>> . I suggest to look at the implementation of TCPConnector (
>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j.tcp/src/org/ecl ipse/net4j/internal/tcp/TCPConnector.java?root=Modeling_Proj ect&view=log
>> ).
>>
>> As I said above, if you succeed in providing a comm port
>> implementation of IConnector (and the supporting factories) you'll
>> get EMF integration for free ;-)
>
> Sounds good, but will I need to also install a database to get EMF
> integration?
Good question! According to the 'normal' setup of a CDO deployment, yes.
But CDO should be open and layered enuogh to find a solution that uses
only the model integration parts. I haven't thought about such usage so far.
Regards,
Eike Stepper
----
http://wiki.eclipse.org/?title=CDO
http://wiki.eclipse.org/?title=Net4j
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #612831 is a reply to message #104545] |
Sun, 16 December 2007 17:25 |
| Eclipse User |
|
|
|
Originally posted by: jconlon.apache.org
Eike Stepper wrote:
> John E. Conlon schrieb:
>> Hi Eike,
>>
>> Eike Stepper wrote:
>>> Hi John,
>>>
>>> Comments below...
>>>
>>>
>>>
>>> John E. Conlon schrieb:
>>>> Hi,
>>>>
>>>> Is there any current technical documentation on the Net4J effort
>>>> that I can refer to, so I may to come up to speed on it's technical
>>>> use-cases, architecture, features and benefits?
>>> I'm currently working on the documentation of CDO and Net4j. Since I
>>> started top-down I haven't arrived at the Net4j parts. Although the
>>> CDO docs are not fully complete I could start with some high-level
>>> Net4j docs to aid your evaluations. Have you already had a look at
>>> the sources.
>> No I haven't looked at the sources to date, but I have seen what
>> appears to be documentation but maybe out of date at www.sympedia.org.
>> Are these documents the ones you are updating?
> No, the docs are at http://wiki.eclipse.org/?title=CDO and will be at
> http://wiki.eclipse.org/?title=Net4j
Ah! Looks comprehensive. Will start digging in next week.
> The overall design (connectors, acceptors, selectors and channels)
> described at sympedia.org is still valid for Net4j but the architecture
> (no Spring at the moment) and the implementation (more asynchronous,
> faster, more reliable) changed completely.
> I'll have to remove the old docs from sympedia.org and add links to
> wiki.eclipse.org...
Look forward to seeing docs for Net4J.
>
>> They are clearly structured so that you should be able to
>>> rather easily get an overview. Could you describe in a bit more
>>> detail which kind of information would be helpful for your matter?
>>
>> At this point I an just surveying the available options for how I can
>> add sensor data to my EMF models, and eventually
>> offer EMF model to EMF model synchronization across distributed
>> systems.
>>
>> In other words, my goal is to ascertain the direction the overall
>> Eclipse Modeling 'movement' will be taking for these two ways of
>> integrating and synchronizing data. Will it be CDO/Net4j or another
>> technology like STP?
>>
>> Have some familiarity with NIO and have done some minor contributions
>> to the Apache Mina project. How does Net4j compare to Mina?
> I haven't heard of Mina before but I just browsed a bit through the
> presentation material. It looks as if Mina has doubled some of the
> efforts I released with Net4j v1.0 in year 2003 ;-)
Common problems often manifest duplicate effort.
> Net4j has always had an additional concept of channels which are
> multiplexed through connections. In other words the application protocol
> logic in Net4j is always capable of sharing a single connection with
> other instances of the same or other protocols. And Net4j has an
> optional layer on top of the buffered, non-blocking transport layer that
> provides for stream-based request/response signals and work threading
> strategies. May be Mina provides for something similar, you seem to be
> the expert ;-)
No, I am not a Mina expert, only a user who wanted to help OSGi
'bundlize' the Mina and it's original parent Apache Directory Server. I
helped in this regard, but not at the core development of either
efforts. (They were the mechanics, I merely attached the license plates.)
>
>>> Have you had a look at the CDO project as well? It integrates your
>>> EMF model with the Net4j communications platform on client and on
>>> server side (repository). So if we manage to create a Net4j connector
>>> for comm ports (see below) you might already have a complete solution
>>> for your problem.
>> I am trying to update my EMF model based on data received from remote
>> sensors attached via Bluetooth. Yes I have seen the Sympedia CDO
>> documentation and it looks very interesting.
> The docs at http://wiki.eclipse.org/?title=CDO are better for the
> Eclipse.org hosted version of CDO (the only one maintained).
>
>> How does CDO compare to Teneo?
> I'd say the main difference is the deployment strategy. While Teneo (I'm
> not a Teneo expert!) is mainly used on the client side (with
> hibernate/jpox generated JDBC on the wire) CDO is is used on the client
> side for EMF model integration and on the server side for the storage
> integration (O/R mapping, OODB integration). CDO uses an own (Net4j
> based) wire protocol which is tailored to transactional semantics in the
> context of objects (not SQL). Since CDO clients rely on a dedicated CDO
> server they can offer some additional functions not available with
> Teneo, like automatic model update on all clients if one client commits
> a transaction (distributed shared model semantics).
So Teneo is more of a client side persistence alternative and CDO is a
model repository server!
Is CDO the only Eclipse Modeling project making this claim?
Side question:
Since models are persisted to a repository server (a rdbms) has anyone
experimented with plugging in BIRT to this rdbms so end user's could be
given reporting support? In other words are the final relational
schemas human readable and understandable enough for report designers to
work with?
>>
>> Does CDO use the EMF transaction framework?
> No, CDO acts directly on the model level. EMF Transaction acts on the
> higher edit/command framework level which, in my opinion, has at least
> two disadvantages:
> 1) Not all clients want to use a command stack to interact with models
> (especially non-UI clients like batch clients). With CDO these clients
> can remain unchanged (are not forced to use a command stack) and since
> CDO transactions are transparent to the command stack UI clients can be
> used, too.
> 2) Worse, command stack based transactions rely on the cooperation of
> *all* clients of a model. If only one client doesn't use a command stack
> or uses a non-transactional command stack all transactions might become
> corrupt! Since CDO integrates with EMF models at their core none of
> these restrictions apply.
>
When you say CDO works at the model level, does that mean entire models
are moved from client to server? Is there facilities for plugging in
Model to Model translation facilities so that one could sync
heterogeneous models to one repository? My mind has not been expanded
as of yet to all the possibilities with CDO, but I am wondering if CDO
may be able to offer an infrastructure for models what XProc
http://www.w3.org/TR/2007/WD-xproc-20071129/
is offering for XML docs?
>>
>> Can I use CDO to synchronize two EMF resources in a peer to peer
>> fashion for example two instances of a model that are persisted as two
>> XMI documents running in two different computers?
>>>
>>>> While it maybe nice to deal with Bluetooth I think a connectivity
>>>> solution to comm ports maybe all I need. Can Net4J establish
>>>> connectivity to a comm port?
>>> For each kind of transport you'll need an implementation of
>>> IConnector
>>> http://download.eclipse.org/modeling/emft/net4j/javadoc/0.8. 0/org/eclipse/net4j/IConnector.html
>>
>>
>> Nice javadoc!
>>
>>> . Net4j does currently not come with a connector implementation that
>>> uses comm ports. Only (NIO) sockets (tcp) and in process transport
>>> (jvm) are currently provided by me.
>>
>> This was done at the Mina project so I expect it could be done with
>> Net4J as well.
> Good point! Would you be willing to contribute such a connector? If so,
> please open an enhancement request in Bugzilla and attach a patch (since
> Net4j is already extensible in the dimension of transports a patch might
> not be needed and you can simply attach the extension bundle project).
> I'd be happy to maintain the code after ;-)
Have several activities scheduled right now, but I am interested enough
to contribute with either a comm port transport or a Bluetooth one. The
problem I for see with either one of these solutions is that I expect
there will be OS library dependencies that will have to be bundled with
the code. This is something I have not done before.
Will start looking into this next month.
>
>> That said, a connector implementation for comm ports should be easy,
>> as easy as the usage of comm ports is in Java (which I have no idea of).
>> I have not done this myself, so I don't know how easy the lower layer
>> will be. Would probably do the http://www.rxtx.org/ versus Sun's impl.
>>
>> As
>>> the docs of IConnector state you'll have to subclass Connector (
>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j/src/org/eclipse /internal/net4j/Connector.java?root=Modeling_Project&vie w=log)
>>> . I suggest to look at the implementation of TCPConnector (
>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j.tcp/src/org/ecl ipse/net4j/internal/tcp/TCPConnector.java?root=Modeling_Proj ect&view=log
>>> ).
>>>
>>> As I said above, if you succeed in providing a comm port
>>> implementation of IConnector (and the supporting factories) you'll
>>> get EMF integration for free ;-)
>>
>> Sounds good, but will I need to also install a database to get EMF
>> integration?
> Good question! According to the 'normal' setup of a CDO deployment, yes.
> But CDO should be open and layered enuogh to find a solution that uses
> only the model integration parts. I haven't thought about such usage so
> far.
kind regards,
John Conlon
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #612835 is a reply to message #104761] |
Mon, 17 December 2007 03:35 |
|
John E. Conlon schrieb:
>> [stuff deleted]
>>> How does CDO compare to Teneo?
>> I'd say the main difference is the deployment strategy. While Teneo
>> (I'm not a Teneo expert!) is mainly used on the client side (with
>> hibernate/jpox generated JDBC on the wire) CDO is is used on the
>> client side for EMF model integration and on the server side for the
>> storage integration (O/R mapping, OODB integration). CDO uses an own
>> (Net4j based) wire protocol which is tailored to transactional
>> semantics in the context of objects (not SQL). Since CDO clients rely
>> on a dedicated CDO server they can offer some additional functions
>> not available with Teneo, like automatic model update on all clients
>> if one client commits a transaction (distributed shared model
>> semantics).
>
> So Teneo is more of a client side persistence alternative and CDO is a
> model repository server!
Right.
> Is CDO the only Eclipse Modeling project making this claim?
AFAIK, yes.
> Side question:
> Since models are persisted to a repository server (a rdbms) has anyone
> experimented with plugging in BIRT to this rdbms so end user's could
> be given reporting support? In other words are the final relational
> schemas human readable and understandable enough for report designers
> to work with?
Interesting question because I just discussed that topic with a friend
of mine. I cc'ed Philipp for this purpose.
1) A CDO server mainly consists of three parts/layers: A protocol peer
(Net4j based), a model repository framework (storage agnostic) and a
storage framework. It depends on the storage implementation (IStore) how
the model data is actually persisted to a storage backend. This *can* be
an RDBMS via plain JDBC (default) but a user has also implemented an
Objectivity store (OODBMS) and plans to implement a Hibernate based store.
2) In case the default JDBC store is used with a repository I'd say yes,
the generated schema is human readable and understandable enough for
report designers to work with but that is my own opinion. Currently CDO
always uses its own generated primary keys (long id values) and
references are mostly always stored in a fixed format that allows for
transparent versioning.
3) I'd prefer to see a model/BIRT integration at the model side (CDO
client) rather than at the DB side (one of several possible CDO storage
backends and highly implementation dependent). I'm neither a BIRT nor an
ODA expert but is it not possible to use an EMF ResourceSet, a Resource
or an EObject as an ODA data source? That'd be much closer to the
semantics of the model than querying the mapped DB.
>>> Does CDO use the EMF transaction framework?
>> No, CDO acts directly on the model level. EMF Transaction acts on the
>> higher edit/command framework level which, in my opinion, has at
>> least two disadvantages:
>> 1) Not all clients want to use a command stack to interact with
>> models (especially non-UI clients like batch clients). With CDO these
>> clients can remain unchanged (are not forced to use a command stack)
>> and since CDO transactions are transparent to the command stack UI
>> clients can be used, too.
>> 2) Worse, command stack based transactions rely on the cooperation of
>> *all* clients of a model. If only one client doesn't use a command
>> stack or uses a non-transactional command stack all transactions
>> might become corrupt! Since CDO integrates with EMF models at their
>> core none of these restrictions apply.
>>
>
>
> When you say CDO works at the model level, does that mean entire
> models are moved from client to server?
I'm not sure if I correctly understand the intend of your question. The
scope of a CDO transaction is always an EMF ResourceSet (no command
stack needed). This ResourceSet can contain multiple CDO Resources (and
possibly other types of Resources). At the time of committing the
transaction no CDO Resource is allowed to contain references to non-CDO
Resources. In other words a CDO repository is always guaranteed to
contain a consistent state of an object graph that can be partitioned
into CDO Resources. Looking from the other side a CDO-prepared
ResourceSet acts like a partial but self-populating view onto the whole
object graph of the repository.
So in this sense, yes, entire models are (initially) moved from client
to server. Once a model is committed into the repository subsequent
reads and writes (commits) act at least at an object granularity. A
recent effort of a user added support for sending only deltas for
changed objects to the server, see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=201266 .
I guess I should stop saying "at the model level" because the word
"model" is one of the only four terms we have available in modern
software engineering, ambiguities granted ;-)
The reason I used it is the following. When you kick the EMF generator
for an ecore model it typically produces 3 plugins:
1) model plugin
2) edit plugin (command framework integration)
3) editor plugin (Eclipse UI)
When I say "at the model level" I really mean that only 1) is needed for
integration. AFAIK EMF Transaction needs 1) plus 2) for its integration
because it intercepts commands of the command framework.
> Is there facilities for plugging in Model to Model translation
> facilities so that one could sync heterogeneous models to one
> repository?
I'm lost. Could you please elaborate on "Model to Model translation
facilities" and "heterogeneous models"?
> My mind has not been expanded as of yet to all the possibilities with
> CDO, but I am wondering if CDO may be able to offer an infrastructure
> for models what XProc http://www.w3.org/TR/2007/WD-xproc-20071129/
> is offering for XML docs?
I'm really not familiar with XProc. The abstract says "[...] a language
for describing operations to be performed on XML documents". From this
I'd say, no, CDO focusses more on the static aspects of a model than on
the possible operations that could modeify a model over time. May be you
can list some specific details of the XProc spec (which I've not read as
a whole) that you're interested in?
>>> [stuff deleted]
>> Good point! Would you be willing to contribute such a connector? If
>> so, please open an enhancement request in Bugzilla and attach a patch
>> (since Net4j is already extensible in the dimension of transports a
>> patch might not be needed and you can simply attach the extension
>> bundle project). I'd be happy to maintain the code after ;-)
>
> Have several activities scheduled right now, but I am interested
> enough to contribute with either a comm port transport or a Bluetooth
> one. The problem I for see with either one of these solutions is that
> I expect there will be OS library dependencies that will have to be
> bundled with the code. This is something I have not done before.
OSGi should be prepared for this ;-)
>
> Will start looking into this next month.
That'd be great! Please tell me when you need my assistance...
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
>>> That said, a connector implementation for comm ports should be easy,
>>> as easy as the usage of comm ports is in Java (which I have no idea
>>> of).
>>> I have not done this myself, so I don't know how easy the lower
>>> layer will be. Would probably do the http://www.rxtx.org/ versus
>>> Sun's impl.
>>>
>>> As
>>>> the docs of IConnector state you'll have to subclass Connector (
>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j/src/org/eclipse /internal/net4j/Connector.java?root=Modeling_Project&vie w=log)
>>>> . I suggest to look at the implementation of TCPConnector (
>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j.tcp/src/org/ecl ipse/net4j/internal/tcp/TCPConnector.java?root=Modeling_Proj ect&view=log
>>>> ).
>>>>
>>>> As I said above, if you succeed in providing a comm port
>>>> implementation of IConnector (and the supporting factories) you'll
>>>> get EMF integration for free ;-)
>>>
>>> Sounds good, but will I need to also install a database to get EMF
>>> integration?
>> Good question! According to the 'normal' setup of a CDO deployment,
>> yes. But CDO should be open and layered enuogh to find a solution
>> that uses only the model integration parts. I haven't thought about
>> such usage so far.
>
>
> kind regards,
> John Conlon
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #612837 is a reply to message #104775] |
Mon, 17 December 2007 08:34 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Eike, John,
Just to add my thoughts about Teneo :-).
Teneo is very much focused on being a persistence solution for persisting (complex) models to a
relational store. This focus means that Teneo has broad support for most complex modeling constructs
(for example feature maps, xml schema anytype, mixed type, etc.) and support for jpa annotations in
the model. On the other hand this focus also means that Teneo does not include specific
client-server functionality, this is outside of the scope of Teneo.
So I would not say that Teneo is a client side solution (I use Teneo server side in a web app).
Teneo can also be used server side (in a rcp app) but then you need to implement your own
client-server layer (using other tools).
Btw, it would be interesting to integrate the client-server capabilities of CDO/net4j with the
mapping capabilities of Teneo. I think this can be a powerfull combination...
gr. Martin
Eike Stepper wrote:
> John E. Conlon schrieb:
>>> [stuff deleted]
>>>> How does CDO compare to Teneo?
>>> I'd say the main difference is the deployment strategy. While Teneo
>>> (I'm not a Teneo expert!) is mainly used on the client side (with
>>> hibernate/jpox generated JDBC on the wire) CDO is is used on the
>>> client side for EMF model integration and on the server side for the
>>> storage integration (O/R mapping, OODB integration). CDO uses an own
>>> (Net4j based) wire protocol which is tailored to transactional
>>> semantics in the context of objects (not SQL). Since CDO clients rely
>>> on a dedicated CDO server they can offer some additional functions
>>> not available with Teneo, like automatic model update on all clients
>>> if one client commits a transaction (distributed shared model
>>> semantics).
>>
>> So Teneo is more of a client side persistence alternative and CDO is a
>> model repository server!
> Right.
>
>> Is CDO the only Eclipse Modeling project making this claim?
> AFAIK, yes.
>
>> Side question:
>> Since models are persisted to a repository server (a rdbms) has anyone
>> experimented with plugging in BIRT to this rdbms so end user's could
>> be given reporting support? In other words are the final relational
>> schemas human readable and understandable enough for report designers
>> to work with?
> Interesting question because I just discussed that topic with a friend
> of mine. I cc'ed Philipp for this purpose.
>
> 1) A CDO server mainly consists of three parts/layers: A protocol peer
> (Net4j based), a model repository framework (storage agnostic) and a
> storage framework. It depends on the storage implementation (IStore) how
> the model data is actually persisted to a storage backend. This *can* be
> an RDBMS via plain JDBC (default) but a user has also implemented an
> Objectivity store (OODBMS) and plans to implement a Hibernate based store.
>
> 2) In case the default JDBC store is used with a repository I'd say yes,
> the generated schema is human readable and understandable enough for
> report designers to work with but that is my own opinion. Currently CDO
> always uses its own generated primary keys (long id values) and
> references are mostly always stored in a fixed format that allows for
> transparent versioning.
>
> 3) I'd prefer to see a model/BIRT integration at the model side (CDO
> client) rather than at the DB side (one of several possible CDO storage
> backends and highly implementation dependent). I'm neither a BIRT nor an
> ODA expert but is it not possible to use an EMF ResourceSet, a Resource
> or an EObject as an ODA data source? That'd be much closer to the
> semantics of the model than querying the mapped DB.
>
>>>> Does CDO use the EMF transaction framework?
>>> No, CDO acts directly on the model level. EMF Transaction acts on the
>>> higher edit/command framework level which, in my opinion, has at
>>> least two disadvantages:
>>> 1) Not all clients want to use a command stack to interact with
>>> models (especially non-UI clients like batch clients). With CDO these
>>> clients can remain unchanged (are not forced to use a command stack)
>>> and since CDO transactions are transparent to the command stack UI
>>> clients can be used, too.
>>> 2) Worse, command stack based transactions rely on the cooperation of
>>> *all* clients of a model. If only one client doesn't use a command
>>> stack or uses a non-transactional command stack all transactions
>>> might become corrupt! Since CDO integrates with EMF models at their
>>> core none of these restrictions apply.
>>>
>>
>>
>> When you say CDO works at the model level, does that mean entire
>> models are moved from client to server?
> I'm not sure if I correctly understand the intend of your question. The
> scope of a CDO transaction is always an EMF ResourceSet (no command
> stack needed). This ResourceSet can contain multiple CDO Resources (and
> possibly other types of Resources). At the time of committing the
> transaction no CDO Resource is allowed to contain references to non-CDO
> Resources. In other words a CDO repository is always guaranteed to
> contain a consistent state of an object graph that can be partitioned
> into CDO Resources. Looking from the other side a CDO-prepared
> ResourceSet acts like a partial but self-populating view onto the whole
> object graph of the repository.
>
> So in this sense, yes, entire models are (initially) moved from client
> to server. Once a model is committed into the repository subsequent
> reads and writes (commits) act at least at an object granularity. A
> recent effort of a user added support for sending only deltas for
> changed objects to the server, see
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=201266 .
>
> I guess I should stop saying "at the model level" because the word
> "model" is one of the only four terms we have available in modern
> software engineering, ambiguities granted ;-)
> The reason I used it is the following. When you kick the EMF generator
> for an ecore model it typically produces 3 plugins:
> 1) model plugin
> 2) edit plugin (command framework integration)
> 3) editor plugin (Eclipse UI)
>
> When I say "at the model level" I really mean that only 1) is needed for
> integration. AFAIK EMF Transaction needs 1) plus 2) for its integration
> because it intercepts commands of the command framework.
>
>> Is there facilities for plugging in Model to Model translation
>> facilities so that one could sync heterogeneous models to one
>> repository?
> I'm lost. Could you please elaborate on "Model to Model translation
> facilities" and "heterogeneous models"?
>
>> My mind has not been expanded as of yet to all the possibilities with
>> CDO, but I am wondering if CDO may be able to offer an infrastructure
>> for models what XProc http://www.w3.org/TR/2007/WD-xproc-20071129/
>> is offering for XML docs?
> I'm really not familiar with XProc. The abstract says "[...] a language
> for describing operations to be performed on XML documents". From this
> I'd say, no, CDO focusses more on the static aspects of a model than on
> the possible operations that could modeify a model over time. May be you
> can list some specific details of the XProc spec (which I've not read as
> a whole) that you're interested in?
>
>>>> [stuff deleted]
>>> Good point! Would you be willing to contribute such a connector? If
>>> so, please open an enhancement request in Bugzilla and attach a patch
>>> (since Net4j is already extensible in the dimension of transports a
>>> patch might not be needed and you can simply attach the extension
>>> bundle project). I'd be happy to maintain the code after ;-)
>>
>> Have several activities scheduled right now, but I am interested
>> enough to contribute with either a comm port transport or a Bluetooth
>> one. The problem I for see with either one of these solutions is that
>> I expect there will be OS library dependencies that will have to be
>> bundled with the code. This is something I have not done before.
> OSGi should be prepared for this ;-)
>>
>> Will start looking into this next month.
> That'd be great! Please tell me when you need my assistance...
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
>>>> That said, a connector implementation for comm ports should be easy,
>>>> as easy as the usage of comm ports is in Java (which I have no idea
>>>> of).
>>>> I have not done this myself, so I don't know how easy the lower
>>>> layer will be. Would probably do the http://www.rxtx.org/ versus
>>>> Sun's impl.
>>>>
>>>> As
>>>>> the docs of IConnector state you'll have to subclass Connector (
>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j/src/org/eclipse /internal/net4j/Connector.java?root=Modeling_Project&vie w=log)
>>>>> . I suggest to look at the implementation of TCPConnector (
>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j.tcp/src/org/ecl ipse/net4j/internal/tcp/TCPConnector.java?root=Modeling_Proj ect&view=log
>>>>> ).
>>>>>
>>>>> As I said above, if you succeed in providing a comm port
>>>>> implementation of IConnector (and the supporting factories) you'll
>>>>> get EMF integration for free ;-)
>>>>
>>>> Sounds good, but will I need to also install a database to get EMF
>>>> integration?
>>> Good question! According to the 'normal' setup of a CDO deployment,
>>> yes. But CDO should be open and layered enuogh to find a solution
>>> that uses only the model integration parts. I haven't thought about
>>> such usage so far.
>>
>>
>> kind regards,
>> John Conlon
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #612839 is a reply to message #104788] |
Mon, 17 December 2007 10:25 |
|
Hi Martin,
comments below...
Martin Taal schrieb:
> Hi Eike, John,
> Just to add my thoughts about Teneo :-).
> Teneo is very much focused on being a persistence solution for
> persisting (complex) models to a relational store. This focus means
> that Teneo has broad support for most complex modeling constructs (for
> example feature maps, xml schema anytype, mixed type, etc.) and
> support for jpa annotations in the model. On the other hand this focus
> also means that Teneo does not include specific client-server
> functionality, this is outside of the scope of Teneo.
> So I would not say that Teneo is a client side solution (I use Teneo
> server side in a web app). Teneo can also be used server side (in a
> rcp app) but then you need to implement your own client-server layer
> (using other tools).
These client/server things are so ambiguous like the model/meta model
things depending on the start point ;-)
But with your clarification the main difference between CDO and Teneo
should be clear now.
> Btw, it would be interesting to integrate the client-server
> capabilities of CDO/net4j with the mapping capabilities of Teneo. I
> think this can be a powerfull combination...
That'd be of course an interesting effort. What do you think could be
the result of such an effort?
Simon (cc'ed) and I often discussed this topic and I seem to remember
that we (you and I) also spoke about such integration.
The result that I'd wish from such an integration would clearly be a CDO
storage framework implementation that uses Hibernate as O/R mapper. I
fear that your general experience with Hibernate can be more helpful
than your actual product Teneo. But I'd be glad to be proven wrong here.
The following is the reason (correct me if I'm wrong):
- Teneos main purpose (with respect to Hibernate) is the integration of
EMF Resources and EObjects with a Hibernate mapped database. In other
words you directly map EMF concepts to/from Hibernate concepts in one
deployment node (client or server).
- CDO wishes Hibernate mapping at its server side
- At the server side of CDO there are no EMF concepts. The CDO (network)
protocol doesn't deal with EMF concepts. The state of EObjects is
translated into non-EMF data structures at client side.
- The non-EMF data structures that represent EObject state at the server
can't easily mapped by Teneo (since Teneo deals with EMF concepts).
Would you agree?
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
>
> gr. Martin
>
> Eike Stepper wrote:
>> John E. Conlon schrieb:
>>>> [stuff deleted]
>>>>> How does CDO compare to Teneo?
>>>> I'd say the main difference is the deployment strategy. While Teneo
>>>> (I'm not a Teneo expert!) is mainly used on the client side (with
>>>> hibernate/jpox generated JDBC on the wire) CDO is is used on the
>>>> client side for EMF model integration and on the server side for
>>>> the storage integration (O/R mapping, OODB integration). CDO uses
>>>> an own (Net4j based) wire protocol which is tailored to
>>>> transactional semantics in the context of objects (not SQL). Since
>>>> CDO clients rely on a dedicated CDO server they can offer some
>>>> additional functions not available with Teneo, like automatic model
>>>> update on all clients if one client commits a transaction
>>>> (distributed shared model semantics).
>>>
>>> So Teneo is more of a client side persistence alternative and CDO is
>>> a model repository server!
>> Right.
>>
>>> Is CDO the only Eclipse Modeling project making this claim?
>> AFAIK, yes.
>>
>>> Side question:
>>> Since models are persisted to a repository server (a rdbms) has
>>> anyone experimented with plugging in BIRT to this rdbms so end
>>> user's could be given reporting support? In other words are the
>>> final relational schemas human readable and understandable enough
>>> for report designers to work with?
>> Interesting question because I just discussed that topic with a
>> friend of mine. I cc'ed Philipp for this purpose.
>>
>> 1) A CDO server mainly consists of three parts/layers: A protocol
>> peer (Net4j based), a model repository framework (storage agnostic)
>> and a storage framework. It depends on the storage implementation
>> (IStore) how the model data is actually persisted to a storage
>> backend. This *can* be an RDBMS via plain JDBC (default) but a user
>> has also implemented an Objectivity store (OODBMS) and plans to
>> implement a Hibernate based store.
>>
>> 2) In case the default JDBC store is used with a repository I'd say
>> yes, the generated schema is human readable and understandable enough
>> for report designers to work with but that is my own opinion.
>> Currently CDO always uses its own generated primary keys (long id
>> values) and references are mostly always stored in a fixed format
>> that allows for transparent versioning.
>>
>> 3) I'd prefer to see a model/BIRT integration at the model side (CDO
>> client) rather than at the DB side (one of several possible CDO
>> storage backends and highly implementation dependent). I'm neither a
>> BIRT nor an ODA expert but is it not possible to use an EMF
>> ResourceSet, a Resource or an EObject as an ODA data source? That'd
>> be much closer to the semantics of the model than querying the mapped
>> DB.
>>
>>>>> Does CDO use the EMF transaction framework?
>>>> No, CDO acts directly on the model level. EMF Transaction acts on
>>>> the higher edit/command framework level which, in my opinion, has
>>>> at least two disadvantages:
>>>> 1) Not all clients want to use a command stack to interact with
>>>> models (especially non-UI clients like batch clients). With CDO
>>>> these clients can remain unchanged (are not forced to use a command
>>>> stack) and since CDO transactions are transparent to the command
>>>> stack UI clients can be used, too.
>>>> 2) Worse, command stack based transactions rely on the cooperation
>>>> of *all* clients of a model. If only one client doesn't use a
>>>> command stack or uses a non-transactional command stack all
>>>> transactions might become corrupt! Since CDO integrates with EMF
>>>> models at their core none of these restrictions apply.
>>>>
>>>
>>>
>>> When you say CDO works at the model level, does that mean entire
>>> models are moved from client to server?
>> I'm not sure if I correctly understand the intend of your question.
>> The scope of a CDO transaction is always an EMF ResourceSet (no
>> command stack needed). This ResourceSet can contain multiple CDO
>> Resources (and possibly other types of Resources). At the time of
>> committing the transaction no CDO Resource is allowed to contain
>> references to non-CDO Resources. In other words a CDO repository is
>> always guaranteed to contain a consistent state of an object graph
>> that can be partitioned into CDO Resources. Looking from the other
>> side a CDO-prepared ResourceSet acts like a partial but
>> self-populating view onto the whole object graph of the repository.
>>
>> So in this sense, yes, entire models are (initially) moved from
>> client to server. Once a model is committed into the repository
>> subsequent reads and writes (commits) act at least at an object
>> granularity. A recent effort of a user added support for sending only
>> deltas for changed objects to the server, see
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=201266 .
>>
>> I guess I should stop saying "at the model level" because the word
>> "model" is one of the only four terms we have available in modern
>> software engineering, ambiguities granted ;-)
>> The reason I used it is the following. When you kick the EMF
>> generator for an ecore model it typically produces 3 plugins:
>> 1) model plugin
>> 2) edit plugin (command framework integration)
>> 3) editor plugin (Eclipse UI)
>>
>> When I say "at the model level" I really mean that only 1) is needed
>> for integration. AFAIK EMF Transaction needs 1) plus 2) for its
>> integration because it intercepts commands of the command framework.
>>
>>> Is there facilities for plugging in Model to Model translation
>>> facilities so that one could sync heterogeneous models to one
>>> repository?
>> I'm lost. Could you please elaborate on "Model to Model translation
>> facilities" and "heterogeneous models"?
>>
>>> My mind has not been expanded as of yet to all the possibilities
>>> with CDO, but I am wondering if CDO may be able to offer an
>>> infrastructure for models what XProc
>>> http://www.w3.org/TR/2007/WD-xproc-20071129/
>>> is offering for XML docs?
>> I'm really not familiar with XProc. The abstract says "[...] a
>> language for describing operations to be performed on XML documents".
>> From this I'd say, no, CDO focusses more on the static aspects of a
>> model than on the possible operations that could modeify a model over
>> time. May be you can list some specific details of the XProc spec
>> (which I've not read as a whole) that you're interested in?
>>
>>>>> [stuff deleted]
>>>> Good point! Would you be willing to contribute such a connector? If
>>>> so, please open an enhancement request in Bugzilla and attach a
>>>> patch (since Net4j is already extensible in the dimension of
>>>> transports a patch might not be needed and you can simply attach
>>>> the extension bundle project). I'd be happy to maintain the code
>>>> after ;-)
>>>
>>> Have several activities scheduled right now, but I am interested
>>> enough to contribute with either a comm port transport or a
>>> Bluetooth one. The problem I for see with either one of these
>>> solutions is that I expect there will be OS library dependencies
>>> that will have to be bundled with the code. This is something I have
>>> not done before.
>> OSGi should be prepared for this ;-)
>>>
>>> Will start looking into this next month.
>> That'd be great! Please tell me when you need my assistance...
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>>>>> That said, a connector implementation for comm ports should be
>>>>> easy, as easy as the usage of comm ports is in Java (which I have
>>>>> no idea of).
>>>>> I have not done this myself, so I don't know how easy the lower
>>>>> layer will be. Would probably do the http://www.rxtx.org/ versus
>>>>> Sun's impl.
>>>>>
>>>>> As
>>>>>> the docs of IConnector state you'll have to subclass Connector (
>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j/src/org/eclipse /internal/net4j/Connector.java?root=Modeling_Project&vie w=log)
>>>>>> . I suggest to look at the implementation of TCPConnector (
>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j.tcp/src/org/ecl ipse/net4j/internal/tcp/TCPConnector.java?root=Modeling_Proj ect&view=log
>>>>>> ).
>>>>>>
>>>>>> As I said above, if you succeed in providing a comm port
>>>>>> implementation of IConnector (and the supporting factories)
>>>>>> you'll get EMF integration for free ;-)
>>>>>
>>>>> Sounds good, but will I need to also install a database to get EMF
>>>>> integration?
>>>> Good question! According to the 'normal' setup of a CDO deployment,
>>>> yes. But CDO should be open and layered enuogh to find a solution
>>>> that uses only the model integration parts. I haven't thought about
>>>> such usage so far.
>>>
>>>
>>> kind regards,
>>> John Conlon
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #612855 is a reply to message #104801] |
Mon, 17 December 2007 22:09 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Eike,
Just to continue on your last points (otherwise the post becomes unreadable to me):
- Teneos main purpose (with respect to Hibernate) is the integration of EMF Resources and EObjects
with a Hibernate mapped database. In other words you directly map EMF concepts to/from Hibernate
concepts in one deployment node (client or server).
MT>> Almost :-), Teneo consists of two main parts:
1) Mapping functionality: maps a model to a relational schema (in fact maps a model to a java
persistence api annotated model which is then translated to a hibernate mapping). The user can
override standard mapping behavior by adding jpa annotations in the model.
2) At runtime provide easy integration between EMF and hibernate (or jpox). This part is mainly to
support automatic mapping (so using the above functionality 1) when initializing and support emf
specifics such as featuremaps, elists and emf resources.
Currently Teneo has 2 runtime layers one for jpox and one for hibernate. It would be interesting to
add other runtime layers.
Btw, I use the mapping functionality of Teneo also outside of EMF: I map the model using Teneo and
then at runtime I have non-emf objects.
- CDO wishes Hibernate mapping at its server side
- At the server side of CDO there are no EMF concepts. The CDO (network) protocol doesn't deal with
EMF concepts. The state of EObjects is translated into non-EMF data structures at client side.
MT>> But still because you currently also create a relational schema, I assume that the server also
has knowledge of the ecore model. I can imagine also that your non-emf data structure refer to this
model?
- The non-EMF data structures that represent EObject state at the server can't easily mapped by
Teneo (since Teneo deals with EMF concepts).
MT>> Not sure if this is an obstacle. I assume that also for the CDO non-emf datastructures there is
a relation to the application model expressed in ecore. Teneo also uses the ecore model as its basis
for mapping to hibernate. So as long as there is a relation between your non-emf datastructure and
the ecore model then a runtime layer which uses the Teneo mapping logic should be pretty doable.
For example next to Teneo I am working on generating seam web applications from ecore models. To
support the persistence side I use Teneo for the mapping and as runtime I have a dynamic-emf-like
object (basically a type-safe hashmap). The runtime layer is about 15 classes.
gr. Martin
Eike Stepper wrote:
> Hi Martin,
>
> comments below...
>
>
> Martin Taal schrieb:
>> Hi Eike, John,
>> Just to add my thoughts about Teneo :-).
>> Teneo is very much focused on being a persistence solution for
>> persisting (complex) models to a relational store. This focus means
>> that Teneo has broad support for most complex modeling constructs (for
>> example feature maps, xml schema anytype, mixed type, etc.) and
>> support for jpa annotations in the model. On the other hand this focus
>> also means that Teneo does not include specific client-server
>> functionality, this is outside of the scope of Teneo.
>> So I would not say that Teneo is a client side solution (I use Teneo
>> server side in a web app). Teneo can also be used server side (in a
>> rcp app) but then you need to implement your own client-server layer
>> (using other tools).
> These client/server things are so ambiguous like the model/meta model
> things depending on the start point ;-)
> But with your clarification the main difference between CDO and Teneo
> should be clear now.
>
>> Btw, it would be interesting to integrate the client-server
>> capabilities of CDO/net4j with the mapping capabilities of Teneo. I
>> think this can be a powerfull combination...
> That'd be of course an interesting effort. What do you think could be
> the result of such an effort?
>
> Simon (cc'ed) and I often discussed this topic and I seem to remember
> that we (you and I) also spoke about such integration.
> The result that I'd wish from such an integration would clearly be a CDO
> storage framework implementation that uses Hibernate as O/R mapper. I
> fear that your general experience with Hibernate can be more helpful
> than your actual product Teneo. But I'd be glad to be proven wrong here.
> The following is the reason (correct me if I'm wrong):
> - Teneos main purpose (with respect to Hibernate) is the integration of
> EMF Resources and EObjects with a Hibernate mapped database. In other
> words you directly map EMF concepts to/from Hibernate concepts in one
> deployment node (client or server).
> - CDO wishes Hibernate mapping at its server side
> - At the server side of CDO there are no EMF concepts. The CDO (network)
> protocol doesn't deal with EMF concepts. The state of EObjects is
> translated into non-EMF data structures at client side.
> - The non-EMF data structures that represent EObject state at the server
> can't easily mapped by Teneo (since Teneo deals with EMF concepts).
>
> Would you agree?
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
>>
>> gr. Martin
>>
>> Eike Stepper wrote:
>>> John E. Conlon schrieb:
>>>>> [stuff deleted]
>>>>>> How does CDO compare to Teneo?
>>>>> I'd say the main difference is the deployment strategy. While Teneo
>>>>> (I'm not a Teneo expert!) is mainly used on the client side (with
>>>>> hibernate/jpox generated JDBC on the wire) CDO is is used on the
>>>>> client side for EMF model integration and on the server side for
>>>>> the storage integration (O/R mapping, OODB integration). CDO uses
>>>>> an own (Net4j based) wire protocol which is tailored to
>>>>> transactional semantics in the context of objects (not SQL). Since
>>>>> CDO clients rely on a dedicated CDO server they can offer some
>>>>> additional functions not available with Teneo, like automatic model
>>>>> update on all clients if one client commits a transaction
>>>>> (distributed shared model semantics).
>>>>
>>>> So Teneo is more of a client side persistence alternative and CDO is
>>>> a model repository server!
>>> Right.
>>>
>>>> Is CDO the only Eclipse Modeling project making this claim?
>>> AFAIK, yes.
>>>
>>>> Side question:
>>>> Since models are persisted to a repository server (a rdbms) has
>>>> anyone experimented with plugging in BIRT to this rdbms so end
>>>> user's could be given reporting support? In other words are the
>>>> final relational schemas human readable and understandable enough
>>>> for report designers to work with?
>>> Interesting question because I just discussed that topic with a
>>> friend of mine. I cc'ed Philipp for this purpose.
>>>
>>> 1) A CDO server mainly consists of three parts/layers: A protocol
>>> peer (Net4j based), a model repository framework (storage agnostic)
>>> and a storage framework. It depends on the storage implementation
>>> (IStore) how the model data is actually persisted to a storage
>>> backend. This *can* be an RDBMS via plain JDBC (default) but a user
>>> has also implemented an Objectivity store (OODBMS) and plans to
>>> implement a Hibernate based store.
>>>
>>> 2) In case the default JDBC store is used with a repository I'd say
>>> yes, the generated schema is human readable and understandable enough
>>> for report designers to work with but that is my own opinion.
>>> Currently CDO always uses its own generated primary keys (long id
>>> values) and references are mostly always stored in a fixed format
>>> that allows for transparent versioning.
>>>
>>> 3) I'd prefer to see a model/BIRT integration at the model side (CDO
>>> client) rather than at the DB side (one of several possible CDO
>>> storage backends and highly implementation dependent). I'm neither a
>>> BIRT nor an ODA expert but is it not possible to use an EMF
>>> ResourceSet, a Resource or an EObject as an ODA data source? That'd
>>> be much closer to the semantics of the model than querying the mapped
>>> DB.
>>>
>>>>>> Does CDO use the EMF transaction framework?
>>>>> No, CDO acts directly on the model level. EMF Transaction acts on
>>>>> the higher edit/command framework level which, in my opinion, has
>>>>> at least two disadvantages:
>>>>> 1) Not all clients want to use a command stack to interact with
>>>>> models (especially non-UI clients like batch clients). With CDO
>>>>> these clients can remain unchanged (are not forced to use a command
>>>>> stack) and since CDO transactions are transparent to the command
>>>>> stack UI clients can be used, too.
>>>>> 2) Worse, command stack based transactions rely on the cooperation
>>>>> of *all* clients of a model. If only one client doesn't use a
>>>>> command stack or uses a non-transactional command stack all
>>>>> transactions might become corrupt! Since CDO integrates with EMF
>>>>> models at their core none of these restrictions apply.
>>>>>
>>>>
>>>>
>>>> When you say CDO works at the model level, does that mean entire
>>>> models are moved from client to server?
>>> I'm not sure if I correctly understand the intend of your question.
>>> The scope of a CDO transaction is always an EMF ResourceSet (no
>>> command stack needed). This ResourceSet can contain multiple CDO
>>> Resources (and possibly other types of Resources). At the time of
>>> committing the transaction no CDO Resource is allowed to contain
>>> references to non-CDO Resources. In other words a CDO repository is
>>> always guaranteed to contain a consistent state of an object graph
>>> that can be partitioned into CDO Resources. Looking from the other
>>> side a CDO-prepared ResourceSet acts like a partial but
>>> self-populating view onto the whole object graph of the repository.
>>>
>>> So in this sense, yes, entire models are (initially) moved from
>>> client to server. Once a model is committed into the repository
>>> subsequent reads and writes (commits) act at least at an object
>>> granularity. A recent effort of a user added support for sending only
>>> deltas for changed objects to the server, see
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=201266 .
>>>
>>> I guess I should stop saying "at the model level" because the word
>>> "model" is one of the only four terms we have available in modern
>>> software engineering, ambiguities granted ;-)
>>> The reason I used it is the following. When you kick the EMF
>>> generator for an ecore model it typically produces 3 plugins:
>>> 1) model plugin
>>> 2) edit plugin (command framework integration)
>>> 3) editor plugin (Eclipse UI)
>>>
>>> When I say "at the model level" I really mean that only 1) is needed
>>> for integration. AFAIK EMF Transaction needs 1) plus 2) for its
>>> integration because it intercepts commands of the command framework.
>>>
>>>> Is there facilities for plugging in Model to Model translation
>>>> facilities so that one could sync heterogeneous models to one
>>>> repository?
>>> I'm lost. Could you please elaborate on "Model to Model translation
>>> facilities" and "heterogeneous models"?
>>>
>>>> My mind has not been expanded as of yet to all the possibilities
>>>> with CDO, but I am wondering if CDO may be able to offer an
>>>> infrastructure for models what XProc
>>>> http://www.w3.org/TR/2007/WD-xproc-20071129/
>>>> is offering for XML docs?
>>> I'm really not familiar with XProc. The abstract says "[...] a
>>> language for describing operations to be performed on XML documents".
>>> From this I'd say, no, CDO focusses more on the static aspects of a
>>> model than on the possible operations that could modeify a model over
>>> time. May be you can list some specific details of the XProc spec
>>> (which I've not read as a whole) that you're interested in?
>>>
>>>>>> [stuff deleted]
>>>>> Good point! Would you be willing to contribute such a connector? If
>>>>> so, please open an enhancement request in Bugzilla and attach a
>>>>> patch (since Net4j is already extensible in the dimension of
>>>>> transports a patch might not be needed and you can simply attach
>>>>> the extension bundle project). I'd be happy to maintain the code
>>>>> after ;-)
>>>>
>>>> Have several activities scheduled right now, but I am interested
>>>> enough to contribute with either a comm port transport or a
>>>> Bluetooth one. The problem I for see with either one of these
>>>> solutions is that I expect there will be OS library dependencies
>>>> that will have to be bundled with the code. This is something I have
>>>> not done before.
>>> OSGi should be prepared for this ;-)
>>>>
>>>> Will start looking into this next month.
>>> That'd be great! Please tell me when you need my assistance...
>>>
>>> Regards,
>>> Eike Stepper
>>> ----
>>> http://wiki.eclipse.org/CDO
>>> http://wiki.eclipse.org/Net4j
>>>
>>>
>>>>>> That said, a connector implementation for comm ports should be
>>>>>> easy, as easy as the usage of comm ports is in Java (which I have
>>>>>> no idea of).
>>>>>> I have not done this myself, so I don't know how easy the lower
>>>>>> layer will be. Would probably do the http://www.rxtx.org/ versus
>>>>>> Sun's impl.
>>>>>>
>>>>>> As
>>>>>>> the docs of IConnector state you'll have to subclass Connector (
>>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j/src/org/eclipse /internal/net4j/Connector.java?root=Modeling_Project&vie w=log)
>>>>>>> . I suggest to look at the implementation of TCPConnector (
>>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j.tcp/src/org/ecl ipse/net4j/internal/tcp/TCPConnector.java?root=Modeling_Proj ect&view=log
>>>>>>> ).
>>>>>>>
>>>>>>> As I said above, if you succeed in providing a comm port
>>>>>>> implementation of IConnector (and the supporting factories)
>>>>>>> you'll get EMF integration for free ;-)
>>>>>>
>>>>>> Sounds good, but will I need to also install a database to get EMF
>>>>>> integration?
>>>>> Good question! According to the 'normal' setup of a CDO deployment,
>>>>> yes. But CDO should be open and layered enuogh to find a solution
>>>>> that uses only the model integration parts. I haven't thought about
>>>>> such usage so far.
>>>>
>>>>
>>>> kind regards,
>>>> John Conlon
>>
>>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #612863 is a reply to message #104865] |
Tue, 18 December 2007 10:32 |
|
Martin Taal schrieb:
> Hi Eike,
> Just to continue on your last points (otherwise the post becomes
> unreadable to me):
> - Teneos main purpose (with respect to Hibernate) is the integration
> of EMF Resources and EObjects with a Hibernate mapped database. In
> other words you directly map EMF concepts to/from Hibernate concepts
> in one deployment node (client or server).
> MT>> Almost :-), Teneo consists of two main parts:
> 1) Mapping functionality: maps a model to a relational schema (in fact
> maps a model to a java persistence api annotated model which is then
> translated to a hibernate mapping). The user can override standard
> mapping behavior by adding jpa annotations in the model.
> 2) At runtime provide easy integration between EMF and hibernate (or
> jpox). This part is mainly to support automatic mapping (so using the
> above functionality 1) when initializing and support emf specifics
> such as featuremaps, elists and emf resources.
That makes sense ;-)
> Currently Teneo has 2 runtime layers one for jpox and one for
> hibernate. It would be interesting to add other runtime layers.
Ok, there I can see a chance for CDO. It would be completely covered by
your runtime framework, right?
> Btw, I use the mapping functionality of Teneo also outside of EMF: I
> map the model using Teneo and then at runtime I have non-emf objects.
>
> - CDO wishes Hibernate mapping at its server side
> - At the server side of CDO there are no EMF concepts. The CDO
> (network) protocol doesn't deal with EMF concepts. The state of
> EObjects is translated into non-EMF data structures at client side.
> MT>> But still because you currently also create a relational schema,
> I assume that the server also has knowledge of the ecore model.
Right, at the client there are bijective conversions between:
EPackage <-> CDOPackage
EClass <-> CDOClass
EStructuralFeature <-> CDOFeature
So I'd say a simplified version of the Ecore model arrives at the server
and is usually stored in an IStore of the CDO storage framework (can be
RDB). BTW. it's even possible to retrieve the XMI string of the original
Ecore model from a CDOPackage.
> I can imagine also that your non-emf data structure refer to this model?
Right, there's a method CDORevision.getCDOClass().
> - The non-EMF data structures that represent EObject state at the
> server can't easily mapped by Teneo (since Teneo deals with EMF
> concepts).
> MT>> Not sure if this is an obstacle. I assume that also for the CDO
> non-emf datastructures there is a relation to the application model
> expressed in ecore. Teneo also uses the ecore model as its basis for
> mapping to hibernate. So as long as there is a relation between your
> non-emf datastructure and the ecore model then a runtime layer which
> uses the Teneo mapping logic should be pretty doable.
That's great to hear. But we have to double check:
CDO (at client side) converts in both directions between an Ecore model
and its internal representation of this model. I think this is the
relation you mean. At CDO's server side there's usually no such
conversion because there's simply no EMF (required).
BUT: since the Ecore XMI string can be retrieved from the repository via
CDOPackage I think a Teneo based IStore implementation could add EMF to
its dependencies, deserialize the original Ecore model and apply the
same E<->CDO conversion as the CDO client.
That sounds reasonable to me. Agreed so far?
I'd have to factor out the conversion mechanism into a separate plugin...
> For example next to Teneo I am working on generating seam web
> applications from ecore models. To support the persistence side I use
> Teneo for the mapping and as runtime I have a dynamic-emf-like object
> (basically a type-safe hashmap). The runtime layer is about 15 classes.
That sounds similar to the CDO server although it has one or two more
classes ;-)
To sum up:
- It seems as we we (out products) could both profit from working together.
- There could be a Teneo with CDO under the runtime hood [A]
- There could be a CDO server with a Teneo-based IStore [B]
- We are willing to spend effort for this ;-)
If you agree up to here we should discuss how we start and who should do
what. I had a similar integration story with Net4j <-> ECF and I learned
that it is often easier to *use* foreign API than to *extend* it. That
also results in the author of the integration being the maintainer.
For [A] that would mean that primarily you would extend your runtime
framework by using CDO API (with my help of course).
For [B] that would mean that primarily I would extend my storage
framework by implementing the above conversions at server side and then
using Teneo API (with your help).
I guess that on the way we'll discover some more challenges ;-)
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
>
> gr. Martin
>
> Eike Stepper wrote:
>> Hi Martin,
>>
>> comments below...
>>
>>
>> Martin Taal schrieb:
>>> Hi Eike, John,
>>> Just to add my thoughts about Teneo :-).
>>> Teneo is very much focused on being a persistence solution for
>>> persisting (complex) models to a relational store. This focus means
>>> that Teneo has broad support for most complex modeling constructs
>>> (for example feature maps, xml schema anytype, mixed type, etc.) and
>>> support for jpa annotations in the model. On the other hand this
>>> focus also means that Teneo does not include specific client-server
>>> functionality, this is outside of the scope of Teneo.
>>> So I would not say that Teneo is a client side solution (I use Teneo
>>> server side in a web app). Teneo can also be used server side (in a
>>> rcp app) but then you need to implement your own client-server layer
>>> (using other tools).
>> These client/server things are so ambiguous like the model/meta model
>> things depending on the start point ;-)
>> But with your clarification the main difference between CDO and Teneo
>> should be clear now.
>>
>>> Btw, it would be interesting to integrate the client-server
>>> capabilities of CDO/net4j with the mapping capabilities of Teneo. I
>>> think this can be a powerfull combination...
>> That'd be of course an interesting effort. What do you think could be
>> the result of such an effort?
>>
>> Simon (cc'ed) and I often discussed this topic and I seem to remember
>> that we (you and I) also spoke about such integration.
>> The result that I'd wish from such an integration would clearly be a
>> CDO storage framework implementation that uses Hibernate as O/R
>> mapper. I fear that your general experience with Hibernate can be
>> more helpful than your actual product Teneo. But I'd be glad to be
>> proven wrong here. The following is the reason (correct me if I'm
>> wrong):
>> - Teneos main purpose (with respect to Hibernate) is the integration
>> of EMF Resources and EObjects with a Hibernate mapped database. In
>> other words you directly map EMF concepts to/from Hibernate concepts
>> in one deployment node (client or server).
>> - CDO wishes Hibernate mapping at its server side
>> - At the server side of CDO there are no EMF concepts. The CDO
>> (network) protocol doesn't deal with EMF concepts. The state of
>> EObjects is translated into non-EMF data structures at client side.
>> - The non-EMF data structures that represent EObject state at the
>> server can't easily mapped by Teneo (since Teneo deals with EMF
>> concepts).
>>
>> Would you agree?
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>>>
>>> gr. Martin
>>>
>>> Eike Stepper wrote:
>>>> John E. Conlon schrieb:
>>>>>> [stuff deleted]
>>>>>>> How does CDO compare to Teneo?
>>>>>> I'd say the main difference is the deployment strategy. While
>>>>>> Teneo (I'm not a Teneo expert!) is mainly used on the client side
>>>>>> (with hibernate/jpox generated JDBC on the wire) CDO is is used
>>>>>> on the client side for EMF model integration and on the server
>>>>>> side for the storage integration (O/R mapping, OODB integration).
>>>>>> CDO uses an own (Net4j based) wire protocol which is tailored to
>>>>>> transactional semantics in the context of objects (not SQL).
>>>>>> Since CDO clients rely on a dedicated CDO server they can offer
>>>>>> some additional functions not available with Teneo, like
>>>>>> automatic model update on all clients if one client commits a
>>>>>> transaction (distributed shared model semantics).
>>>>>
>>>>> So Teneo is more of a client side persistence alternative and CDO
>>>>> is a model repository server!
>>>> Right.
>>>>
>>>>> Is CDO the only Eclipse Modeling project making this claim?
>>>> AFAIK, yes.
>>>>
>>>>> Side question:
>>>>> Since models are persisted to a repository server (a rdbms) has
>>>>> anyone experimented with plugging in BIRT to this rdbms so end
>>>>> user's could be given reporting support? In other words are the
>>>>> final relational schemas human readable and understandable enough
>>>>> for report designers to work with?
>>>> Interesting question because I just discussed that topic with a
>>>> friend of mine. I cc'ed Philipp for this purpose.
>>>>
>>>> 1) A CDO server mainly consists of three parts/layers: A protocol
>>>> peer (Net4j based), a model repository framework (storage agnostic)
>>>> and a storage framework. It depends on the storage implementation
>>>> (IStore) how the model data is actually persisted to a storage
>>>> backend. This *can* be an RDBMS via plain JDBC (default) but a user
>>>> has also implemented an Objectivity store (OODBMS) and plans to
>>>> implement a Hibernate based store.
>>>>
>>>> 2) In case the default JDBC store is used with a repository I'd say
>>>> yes, the generated schema is human readable and understandable
>>>> enough for report designers to work with but that is my own
>>>> opinion. Currently CDO always uses its own generated primary keys
>>>> (long id values) and references are mostly always stored in a fixed
>>>> format that allows for transparent versioning.
>>>>
>>>> 3) I'd prefer to see a model/BIRT integration at the model side
>>>> (CDO client) rather than at the DB side (one of several possible
>>>> CDO storage backends and highly implementation dependent). I'm
>>>> neither a BIRT nor an ODA expert but is it not possible to use an
>>>> EMF ResourceSet, a Resource or an EObject as an ODA data source?
>>>> That'd be much closer to the semantics of the model than querying
>>>> the mapped DB.
>>>>
>>>>>>> Does CDO use the EMF transaction framework?
>>>>>> No, CDO acts directly on the model level. EMF Transaction acts on
>>>>>> the higher edit/command framework level which, in my opinion, has
>>>>>> at least two disadvantages:
>>>>>> 1) Not all clients want to use a command stack to interact with
>>>>>> models (especially non-UI clients like batch clients). With CDO
>>>>>> these clients can remain unchanged (are not forced to use a
>>>>>> command stack) and since CDO transactions are transparent to the
>>>>>> command stack UI clients can be used, too.
>>>>>> 2) Worse, command stack based transactions rely on the
>>>>>> cooperation of *all* clients of a model. If only one client
>>>>>> doesn't use a command stack or uses a non-transactional command
>>>>>> stack all transactions might become corrupt! Since CDO integrates
>>>>>> with EMF models at their core none of these restrictions apply.
>>>>>>
>>>>>
>>>>>
>>>>> When you say CDO works at the model level, does that mean entire
>>>>> models are moved from client to server?
>>>> I'm not sure if I correctly understand the intend of your question.
>>>> The scope of a CDO transaction is always an EMF ResourceSet (no
>>>> command stack needed). This ResourceSet can contain multiple CDO
>>>> Resources (and possibly other types of Resources). At the time of
>>>> committing the transaction no CDO Resource is allowed to contain
>>>> references to non-CDO Resources. In other words a CDO repository is
>>>> always guaranteed to contain a consistent state of an object graph
>>>> that can be partitioned into CDO Resources. Looking from the other
>>>> side a CDO-prepared ResourceSet acts like a partial but
>>>> self-populating view onto the whole object graph of the repository.
>>>>
>>>> So in this sense, yes, entire models are (initially) moved from
>>>> client to server. Once a model is committed into the repository
>>>> subsequent reads and writes (commits) act at least at an object
>>>> granularity. A recent effort of a user added support for sending
>>>> only deltas for changed objects to the server, see
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=201266 .
>>>>
>>>> I guess I should stop saying "at the model level" because the word
>>>> "model" is one of the only four terms we have available in modern
>>>> software engineering, ambiguities granted ;-)
>>>> The reason I used it is the following. When you kick the EMF
>>>> generator for an ecore model it typically produces 3 plugins:
>>>> 1) model plugin
>>>> 2) edit plugin (command framework integration)
>>>> 3) editor plugin (Eclipse UI)
>>>>
>>>> When I say "at the model level" I really mean that only 1) is
>>>> needed for integration. AFAIK EMF Transaction needs 1) plus 2) for
>>>> its integration because it intercepts commands of the command
>>>> framework.
>>>>
>>>>> Is there facilities for plugging in Model to Model translation
>>>>> facilities so that one could sync heterogeneous models to one
>>>>> repository?
>>>> I'm lost. Could you please elaborate on "Model to Model translation
>>>> facilities" and "heterogeneous models"?
>>>>
>>>>> My mind has not been expanded as of yet to all the possibilities
>>>>> with CDO, but I am wondering if CDO may be able to offer an
>>>>> infrastructure for models what XProc
>>>>> http://www.w3.org/TR/2007/WD-xproc-20071129/
>>>>> is offering for XML docs?
>>>> I'm really not familiar with XProc. The abstract says "[...] a
>>>> language for describing operations to be performed on XML
>>>> documents". From this I'd say, no, CDO focusses more on the static
>>>> aspects of a model than on the possible operations that could
>>>> modeify a model over time. May be you can list some specific
>>>> details of the XProc spec (which I've not read as a whole) that
>>>> you're interested in?
>>>>
>>>>>>> [stuff deleted]
>>>>>> Good point! Would you be willing to contribute such a connector?
>>>>>> If so, please open an enhancement request in Bugzilla and attach
>>>>>> a patch (since Net4j is already extensible in the dimension of
>>>>>> transports a patch might not be needed and you can simply attach
>>>>>> the extension bundle project). I'd be happy to maintain the code
>>>>>> after ;-)
>>>>>
>>>>> Have several activities scheduled right now, but I am interested
>>>>> enough to contribute with either a comm port transport or a
>>>>> Bluetooth one. The problem I for see with either one of these
>>>>> solutions is that I expect there will be OS library dependencies
>>>>> that will have to be bundled with the code. This is something I
>>>>> have not done before.
>>>> OSGi should be prepared for this ;-)
>>>>>
>>>>> Will start looking into this next month.
>>>> That'd be great! Please tell me when you need my assistance...
>>>>
>>>> Regards,
>>>> Eike Stepper
>>>> ----
>>>> http://wiki.eclipse.org/CDO
>>>> http://wiki.eclipse.org/Net4j
>>>>
>>>>
>>>>>>> That said, a connector implementation for comm ports should be
>>>>>>> easy, as easy as the usage of comm ports is in Java (which I
>>>>>>> have no idea of).
>>>>>>> I have not done this myself, so I don't know how easy the lower
>>>>>>> layer will be. Would probably do the http://www.rxtx.org/
>>>>>>> versus Sun's impl.
>>>>>>>
>>>>>>> As
>>>>>>>> the docs of IConnector state you'll have to subclass Connector
>>>>>>>> (
>>>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j/src/org/eclipse /internal/net4j/Connector.java?root=Modeling_Project&vie w=log)
>>>>>>>> . I suggest to look at the implementation of TCPConnector (
>>>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j.tcp/src/org/ecl ipse/net4j/internal/tcp/TCPConnector.java?root=Modeling_Proj ect&view=log
>>>>>>>> ).
>>>>>>>>
>>>>>>>> As I said above, if you succeed in providing a comm port
>>>>>>>> implementation of IConnector (and the supporting factories)
>>>>>>>> you'll get EMF integration for free ;-)
>>>>>>>
>>>>>>> Sounds good, but will I need to also install a database to get
>>>>>>> EMF integration?
>>>>>> Good question! According to the 'normal' setup of a CDO
>>>>>> deployment, yes. But CDO should be open and layered enuogh to
>>>>>> find a solution that uses only the model integration parts. I
>>>>>> haven't thought about such usage so far.
>>>>>
>>>>>
>>>>> kind regards,
>>>>> John Conlon
>>>
>>>
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #612903 is a reply to message #104873] |
Wed, 19 December 2007 10:53 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Eike,
I pasted your comments back up to make the post readable:
ES>> CDO (at client side) converts in both directions between an Ecore model and its internal
representation of this model. I think this is the relation you mean. At CDO's server side there's
usually no such conversion because there's simply no EMF (required).
BUT: since the Ecore XMI string can be retrieved from the repository via CDOPackage I think a Teneo
based IStore implementation could add EMF to its dependencies, deserialize the original Ecore model
and apply the same E<->CDO conversion as the CDO client.
MT>> Yes that would surely work afaics. The ecore model is also important for Teneo because it can
contain annotations which influence the persistence strategy.
ES>>
To sum up:
- It seems as we we (out products) could both profit from working together.
- There could be a Teneo with CDO under the runtime hood [A]
- There could be a CDO server with a Teneo-based IStore [B]
- We are willing to spend effort for this ;-)
MT>>
I fully agree, hopefully the teneo based istore would offer the same api as you currently use within
cdo server so that the changes in the cdo server are not that large.
I am willing to spend the effort in doing this (but not before the new year :-).
ES>>
If you agree up to here we should discuss how we start and who should do what. I had a similar
integration story with Net4j <-> ECF and I learned that it is often easier to *use* foreign API than
to *extend* it. That also results in the author of the integration being the maintainer.
For [A] that would mean that primarily you would extend your runtime framework by using CDO API
(with my help of course).
For [B] that would mean that primarily I would extend my storage framework by implementing the above
conversions at server side and then using Teneo API (with your help).
MT>> No problem we can see how we can divide the work. I am willing to spend time on this and also
maintain the runtime layer afterwards. I can start looking at CDO and see how the persistence works
currently (using IStore). Can I download/test cdo separately without net4j? Do you have some
hyperlinks with the docs?
ES>>
I guess that on the way we'll discover some more challenges ;-)
MT>>
For sure, it makes all this 'unpaid' work interesting and worthwhile doesn't it :-).
One last question for my interest, does the non-emf cdo server side support the emf featuremap and
other emf/xml schema specialities such as mixed or anytype?
gr. Martin
Eike Stepper wrote:
> Martin Taal schrieb:
>> Hi Eike,
>> Just to continue on your last points (otherwise the post becomes
>> unreadable to me):
>> - Teneos main purpose (with respect to Hibernate) is the integration
>> of EMF Resources and EObjects with a Hibernate mapped database. In
>> other words you directly map EMF concepts to/from Hibernate concepts
>> in one deployment node (client or server).
>> MT>> Almost :-), Teneo consists of two main parts:
>> 1) Mapping functionality: maps a model to a relational schema (in fact
>> maps a model to a java persistence api annotated model which is then
>> translated to a hibernate mapping). The user can override standard
>> mapping behavior by adding jpa annotations in the model.
>> 2) At runtime provide easy integration between EMF and hibernate (or
>> jpox). This part is mainly to support automatic mapping (so using the
>> above functionality 1) when initializing and support emf specifics
>> such as featuremaps, elists and emf resources.
> That makes sense ;-)
>
>> Currently Teneo has 2 runtime layers one for jpox and one for
>> hibernate. It would be interesting to add other runtime layers.
> Ok, there I can see a chance for CDO. It would be completely covered by
> your runtime framework, right?
>
>> Btw, I use the mapping functionality of Teneo also outside of EMF: I
>> map the model using Teneo and then at runtime I have non-emf objects.
>>
>> - CDO wishes Hibernate mapping at its server side
>> - At the server side of CDO there are no EMF concepts. The CDO
>> (network) protocol doesn't deal with EMF concepts. The state of
>> EObjects is translated into non-EMF data structures at client side.
>> MT>> But still because you currently also create a relational schema,
>> I assume that the server also has knowledge of the ecore model.
> Right, at the client there are bijective conversions between:
> EPackage <-> CDOPackage
> EClass <-> CDOClass
> EStructuralFeature <-> CDOFeature
>
> So I'd say a simplified version of the Ecore model arrives at the server
> and is usually stored in an IStore of the CDO storage framework (can be
> RDB). BTW. it's even possible to retrieve the XMI string of the original
> Ecore model from a CDOPackage.
>
>> I can imagine also that your non-emf data structure refer to this model?
> Right, there's a method CDORevision.getCDOClass().
>
>> - The non-EMF data structures that represent EObject state at the
>> server can't easily mapped by Teneo (since Teneo deals with EMF
>> concepts).
>> MT>> Not sure if this is an obstacle. I assume that also for the CDO
>> non-emf datastructures there is a relation to the application model
>> expressed in ecore. Teneo also uses the ecore model as its basis for
>> mapping to hibernate. So as long as there is a relation between your
>> non-emf datastructure and the ecore model then a runtime layer which
>> uses the Teneo mapping logic should be pretty doable.
> That's great to hear. But we have to double check:
> CDO (at client side) converts in both directions between an Ecore model
> and its internal representation of this model. I think this is the
> relation you mean. At CDO's server side there's usually no such
> conversion because there's simply no EMF (required).
> BUT: since the Ecore XMI string can be retrieved from the repository via
> CDOPackage I think a Teneo based IStore implementation could add EMF to
> its dependencies, deserialize the original Ecore model and apply the
> same E<->CDO conversion as the CDO client.
>
> That sounds reasonable to me. Agreed so far?
> I'd have to factor out the conversion mechanism into a separate plugin...
>
>> For example next to Teneo I am working on generating seam web
>> applications from ecore models. To support the persistence side I use
>> Teneo for the mapping and as runtime I have a dynamic-emf-like object
>> (basically a type-safe hashmap). The runtime layer is about 15 classes.
> That sounds similar to the CDO server although it has one or two more
> classes ;-)
>
> To sum up:
> - It seems as we we (out products) could both profit from working together.
> - There could be a Teneo with CDO under the runtime hood [A]
> - There could be a CDO server with a Teneo-based IStore [B]
> - We are willing to spend effort for this ;-)
>
> If you agree up to here we should discuss how we start and who should do
> what. I had a similar integration story with Net4j <-> ECF and I learned
> that it is often easier to *use* foreign API than to *extend* it. That
> also results in the author of the integration being the maintainer.
>
> For [A] that would mean that primarily you would extend your runtime
> framework by using CDO API (with my help of course).
> For [B] that would mean that primarily I would extend my storage
> framework by implementing the above conversions at server side and then
> using Teneo API (with your help).
>
> I guess that on the way we'll discover some more challenges ;-)
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
>>
>> gr. Martin
>>
>> Eike Stepper wrote:
>>> Hi Martin,
>>>
>>> comments below...
>>>
>>>
>>> Martin Taal schrieb:
>>>> Hi Eike, John,
>>>> Just to add my thoughts about Teneo :-).
>>>> Teneo is very much focused on being a persistence solution for
>>>> persisting (complex) models to a relational store. This focus means
>>>> that Teneo has broad support for most complex modeling constructs
>>>> (for example feature maps, xml schema anytype, mixed type, etc.) and
>>>> support for jpa annotations in the model. On the other hand this
>>>> focus also means that Teneo does not include specific client-server
>>>> functionality, this is outside of the scope of Teneo.
>>>> So I would not say that Teneo is a client side solution (I use Teneo
>>>> server side in a web app). Teneo can also be used server side (in a
>>>> rcp app) but then you need to implement your own client-server layer
>>>> (using other tools).
>>> These client/server things are so ambiguous like the model/meta model
>>> things depending on the start point ;-)
>>> But with your clarification the main difference between CDO and Teneo
>>> should be clear now.
>>>
>>>> Btw, it would be interesting to integrate the client-server
>>>> capabilities of CDO/net4j with the mapping capabilities of Teneo. I
>>>> think this can be a powerfull combination...
>>> That'd be of course an interesting effort. What do you think could be
>>> the result of such an effort?
>>>
>>> Simon (cc'ed) and I often discussed this topic and I seem to remember
>>> that we (you and I) also spoke about such integration.
>>> The result that I'd wish from such an integration would clearly be a
>>> CDO storage framework implementation that uses Hibernate as O/R
>>> mapper. I fear that your general experience with Hibernate can be
>>> more helpful than your actual product Teneo. But I'd be glad to be
>>> proven wrong here. The following is the reason (correct me if I'm
>>> wrong):
>>> - Teneos main purpose (with respect to Hibernate) is the integration
>>> of EMF Resources and EObjects with a Hibernate mapped database. In
>>> other words you directly map EMF concepts to/from Hibernate concepts
>>> in one deployment node (client or server).
>>> - CDO wishes Hibernate mapping at its server side
>>> - At the server side of CDO there are no EMF concepts. The CDO
>>> (network) protocol doesn't deal with EMF concepts. The state of
>>> EObjects is translated into non-EMF data structures at client side.
>>> - The non-EMF data structures that represent EObject state at the
>>> server can't easily mapped by Teneo (since Teneo deals with EMF
>>> concepts).
>>>
>>> Would you agree?
>>>
>>> Regards,
>>> Eike Stepper
>>> ----
>>> http://wiki.eclipse.org/CDO
>>> http://wiki.eclipse.org/Net4j
>>>
>>>
>>>>
>>>> gr. Martin
>>>>
>>>> Eike Stepper wrote:
>>>>> John E. Conlon schrieb:
>>>>>>> [stuff deleted]
>>>>>>>> How does CDO compare to Teneo?
>>>>>>> I'd say the main difference is the deployment strategy. While
>>>>>>> Teneo (I'm not a Teneo expert!) is mainly used on the client side
>>>>>>> (with hibernate/jpox generated JDBC on the wire) CDO is is used
>>>>>>> on the client side for EMF model integration and on the server
>>>>>>> side for the storage integration (O/R mapping, OODB integration).
>>>>>>> CDO uses an own (Net4j based) wire protocol which is tailored to
>>>>>>> transactional semantics in the context of objects (not SQL).
>>>>>>> Since CDO clients rely on a dedicated CDO server they can offer
>>>>>>> some additional functions not available with Teneo, like
>>>>>>> automatic model update on all clients if one client commits a
>>>>>>> transaction (distributed shared model semantics).
>>>>>>
>>>>>> So Teneo is more of a client side persistence alternative and CDO
>>>>>> is a model repository server!
>>>>> Right.
>>>>>
>>>>>> Is CDO the only Eclipse Modeling project making this claim?
>>>>> AFAIK, yes.
>>>>>
>>>>>> Side question:
>>>>>> Since models are persisted to a repository server (a rdbms) has
>>>>>> anyone experimented with plugging in BIRT to this rdbms so end
>>>>>> user's could be given reporting support? In other words are the
>>>>>> final relational schemas human readable and understandable enough
>>>>>> for report designers to work with?
>>>>> Interesting question because I just discussed that topic with a
>>>>> friend of mine. I cc'ed Philipp for this purpose.
>>>>>
>>>>> 1) A CDO server mainly consists of three parts/layers: A protocol
>>>>> peer (Net4j based), a model repository framework (storage agnostic)
>>>>> and a storage framework. It depends on the storage implementation
>>>>> (IStore) how the model data is actually persisted to a storage
>>>>> backend. This *can* be an RDBMS via plain JDBC (default) but a user
>>>>> has also implemented an Objectivity store (OODBMS) and plans to
>>>>> implement a Hibernate based store.
>>>>>
>>>>> 2) In case the default JDBC store is used with a repository I'd say
>>>>> yes, the generated schema is human readable and understandable
>>>>> enough for report designers to work with but that is my own
>>>>> opinion. Currently CDO always uses its own generated primary keys
>>>>> (long id values) and references are mostly always stored in a fixed
>>>>> format that allows for transparent versioning.
>>>>>
>>>>> 3) I'd prefer to see a model/BIRT integration at the model side
>>>>> (CDO client) rather than at the DB side (one of several possible
>>>>> CDO storage backends and highly implementation dependent). I'm
>>>>> neither a BIRT nor an ODA expert but is it not possible to use an
>>>>> EMF ResourceSet, a Resource or an EObject as an ODA data source?
>>>>> That'd be much closer to the semantics of the model than querying
>>>>> the mapped DB.
>>>>>
>>>>>>>> Does CDO use the EMF transaction framework?
>>>>>>> No, CDO acts directly on the model level. EMF Transaction acts on
>>>>>>> the higher edit/command framework level which, in my opinion, has
>>>>>>> at least two disadvantages:
>>>>>>> 1) Not all clients want to use a command stack to interact with
>>>>>>> models (especially non-UI clients like batch clients). With CDO
>>>>>>> these clients can remain unchanged (are not forced to use a
>>>>>>> command stack) and since CDO transactions are transparent to the
>>>>>>> command stack UI clients can be used, too.
>>>>>>> 2) Worse, command stack based transactions rely on the
>>>>>>> cooperation of *all* clients of a model. If only one client
>>>>>>> doesn't use a command stack or uses a non-transactional command
>>>>>>> stack all transactions might become corrupt! Since CDO integrates
>>>>>>> with EMF models at their core none of these restrictions apply.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> When you say CDO works at the model level, does that mean entire
>>>>>> models are moved from client to server?
>>>>> I'm not sure if I correctly understand the intend of your question.
>>>>> The scope of a CDO transaction is always an EMF ResourceSet (no
>>>>> command stack needed). This ResourceSet can contain multiple CDO
>>>>> Resources (and possibly other types of Resources). At the time of
>>>>> committing the transaction no CDO Resource is allowed to contain
>>>>> references to non-CDO Resources. In other words a CDO repository is
>>>>> always guaranteed to contain a consistent state of an object graph
>>>>> that can be partitioned into CDO Resources. Looking from the other
>>>>> side a CDO-prepared ResourceSet acts like a partial but
>>>>> self-populating view onto the whole object graph of the repository.
>>>>>
>>>>> So in this sense, yes, entire models are (initially) moved from
>>>>> client to server. Once a model is committed into the repository
>>>>> subsequent reads and writes (commits) act at least at an object
>>>>> granularity. A recent effort of a user added support for sending
>>>>> only deltas for changed objects to the server, see
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=201266 .
>>>>>
>>>>> I guess I should stop saying "at the model level" because the word
>>>>> "model" is one of the only four terms we have available in modern
>>>>> software engineering, ambiguities granted ;-)
>>>>> The reason I used it is the following. When you kick the EMF
>>>>> generator for an ecore model it typically produces 3 plugins:
>>>>> 1) model plugin
>>>>> 2) edit plugin (command framework integration)
>>>>> 3) editor plugin (Eclipse UI)
>>>>>
>>>>> When I say "at the model level" I really mean that only 1) is
>>>>> needed for integration. AFAIK EMF Transaction needs 1) plus 2) for
>>>>> its integration because it intercepts commands of the command
>>>>> framework.
>>>>>
>>>>>> Is there facilities for plugging in Model to Model translation
>>>>>> facilities so that one could sync heterogeneous models to one
>>>>>> repository?
>>>>> I'm lost. Could you please elaborate on "Model to Model translation
>>>>> facilities" and "heterogeneous models"?
>>>>>
>>>>>> My mind has not been expanded as of yet to all the possibilities
>>>>>> with CDO, but I am wondering if CDO may be able to offer an
>>>>>> infrastructure for models what XProc
>>>>>> http://www.w3.org/TR/2007/WD-xproc-20071129/
>>>>>> is offering for XML docs?
>>>>> I'm really not familiar with XProc. The abstract says "[...] a
>>>>> language for describing operations to be performed on XML
>>>>> documents". From this I'd say, no, CDO focusses more on the static
>>>>> aspects of a model than on the possible operations that could
>>>>> modeify a model over time. May be you can list some specific
>>>>> details of the XProc spec (which I've not read as a whole) that
>>>>> you're interested in?
>>>>>
>>>>>>>> [stuff deleted]
>>>>>>> Good point! Would you be willing to contribute such a connector?
>>>>>>> If so, please open an enhancement request in Bugzilla and attach
>>>>>>> a patch (since Net4j is already extensible in the dimension of
>>>>>>> transports a patch might not be needed and you can simply attach
>>>>>>> the extension bundle project). I'd be happy to maintain the code
>>>>>>> after ;-)
>>>>>>
>>>>>> Have several activities scheduled right now, but I am interested
>>>>>> enough to contribute with either a comm port transport or a
>>>>>> Bluetooth one. The problem I for see with either one of these
>>>>>> solutions is that I expect there will be OS library dependencies
>>>>>> that will have to be bundled with the code. This is something I
>>>>>> have not done before.
>>>>> OSGi should be prepared for this ;-)
>>>>>>
>>>>>> Will start looking into this next month.
>>>>> That'd be great! Please tell me when you need my assistance...
>>>>>
>>>>> Regards,
>>>>> Eike Stepper
>>>>> ----
>>>>> http://wiki.eclipse.org/CDO
>>>>> http://wiki.eclipse.org/Net4j
>>>>>
>>>>>
>>>>>>>> That said, a connector implementation for comm ports should be
>>>>>>>> easy, as easy as the usage of comm ports is in Java (which I
>>>>>>>> have no idea of).
>>>>>>>> I have not done this myself, so I don't know how easy the lower
>>>>>>>> layer will be. Would probably do the http://www.rxtx.org/
>>>>>>>> versus Sun's impl.
>>>>>>>>
>>>>>>>> As
>>>>>>>>> the docs of IConnector state you'll have to subclass Connector
>>>>>>>>> (
>>>>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j/src/org/eclipse /internal/net4j/Connector.java?root=Modeling_Project&vie w=log)
>>>>>>>>> . I suggest to look at the implementation of TCPConnector (
>>>>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j.tcp/src/org/ecl ipse/net4j/internal/tcp/TCPConnector.java?root=Modeling_Proj ect&view=log
>>>>>>>>> ).
>>>>>>>>>
>>>>>>>>> As I said above, if you succeed in providing a comm port
>>>>>>>>> implementation of IConnector (and the supporting factories)
>>>>>>>>> you'll get EMF integration for free ;-)
>>>>>>>>
>>>>>>>> Sounds good, but will I need to also install a database to get
>>>>>>>> EMF integration?
>>>>>>> Good question! According to the 'normal' setup of a CDO
>>>>>>> deployment, yes. But CDO should be open and layered enuogh to
>>>>>>> find a solution that uses only the model integration parts. I
>>>>>>> haven't thought about such usage so far.
>>>>>>
>>>>>>
>>>>>> kind regards,
>>>>>> John Conlon
>>>>
>>>>
>>
>>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #612905 is a reply to message #104775] |
Wed, 19 December 2007 16:29 |
| Eclipse User |
|
|
|
Originally posted by: jconlon.apache.org
Eike Stepper wrote:
> John E. Conlon schrieb:
>>> [stuff deleted]
>>>> How does CDO compare to Teneo?
>>> I'd say the main difference is the deployment strategy. While Teneo
>>> (I'm not a Teneo expert!) is mainly used on the client side (with
>>> hibernate/jpox generated JDBC on the wire) CDO is is used on the
>>> client side for EMF model integration and on the server side for the
>>> storage integration (O/R mapping, OODB integration). CDO uses an own
>>> (Net4j based) wire protocol which is tailored to transactional
>>> semantics in the context of objects (not SQL). Since CDO clients rely
>>> on a dedicated CDO server they can offer some additional functions
>>> not available with Teneo, like automatic model update on all clients
>>> if one client commits a transaction (distributed shared model
>>> semantics).
>>
>> So Teneo is more of a client side persistence alternative and CDO is a
>> model repository server!
> Right.
>
>> Is CDO the only Eclipse Modeling project making this claim?
> AFAIK, yes.
That makes the choice clear.
>
>> Side question:
>> Since models are persisted to a repository server (a rdbms) has anyone
>> experimented with plugging in BIRT to this rdbms so end user's could
>> be given reporting support? In other words are the final relational
>> schemas human readable and understandable enough for report designers
>> to work with?
> Interesting question because I just discussed that topic with a friend
> of mine. I cc'ed Philipp for this purpose.
>
> 1) A CDO server mainly consists of three parts/layers: A protocol peer
> (Net4j based), a model repository framework (storage agnostic) and a
> storage framework. It depends on the storage implementation (IStore) how
> the model data is actually persisted to a storage backend. This *can* be
> an RDBMS via plain JDBC (default) but a user has also implemented an
> Objectivity store (OODBMS) and plans to implement a Hibernate based store.
>
> 2) In case the default JDBC store is used with a repository I'd say yes,
> the generated schema is human readable and understandable enough for
> report designers to work with but that is my own opinion. Currently CDO
> always uses its own generated primary keys (long id values) and
> references are mostly always stored in a fixed format that allows for
> transparent versioning.
>
> 3) I'd prefer to see a model/BIRT integration at the model side (CDO
> client) rather than at the DB side (one of several possible CDO storage
> backends and highly implementation dependent). I'm neither a BIRT nor an
> ODA expert but is it not possible to use an EMF ResourceSet, a Resource
> or an EObject as an ODA data source? That'd be much closer to the
> semantics of the model than querying the mapped DB.
Glad to here you agree with an approach now ongoing: see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=132958
Jeff Ramsdale is heading this effort.
See also topic 'Help with Ecore ODA Driver - Need MindMap data' in the
eclipse.dtp newsgroup.
>
>>>> Does CDO use the EMF transaction framework?
>>> No, CDO acts directly on the model level. EMF Transaction acts on the
>>> higher edit/command framework level which, in my opinion, has at
>>> least two disadvantages:
>>> 1) Not all clients want to use a command stack to interact with
>>> models (especially non-UI clients like batch clients). With CDO these
>>> clients can remain unchanged (are not forced to use a command stack)
>>> and since CDO transactions are transparent to the command stack UI
>>> clients can be used, too.
>>> 2) Worse, command stack based transactions rely on the cooperation of
>>> *all* clients of a model. If only one client doesn't use a command
>>> stack or uses a non-transactional command stack all transactions
>>> might become corrupt! Since CDO integrates with EMF models at their
>>> core none of these restrictions apply.
>>>
>>
>>
>> When you say CDO works at the model level, does that mean entire
>> models are moved from client to server?
> I'm not sure if I correctly understand the intend of your question. The
> scope of a CDO transaction is always an EMF ResourceSet (no command
> stack needed). This ResourceSet can contain multiple CDO Resources (and
> possibly other types of Resources). At the time of committing the
> transaction no CDO Resource is allowed to contain references to non-CDO
> Resources. In other words a CDO repository is always guaranteed to
> contain a consistent state of an object graph that can be partitioned
> into CDO Resources. Looking from the other side a CDO-prepared
> ResourceSet acts like a partial but self-populating view onto the whole
> object graph of the repository.
>
> So in this sense, yes, entire models are (initially) moved from client
> to server. Once a model is committed into the repository subsequent
> reads and writes (commits) act at least at an object granularity. A
> recent effort of a user added support for sending only deltas for
> changed objects to the server, see
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=201266 .
>
> I guess I should stop saying "at the model level" because the word
> "model" is one of the only four terms we have available in modern
> software engineering, ambiguities granted ;-)
> The reason I used it is the following. When you kick the EMF generator
> for an ecore model it typically produces 3 plugins:
> 1) model plugin
> 2) edit plugin (command framework integration)
> 3) editor plugin (Eclipse UI)
>
> When I say "at the model level" I really mean that only 1) is needed for
> integration. AFAIK EMF Transaction needs 1) plus 2) for its integration
> because it intercepts commands of the command framework.
>
Thanks that answered my question.
>> Is there facilities for plugging in Model to Model translation
>> facilities so that one could sync heterogeneous models to one
>> repository?
> I'm lost. Could you please elaborate on "Model to Model translation
> facilities" and "heterogeneous models"?
Caveat: Based on no experience with CDO/Net4J ...
I was referring to the M2M work done as part of:
http://www.eclipse.org/m2m/
If a specific model in CDO is persisted in the model repository and this
model can be synchronized to one or more client views of the model, I
was speculating that a CDO client view could be created on one side of a
M2M transformation service and on the other side of the M2M service a
different or heterogeneous model could be attached. Then as the
heterogeneous model changed the transformer would map it to changes on
the CDO client side of the transformer.
>> My mind has not been expanded as of yet to all the possibilities with
>> CDO, but I am wondering if CDO may be able to offer an infrastructure
>> for models what XProc http://www.w3.org/TR/2007/WD-xproc-20071129/
>> is offering for XML docs?
> I'm really not familiar with XProc. The abstract says "[...] a language
> for describing operations to be performed on XML documents". From this
> I'd say, no, CDO focusses more on the static aspects of a model than on
> the possible operations that could modeify a model over time. May be you
> can list some specific details of the XProc spec (which I've not read as
> a whole) that you're interested in?
This question was expanding on the previous one related to M2M. It was
referring to XProc merely as an analogy not so much for a language but
for a pipeline infrastructure that I was thinking might already be
something implemented, designed or thought about for the CDO/Net4J
client server model repo infrastructure.
The idea is CDO as pipeline infrastructure where Model A (Ma) could be
persisted in the repository but then have instances of another Model B
(Mb) part of the synchronization. Where <-> represents the linkage.
Ma Source as a CDO Client <->
Ma Repo as CDO server <->
Ma Target Client <->
M2M transformer<->
Mb Target as a CDO Client
>>>> [stuff deleted]
>>> Good point! Would you be willing to contribute such a connector? If
>>> so, please open an enhancement request in Bugzilla and attach a patch
>>> (since Net4j is already extensible in the dimension of transports a
>>> patch might not be needed and you can simply attach the extension
>>> bundle project). I'd be happy to maintain the code after ;-)
>>
>> Have several activities scheduled right now, but I am interested
>> enough to contribute with either a comm port transport or a Bluetooth
>> one. The problem I for see with either one of these solutions is that
>> I expect there will be OS library dependencies that will have to be
>> bundled with the code. This is something I have not done before.
> OSGi should be prepared for this ;-)
>>
>> Will start looking into this next month.
> That'd be great! Please tell me when you need my assistance...
Will do.
kind regards,
John Conlon
jconlon@verticon.com
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #612908 is a reply to message #104801] |
Wed, 19 December 2007 16:32 |
| Eclipse User |
|
|
|
Originally posted by: jconlon.apache.org
Eike Stepper wrote:
> Hi Martin,
>
> comments below...
>
>
> Martin Taal schrieb:
>> Hi Eike, John,
>> Just to add my thoughts about Teneo :-).
>> Teneo is very much focused on being a persistence solution for
>> persisting (complex) models to a relational store. This focus means
>> that Teneo has broad support for most complex modeling constructs (for
>> example feature maps, xml schema anytype, mixed type, etc.) and
>> support for jpa annotations in the model. On the other hand this focus
>> also means that Teneo does not include specific client-server
>> functionality, this is outside of the scope of Teneo.
>> So I would not say that Teneo is a client side solution (I use Teneo
>> server side in a web app). Teneo can also be used server side (in a
>> rcp app) but then you need to implement your own client-server layer
>> (using other tools).
> These client/server things are so ambiguous like the model/meta model
> things depending on the start point ;-)
> But with your clarification the main difference between CDO and Teneo
> should be clear now.
Yes it is, thank you Martin and Eike for clarifying.
kind regards,
John Conlon
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #612916 is a reply to message #104975] |
Thu, 20 December 2007 08:01 |
|
Martin Taal schrieb:
> Hi Eike,
> I pasted your comments back up to make the post readable:
Hmm, I found it more readable before ;-)
> ES>> CDO (at client side) converts in both directions between an Ecore
> model and its internal representation of this model. I think this is
> the relation you mean. At CDO's server side there's usually no such
> conversion because there's simply no EMF (required).
> BUT: since the Ecore XMI string can be retrieved from the repository
> via CDOPackage I think a Teneo based IStore implementation could add
> EMF to its dependencies, deserialize the original Ecore model and
> apply the same E<->CDO conversion as the CDO client.
>
> MT>> Yes that would surely work afaics. The ecore model is also
> important for Teneo because it can contain annotations which influence
> the persistence strategy.
Annotations in the model have been the original trigger to make the
model string available on the server.
> ES>>
> To sum up:
> - It seems as we we (out products) could both profit from working
> together.
> - There could be a Teneo with CDO under the runtime hood [A]
> - There could be a CDO server with a Teneo-based IStore [B]
> - We are willing to spend effort for this ;-)
>
> MT>>
> I fully agree, hopefully the teneo based istore would offer the same
> api as you currently use within cdo server so that the changes in the
> cdo server are not that large.
The goal is to not change the repository framework but just plug in the
new IStore implementation. Since we have already two implementations
with quite different backends (OO and relational) there is a chance that
we catch the goal.
> I am willing to spend the effort in doing this (but not before the new
> year :-).
That's great!
> ES>>
> If you agree up to here we should discuss how we start and who should
> do what. I had a similar integration story with Net4j <-> ECF and I
> learned that it is often easier to *use* foreign API than to *extend*
> it. That also results in the author of the integration being the
> maintainer.
>
> For [A] that would mean that primarily you would extend your runtime
> framework by using CDO API (with my help of course).
> For [B] that would mean that primarily I would extend my storage
> framework by implementing the above conversions at server side and
> then using Teneo API (with your help).
>
> MT>> No problem we can see how we can divide the work. I am willing to
> spend time on this and also maintain the runtime layer afterwards. I
> can start looking at CDO and see how the persistence works currently
> (using IStore). Can I download/test cdo separately without net4j?
No, not if you want to compile CDO without errors. Please use "All.psf"
from http://wiki.eclipse.org/CDO_Project_Resources#Sources
> Do you have some hyperlinks with the docs?
Hehe, after years without automatic signature I recently installed a
Thunderbird plugin to get this dignified signature:
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
There's some (hopefully) useful information in the CDO wiki ;-)
That said, it's not yet fully complete so I guess we will have to
discuss after you got a general overview.
> ES>>
> I guess that on the way we'll discover some more challenges ;-)
> MT>>
> For sure, it makes all this 'unpaid' work interesting and worthwhile
> doesn't it :-).
Really addictive!
> One last question for my interest, does the non-emf cdo server side
> support the emf featuremap and other emf/xml schema specialities such
> as mixed or anytype?
I'm not an expert myself in neither feature maps nor xsd details ;-(
BUT I believe feature maps have already been reported to be used.
More important, CDO/EMF integration is based on the EStore interface
which I'd expect to support all EObject functionality including feature
maps.
For xml schema specialities such as mixed or anytype I'm not sure. Do
they rely on EAnnotations? The only thing I can say is that I never
thought about xsd in the context of CDO.
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO ;-)
http://wiki.eclipse.org/Net4j
>
> gr. Martin
>
> Eike Stepper wrote:
>> Martin Taal schrieb:
>>> Hi Eike,
>>> Just to continue on your last points (otherwise the post becomes
>>> unreadable to me):
>>> - Teneos main purpose (with respect to Hibernate) is the integration
>>> of EMF Resources and EObjects with a Hibernate mapped database. In
>>> other words you directly map EMF concepts to/from Hibernate concepts
>>> in one deployment node (client or server).
>>> MT>> Almost :-), Teneo consists of two main parts:
>>> 1) Mapping functionality: maps a model to a relational schema (in
>>> fact maps a model to a java persistence api annotated model which is
>>> then translated to a hibernate mapping). The user can override
>>> standard mapping behavior by adding jpa annotations in the model.
>>> 2) At runtime provide easy integration between EMF and hibernate (or
>>> jpox). This part is mainly to support automatic mapping (so using
>>> the above functionality 1) when initializing and support emf
>>> specifics such as featuremaps, elists and emf resources.
>> That makes sense ;-)
>>
>>> Currently Teneo has 2 runtime layers one for jpox and one for
>>> hibernate. It would be interesting to add other runtime layers.
>> Ok, there I can see a chance for CDO. It would be completely covered
>> by your runtime framework, right?
>>
>>> Btw, I use the mapping functionality of Teneo also outside of EMF: I
>>> map the model using Teneo and then at runtime I have non-emf objects.
>>>
>>> - CDO wishes Hibernate mapping at its server side
>>> - At the server side of CDO there are no EMF concepts. The CDO
>>> (network) protocol doesn't deal with EMF concepts. The state of
>>> EObjects is translated into non-EMF data structures at client side.
>>> MT>> But still because you currently also create a relational
>>> schema, I assume that the server also has knowledge of the ecore model.
>> Right, at the client there are bijective conversions between:
>> EPackage <-> CDOPackage
>> EClass <-> CDOClass
>> EStructuralFeature <-> CDOFeature
>>
>> So I'd say a simplified version of the Ecore model arrives at the
>> server and is usually stored in an IStore of the CDO storage
>> framework (can be RDB). BTW. it's even possible to retrieve the XMI
>> string of the original Ecore model from a CDOPackage.
>>
>>> I can imagine also that your non-emf data structure refer to this
>>> model?
>> Right, there's a method CDORevision.getCDOClass().
>>
>>> - The non-EMF data structures that represent EObject state at the
>>> server can't easily mapped by Teneo (since Teneo deals with EMF
>>> concepts).
>>> MT>> Not sure if this is an obstacle. I assume that also for the CDO
>>> non-emf datastructures there is a relation to the application model
>>> expressed in ecore. Teneo also uses the ecore model as its basis for
>>> mapping to hibernate. So as long as there is a relation between your
>>> non-emf datastructure and the ecore model then a runtime layer which
>>> uses the Teneo mapping logic should be pretty doable.
>> That's great to hear. But we have to double check:
>> CDO (at client side) converts in both directions between an Ecore
>> model and its internal representation of this model. I think this is
>> the relation you mean. At CDO's server side there's usually no such
>> conversion because there's simply no EMF (required).
>> BUT: since the Ecore XMI string can be retrieved from the repository
>> via CDOPackage I think a Teneo based IStore implementation could add
>> EMF to its dependencies, deserialize the original Ecore model and
>> apply the same E<->CDO conversion as the CDO client.
>>
>> That sounds reasonable to me. Agreed so far?
>> I'd have to factor out the conversion mechanism into a separate
>> plugin...
>>
>>> For example next to Teneo I am working on generating seam web
>>> applications from ecore models. To support the persistence side I
>>> use Teneo for the mapping and as runtime I have a dynamic-emf-like
>>> object (basically a type-safe hashmap). The runtime layer is about
>>> 15 classes.
>> That sounds similar to the CDO server although it has one or two more
>> classes ;-)
>>
>> To sum up:
>> - It seems as we we (out products) could both profit from working
>> together.
>> - There could be a Teneo with CDO under the runtime hood [A]
>> - There could be a CDO server with a Teneo-based IStore [B]
>> - We are willing to spend effort for this ;-)
>>
>> If you agree up to here we should discuss how we start and who should
>> do what. I had a similar integration story with Net4j <-> ECF and I
>> learned that it is often easier to *use* foreign API than to *extend*
>> it. That also results in the author of the integration being the
>> maintainer.
>>
>> For [A] that would mean that primarily you would extend your runtime
>> framework by using CDO API (with my help of course).
>> For [B] that would mean that primarily I would extend my storage
>> framework by implementing the above conversions at server side and
>> then using Teneo API (with your help).
>>
>> I guess that on the way we'll discover some more challenges ;-)
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>>>
>>> gr. Martin
>>>
>>> Eike Stepper wrote:
>>>> Hi Martin,
>>>>
>>>> comments below...
>>>>
>>>>
>>>> Martin Taal schrieb:
>>>>> Hi Eike, John,
>>>>> Just to add my thoughts about Teneo :-).
>>>>> Teneo is very much focused on being a persistence solution for
>>>>> persisting (complex) models to a relational store. This focus
>>>>> means that Teneo has broad support for most complex modeling
>>>>> constructs (for example feature maps, xml schema anytype, mixed
>>>>> type, etc.) and support for jpa annotations in the model. On the
>>>>> other hand this focus also means that Teneo does not include
>>>>> specific client-server functionality, this is outside of the scope
>>>>> of Teneo.
>>>>> So I would not say that Teneo is a client side solution (I use
>>>>> Teneo server side in a web app). Teneo can also be used server
>>>>> side (in a rcp app) but then you need to implement your own
>>>>> client-server layer (using other tools).
>>>> These client/server things are so ambiguous like the model/meta
>>>> model things depending on the start point ;-)
>>>> But with your clarification the main difference between CDO and
>>>> Teneo should be clear now.
>>>>
>>>>> Btw, it would be interesting to integrate the client-server
>>>>> capabilities of CDO/net4j with the mapping capabilities of Teneo.
>>>>> I think this can be a powerfull combination...
>>>> That'd be of course an interesting effort. What do you think could
>>>> be the result of such an effort?
>>>>
>>>> Simon (cc'ed) and I often discussed this topic and I seem to
>>>> remember that we (you and I) also spoke about such integration.
>>>> The result that I'd wish from such an integration would clearly be
>>>> a CDO storage framework implementation that uses Hibernate as O/R
>>>> mapper. I fear that your general experience with Hibernate can be
>>>> more helpful than your actual product Teneo. But I'd be glad to be
>>>> proven wrong here. The following is the reason (correct me if I'm
>>>> wrong):
>>>> - Teneos main purpose (with respect to Hibernate) is the
>>>> integration of EMF Resources and EObjects with a Hibernate mapped
>>>> database. In other words you directly map EMF concepts to/from
>>>> Hibernate concepts in one deployment node (client or server).
>>>> - CDO wishes Hibernate mapping at its server side
>>>> - At the server side of CDO there are no EMF concepts. The CDO
>>>> (network) protocol doesn't deal with EMF concepts. The state of
>>>> EObjects is translated into non-EMF data structures at client side.
>>>> - The non-EMF data structures that represent EObject state at the
>>>> server can't easily mapped by Teneo (since Teneo deals with EMF
>>>> concepts).
>>>>
>>>> Would you agree?
>>>>
>>>> Regards,
>>>> Eike Stepper
>>>> ----
>>>> http://wiki.eclipse.org/CDO
>>>> http://wiki.eclipse.org/Net4j
>>>>
>>>>
>>>>>
>>>>> gr. Martin
>>>>>
>>>>> Eike Stepper wrote:
>>>>>> John E. Conlon schrieb:
>>>>>>>> [stuff deleted]
>>>>>>>>> How does CDO compare to Teneo?
>>>>>>>> I'd say the main difference is the deployment strategy. While
>>>>>>>> Teneo (I'm not a Teneo expert!) is mainly used on the client
>>>>>>>> side (with hibernate/jpox generated JDBC on the wire) CDO is is
>>>>>>>> used on the client side for EMF model integration and on the
>>>>>>>> server side for the storage integration (O/R mapping, OODB
>>>>>>>> integration). CDO uses an own (Net4j based) wire protocol which
>>>>>>>> is tailored to transactional semantics in the context of
>>>>>>>> objects (not SQL). Since CDO clients rely on a dedicated CDO
>>>>>>>> server they can offer some additional functions not available
>>>>>>>> with Teneo, like automatic model update on all clients if one
>>>>>>>> client commits a transaction (distributed shared model semantics).
>>>>>>>
>>>>>>> So Teneo is more of a client side persistence alternative and
>>>>>>> CDO is a model repository server!
>>>>>> Right.
>>>>>>
>>>>>>> Is CDO the only Eclipse Modeling project making this claim?
>>>>>> AFAIK, yes.
>>>>>>
>>>>>>> Side question:
>>>>>>> Since models are persisted to a repository server (a rdbms) has
>>>>>>> anyone experimented with plugging in BIRT to this rdbms so end
>>>>>>> user's could be given reporting support? In other words are the
>>>>>>> final relational schemas human readable and understandable
>>>>>>> enough for report designers to work with?
>>>>>> Interesting question because I just discussed that topic with a
>>>>>> friend of mine. I cc'ed Philipp for this purpose.
>>>>>>
>>>>>> 1) A CDO server mainly consists of three parts/layers: A protocol
>>>>>> peer (Net4j based), a model repository framework (storage
>>>>>> agnostic) and a storage framework. It depends on the storage
>>>>>> implementation (IStore) how the model data is actually persisted
>>>>>> to a storage backend. This *can* be an RDBMS via plain JDBC
>>>>>> (default) but a user has also implemented an Objectivity store
>>>>>> (OODBMS) and plans to implement a Hibernate based store.
>>>>>>
>>>>>> 2) In case the default JDBC store is used with a repository I'd
>>>>>> say yes, the generated schema is human readable and
>>>>>> understandable enough for report designers to work with but that
>>>>>> is my own opinion. Currently CDO always uses its own generated
>>>>>> primary keys (long id values) and references are mostly always
>>>>>> stored in a fixed format that allows for transparent versioning.
>>>>>>
>>>>>> 3) I'd prefer to see a model/BIRT integration at the model side
>>>>>> (CDO client) rather than at the DB side (one of several possible
>>>>>> CDO storage backends and highly implementation dependent). I'm
>>>>>> neither a BIRT nor an ODA expert but is it not possible to use an
>>>>>> EMF ResourceSet, a Resource or an EObject as an ODA data source?
>>>>>> That'd be much closer to the semantics of the model than querying
>>>>>> the mapped DB.
>>>>>>
>>>>>>>>> Does CDO use the EMF transaction framework?
>>>>>>>> No, CDO acts directly on the model level. EMF Transaction acts
>>>>>>>> on the higher edit/command framework level which, in my
>>>>>>>> opinion, has at least two disadvantages:
>>>>>>>> 1) Not all clients want to use a command stack to interact with
>>>>>>>> models (especially non-UI clients like batch clients). With CDO
>>>>>>>> these clients can remain unchanged (are not forced to use a
>>>>>>>> command stack) and since CDO transactions are transparent to
>>>>>>>> the command stack UI clients can be used, too.
>>>>>>>> 2) Worse, command stack based transactions rely on the
>>>>>>>> cooperation of *all* clients of a model. If only one client
>>>>>>>> doesn't use a command stack or uses a non-transactional command
>>>>>>>> stack all transactions might become corrupt! Since CDO
>>>>>>>> integrates with EMF models at their core none of these
>>>>>>>> restrictions apply.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> When you say CDO works at the model level, does that mean entire
>>>>>>> models are moved from client to server?
>>>>>> I'm not sure if I correctly understand the intend of your
>>>>>> question. The scope of a CDO transaction is always an EMF
>>>>>> ResourceSet (no command stack needed). This ResourceSet can
>>>>>> contain multiple CDO Resources (and possibly other types of
>>>>>> Resources). At the time of committing the transaction no CDO
>>>>>> Resource is allowed to contain references to non-CDO Resources.
>>>>>> In other words a CDO repository is always guaranteed to contain a
>>>>>> consistent state of an object graph that can be partitioned into
>>>>>> CDO Resources. Looking from the other side a CDO-prepared
>>>>>> ResourceSet acts like a partial but self-populating view onto the
>>>>>> whole object graph of the repository.
>>>>>>
>>>>>> So in this sense, yes, entire models are (initially) moved from
>>>>>> client to server. Once a model is committed into the repository
>>>>>> subsequent reads and writes (commits) act at least at an object
>>>>>> granularity. A recent effort of a user added support for sending
>>>>>> only deltas for changed objects to the server, see
>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=201266 .
>>>>>>
>>>>>> I guess I should stop saying "at the model level" because the
>>>>>> word "model" is one of the only four terms we have available in
>>>>>> modern software engineering, ambiguities granted ;-)
>>>>>> The reason I used it is the following. When you kick the EMF
>>>>>> generator for an ecore model it typically produces 3 plugins:
>>>>>> 1) model plugin
>>>>>> 2) edit plugin (command framework integration)
>>>>>> 3) editor plugin (Eclipse UI)
>>>>>>
>>>>>> When I say "at the model level" I really mean that only 1) is
>>>>>> needed for integration. AFAIK EMF Transaction needs 1) plus 2)
>>>>>> for its integration because it intercepts commands of the command
>>>>>> framework.
>>>>>>
>>>>>>> Is there facilities for plugging in Model to Model translation
>>>>>>> facilities so that one could sync heterogeneous models to one
>>>>>>> repository?
>>>>>> I'm lost. Could you please elaborate on "Model to Model
>>>>>> translation facilities" and "heterogeneous models"?
>>>>>>
>>>>>>> My mind has not been expanded as of yet to all the possibilities
>>>>>>> with CDO, but I am wondering if CDO may be able to offer an
>>>>>>> infrastructure for models what XProc
>>>>>>> http://www.w3.org/TR/2007/WD-xproc-20071129/
>>>>>>> is offering for XML docs?
>>>>>> I'm really not familiar with XProc. The abstract says "[...] a
>>>>>> language for describing operations to be performed on XML
>>>>>> documents". From this I'd say, no, CDO focusses more on the
>>>>>> static aspects of a model than on the possible operations that
>>>>>> could modeify a model over time. May be you can list some
>>>>>> specific details of the XProc spec (which I've not read as a
>>>>>> whole) that you're interested in?
>>>>>>
>>>>>>>>> [stuff deleted]
>>>>>>>> Good point! Would you be willing to contribute such a
>>>>>>>> connector? If so, please open an enhancement request in
>>>>>>>> Bugzilla and attach a patch (since Net4j is already extensible
>>>>>>>> in the dimension of transports a patch might not be needed and
>>>>>>>> you can simply attach the extension bundle project). I'd be
>>>>>>>> happy to maintain the code after ;-)
>>>>>>>
>>>>>>> Have several activities scheduled right now, but I am interested
>>>>>>> enough to contribute with either a comm port transport or a
>>>>>>> Bluetooth one. The problem I for see with either one of these
>>>>>>> solutions is that I expect there will be OS library dependencies
>>>>>>> that will have to be bundled with the code. This is something I
>>>>>>> have not done before.
>>>>>> OSGi should be prepared for this ;-)
>>>>>>>
>>>>>>> Will start looking into this next month.
>>>>>> That'd be great! Please tell me when you need my assistance...
>>>>>>
>>>>>> Regards,
>>>>>> Eike Stepper
>>>>>> ----
>>>>>> http://wiki.eclipse.org/CDO
>>>>>> http://wiki.eclipse.org/Net4j
>>>>>>
>>>>>>
>>>>>>>>> That said, a connector implementation for comm ports should be
>>>>>>>>> easy, as easy as the usage of comm ports is in Java (which I
>>>>>>>>> have no idea of).
>>>>>>>>> I have not done this myself, so I don't know how easy the
>>>>>>>>> lower layer will be. Would probably do the
>>>>>>>>> http://www.rxtx.org/ versus Sun's impl.
>>>>>>>>>
>>>>>>>>> As
>>>>>>>>>> the docs of IConnector state you'll have to subclass
>>>>>>>>>> Connector (
>>>>>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j/src/org/eclipse /internal/net4j/Connector.java?root=Modeling_Project&vie w=log)
>>>>>>>>>> . I suggest to look at the implementation of TCPConnector (
>>>>>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j.tcp/src/org/ecl ipse/net4j/internal/tcp/TCPConnector.java?root=Modeling_Proj ect&view=log
>>>>>>>>>> ).
>>>>>>>>>>
>>>>>>>>>> As I said above, if you succeed in providing a comm port
>>>>>>>>>> implementation of IConnector (and the supporting factories)
>>>>>>>>>> you'll get EMF integration for free ;-)
>>>>>>>>>
>>>>>>>>> Sounds good, but will I need to also install a database to get
>>>>>>>>> EMF integration?
>>>>>>>> Good question! According to the 'normal' setup of a CDO
>>>>>>>> deployment, yes. But CDO should be open and layered enuogh to
>>>>>>>> find a solution that uses only the model integration parts. I
>>>>>>>> haven't thought about such usage so far.
>>>>>>>
>>>>>>>
>>>>>>> kind regards,
>>>>>>> John Conlon
>>>>>
>>>>>
>>>
>>>
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #612920 is a reply to message #104978] |
Thu, 20 December 2007 11:26 |
|
[stuff deleted]
>>> Is there facilities for plugging in Model to Model translation
>>> facilities so that one could sync heterogeneous models to one
>>> repository?
>> I'm lost. Could you please elaborate on "Model to Model translation
>> facilities" and "heterogeneous models"?
>
> Caveat: Based on no experience with CDO/Net4J ...
>
> I was referring to the M2M work done as part of:
> http://www.eclipse.org/m2m/
>
> If a specific model in CDO is persisted in the model repository and
> this model can be synchronized to one or more client views of the
> model, I was speculating that a CDO client view could be created on
> one side of a M2M transformation service and on the other side of the
> M2M service a different or heterogeneous model could be attached.
> Then as the heterogeneous model changed the transformer would map it
> to changes on the CDO client side of the transformer.
>
>
>>> My mind has not been expanded as of yet to all the possibilities
>>> with CDO, but I am wondering if CDO may be able to offer an
>>> infrastructure for models what XProc
>>> http://www.w3.org/TR/2007/WD-xproc-20071129/
>>> is offering for XML docs?
>> I'm really not familiar with XProc. The abstract says "[...] a
>> language for describing operations to be performed on XML documents".
>> From this I'd say, no, CDO focusses more on the static aspects of a
>> model than on the possible operations that could modeify a model over
>> time. May be you can list some specific details of the XProc spec
>> (which I've not read as a whole) that you're interested in?
>
> This question was expanding on the previous one related to M2M. It was
> referring to XProc merely as an analogy not so much for a language but
> for a pipeline infrastructure that I was thinking might already be
> something implemented, designed or thought about for the CDO/Net4J
> client server model repo infrastructure.
>
> The idea is CDO as pipeline infrastructure where Model A (Ma) could be
> persisted in the repository but then have instances of another Model B
> (Mb) part of the synchronization. Where <-> represents the linkage.
>
> Ma Source as a CDO Client <->
> Ma Repo as CDO server <->
> Ma Target Client <->
> M2M transformer<->
> Mb Target as a CDO Client
Basically you can establish chains like
Client1 <-> CDOView1 <---> CDORepository <---> CDOView2 <->Client2
Where client1 and client2 can be any sort of process deployed on any
node in the network. Either client is able to detect the changes of all
other clients and see the result of the changes immediately.
I don't think that the number of models used plays an important role
with respect to feasibility. A CDO repository can be dynamically
populated with multiple models which are loaded by the clients as
needed. This is all transparent and automatic, i.e. when client1
registered a new model (EPackage) and committed a transaction that
actually contains objects with EClasses of this EPackage then this
EPackage is stored in the repository and delivered to other clients when
they need it. If the source package was generated and the target clients
don't have the generated model plugin installed they try to create a
dynamic model for it.
Does this help?
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #612922 is a reply to message #104995] |
Thu, 20 December 2007 15:11 |
| Eclipse User |
|
|
|
Originally posted by: jconlon.apache.org
Hi Eike,
Yes your explanation was helpful, thanks for the clarification.
Ok enough of the a priori questions it's time for me to download and
experiment with the code...
kind regards,
John
Eike Stepper wrote:
> [stuff deleted]
>> The idea is CDO as pipeline infrastructure where Model A (Ma) could be
>> persisted in the repository but then have instances of another Model B
>> (Mb) part of the synchronization. Where <-> represents the linkage.
>>
>> Ma Source as a CDO Client <->
>> Ma Repo as CDO server <->
>> Ma Target Client <->
>> M2M transformer<->
>> Mb Target as a CDO Client
> Basically you can establish chains like
>
> Client1 <-> CDOView1 <---> CDORepository <---> CDOView2 <->Client2
>
> Where client1 and client2 can be any sort of process deployed on any
> node in the network. Either client is able to detect the changes of all
> other clients and see the result of the changes immediately.
>
> I don't think that the number of models used plays an important role
> with respect to feasibility. A CDO repository can be dynamically
> populated with multiple models which are loaded by the clients as
> needed. This is all transparent and automatic, i.e. when client1
> registered a new model (EPackage) and committed a transaction that
> actually contains objects with EClasses of this EPackage then this
> EPackage is stored in the repository and delivered to other clients when
> they need it. If the source package was generated and the target clients
> don't have the generated model plugin installed they try to create a
> dynamic model for it.
>
> Does this help?
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
|
|
| |
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #612926 is a reply to message #104999] |
Thu, 20 December 2007 17:11 |
| Eclipse User |
|
|
|
Originally posted by: jconlon.apache.org
Hi Eike,
I read the docs at http://wiki.eclipse.org/?title=CDO
and your right with just two clicks (and a couple of steps) my repo is
running on my windows box! That was easy.
Now for preparing my existing models. I've been bad and have added a
lot of code to support various EMF editor tweaks to meet various
customer requirements. (This has kept me up at night as I am concerned
I have veered from the true path of MDE;-)
Do the .edit and .editor project gui artifacts generated with CDO,
create very different editors than the standard ones the EMF generators
do? In other words can I expect my coded tweaks to the EMF editors to
still work when I generate my CDO models?
kind regards,
John
Eike Stepper wrote:
> John E. Conlon schrieb:
>> Hi Eike,
>>
>> Yes your explanation was helpful, thanks for the clarification.
>>
>> Ok enough of the a priori questions it's time for me to download and
>> experiment with the code...
> Have fun and I'm here ;-)
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #612928 is a reply to message #105000] |
Thu, 20 December 2007 19:39 |
|
John E. Conlon schrieb:
> Hi Eike,
>
> I read the docs at http://wiki.eclipse.org/?title=CDO
> and your right with just two clicks (and a couple of steps) my repo is
> running on my windows box! That was easy.
Great!
> Now for preparing my existing models. I've been bad and have added a
> lot of code to support various EMF editor tweaks to meet various
> customer requirements. (This has kept me up at night as I am
> concerned I have veered from the true path of MDE;-)
>
> Do the .edit and .editor project gui artifacts generated with CDO,
> create very different editors than the standard ones the EMF
> generators do? In other words can I expect my coded tweaks to the EMF
> editors to still work when I generate my CDO models?
Ok, some details to the three generated plugins:
model: The only things that change when generating for CDO are the
superclass and the reflective feature delegation. If you have changes in
your model (other than the aforementioned ones) they should still work.
edit: The item providers are not changed by CDO (except for a
performance optimization of the hasChildren method that I currently
discuss with Ed).
editor: CDO doesn't generate an editor. Instead CDO comes with an own
editor implementation that works with your generated item providers. I
don't think that you can use a generated (and unchanged) editor with
CDO. If you have a look at the CDOEditor you get a clue what's
necessary. I've marked all additions with @ADDED. You won't be able (or
willing) to make all your editors CDO capable! Nevertheless it'd be an
intereting task to come up with a JET solution for CDO editors. That
said, I'm not a fan of model dependent changes to an editor, i.e. and to
generate model editors at all. Latest when you start mixing different
models within one resource you'll get a headache if your extra logic is
located in model dependent editors. I guess not everyone agrees here so
this is clearly not the reason why I don't provide JET templates for CDO
editors - it's only a matter of time and priorities.
Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
>
> kind regards,
> John
>
> Eike Stepper wrote:
>> John E. Conlon schrieb:
>>> Hi Eike,
>>>
>>> Yes your explanation was helpful, thanks for the clarification.
>>>
>>> Ok enough of the a priori questions it's time for me to download and
>>> experiment with the code...
>> Have fun and I'm here ;-)
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #612934 is a reply to message #105001] |
Thu, 20 December 2007 21:43 |
| Eclipse User |
|
|
|
Originally posted by: jconlon.apache.org
Eike Stepper wrote:
> John E. Conlon schrieb:
>> Hi Eike,
>>
>> I read the docs at http://wiki.eclipse.org/?title=CDO
>> and your right with just two clicks (and a couple of steps) my repo is
>> running on my windows box! That was easy.
> Great!
>
>> Now for preparing my existing models. I've been bad and have added a
>> lot of code to support various EMF editor tweaks to meet various
>> customer requirements. (This has kept me up at night as I am
>> concerned I have veered from the true path of MDE;-)
>>
>> Do the .edit and .editor project gui artifacts generated with CDO,
>> create very different editors than the standard ones the EMF
>> generators do? In other words can I expect my coded tweaks to the EMF
>> editors to still work when I generate my CDO models?
> Ok, some details to the three generated plugins:
>
> model: The only things that change when generating for CDO are the
> superclass and the reflective feature delegation. If you have changes in
> your model (other than the aforementioned ones) they should still work.
Cool.
> edit: The item providers are not changed by CDO (except for a
> performance optimization of the hasChildren method that I currently
> discuss with Ed).
Also good.
> editor: CDO doesn't generate an editor. Instead CDO comes with an own
> editor implementation that works with your generated item providers. I
> don't think that you can use a generated (and unchanged) editor with
> CDO. If you have a look at the CDOEditor you get a clue what's
> necessary. I've marked all additions with @ADDED. You won't be able (or
> willing) to make all your editors CDO capable! Nevertheless it'd be an
> intereting task to come up with a JET solution for CDO editors.
Or to make the CDO editor flexible enough to handle the kind of tasks
one has normally customized the generated editors to do. For example
Tree viewers with movable, hidable, sortable columns and filters for
row focusing for example.
Like:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=207324
I guess any gui customization necessary could also be done externally
via views.
That
> said, I'm not a fan of model dependent changes to an editor, i.e. and to
> generate model editors at all. Latest when you start mixing different
> models within one resource you'll get a headache if your extra logic is
> located in model dependent editors. I guess not everyone agrees here so
> this is clearly not the reason why I don't provide JET templates for CDO
> editors - it's only a matter of time and priorities.
Right.
cheers,
John
|
|
|
| Re: [Net4J] Bluetooth and/or comm port connectivity [message #612945 is a reply to message #104992] |
Fri, 21 December 2007 07:58 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Eike,
Then I think it is clear. I will start looking at how cdo operates currently and see how it can be
integrated with Teneo. Probably I will start doing this right in the new year.
gr. Martin
Eike Stepper wrote:
> Martin Taal schrieb:
>> Hi Eike,
>> I pasted your comments back up to make the post readable:
> Hmm, I found it more readable before ;-)
>
>> ES>> CDO (at client side) converts in both directions between an Ecore
>> model and its internal representation of this model. I think this is
>> the relation you mean. At CDO's server side there's usually no such
>> conversion because there's simply no EMF (required).
>> BUT: since the Ecore XMI string can be retrieved from the repository
>> via CDOPackage I think a Teneo based IStore implementation could add
>> EMF to its dependencies, deserialize the original Ecore model and
>> apply the same E<->CDO conversion as the CDO client.
>>
>> MT>> Yes that would surely work afaics. The ecore model is also
>> important for Teneo because it can contain annotations which influence
>> the persistence strategy.
> Annotations in the model have been the original trigger to make the
> model string available on the server.
>
>> ES>>
>> To sum up:
>> - It seems as we we (out products) could both profit from working
>> together.
>> - There could be a Teneo with CDO under the runtime hood [A]
>> - There could be a CDO server with a Teneo-based IStore [B]
>> - We are willing to spend effort for this ;-)
>>
>> MT>>
>> I fully agree, hopefully the teneo based istore would offer the same
>> api as you currently use within cdo server so that the changes in the
>> cdo server are not that large.
> The goal is to not change the repository framework but just plug in the
> new IStore implementation. Since we have already two implementations
> with quite different backends (OO and relational) there is a chance that
> we catch the goal.
>
>> I am willing to spend the effort in doing this (but not before the new
>> year :-).
> That's great!
>
>> ES>>
>> If you agree up to here we should discuss how we start and who should
>> do what. I had a similar integration story with Net4j <-> ECF and I
>> learned that it is often easier to *use* foreign API than to *extend*
>> it. That also results in the author of the integration being the
>> maintainer.
>>
>> For [A] that would mean that primarily you would extend your runtime
>> framework by using CDO API (with my help of course).
>> For [B] that would mean that primarily I would extend my storage
>> framework by implementing the above conversions at server side and
>> then using Teneo API (with your help).
>>
>> MT>> No problem we can see how we can divide the work. I am willing to
>> spend time on this and also maintain the runtime layer afterwards. I
>> can start looking at CDO and see how the persistence works currently
>> (using IStore). Can I download/test cdo separately without net4j?
> No, not if you want to compile CDO without errors. Please use "All.psf"
> from http://wiki.eclipse.org/CDO_Project_Resources#Sources
>
>> Do you have some hyperlinks with the docs?
> Hehe, after years without automatic signature I recently installed a
> Thunderbird plugin to get this dignified signature:
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
> There's some (hopefully) useful information in the CDO wiki ;-)
> That said, it's not yet fully complete so I guess we will have to
> discuss after you got a general overview.
>
>> ES>>
>> I guess that on the way we'll discover some more challenges ;-)
>> MT>>
>> For sure, it makes all this 'unpaid' work interesting and worthwhile
>> doesn't it :-).
> Really addictive!
>
>> One last question for my interest, does the non-emf cdo server side
>> support the emf featuremap and other emf/xml schema specialities such
>> as mixed or anytype?
> I'm not an expert myself in neither feature maps nor xsd details ;-(
> BUT I believe feature maps have already been reported to be used.
> More important, CDO/EMF integration is based on the EStore interface
> which I'd expect to support all EObject functionality including feature
> maps.
> For xml schema specialities such as mixed or anytype I'm not sure. Do
> they rely on EAnnotations? The only thing I can say is that I never
> thought about xsd in the context of CDO.
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO ;-)
> http://wiki.eclipse.org/Net4j
>
>
>>
>> gr. Martin
>>
>> Eike Stepper wrote:
>>> Martin Taal schrieb:
>>>> Hi Eike,
>>>> Just to continue on your last points (otherwise the post becomes
>>>> unreadable to me):
>>>> - Teneos main purpose (with respect to Hibernate) is the integration
>>>> of EMF Resources and EObjects with a Hibernate mapped database. In
>>>> other words you directly map EMF concepts to/from Hibernate concepts
>>>> in one deployment node (client or server).
>>>> MT>> Almost :-), Teneo consists of two main parts:
>>>> 1) Mapping functionality: maps a model to a relational schema (in
>>>> fact maps a model to a java persistence api annotated model which is
>>>> then translated to a hibernate mapping). The user can override
>>>> standard mapping behavior by adding jpa annotations in the model.
>>>> 2) At runtime provide easy integration between EMF and hibernate (or
>>>> jpox). This part is mainly to support automatic mapping (so using
>>>> the above functionality 1) when initializing and support emf
>>>> specifics such as featuremaps, elists and emf resources.
>>> That makes sense ;-)
>>>
>>>> Currently Teneo has 2 runtime layers one for jpox and one for
>>>> hibernate. It would be interesting to add other runtime layers.
>>> Ok, there I can see a chance for CDO. It would be completely covered
>>> by your runtime framework, right?
>>>
>>>> Btw, I use the mapping functionality of Teneo also outside of EMF: I
>>>> map the model using Teneo and then at runtime I have non-emf objects.
>>>>
>>>> - CDO wishes Hibernate mapping at its server side
>>>> - At the server side of CDO there are no EMF concepts. The CDO
>>>> (network) protocol doesn't deal with EMF concepts. The state of
>>>> EObjects is translated into non-EMF data structures at client side.
>>>> MT>> But still because you currently also create a relational
>>>> schema, I assume that the server also has knowledge of the ecore model.
>>> Right, at the client there are bijective conversions between:
>>> EPackage <-> CDOPackage
>>> EClass <-> CDOClass
>>> EStructuralFeature <-> CDOFeature
>>>
>>> So I'd say a simplified version of the Ecore model arrives at the
>>> server and is usually stored in an IStore of the CDO storage
>>> framework (can be RDB). BTW. it's even possible to retrieve the XMI
>>> string of the original Ecore model from a CDOPackage.
>>>
>>>> I can imagine also that your non-emf data structure refer to this
>>>> model?
>>> Right, there's a method CDORevision.getCDOClass().
>>>
>>>> - The non-EMF data structures that represent EObject state at the
>>>> server can't easily mapped by Teneo (since Teneo deals with EMF
>>>> concepts).
>>>> MT>> Not sure if this is an obstacle. I assume that also for the CDO
>>>> non-emf datastructures there is a relation to the application model
>>>> expressed in ecore. Teneo also uses the ecore model as its basis for
>>>> mapping to hibernate. So as long as there is a relation between your
>>>> non-emf datastructure and the ecore model then a runtime layer which
>>>> uses the Teneo mapping logic should be pretty doable.
>>> That's great to hear. But we have to double check:
>>> CDO (at client side) converts in both directions between an Ecore
>>> model and its internal representation of this model. I think this is
>>> the relation you mean. At CDO's server side there's usually no such
>>> conversion because there's simply no EMF (required).
>>> BUT: since the Ecore XMI string can be retrieved from the repository
>>> via CDOPackage I think a Teneo based IStore implementation could add
>>> EMF to its dependencies, deserialize the original Ecore model and
>>> apply the same E<->CDO conversion as the CDO client.
>>>
>>> That sounds reasonable to me. Agreed so far?
>>> I'd have to factor out the conversion mechanism into a separate
>>> plugin...
>>>
>>>> For example next to Teneo I am working on generating seam web
>>>> applications from ecore models. To support the persistence side I
>>>> use Teneo for the mapping and as runtime I have a dynamic-emf-like
>>>> object (basically a type-safe hashmap). The runtime layer is about
>>>> 15 classes.
>>> That sounds similar to the CDO server although it has one or two more
>>> classes ;-)
>>>
>>> To sum up:
>>> - It seems as we we (out products) could both profit from working
>>> together.
>>> - There could be a Teneo with CDO under the runtime hood [A]
>>> - There could be a CDO server with a Teneo-based IStore [B]
>>> - We are willing to spend effort for this ;-)
>>>
>>> If you agree up to here we should discuss how we start and who should
>>> do what. I had a similar integration story with Net4j <-> ECF and I
>>> learned that it is often easier to *use* foreign API than to *extend*
>>> it. That also results in the author of the integration being the
>>> maintainer.
>>>
>>> For [A] that would mean that primarily you would extend your runtime
>>> framework by using CDO API (with my help of course).
>>> For [B] that would mean that primarily I would extend my storage
>>> framework by implementing the above conversions at server side and
>>> then using Teneo API (with your help).
>>>
>>> I guess that on the way we'll discover some more challenges ;-)
>>>
>>> Regards,
>>> Eike Stepper
>>> ----
>>> http://wiki.eclipse.org/CDO
>>> http://wiki.eclipse.org/Net4j
>>>
>>>
>>>>
>>>> gr. Martin
>>>>
>>>> Eike Stepper wrote:
>>>>> Hi Martin,
>>>>>
>>>>> comments below...
>>>>>
>>>>>
>>>>> Martin Taal schrieb:
>>>>>> Hi Eike, John,
>>>>>> Just to add my thoughts about Teneo :-).
>>>>>> Teneo is very much focused on being a persistence solution for
>>>>>> persisting (complex) models to a relational store. This focus
>>>>>> means that Teneo has broad support for most complex modeling
>>>>>> constructs (for example feature maps, xml schema anytype, mixed
>>>>>> type, etc.) and support for jpa annotations in the model. On the
>>>>>> other hand this focus also means that Teneo does not include
>>>>>> specific client-server functionality, this is outside of the scope
>>>>>> of Teneo.
>>>>>> So I would not say that Teneo is a client side solution (I use
>>>>>> Teneo server side in a web app). Teneo can also be used server
>>>>>> side (in a rcp app) but then you need to implement your own
>>>>>> client-server layer (using other tools).
>>>>> These client/server things are so ambiguous like the model/meta
>>>>> model things depending on the start point ;-)
>>>>> But with your clarification the main difference between CDO and
>>>>> Teneo should be clear now.
>>>>>
>>>>>> Btw, it would be interesting to integrate the client-server
>>>>>> capabilities of CDO/net4j with the mapping capabilities of Teneo.
>>>>>> I think this can be a powerfull combination...
>>>>> That'd be of course an interesting effort. What do you think could
>>>>> be the result of such an effort?
>>>>>
>>>>> Simon (cc'ed) and I often discussed this topic and I seem to
>>>>> remember that we (you and I) also spoke about such integration.
>>>>> The result that I'd wish from such an integration would clearly be
>>>>> a CDO storage framework implementation that uses Hibernate as O/R
>>>>> mapper. I fear that your general experience with Hibernate can be
>>>>> more helpful than your actual product Teneo. But I'd be glad to be
>>>>> proven wrong here. The following is the reason (correct me if I'm
>>>>> wrong):
>>>>> - Teneos main purpose (with respect to Hibernate) is the
>>>>> integration of EMF Resources and EObjects with a Hibernate mapped
>>>>> database. In other words you directly map EMF concepts to/from
>>>>> Hibernate concepts in one deployment node (client or server).
>>>>> - CDO wishes Hibernate mapping at its server side
>>>>> - At the server side of CDO there are no EMF concepts. The CDO
>>>>> (network) protocol doesn't deal with EMF concepts. The state of
>>>>> EObjects is translated into non-EMF data structures at client side.
>>>>> - The non-EMF data structures that represent EObject state at the
>>>>> server can't easily mapped by Teneo (since Teneo deals with EMF
>>>>> concepts).
>>>>>
>>>>> Would you agree?
>>>>>
>>>>> Regards,
>>>>> Eike Stepper
>>>>> ----
>>>>> http://wiki.eclipse.org/CDO
>>>>> http://wiki.eclipse.org/Net4j
>>>>>
>>>>>
>>>>>>
>>>>>> gr. Martin
>>>>>>
>>>>>> Eike Stepper wrote:
>>>>>>> John E. Conlon schrieb:
>>>>>>>>> [stuff deleted]
>>>>>>>>>> How does CDO compare to Teneo?
>>>>>>>>> I'd say the main difference is the deployment strategy. While
>>>>>>>>> Teneo (I'm not a Teneo expert!) is mainly used on the client
>>>>>>>>> side (with hibernate/jpox generated JDBC on the wire) CDO is is
>>>>>>>>> used on the client side for EMF model integration and on the
>>>>>>>>> server side for the storage integration (O/R mapping, OODB
>>>>>>>>> integration). CDO uses an own (Net4j based) wire protocol which
>>>>>>>>> is tailored to transactional semantics in the context of
>>>>>>>>> objects (not SQL). Since CDO clients rely on a dedicated CDO
>>>>>>>>> server they can offer some additional functions not available
>>>>>>>>> with Teneo, like automatic model update on all clients if one
>>>>>>>>> client commits a transaction (distributed shared model semantics).
>>>>>>>>
>>>>>>>> So Teneo is more of a client side persistence alternative and
>>>>>>>> CDO is a model repository server!
>>>>>>> Right.
>>>>>>>
>>>>>>>> Is CDO the only Eclipse Modeling project making this claim?
>>>>>>> AFAIK, yes.
>>>>>>>
>>>>>>>> Side question:
>>>>>>>> Since models are persisted to a repository server (a rdbms) has
>>>>>>>> anyone experimented with plugging in BIRT to this rdbms so end
>>>>>>>> user's could be given reporting support? In other words are the
>>>>>>>> final relational schemas human readable and understandable
>>>>>>>> enough for report designers to work with?
>>>>>>> Interesting question because I just discussed that topic with a
>>>>>>> friend of mine. I cc'ed Philipp for this purpose.
>>>>>>>
>>>>>>> 1) A CDO server mainly consists of three parts/layers: A protocol
>>>>>>> peer (Net4j based), a model repository framework (storage
>>>>>>> agnostic) and a storage framework. It depends on the storage
>>>>>>> implementation (IStore) how the model data is actually persisted
>>>>>>> to a storage backend. This *can* be an RDBMS via plain JDBC
>>>>>>> (default) but a user has also implemented an Objectivity store
>>>>>>> (OODBMS) and plans to implement a Hibernate based store.
>>>>>>>
>>>>>>> 2) In case the default JDBC store is used with a repository I'd
>>>>>>> say yes, the generated schema is human readable and
>>>>>>> understandable enough for report designers to work with but that
>>>>>>> is my own opinion. Currently CDO always uses its own generated
>>>>>>> primary keys (long id values) and references are mostly always
>>>>>>> stored in a fixed format that allows for transparent versioning.
>>>>>>>
>>>>>>> 3) I'd prefer to see a model/BIRT integration at the model side
>>>>>>> (CDO client) rather than at the DB side (one of several possible
>>>>>>> CDO storage backends and highly implementation dependent). I'm
>>>>>>> neither a BIRT nor an ODA expert but is it not possible to use an
>>>>>>> EMF ResourceSet, a Resource or an EObject as an ODA data source?
>>>>>>> That'd be much closer to the semantics of the model than querying
>>>>>>> the mapped DB.
>>>>>>>
>>>>>>>>>> Does CDO use the EMF transaction framework?
>>>>>>>>> No, CDO acts directly on the model level. EMF Transaction acts
>>>>>>>>> on the higher edit/command framework level which, in my
>>>>>>>>> opinion, has at least two disadvantages:
>>>>>>>>> 1) Not all clients want to use a command stack to interact with
>>>>>>>>> models (especially non-UI clients like batch clients). With CDO
>>>>>>>>> these clients can remain unchanged (are not forced to use a
>>>>>>>>> command stack) and since CDO transactions are transparent to
>>>>>>>>> the command stack UI clients can be used, too.
>>>>>>>>> 2) Worse, command stack based transactions rely on the
>>>>>>>>> cooperation of *all* clients of a model. If only one client
>>>>>>>>> doesn't use a command stack or uses a non-transactional command
>>>>>>>>> stack all transactions might become corrupt! Since CDO
>>>>>>>>> integrates with EMF models at their core none of these
>>>>>>>>> restrictions apply.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> When you say CDO works at the model level, does that mean entire
>>>>>>>> models are moved from client to server?
>>>>>>> I'm not sure if I correctly understand the intend of your
>>>>>>> question. The scope of a CDO transaction is always an EMF
>>>>>>> ResourceSet (no command stack needed). This ResourceSet can
>>>>>>> contain multiple CDO Resources (and possibly other types of
>>>>>>> Resources). At the time of committing the transaction no CDO
>>>>>>> Resource is allowed to contain references to non-CDO Resources.
>>>>>>> In other words a CDO repository is always guaranteed to contain a
>>>>>>> consistent state of an object graph that can be partitioned into
>>>>>>> CDO Resources. Looking from the other side a CDO-prepared
>>>>>>> ResourceSet acts like a partial but self-populating view onto the
>>>>>>> whole object graph of the repository.
>>>>>>>
>>>>>>> So in this sense, yes, entire models are (initially) moved from
>>>>>>> client to server. Once a model is committed into the repository
>>>>>>> subsequent reads and writes (commits) act at least at an object
>>>>>>> granularity. A recent effort of a user added support for sending
>>>>>>> only deltas for changed objects to the server, see
>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=201266 .
>>>>>>>
>>>>>>> I guess I should stop saying "at the model level" because the
>>>>>>> word "model" is one of the only four terms we have available in
>>>>>>> modern software engineering, ambiguities granted ;-)
>>>>>>> The reason I used it is the following. When you kick the EMF
>>>>>>> generator for an ecore model it typically produces 3 plugins:
>>>>>>> 1) model plugin
>>>>>>> 2) edit plugin (command framework integration)
>>>>>>> 3) editor plugin (Eclipse UI)
>>>>>>>
>>>>>>> When I say "at the model level" I really mean that only 1) is
>>>>>>> needed for integration. AFAIK EMF Transaction needs 1) plus 2)
>>>>>>> for its integration because it intercepts commands of the command
>>>>>>> framework.
>>>>>>>
>>>>>>>> Is there facilities for plugging in Model to Model translation
>>>>>>>> facilities so that one could sync heterogeneous models to one
>>>>>>>> repository?
>>>>>>> I'm lost. Could you please elaborate on "Model to Model
>>>>>>> translation facilities" and "heterogeneous models"?
>>>>>>>
>>>>>>>> My mind has not been expanded as of yet to all the possibilities
>>>>>>>> with CDO, but I am wondering if CDO may be able to offer an
>>>>>>>> infrastructure for models what XProc
>>>>>>>> http://www.w3.org/TR/2007/WD-xproc-20071129/
>>>>>>>> is offering for XML docs?
>>>>>>> I'm really not familiar with XProc. The abstract says "[...] a
>>>>>>> language for describing operations to be performed on XML
>>>>>>> documents". From this I'd say, no, CDO focusses more on the
>>>>>>> static aspects of a model than on the possible operations that
>>>>>>> could modeify a model over time. May be you can list some
>>>>>>> specific details of the XProc spec (which I've not read as a
>>>>>>> whole) that you're interested in?
>>>>>>>
>>>>>>>>>> [stuff deleted]
>>>>>>>>> Good point! Would you be willing to contribute such a
>>>>>>>>> connector? If so, please open an enhancement request in
>>>>>>>>> Bugzilla and attach a patch (since Net4j is already extensible
>>>>>>>>> in the dimension of transports a patch might not be needed and
>>>>>>>>> you can simply attach the extension bundle project). I'd be
>>>>>>>>> happy to maintain the code after ;-)
>>>>>>>>
>>>>>>>> Have several activities scheduled right now, but I am interested
>>>>>>>> enough to contribute with either a comm port transport or a
>>>>>>>> Bluetooth one. The problem I for see with either one of these
>>>>>>>> solutions is that I expect there will be OS library dependencies
>>>>>>>> that will have to be bundled with the code. This is something I
>>>>>>>> have not done before.
>>>>>>> OSGi should be prepared for this ;-)
>>>>>>>>
>>>>>>>> Will start looking into this next month.
>>>>>>> That'd be great! Please tell me when you need my assistance...
>>>>>>>
>>>>>>> Regards,
>>>>>>> Eike Stepper
>>>>>>> ----
>>>>>>> http://wiki.eclipse.org/CDO
>>>>>>> http://wiki.eclipse.org/Net4j
>>>>>>>
>>>>>>>
>>>>>>>>>> That said, a connector implementation for comm ports should be
>>>>>>>>>> easy, as easy as the usage of comm ports is in Java (which I
>>>>>>>>>> have no idea of).
>>>>>>>>>> I have not done this myself, so I don't know how easy the
>>>>>>>>>> lower layer will be. Would probably do the
>>>>>>>>>> http://www.rxtx.org/ versus Sun's impl.
>>>>>>>>>>
>>>>>>>>>> As
>>>>>>>>>>> the docs of IConnector state you'll have to subclass
>>>>>>>>>>> Connector (
>>>>>>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j/src/org/eclipse /internal/net4j/Connector.java?root=Modeling_Project&vie w=log)
>>>>>>>>>>> . I suggest to look at the implementation of TCPConnector (
>>>>>>>>>>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.net4j/plugins/org.eclipse.net4j.tcp/src/org/ecl ipse/net4j/internal/tcp/TCPConnector.java?root=Modeling_Proj ect&view=log
>>>>>>>>>>> ).
>>>>>>>>>>>
>>>>>>>>>>> As I said above, if you succeed in providing a comm port
>>>>>>>>>>> implementation of IConnector (and the supporting factories)
>>>>>>>>>>> you'll get EMF integration for free ;-)
>>>>>>>>>>
>>>>>>>>>> Sounds good, but will I need to also install a database to get
>>>>>>>>>> EMF integration?
>>>>>>>>> Good question! According to the 'normal' setup of a CDO
>>>>>>>>> deployment, yes. But CDO should be open and layered enuogh to
>>>>>>>>> find a solution that uses only the model integration parts. I
>>>>>>>>> haven't thought about such usage so far.
>>>>>>>>
>>>>>>>>
>>>>>>>> kind regards,
>>>>>>>> John Conlon
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
Goto Forum:
Current Time: Fri Dec 27 00:56:34 GMT 2024
Powered by FUDForum. Page generated in 0.10185 seconds |
] 
Search
Help
Register
Login
Home
