plugins/org.eclipse.emf.cdo.doc/html/Overview.html - cdo/cdo - Git at Google

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
 <HTML>

 <HEAD>
 <TITLE>Overview (CDO Model Repository Documentation)</TITLE>

 <LINK REL="STYLESHEET" HREF="book.css" CHARSET="ISO-8859-1" TYPE="text/css">

 <SCRIPT type="text/javascript">
 function windowTitle()
 {
     if (location.href.indexOf('is-external=true') == -1) {
         parent.document.title="Overview (CDO Model Repository Documentation)";
     }
 }
 </SCRIPT>
 <NOSCRIPT></NOSCRIPT>
 </HEAD>

 <BODY BGCOLOR="white" onload="windowTitle();">
 <!-- <div class="help_breadcrumbs"><a href="" title="CDO Model Repository Documentation">CDO Model Repository Documentation</a></div> -->

 <table border="0">
 	<tr>
 		<td width="100%"><h1>Overview</h1></td>
 		<td align="right" valign="middle" nowrap>&nbsp;<a href="reference/index.html" title="Forward to Reference"><img src="../images/forward.png"/></a></td>
 	</tr>
 </table>
 <p>
  CDO is a pure Java <i>model repository</i> for your EMF models and meta models. CDO can also serve as a
  <i>persistence and distribution framework</i> for your EMF based application systems. For the sake of this overview a
  model can be regarded as a graph of application or business objects and a meta model as a set of classifiers that
  describe the structure of and the possible relations between these objects.
  <p>
  CDO supports plentyfold deployments such as embedded repositories, offline clones or replicated clusters. The
  following diagram illustrates the most common scenario:
  <p align="center">
  <img src="cdo-overview.png"/>

 <h2><a name="Functionality"/>1&nbsp;&nbsp;Functionality</h2>
 <p>
  The main functionality of CDO can be summarized as follows:
  <ul>
  <li><b>Persistence</b> of your models in all kinds of database backends like major relational databases or NoSQL
  databases. CDO keeps your application code free of vendor specific data access code and eases transitions between
  the supported backend types.
  <p>
  <li><b>Multi user access</b> to your models is supported through the notion of repository sessions. The physical
  transport of sessions is pluggable and repositories can be configured to require secure authentication of users.
  Various authorization policies can be established programmatically.
  <p>
  <li><b>Transactional access</b> to your models with ACID properties is provided by optimistic and/or pessimistic
  locking on a per object granule. Transactions support multiple savepoints that changes can be rolled back to.
  Pessimistic locks can be acquired separately for read access, write access and the option to reserve write access
  in the future. All kinds of locks can optionally be turned into long lasting locks that survive repository
  restarts. Transactional modification of models in multiple repositories is provided through the notion of XA
  transactions with a two phase commit protocol.
  <p>
  <li><b>Transparent temporality</b> is available through audit views, a special kind of read only transactions that
  provide you with a consistent model object graph exactly in the state it has been at a point in the past. Depending
  on the chosen backend type the storage of the audit data can lead to considerable increase of database sizes in
  time. Therefore it can be configured per repository.
  <p>
  <li><b>Parallel evolution</b> of the object graph stored in a repository through the concept of branches similar to
  source code management systems like Subversion or Git. Comparisons or merges between any two branch points are
  supported through sophisticated APIs, as well as the reconstruction of committed change sets or old states of
  single objects.
  <p>
  <li><b>Scalability</b>, the ability to store and access models of arbitrary size, is transparently achieved by
  loading single objects on demand and caching them <i>softly</i> in your application. That implies that objects that
  are no longer referenced by the application are automatically garbage collected when memory contention occurs. Lazy
  loading is accompanied by various prefetching strategies, including the monitoring of the object graph's
  <i>usage</i> and the calculation of fetch rules that are optimal for the current usage patterns. The scalability of
  EMF applications can be further increased by leveraging CDO constructs such as remote cross referencing or
  optimized content adapters.
  <p>
  <li><b>Thread safety</b> ensures that multiple threads of your application can access and modify the object graph
  without worrying about the synchronization details. This is possible and cheap because multiple transactions can be
  opened from within a single session and they all share the same object data until one of them modifies the graph.
  Possible commit conflicts can be handled in the same way as if they were conflicts between different sessions.
  <p>
  <li><b>Collaboration</b> on models with CDO is a snap because an application can opt in to be notified about remote
  changes to the object graph. By default your local object graph transparently changes when it has changed remotely.
  With configurable change subscription policies you can fine tune the characteristics of your <i>distributed shared
  model</i> so that all users enjoy the impression to collaborate on a single instance of an object graph. The level
  of collaboration can be further increased by plugging custom collaboration handlers into the asynchronous CDO
  protocol.
  <p>
  <li><b>Data integrity</b> can be ensured by enabling optional commit checks in the repository server such as
  referential integrity checks and containment cycle checks, as well as custom checks implemented by write access
  handlers.
  <p>
  <li><b>Fault tolerance</b> on multiple levels, namely the setup of fail-over clusters of replicating repositories
  under the control of a fail-over monitor, as well as the usage of a number of special session types such as
  fail-over or reconnecting sessions that allow applications to hold on their copy of the object graph even though
  the physical repository connection has broken down or changed to a different fail-over participant.
  <p>
  <li><b>Offline work</b> with your models is supported by two different mechanisms:
  <ul>
  <li>One way is to create a <b>clone</b> of a complete remote repository, including all history of all branches.
  Such a clone is continuously synchronized with its remote master and can either act as an embedded repository to
  make a single application tolerant against network outage or it can be set up to serve multiple clients, e.g., to
  compensate low latency master connections and speed up read access to the object graph.
  <p>
  <li>An entirely different and somewhat lighter approach to offline work is to check out a single version of the
  object graph from a particular branch point of the repository into a local CDO <b>workspace</b>. Such a workspace
  behaves similar to a local repository without branching or history capture, in particular it supports multiple
  concurrent transactions on the local checkout. In addition it supports most remote functionality that is known from
  source code management systems such as update, merge, compare, revert and check in.
  </ul>
  </ul>

 <h2><a name="Architecture"/>2&nbsp;&nbsp;Architecture</h2>
 <p>
  The architecture of CDO comprises applications and repositories. Despite a number of embedding options applications
  are usually deployed to client nodes and repositories to server nodes. They communicate through an application
  level CDO protocol which can be driven through various kinds of physical transports, including fast intra JVM
  connections.
  <p>
  CDO has been designed to take full advantage of the OSGi platform, if available at runtime, but can perfectly be
  operated in standalone deployments or in various kinds of containers such as JEE web or application servers.
  <p>
  The following chapters give an overview about the architecures of applications and repositories, respectively.

 <h3><a name="Application"/>2.1&nbsp;&nbsp;Application Architecture</h3>
 <p>
  The architecture of a CDO application is characterized by its mandatory dependency on EMF, the Eclipse Modeling
  Framework. Most of the time an application interacts with the object graph of the model through standard EMF APIs
  because CDO model graph objects are <a href="http://download.eclipse.org/modeling/emf/emf/javadoc/2.7.0/org/eclipse/emf/ecore/EObject.html" title="Interface in org.eclipse.emf.ecore"><code>EObjects</code></a>. While CDO's basic functionality integrates nicely
  and transparently with EMF's extension mechansims some of the more advanced functions may require to add direct
  dependendcies on CDO to your application code.
  <p>
  The following diagram illustrates the major building blocks of a CDO application:
  <p align="center">
  <img src="application-architecture.png"/>

 <h3><a name="Repository"/>2.2&nbsp;&nbsp;Repository Architecture</h3>
 <p>
  The main building block of a CDO repository is split into two layers, the generic repository layer that client
  applications interact with and the database integration layer that providers can hook into to integrate their
  data storage solutions with CDO. A number of such integrations already ship with CDO, making it possible to
  connect a repository to all sorts of JDBC databases, Hibernate, Objectivity/DB, MongoDB or DB4O.
  <p>
  While technically a CDO repository depends on EMF this dependency is not of equal importance as it is in a CDO
  application. In particular the generated application models are not required to be deployed to the server because
  a CDO repository accesses models reflectively and the model objects are not implemented as <a href="http://download.eclipse.org/modeling/emf/emf/javadoc/2.7.0/org/eclipse/emf/ecore/EObject.html" title="Interface in org.eclipse.emf.ecore"><code>EObjects</code></a> on the server.
  <p>
  The following diagram illustrates the major building blocks of a CDO repository:
  <p align="center">
  <img src="repository-architecture.png"/>.

 <p align="right">
 &nbsp;<a href="reference/index.html" title="Forward to Reference"><img src="../images/forward.png"/></a></p>
 <HR>
 <i>Copyright (c) 2004 - 2011 Eike Stepper (Berlin, Germany) and others.</i>
 </BODY>
 </HTML>
	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
	<HTML>

	<HEAD>
	<TITLE>Overview (CDO Model Repository Documentation)</TITLE>

	<LINK REL="STYLESHEET" HREF="book.css" CHARSET="ISO-8859-1" TYPE="text/css">

	<SCRIPT type="text/javascript">
	function windowTitle()
	{
	if (location.href.indexOf('is-external=true') == -1) {
	parent.document.title="Overview (CDO Model Repository Documentation)";
	}
	}
	</SCRIPT>
	<NOSCRIPT></NOSCRIPT>
	</HEAD>

	<BODY BGCOLOR="white" onload="windowTitle();">
	<!-- <div class="help_breadcrumbs"><a href="" title="CDO Model Repository Documentation">CDO Model Repository Documentation</a></div> -->

	<table border="0">
	<tr>
	<td width="100%"><h1>Overview</h1></td>
	<td align="right" valign="middle" nowrap> <a href="reference/index.html" title="Forward to Reference"><img src="../images/forward.png"/></a></td>
	</tr>
	</table>
	<p>
	CDO is a pure Java <i>model repository</i> for your EMF models and meta models. CDO can also serve as a
	<i>persistence and distribution framework</i> for your EMF based application systems. For the sake of this overview a
	model can be regarded as a graph of application or business objects and a meta model as a set of classifiers that
	describe the structure of and the possible relations between these objects.
	<p>
	CDO supports plentyfold deployments such as embedded repositories, offline clones or replicated clusters. The
	following diagram illustrates the most common scenario:
	<p align="center">
	<img src="cdo-overview.png"/>

	<h2><a name="Functionality"/>1  Functionality</h2>
	<p>
	The main functionality of CDO can be summarized as follows:
	<ul>
	<li><b>Persistence</b> of your models in all kinds of database backends like major relational databases or NoSQL
	databases. CDO keeps your application code free of vendor specific data access code and eases transitions between
	the supported backend types.
	<p>
	<li><b>Multi user access</b> to your models is supported through the notion of repository sessions. The physical
	transport of sessions is pluggable and repositories can be configured to require secure authentication of users.
	Various authorization policies can be established programmatically.
	<p>
	<li><b>Transactional access</b> to your models with ACID properties is provided by optimistic and/or pessimistic
	locking on a per object granule. Transactions support multiple savepoints that changes can be rolled back to.
	Pessimistic locks can be acquired separately for read access, write access and the option to reserve write access
	in the future. All kinds of locks can optionally be turned into long lasting locks that survive repository
	restarts. Transactional modification of models in multiple repositories is provided through the notion of XA
	transactions with a two phase commit protocol.
	<p>
	<li><b>Transparent temporality</b> is available through audit views, a special kind of read only transactions that
	provide you with a consistent model object graph exactly in the state it has been at a point in the past. Depending
	on the chosen backend type the storage of the audit data can lead to considerable increase of database sizes in
	time. Therefore it can be configured per repository.
	<p>
	<li><b>Parallel evolution</b> of the object graph stored in a repository through the concept of branches similar to
	source code management systems like Subversion or Git. Comparisons or merges between any two branch points are
	supported through sophisticated APIs, as well as the reconstruction of committed change sets or old states of
	single objects.
	<p>
	<li><b>Scalability</b>, the ability to store and access models of arbitrary size, is transparently achieved by
	loading single objects on demand and caching them <i>softly</i> in your application. That implies that objects that
	are no longer referenced by the application are automatically garbage collected when memory contention occurs. Lazy
	loading is accompanied by various prefetching strategies, including the monitoring of the object graph's
	<i>usage</i> and the calculation of fetch rules that are optimal for the current usage patterns. The scalability of
	EMF applications can be further increased by leveraging CDO constructs such as remote cross referencing or
	optimized content adapters.
	<p>
	<li><b>Thread safety</b> ensures that multiple threads of your application can access and modify the object graph
	without worrying about the synchronization details. This is possible and cheap because multiple transactions can be
	opened from within a single session and they all share the same object data until one of them modifies the graph.
	Possible commit conflicts can be handled in the same way as if they were conflicts between different sessions.
	<p>
	<li><b>Collaboration</b> on models with CDO is a snap because an application can opt in to be notified about remote
	changes to the object graph. By default your local object graph transparently changes when it has changed remotely.
	With configurable change subscription policies you can fine tune the characteristics of your <i>distributed shared
	model</i> so that all users enjoy the impression to collaborate on a single instance of an object graph. The level
	of collaboration can be further increased by plugging custom collaboration handlers into the asynchronous CDO
	protocol.
	<p>
	<li><b>Data integrity</b> can be ensured by enabling optional commit checks in the repository server such as
	referential integrity checks and containment cycle checks, as well as custom checks implemented by write access
	handlers.
	<p>
	<li><b>Fault tolerance</b> on multiple levels, namely the setup of fail-over clusters of replicating repositories
	under the control of a fail-over monitor, as well as the usage of a number of special session types such as
	fail-over or reconnecting sessions that allow applications to hold on their copy of the object graph even though
	the physical repository connection has broken down or changed to a different fail-over participant.
	<p>
	<li><b>Offline work</b> with your models is supported by two different mechanisms:
	<ul>
	<li>One way is to create a <b>clone</b> of a complete remote repository, including all history of all branches.
	Such a clone is continuously synchronized with its remote master and can either act as an embedded repository to
	make a single application tolerant against network outage or it can be set up to serve multiple clients, e.g., to
	compensate low latency master connections and speed up read access to the object graph.
	<p>
	<li>An entirely different and somewhat lighter approach to offline work is to check out a single version of the
	object graph from a particular branch point of the repository into a local CDO <b>workspace</b>. Such a workspace
	behaves similar to a local repository without branching or history capture, in particular it supports multiple
	concurrent transactions on the local checkout. In addition it supports most remote functionality that is known from
	source code management systems such as update, merge, compare, revert and check in.
	</ul>
	</ul>

	<h2><a name="Architecture"/>2  Architecture</h2>
	<p>
	The architecture of CDO comprises applications and repositories. Despite a number of embedding options applications
	are usually deployed to client nodes and repositories to server nodes. They communicate through an application
	level CDO protocol which can be driven through various kinds of physical transports, including fast intra JVM
	connections.
	<p>
	CDO has been designed to take full advantage of the OSGi platform, if available at runtime, but can perfectly be
	operated in standalone deployments or in various kinds of containers such as JEE web or application servers.
	<p>
	The following chapters give an overview about the architecures of applications and repositories, respectively.

	<h3><a name="Application"/>2.1  Application Architecture</h3>
	<p>
	The architecture of a CDO application is characterized by its mandatory dependency on EMF, the Eclipse Modeling
	Framework. Most of the time an application interacts with the object graph of the model through standard EMF APIs
	because CDO model graph objects are <a href="http://download.eclipse.org/modeling/emf/emf/javadoc/2.7.0/org/eclipse/emf/ecore/EObject.html" title="Interface in org.eclipse.emf.ecore"><code>EObjects</code></a>. While CDO's basic functionality integrates nicely
	and transparently with EMF's extension mechansims some of the more advanced functions may require to add direct
	dependendcies on CDO to your application code.
	<p>
	The following diagram illustrates the major building blocks of a CDO application:
	<p align="center">
	<img src="application-architecture.png"/>

	<h3><a name="Repository"/>2.2  Repository Architecture</h3>
	<p>
	The main building block of a CDO repository is split into two layers, the generic repository layer that client
	applications interact with and the database integration layer that providers can hook into to integrate their
	data storage solutions with CDO. A number of such integrations already ship with CDO, making it possible to
	connect a repository to all sorts of JDBC databases, Hibernate, Objectivity/DB, MongoDB or DB4O.
	<p>
	While technically a CDO repository depends on EMF this dependency is not of equal importance as it is in a CDO
	application. In particular the generated application models are not required to be deployed to the server because
	a CDO repository accesses models reflectively and the model objects are not implemented as <a href="http://download.eclipse.org/modeling/emf/emf/javadoc/2.7.0/org/eclipse/emf/ecore/EObject.html" title="Interface in org.eclipse.emf.ecore"><code>EObjects</code></a> on the server.
	<p>
	The following diagram illustrates the major building blocks of a CDO repository:
	<p align="center">
	<img src="repository-architecture.png"/>.

	<p align="right">
	<a href="reference/index.html" title="Forward to Reference"><img src="../images/forward.png"/></a></p>
	<HR>
	<i>Copyright (c) 2004 - 2011 Eike Stepper (Berlin, Germany) and others.</i>
	</BODY>
	</HTML>