Skip to main content
Jump to: navigation, search

Difference between revisions of "CDO"

(Project Resources)
(Project Resources)
Line 78: Line 78:
 
* [[Media:CDOAndNet4jProjectSet.psf|Eclipse Team Project Set File (PSF) to checkout Net4j and CDO from CVS]]
 
* [[Media:CDOAndNet4jProjectSet.psf|Eclipse Team Project Set File (PSF) to checkout Net4j and CDO from CVS]]
 
* [http://download.eclipse.org/modeling/emft/cdo/javadoc/0.8.0/ JavaDoc for CDO 0.8.0]
 
* [http://download.eclipse.org/modeling/emft/cdo/javadoc/0.8.0/ JavaDoc for CDO 0.8.0]
* [http://bugs.eclipse.org/bugs/buglist.cgi?product=EMFT&component=CDO&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&order=bugs.bug_status,bugs.target_milestone,bugs.bug_id&query_format=advanced Open Bugs]
+
* [http://bugs.eclipse.org/bugs/buglist.cgi?product=EMFT&component=CDO&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&order=bugs.bug_status,bugs.target_milestone,bugs.bug_id&query_format=advanced Open Bugs List] or [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EMFT Submit a Bug]
 +
* [http://www.eclipse.org/modeling/emft/newsgroup-mailing-list.php Newsgroups & Mailing Lists]
  
 
==Further Reading==
 
==Further Reading==

Revision as of 17:20, 18 October 2007

Introduction

CDO is a 3-tiers solution for distributed shared models and a complete model repository. 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


Features

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)

DB Storage Adapter

  • Pluggable SQL dialect adapters
  • Pluggable mapping strategies
  • Supports horizontal mapping strategy (one table per concrete class)
  • Supports vertical mapping strategy (TBD, one table per class in hierarchy)
  • Supports different mapping modes for collections


Project Resources

Further Reading


Wikis: Net4j | EMF | Eclipse

Back to the top