Skip to main content
Jump to: navigation, search

Difference between revisions of "CDO"

Line 1: Line 1:
 
__NOTOC__
 
__NOTOC__
 
{|border="0" cellspacing="10"
 
{|border="0" cellspacing="10"
|valign="top" width="500"|CDO is a 3-tiers solution for '''distributed shared models''' and a complete '''model repository''' server.<br><br>With CDO you can easily enhance your existing [[EMF]] models in such a way that they can be stored and subsequently maintained in a central model repository. While object relational mapping against a JDBC data source on the server side is the shipped default CDO provides for ''pluggable storage adapters'' that allow you to develop and use different mappers (like Hibernate- or OODB-based). On the client side CDO provides a default integration with EMF, the Eclipse Modeling Framework, although other model integrations on top of the ''CDO protocol'' are imaginable as well.
+
|valign="top" width="450"|CDO is a 3-tiers solution for '''distributed shared models''' and a complete '''model repository''' server.<br><br>With CDO you can easily enhance your existing [[EMF]] models in such a way that they can be stored and subsequently maintained in a central model repository. While object relational mapping against a JDBC data source on the server side is the shipped default CDO provides for ''pluggable storage adapters'' that allow you to develop and use different mappers (like Hibernate- or OODB-based). On the client side CDO provides a default integration with EMF, the Eclipse Modeling Framework, although other model integrations on top of the ''CDO protocol'' are imaginable as well.
  
 
|valign="top"|[[Image:CDOOverview.png]]
 
|valign="top"|[[Image:CDOOverview.png]]

Revision as of 04:08, 2 November 2007

CDO is a 3-tiers solution for distributed shared models and a complete model repository server.

With CDO you can easily enhance your existing EMF models in such a way that they can be stored and subsequently maintained in a central model repository. While object relational mapping against a JDBC data source on the server side is the shipped default CDO provides for pluggable storage adapters that allow you to develop and use different mappers (like Hibernate- or OODB-based). On the client side CDO provides a default integration with EMF, the Eclipse Modeling Framework, although other model integrations on top of the CDO protocol are imaginable as well.
CDOOverview.png
Documentation

CDO Architecture
CDO Weaver
CDO User Interface
CDO Client
CDO Protocol
CDO Server
CDO Storage Framework

Tutorials

Setting up a CDO Server
Preparing EMF Models for CDO
Using the CDO User Interface
Writing Standalone CDO Applications

Resources

Downloads
Sources
JavaDocs
Support and Feedback
Miscellaneous

Features

Model Integration
Model
CDO User Interface
CDO Client
CDO Protocol
CDO Server
JDBC Storage Adapter

Model Integration

  • EMF integration on model level (as opposed to the edit level)
  • Support for generated models (just switch two .genmodel properties)
  • Support for dynamic models (just load .ecore file and commit to repository)
  • Support for legacy models (for compiled models without access to .genmodel)
  • Support for the Ecore meta meta model and descendants

CDO User Interface

  • Eclipse view for working with CDO sessions, transactions, views and resources
  • Package Manager dialog per session
  • Eclipse editor for working with resources and objects

CDO Client

  • Multiple sessions to multiple repositories on multiple servers
  • Multiple transactions per session
  • Multiple read-only views per session
  • Multiple audit views per session (an audit is a view that shows a consistent, historical version of a repository)
  • Multiple resources per view (a view is always associated with its own EMF ResourceSet)
  • Inter-resource proxy resolution
  • Multiple root objects per resource
  • Object state shared among all views of a session
  • Object graph internally unconnected (unused parts of the graph can easily be reclaimed by the garbage collector)
  • Only new and modified objects committed in a transaction
  • Transactions can span multiple resources
  • Demand loading of objects (resources are populated as they are navigated)
  • Partial loading of collections (chunk size can be configured per session)
  • Adaptable pre-fetching of objects (different intelligent usage analyzers are available)
  • Asynchronous object invalidation (optional)
  • Clean API to work with sessions, views, transactions and objects
  • CDOResources are EObjects as well
  • Objects carry meta information like id, state, version and life span
  • Support for OSGi environments (headless, Eclipse RCP, ...)
  • Support for standalone applications (non-OSGi)

CDO Protocol

  • Net4j based binary application protocol
  • Pluggable transport layer (shipped with NIO socket transport and JVM embedded transport)
  • Pluggable fail over support
  • Pluggable authentication (shipped with challenge/response negotiation)
  • Multiple acceptors per server

CDO Server

  • Pluggable storage adapters
  • Multiple repositories per server
  • Multiple models (packages) per repository
  • Multiple resources (instance documents) per repository
  • Expressive XML configuration file
  • Configurable storage adapter per repository (see below)
  • Configurable caching per repository
  • Clean API to work with repositories, sessions, views, transactions and revisions
  • Support for OSGi environments (usually headless)
  • Support for standalone applications (non-OSGi)

JDBC Storage Adapter

  • Supports all optional features of the CDO Server
  • Pluggable SQL dialect adapters
  • Includes support for Derby, HSQLDB, MySQL and Oracle (TBD)
  • Pluggable mapping strategies
  • Includes horizontal mapping strategy (one table per concrete class)
  • Includes vertical mapping strategy (TBD, one table per class in hierarchy)
  • Supports different mapping modes for collections



Wikis: Net4j | EMF | Eclipse

Back to the top