diff options
author | Eike Stepper | 2011-09-20 09:47:26 +0000 |
---|---|---|
committer | Eike Stepper | 2011-09-20 09:47:26 +0000 |
commit | 0c89905307ebf59a7bf3597d07e809e43187644f (patch) | |
tree | dfe63afa70a00a7d88513e4a3084348ad004b3c8 | |
parent | 7867093f33b6c90a6393b0bc09b2fc3f4905df4d (diff) | |
download | cdo-0c89905307ebf59a7bf3597d07e809e43187644f.tar.gz cdo-0c89905307ebf59a7bf3597d07e809e43187644f.tar.xz cdo-0c89905307ebf59a7bf3597d07e809e43187644f.zip |
overview
11 files changed, 251 insertions, 26 deletions
diff --git a/plugins/org.eclipse.emf.cdo.doc/diagrams.pptx b/plugins/org.eclipse.emf.cdo.doc/diagrams.pptx Binary files differnew file mode 100644 index 0000000000..148db250d9 --- /dev/null +++ b/plugins/org.eclipse.emf.cdo.doc/diagrams.pptx diff --git a/plugins/org.eclipse.emf.cdo.doc/html/Overview.html b/plugins/org.eclipse.emf.cdo.doc/html/Overview.html index 291e2b7745..fd60c9bfe1 100644 --- a/plugins/org.eclipse.emf.cdo.doc/html/Overview.html +++ b/plugins/org.eclipse.emf.cdo.doc/html/Overview.html @@ -23,19 +23,109 @@ function windowTitle() <BODY BGCOLOR="white" onload="windowTitle();"> <h1><a name="Overview.html"/>Overview</h1> <p> + CDO is a pure Java <i>model repository</i> for your EMF models and meta models (refer to <a href="Overview.html#Application" title="Chapter in CDO Model Repository Documentation">application architecture</a> for details). 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> -<table border="0"> -<tr><td><img src="../images/article.gif"/> </td><td colspan="4"><a href="" title="Article in CDO Model Repository Documentation">Overview</a></td></tr> -<tr><td><img src="../images/category.gif"/> </td><td colspan="4"><a href="reference/index.html" title="Category in CDO Model Repository Documentation">Reference</a></td></tr> -<tr><td/><td><img src="../images/category.gif"/> </td><td colspan="3"><a href="reference/api/index.html" title="Category in CDO Model Repository Documentation">API Reference</a></td></tr> -<tr><td/><td><img src="../images/category.gif"/> </td><td colspan="3"><a href="reference/schema/index.html" title="Category in CDO Model Repository Documentation">Extension Point Reference</a></td></tr> -<tr><td><img src="../images/category.gif"/> </td><td colspan="4"><a href="online/index.html" title="Category in CDO Model Repository Documentation">Online Docs</a></td></tr> -<tr><td/><td><img src="../images/article.gif"/> </td><td colspan="3"><a href="http://www.eclipse.org/cdo" title="Article in CDO Model Repository Documentation">Homepage</a></td></tr> -<tr><td/><td><img src="../images/article.gif"/> </td><td colspan="3"><a href="http://wiki.eclipse.org/CDO" title="Article in CDO Model Repository Documentation">Wiki</a></td></tr> -<tr><td><img src="../images/article.gif"/> </td><td colspan="4"><a href="about.html" title="Article in CDO Model Repository Documentation">Legal</a></td></tr> -</table> -</p> +<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 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 fail-over monitors, as well as the usage of anumber of special kinds of session 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. One way is to create a clone 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. 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 workspace. 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> + +<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> + <img src="application-architecture.png"/>. + +<h3><a name="Repository"/>2.2 Repository Architecture</h3> +<p> + <img src="repository-architecture.png"/>. <HR> <i>Copyright (c) 2004 - 2011 Eike Stepper (Berlin, Germany) and others.</i> diff --git a/plugins/org.eclipse.emf.cdo.doc/html/application-architecture.png b/plugins/org.eclipse.emf.cdo.doc/html/application-architecture.png Binary files differnew file mode 100644 index 0000000000..2ae8bc66f0 --- /dev/null +++ b/plugins/org.eclipse.emf.cdo.doc/html/application-architecture.png diff --git a/plugins/org.eclipse.emf.cdo.doc/html/repository-architecture.png b/plugins/org.eclipse.emf.cdo.doc/html/repository-architecture.png Binary files differnew file mode 100644 index 0000000000..c2196e4f53 --- /dev/null +++ b/plugins/org.eclipse.emf.cdo.doc/html/repository-architecture.png diff --git a/plugins/org.eclipse.emf.cdo.doc/src/org/eclipse/emf/cdo/doc/Overview.java b/plugins/org.eclipse.emf.cdo.doc/src/org/eclipse/emf/cdo/doc/Overview.java index baac65d114..ccc24cc286 100644 --- a/plugins/org.eclipse.emf.cdo.doc/src/org/eclipse/emf/cdo/doc/Overview.java +++ b/plugins/org.eclipse.emf.cdo.doc/src/org/eclipse/emf/cdo/doc/Overview.java @@ -10,14 +10,136 @@ */
package org.eclipse.emf.cdo.doc;
+import org.eclipse.emf.ecore.EObject;
+
/**
* Overview
* <p>
- * {@toc}
+ * 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>
*
* @number 0
* @default
*/
public class Overview
{
+ /**
+ * Functionality
+ * <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 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 fail-over monitors, as well as the usage of anumber of special kinds of session 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. One way is to create a clone 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. 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 workspace. 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>
+ */
+ public class Functionality
+ {
+ }
+
+ /**
+ * Architecture
+ * <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.
+ */
+ public class Architecture
+ {
+ /**
+ * Application Architecture
+ * <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 {@link EObject EObjects}. 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>
+ * <img src="application-architecture.png"/>.
+ */
+ public class Application
+ {
+ }
+
+ /**
+ * Repository Architecture
+ * <p>
+ * <img src="repository-architecture.png"/>.
+ */
+ public class Repository
+ {
+ }
+ }
}
diff --git a/plugins/org.eclipse.emf.cdo.doc/src/org/eclipse/emf/cdo/doc/application-architecture.png b/plugins/org.eclipse.emf.cdo.doc/src/org/eclipse/emf/cdo/doc/application-architecture.png Binary files differnew file mode 100644 index 0000000000..2ae8bc66f0 --- /dev/null +++ b/plugins/org.eclipse.emf.cdo.doc/src/org/eclipse/emf/cdo/doc/application-architecture.png diff --git a/plugins/org.eclipse.emf.cdo.doc/src/org/eclipse/emf/cdo/doc/repository-architecture.png b/plugins/org.eclipse.emf.cdo.doc/src/org/eclipse/emf/cdo/doc/repository-architecture.png Binary files differnew file mode 100644 index 0000000000..c2196e4f53 --- /dev/null +++ b/plugins/org.eclipse.emf.cdo.doc/src/org/eclipse/emf/cdo/doc/repository-architecture.png diff --git a/plugins/org.eclipse.emf.cdo.releng.doc/model/article.ecorediag b/plugins/org.eclipse.emf.cdo.releng.doc/model/article.ecorediag index 1fa107ce4a..22e4cb72c8 100644 --- a/plugins/org.eclipse.emf.cdo.releng.doc/model/article.ecorediag +++ b/plugins/org.eclipse.emf.cdo.releng.doc/model/article.ecorediag @@ -749,7 +749,7 @@ <styles xmi:type="notation:ConnectorStyle" xmi:id="_p1VWcdxaEeCpIJpgvmzkYA" routing="Rectilinear" lineColor="4210752"/>
<styles xmi:type="notation:FontStyle" xmi:id="_p1VWctxaEeCpIJpgvmzkYA" fontName="Segoe UI"/>
<element xsi:nil="true"/>
- <bendpoints xmi:type="notation:RelativeBendpoints" xmi:id="_p1VWc9xaEeCpIJpgvmzkYA" points="[-4, -20, 182, 88]$[-4, -50, 182, 58]$[-187, -50, -1, 58]$[-187, -79, -1, 29]"/>
+ <bendpoints xmi:type="notation:RelativeBendpoints" xmi:id="_p1VWc9xaEeCpIJpgvmzkYA" points="[-1, -20, 185, 92]$[-1, -51, 185, 61]$[-187, -51, -1, 61]$[-187, -87, -1, 25]"/>
</edges>
<edges xmi:type="notation:Edge" xmi:id="_6-blYNxaEeCpIJpgvmzkYA" type="3003" source="_5fxPANxaEeCpIJpgvmzkYA" target="_yWi_ANxZEeCpIJpgvmzkYA">
<styles xmi:type="notation:ConnectorStyle" xmi:id="_6-blYdxaEeCpIJpgvmzkYA" routing="Rectilinear" lineColor="4210752"/>
diff --git a/plugins/org.eclipse.emf.cdo.releng.doc/src/org/eclipse/emf/cdo/releng/doc/article/impl/CategoryImpl.java b/plugins/org.eclipse.emf.cdo.releng.doc/src/org/eclipse/emf/cdo/releng/doc/article/impl/CategoryImpl.java index ed2738df45..1d5a144d9f 100644 --- a/plugins/org.eclipse.emf.cdo.releng.doc/src/org/eclipse/emf/cdo/releng/doc/article/impl/CategoryImpl.java +++ b/plugins/org.eclipse.emf.cdo.releng.doc/src/org/eclipse/emf/cdo/releng/doc/article/impl/CategoryImpl.java @@ -81,20 +81,8 @@ public class CategoryImpl extends BodyImpl implements Category @Override public void generate() throws IOException { - File targetFolder = getOutputFile(); File sourceFolder = getDoc().position().file().getParentFile(); - for (File file : sourceFolder.listFiles()) - { - if (file.isFile()) - { - String name = file.getName(); - if (!name.endsWith(".java") && !name.equals("package-info.java")) - { - File targetFile = new File(targetFolder, name); - ArticleUtil.copyFile(file, targetFile); - } - } - } + copyResources(sourceFolder, getOutputFile()); super.generate(); generate(getTocTarget()); diff --git a/plugins/org.eclipse.emf.cdo.releng.doc/src/org/eclipse/emf/cdo/releng/doc/article/impl/DocumentationImpl.java b/plugins/org.eclipse.emf.cdo.releng.doc/src/org/eclipse/emf/cdo/releng/doc/article/impl/DocumentationImpl.java index a16905a71a..6e3c163875 100644 --- a/plugins/org.eclipse.emf.cdo.releng.doc/src/org/eclipse/emf/cdo/releng/doc/article/impl/DocumentationImpl.java +++ b/plugins/org.eclipse.emf.cdo.releng.doc/src/org/eclipse/emf/cdo/releng/doc/article/impl/DocumentationImpl.java @@ -655,7 +655,16 @@ public class DocumentationImpl extends StructuralElementImpl implements Document @Override public void generate() throws IOException { + EList<StructuralElement> children = getChildren(); + if (!children.isEmpty()) + { + StructuralElement child = children.get(0); + File sourceFolder = child.getDoc().position().file().getParentFile().getParentFile(); + copyResources(sourceFolder, getOutputFile()); + } + super.generate(); + generateToc(false); generateToc(true); } diff --git a/plugins/org.eclipse.emf.cdo.releng.doc/src/org/eclipse/emf/cdo/releng/doc/article/impl/StructuralElementImpl.java b/plugins/org.eclipse.emf.cdo.releng.doc/src/org/eclipse/emf/cdo/releng/doc/article/impl/StructuralElementImpl.java index 44c5ee4f96..415f385632 100644 --- a/plugins/org.eclipse.emf.cdo.releng.doc/src/org/eclipse/emf/cdo/releng/doc/article/impl/StructuralElementImpl.java +++ b/plugins/org.eclipse.emf.cdo.releng.doc/src/org/eclipse/emf/cdo/releng/doc/article/impl/StructuralElementImpl.java @@ -668,4 +668,20 @@ public abstract class StructuralElementImpl extends LinkTargetImpl implements St File projectFolder = getDocumentation().getOutputFile().getParentFile(); return ArticleUtil.createLink(projectFolder, getTocTarget()); } + + protected void copyResources(File sourceFolder, File targetFolder) + { + for (File file : sourceFolder.listFiles()) + { + if (file.isFile()) + { + String name = file.getName(); + if (!name.endsWith(".java") && !name.equals("package-info.java")) + { + File targetFile = new File(targetFolder, name); + ArticleUtil.copyFile(file, targetFile); + } + } + } + } } // StructuralElementImpl |