Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "CDO"
Line 7: | Line 7: | ||
| <br> | | <br> | ||
| <br> | | <br> | ||
− | | width="500" valign="top" | The CDO (Connected Data Objects) Model Repository is a distributed shared model framework for EMF models and meta models. CDO is also a model runtime environment with a focus on orthogonal aspects like model scalability, transactionality, persistence, distribution, queries and more.<br> | + | | width="500" valign="top" | The CDO (Connected Data Objects) Model Repository is a distributed shared model framework for [[EMF]] models and meta models. CDO is also a model runtime environment with a focus on orthogonal aspects like model scalability, transactionality, persistence, distribution, queries and more.<br> |
− | CDO has a 3-tier architecture supporting EMF-based client applications, featuring a central model repository server and leveraging different types of pluggable data storage back-ends like relational databases, object databases and file systems. The default client/server communication protocol is implemented with the Net4j Signalling Platform. | + | CDO has a 3-tier architecture supporting EMF-based client applications, featuring a central model repository server and leveraging different types of pluggable data storage back-ends like relational databases, object databases and file systems. The default client/server communication protocol is implemented with the [[Net4j]] Signalling Platform. |
|} | |} | ||
Line 38: | Line 38: | ||
*EMF integration at model level (as opposed to the edit level) | *EMF integration at model level (as opposed to the edit level) | ||
− | *Supported model types: | + | *Supported model types: |
**Generated models (just switch two .genmodel properties) | **Generated models (just switch two .genmodel properties) | ||
**Dynamic models (just load .ecore file and commit to repository) | **Dynamic models (just load .ecore file and commit to repository) | ||
Line 72: | Line 72: | ||
*Asynchronous object invalidation (optional) | *Asynchronous object invalidation (optional) | ||
*Clean API to work with sessions, views, transactions and objects | *Clean API to work with sessions, views, transactions and objects | ||
− | *CDOResources are | + | *CDOResources are [[EObject]]s as well |
*Objects carry meta information like id, state, version and life span | *Objects carry meta information like id, state, version and life span | ||
− | *Support for OSGi environments (headless, Eclipse RCP, ...) | + | *Support for [[OSGi]] environments (headless, Eclipse [[RCP]], ...) |
*Support for standalone applications (non-OSGi) | *Support for standalone applications (non-OSGi) | ||
Line 112: | Line 112: | ||
*Supports all optional features of the [[#CDO_Server|CDO Server]] | *Supports all optional features of the [[#CDO_Server|CDO Server]] | ||
*Pluggable SQL dialect adapters | *Pluggable SQL dialect adapters | ||
− | *Includes support for Derby, H2, HSQLDB, MySQL and Oracle (TBD) | + | *Includes support for [[Derby]], [[H2]], [[HSQLDB]], [[MySQL]] and [[Oracle]] (TBD) |
*Pluggable mapping strategies | *Pluggable mapping strategies | ||
*Includes horizontal mapping strategy (one table per concrete class) | *Includes horizontal mapping strategy (one table per concrete class) | ||
*Includes vertical mapping strategy (TBD, one table per class in hierarchy) | *Includes vertical mapping strategy (TBD, one table per class in hierarchy) | ||
*Supports different mapping modes for collections | *Supports different mapping modes for collections | ||
− | *Various mapping options by using EAnnotation | + | *Various mapping options by using [[EAnnotation]] |
<br> <br> | <br> <br> |
Revision as of 19:05, 9 December 2010
|
|
|
The CDO (Connected Data Objects) Model Repository is a distributed shared model framework for EMF models and meta models. CDO is also a model runtime environment with a focus on orthogonal aspects like model scalability, transactionality, persistence, distribution, queries and more. CDO has a 3-tier architecture supporting EMF-based client applications, featuring a central model repository server and leveraging different types of pluggable data storage back-ends like relational databases, object databases and file systems. The default client/server communication protocol is implemented with the Net4j Signalling Platform. |
Model Integration Features
- EMF integration at model level (as opposed to the edit level)
- Supported model types:
- Generated models (just switch two .genmodel properties)
- Dynamic models (just load .ecore file and commit to repository)
- Legacy models (for compiled models without access to .genmodel)
- Ecore meta meta model and descendants
User Interface Features
- Eclipse view for working with CDO sessions, transactions, views and resources
- Package Manager dialog per session
- Eclipse editor for working with resources and objects
Client Side Features
- 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)
Network Protocol Features
- Net4j based binary application protocol
- Pluggable transport layer (shipped with NIO socket transport, polling HTTP and JVM embedded transport)
- Pluggable fail over support
- Pluggable authentication (shipped with challenge/response negotiation)
- Multiple acceptors per server
Server Side Features
- Pluggable storage adapters
- See DB Store Features
- See Hibernate Store Features
- Objectivity support coming soon
- Native memory storage adapter
- 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 Store Features
- Supports all optional features of the CDO Server
- Pluggable SQL dialect adapters
- Includes support for Derby, H2, 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
- Various mapping options by using EAnnotation