CDO Model Repository

It's always been one of the major problems in my applications:

Keep the model instance at multiple clients in sync so that people don't see stale states

The code required to make was huge, error prone and didn't solved all corner cases.

Switching our applications to CDO solved this problem because it is an integral part of CDO.

The other major problem CDO solved for me the problem of transfering only certain chunks of the big object graph and lazy loading other nested stuff once it is needed (one of the major problems in 3tier applications who are based upon models)

Recently started to use CDO to migrate a legacy jdbc app to profit by model driven architectures in general and CDO/EMF in particular.

It [CDO] has a very clean code base and allows for easy integrations and own extensions.

As a domain expert in telecommunications, I have been designing, calculating and building Infrastructure in Europe, Asia and Africa. Most of the work was done using a spreadsheet program, which is quick, but ad-hoc and not audible or re-usable. NetXForge is now aiming to change that, with a mixture of a Network inventory system, Performance management and Expression system.

Combining these capabilities opens an extraordinary new way into the field of telecommunications planning. The requirements for the System, are the capabilities to work with meta-models, which change frequently, hold revision information and allow auditing of performed work. On top it has to be robust, and allow multiple users to collaborate on the same data sets either graphically or through regular presentation widgets like tables or trees.

The Eclipse modeling project provided the answer. EMF is solid foundation, topped with many capabilities as EMF Compare, Search and a project like Xtext which is the base for the expression editor.

The back-end solution for EMF objects is of course CDO. CDO provides many features out of the box, and allowed us to choose the backend persistence store.

We chose Hibernate, as Postgres DB was a requirement, but we are looking into a native DB store to support revision handling. We also make use of the Dawn facilities to handle conflict or other notifications. This gives a great user experience, suddenly getting warned someone else accessing the same object.

What we like about CDO is the fact that we deal with EMF objects, and we have a way to work with large models which can be retrieved in granular fashion, as well as garbage collected.

Some aspects were not readily available or unclear how to do, but thanks to the great responsiveness from the CDO team on the forum, it was a matter of hours (not days!) before we were already moving on.

We have by far, explored all the capabilities of CDO, but we will continue to push the envelop and provide more value to our customers. We have some ideas on how CDO could be used to hold objects which are process entities by themselves. This would allow the modeling of large interacting entities to simulate real live processing of telecommunications functions as an alternative or complement to statistical functions.

We use CDO in one of our product since more than 1 year. Offline mode, transaction support, real-time updates of shared models, conflicts resolving are some of the most important features we need.

We found some critical bugs in CDO but they were always quickly fixed by the developers and there is always someone to answer your questions in the EMF newsgroup.

CDO is still missing some important features like model evolution or purge old revisions from the database. However, CDO is evolving quickly and the development process (extended test suite, continuous integration, etc) ensures a high-quality framework.

Sharing models between multiple clients is definitely not a trivial task and beside some bugs we had at the beginning and some features we still miss, CDO allows us to write high-quality software for our customers.

since some years we're using CDO - and we have to state that CDO is a great way to persist distributed EMF models, which is important for rcp clients running redView (EMF - model-based dynamic UI).

if I only had to rate the quality of code and support of CDO project team I would give 5 stars, but we're missing one part: model-evolution. UI models often get new elements and it would be nice to use these new enhanced models with existing persisted models.

ekke