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):
- CDO User Interface (Eclipse RCP based)
- CDO Client (EMF model integration and programmatic repository access)
- CDO Protocol (Net4j based binary application protocol)
- CDO Server (Repository and session management)
- 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:
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. For the CDO server there is even a zipped, installable Eclipse product available that comes with a pre-installed Derby database server, a cdo-server.exe for Windows and a complete configuration. You're about two clicks away from your own model repository server!