Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "CDO Architecture"

(Overview)
 
(7 intermediate revisions by the same user not shown)
Line 1: Line 1:
 +
__TOC__
 +
 +
==Overview==
 +
 
The architecture of CDO is strongly influenced by the concepts of the [http://www.osgi.org OSGi specification]. The modules of CDO are OSGi bundles, including Eclipse plugins, and the easiest way to execute CDO applications is to deploy these bundles to an OSGi or Eclipse installation. Despite this capability care has been taken that all the core modules (that is everything except the user interface) can also be used in standalone applications outside of an OSGi bundle container.
 
The architecture of CDO is strongly influenced by the concepts of the [http://www.osgi.org OSGi specification]. The modules of CDO are OSGi bundles, including Eclipse plugins, and the easiest way to execute CDO applications is to deploy these bundles to an OSGi or Eclipse installation. Despite this capability care has been taken that all the core modules (that is everything except the user interface) can also be used in standalone applications outside of an OSGi bundle container.
  
 
The architecture of CDO is strictly layered where each layer is potentially replaceable or extendable. The basic layers are (top-down):
 
The architecture of CDO is strictly layered where each layer is potentially replaceable or extendable. The basic layers are (top-down):
* CDO user interface (Eclipse RCP based)
+
* '''[[CDO User Interface]]''' (Eclipse RCP based)
* CDO client (EMF model integration and programmatic repository access)
+
* '''[[CDO Client]]''' (EMF model integration and programmatic repository access)
* CDO protocol (Net4j based binary application protocol)
+
* '''[[CDO Protocol]]''' (Net4j based binary application protocol)
* CDO server (Repository and session management)
+
* '''[[CDO Server]]''' (Repository and session management)
* CDO storage framework (Connection to various types of persistent storage like relational databases)
+
* '''[[CDO Storage Framework]]''' (Connection to various types of persistent storage like relational databases)
  
 
Each layer carefully attends to proper separation of public API and internal implementation. Together this makes CDO a very flexible technology that can easily be extended or taylored to meet specific environmental needs. There are many different assemblies possible, though a typical 3-tier deployment could look like these stacks:
 
Each layer carefully attends to proper separation of public API and internal implementation. Together this makes CDO a very flexible technology that can easily be extended or taylored to meet specific environmental needs. There are many different assemblies possible, though a typical 3-tier deployment could look like these stacks:
Line 12: Line 16:
  
 
[[Image:CDOStacks.png]]
 
[[Image:CDOStacks.png]]
 +
 +
 +
You might find this diagram look a bit frightening at a first glance but with an OSGi or Eclipse platform deployment is mostly a matter of copying the required bundles into the proper plugins folder on the disk.
 +
 +
==Dependencies==
 +
 +
TBD.
 +
 +
==Modules==
 +
 +
TBD.
 +
 +
==Components==
 +
 +
TBD.
 +
 +
==Wiring==
 +
 +
TBD.
 +
 +
 +
----
 +
Wikis: [[CDO]] | [[Net4j]] | [[EMF]] | [[Eclipse]]

Latest revision as of 05:34, 12 April 2008

Overview

The architecture of CDO is strongly influenced by the concepts of the OSGi specification. The modules of CDO are OSGi bundles, including Eclipse plugins, and the easiest way to execute CDO applications is to deploy these bundles to an OSGi or Eclipse installation. Despite this capability care has been taken that all the core modules (that is everything except the user interface) can also be used in standalone applications outside of an OSGi bundle container.

The architecture of CDO is strictly layered where each layer is potentially replaceable or extendable. The basic layers are (top-down):

Each layer carefully attends to proper separation of public API and internal implementation. Together this makes CDO a very flexible technology that can easily be extended or taylored to meet specific environmental needs. There are many different assemblies possible, though a typical 3-tier deployment could look like these stacks:


CDOStacks.png


You might find this diagram look a bit frightening at a first glance but with an OSGi or Eclipse platform deployment is mostly a matter of copying the required bundles into the proper plugins folder on the disk.

Dependencies

TBD.

Modules

TBD.

Components

TBD.

Wiring

TBD.



Wikis: CDO | Net4j | EMF | Eclipse

Back to the top