emf-store/proposal.html - www.eclipse.org/proposals - Git at Google


 <html>
 <head>


 <title>EMF Store</title>
 </head>

 <!--
 	We make use of the 'classic' HTML Definition List (dl) tag to specify
 	committers. I know... you haven't seen this tag in a long while...
  -->

 <style>
 dt {
 display: list-item;
 list-style-position:outside;
 list-style-image:url(/eclipse.org-common/themes/Phoenix/images/arrow.gif);
 margin-left:16px;
 }
 </style>

 <body>
 <p>We propose the EMF Store as a project in the <a
 	href="http://www.eclipse.org/projects/project_summary.php?projectid=EMFT">Eclipse Modeling Framework Technology Project (EMFT)</a>. This proposal is in the Project
 	Proposal Phase (as defined in the Eclipse Development Process document). The goal of this proposal is to find more interested parties and to get feedback of the
 	community. Please send all feedback to the <a href="http://www.eclipse.org/forums/eclipse.technology.emft " >EMFT forum</a>.</p>
 <h2>Background</h2>
 Many EMF-based Applications need to share data among multiple clients. A model repository can help an application to share instances of an EMF model. Additionally a model repository will keep track of the version history of the model. File-based repositories such as SVN or CVS are not well suited for this task since they work on a different level of abstraction, namely on files with textual content. With a file-based repository frequent merging is required since every simultaneous change on file is considered a conflict and must be merged in the local client. A model repository manages models on the appropriate level of abstract models. Therefore it can supply support tailored to models for change tracking, diffing, conflict detection, merging and versioning.
 <h2>Scope</h2>

 In a model repository framework every client can manipulate the model instances and send its changes to a central repository, where the currently valid version of all model instances is maintained. Similar to SVN or CVS, clients keep a local copy of the model instances they need to work on and can therefore work disconnected (=> <b>Offline Mode</b>) from the repository. If the clients send their changes to the repository, conflicts may occur, which need to be detected and resolved by a user (=> <b>Model Merging</b>). The framework supplies user interfaces for commit, update and merge, which can be replaced if necessary. Since changing the Ecore model requires migration of existing instances of the model, the repository also supports the generation of migrators from the changes performed in the Ecore (=> <b>Model Migration</b>). To help developers in the development of applications based on a model repository, the framework supplies views to browse the repository, to view the history of model instances, to manage access control and to view and manipulate model instances on the client (=> <b>Tooling</b>). The goal of EMFStore is to allow for a very easy integration into existing applications with minimum effort.

 <h2>Description</h2>

 We will describe important aspects of the EMFStore in more detail in the following:
 <h4>Model Repository</h4>
 The EMFStore is a model repository that allows to store EMF model instances and which keeps a version history of these instances. EMFStore follows the checkout/update/commit interaction paradigm known from SVN or CVS. The framework allows to checkout a copy of a model instance from the repository. Then it tracks change on the model instances on the clients and provides an API to send the changes to the repository. Also the API allows updating the model instances according to changes of other clients via the repository.
 <h3>Automatic Persistency</h3>
 The framework persists the model instances on the client transparently. In other words if a change is performed on a model instances, this change is immediately persistent. There is no need to manually save a model instance to a resource. The same applies for data on the server.
 <h3>Transparency on Model API</h3>
 Applications can use the regular EMF model API for changing to the model and the regular EMF observer patterns to listen for changes to the model. The framework is transparent for code operating at this level of abstraction.
 <h3>Offline Mode</h3>
 EMFStore clients work disconnected and do not need a connection to the repository other than to update or commit changes.
 <h3>Interactive Model Merging</h3>
 EMFStore supports Interactive Model Merging to resolve conflicts if two clients changes the same data in a model instance. It supplies interactive merge user interfaces to support users in model merging. Conflict detection and merging are extensible by extension points.
 <h3>Model Migration</h3>
 If the Ecore model of an application is changed, a migrator can be generated from these changes to migrate existing model instances to conform to the new model. This migration is based on the technology of the Edapt Eclipse project (formerly COPE) and is already integrated in the EMFStore. Clients and Server will automatically migrate existing instances.
 <h3>Tooling</h3>
 To ease the development of applications that store data in the EMFStore, the framework ships with comprehensive tooling. The EMFStore Browser view allows browsing an EMFStore server and its model instances. Also access control to model instances can be configured in this view. The History Browser helps to visualize the version history of a model instance and to restore old versions. The Navigator shows all model instances, which have been checked out on a client. The Model Element Editor can be used to view a single model element in a reflective editor.
 <br />
 <br />
 The EMFStore (http://emfstore.org) is developed as part of the UNICASE project (http://unicase.org). While it was originally targeted only at the UNICASE Client application, it is now used by a number of different applications and it is available as a standalone framework. The goal of this proposal is to make the EMFStore technology available to the Eclipse community as an EMFT project and to build an active open source community around the EMFStore.
 <h1>Code contributions</h1>
 EMFStore is already implemented and its entire code will be contributed to the Eclipse project. The code is currently hosted on Google code at <a href="http://emfstore.org">emfstore.org</a>


 <h2>Relationship with other Eclipse Projects</h2>
 <dl>
 <dt>EMFStore builts on top of EMF</dt>
 <dt>EMFStore builts on top of Edapt for model migration</dt>
 <dt>EMFStore will use EMFCompare to create diffs</dt>
 <dt>EMFStore can built on EclipseLink for persistency</dt>
 <dt>EMFStore has a different focus than CDO:</dt>
 <dd>Continuous Offline Operation (like SVN)</dd>
 <dd>Interactive Model Merging</dd>
 <dd>Automated Model Evolution Support</dd>
 <dd>Tooling and Views: Commit/Update/Merge, Repo-Browser, History-Browser</dd>
 <dd>Slim but fully vertical integration </dd>


 <h2>Committers</h2>

 <p>The following individuals are proposed as initial committers to the project:</p>

 <dl>
 	<dt>Maximilian Koegel, Technische Universitaet Muenchen - proposed project co-lead</dt>
     <dt>Jonas Helming, Technische Universitaet Muenchen - proposed project co-lead</dt>
     <dt>Otto von Wesendonk, Individual</dt>
     <dt>Florian Pirchner, redView</dt>
 </dl>

 <h2>Mentors</h2>

 <p>The following Architecture Council members will mentor this
 project:</p>

 <ul>
 	<li>Ed Merks</li>
 	<li>Sven Efftinge</li>
 </ul>

 <h2>Interested Parties</h2>

 <p>The following individuals, organisations, companies and projects have
 expressed interest in this project:</p>


 <ul>
 	<li>Bauhaus Luftfahrt Germany, Gernot Stenz, http://www.bauhaus-luftfahrt.net</li>
 	<li>Beople, Harald Stangl, http://beople.de</li>
 	<li>EADS Germany, Matthias Buderath, http://www.eads.com</li>
     <li>EclipseSource, Jochen Krause, http://eclipsesource.com</li>
 	<li>Edapt Eclipse Project, Markus Herrmansdoerfer, http://cope.in.tum.de</li>
 	<li>Mangrove SOA Modeling Framework, Juan Cadavid, http://www.eclipse.org/proposals/mangrove/</li>
 	<li>Instantiations, Steve Messick, http://www.instantiations.com</li>
 	<li>Max Plank Institute for Physics, Prof. Bethke, http://www.mpp.mpg.de</li>
 	<li>red-open, Ekkehard Gentz, Florian Pirchner, http://red.open.org</li>
 	<li>redView, Florian Pirchner, Ekkehard Gentz, http://redview.org</li>
 	<li>Steffen Stundzig, Itemis, http://www.itemis.com/</li>
 	<li>Serano Colameo, itemis Schweiz, http://www.itemis-schweiz.ch</li>
 	<li>Seissol Project, Technische Universitaet Muenchen, Department for Geophysics, Prof. Bunge, Dr. Martin Kaeser, http://www.geophysik.uni-muenchen.de/~kaeser/SeisSol/
 </li>
 	<li>Technische Universitaet Muenchen, Chair for Applied Software Engineering, Prof. Bernd Bruegge Ph.D., http://www1.in.tum.de</li>
 	<li>University Bonn-Rhein-Siegen, Software Engineering, Prof. Dr. Simone B&uuml;rsner, http://www.hochschule-bonn-rhein-sieg.de
 </li>
 	<li>University Heidelberg, Chair for Software Engineering, Prof. Dr. Barbara Paech, Germany, http://se.ifi.uni-heidelberg.de
 </li>

 </ul>


 <h2>Changes to this Document</h2>

 <!--
 	List any changes that have occurred in the document here.
 	You only need to document changes that have occurred after the document
 	has been posted live for the community to view and comment.
  -->

 <table>
 	<tr>
 		<th>Date</th>
 		<th>Change</th>
 	</tr>
 	<tr>
 		<td>DD-Month-YYYY</td>
 		<td>Document created</td>
 	</tr>
 </table>
 </body>
 </html>

	<html>
	<head>


	<title>EMF Store</title>
	</head>

	<!--
	We make use of the 'classic' HTML Definition List (dl) tag to specify
	committers. I know... you haven't seen this tag in a long while...
	-->

	<style>
	dt {
	display: list-item;
	list-style-position:outside;
	list-style-image:url(/eclipse.org-common/themes/Phoenix/images/arrow.gif);
	margin-left:16px;
	}
	</style>

	<body>
	<p>We propose the EMF Store as a project in the <a
	href="http://www.eclipse.org/projects/project_summary.php?projectid=EMFT">Eclipse Modeling Framework Technology Project (EMFT)</a>. This proposal is in the Project
	Proposal Phase (as defined in the Eclipse Development Process document). The goal of this proposal is to find more interested parties and to get feedback of the
	community. Please send all feedback to the <a href="http://www.eclipse.org/forums/eclipse.technology.emft " >EMFT forum</a>.</p>
	<h2>Background</h2>
	Many EMF-based Applications need to share data among multiple clients. A model repository can help an application to share instances of an EMF model. Additionally a model repository will keep track of the version history of the model. File-based repositories such as SVN or CVS are not well suited for this task since they work on a different level of abstraction, namely on files with textual content. With a file-based repository frequent merging is required since every simultaneous change on file is considered a conflict and must be merged in the local client. A model repository manages models on the appropriate level of abstract models. Therefore it can supply support tailored to models for change tracking, diffing, conflict detection, merging and versioning.
	<h2>Scope</h2>

	In a model repository framework every client can manipulate the model instances and send its changes to a central repository, where the currently valid version of all model instances is maintained. Similar to SVN or CVS, clients keep a local copy of the model instances they need to work on and can therefore work disconnected (=> <b>Offline Mode</b>) from the repository. If the clients send their changes to the repository, conflicts may occur, which need to be detected and resolved by a user (=> <b>Model Merging</b>). The framework supplies user interfaces for commit, update and merge, which can be replaced if necessary. Since changing the Ecore model requires migration of existing instances of the model, the repository also supports the generation of migrators from the changes performed in the Ecore (=> <b>Model Migration</b>). To help developers in the development of applications based on a model repository, the framework supplies views to browse the repository, to view the history of model instances, to manage access control and to view and manipulate model instances on the client (=> <b>Tooling</b>). The goal of EMFStore is to allow for a very easy integration into existing applications with minimum effort.

	<h2>Description</h2>

	We will describe important aspects of the EMFStore in more detail in the following:
	<h4>Model Repository</h4>
	The EMFStore is a model repository that allows to store EMF model instances and which keeps a version history of these instances. EMFStore follows the checkout/update/commit interaction paradigm known from SVN or CVS. The framework allows to checkout a copy of a model instance from the repository. Then it tracks change on the model instances on the clients and provides an API to send the changes to the repository. Also the API allows updating the model instances according to changes of other clients via the repository.
	<h3>Automatic Persistency</h3>
	The framework persists the model instances on the client transparently. In other words if a change is performed on a model instances, this change is immediately persistent. There is no need to manually save a model instance to a resource. The same applies for data on the server.
	<h3>Transparency on Model API</h3>
	Applications can use the regular EMF model API for changing to the model and the regular EMF observer patterns to listen for changes to the model. The framework is transparent for code operating at this level of abstraction.
	<h3>Offline Mode</h3>
	EMFStore clients work disconnected and do not need a connection to the repository other than to update or commit changes.
	<h3>Interactive Model Merging</h3>
	EMFStore supports Interactive Model Merging to resolve conflicts if two clients changes the same data in a model instance. It supplies interactive merge user interfaces to support users in model merging. Conflict detection and merging are extensible by extension points.
	<h3>Model Migration</h3>
	If the Ecore model of an application is changed, a migrator can be generated from these changes to migrate existing model instances to conform to the new model. This migration is based on the technology of the Edapt Eclipse project (formerly COPE) and is already integrated in the EMFStore. Clients and Server will automatically migrate existing instances.
	<h3>Tooling</h3>
	To ease the development of applications that store data in the EMFStore, the framework ships with comprehensive tooling. The EMFStore Browser view allows browsing an EMFStore server and its model instances. Also access control to model instances can be configured in this view. The History Browser helps to visualize the version history of a model instance and to restore old versions. The Navigator shows all model instances, which have been checked out on a client. The Model Element Editor can be used to view a single model element in a reflective editor.
	<br />
	<br />
	The EMFStore (http://emfstore.org) is developed as part of the UNICASE project (http://unicase.org). While it was originally targeted only at the UNICASE Client application, it is now used by a number of different applications and it is available as a standalone framework. The goal of this proposal is to make the EMFStore technology available to the Eclipse community as an EMFT project and to build an active open source community around the EMFStore.
	<h1>Code contributions</h1>
	EMFStore is already implemented and its entire code will be contributed to the Eclipse project. The code is currently hosted on Google code at <a href="http://emfstore.org">emfstore.org</a>


	<h2>Relationship with other Eclipse Projects</h2>
	<dl>
	<dt>EMFStore builts on top of EMF</dt>
	<dt>EMFStore builts on top of Edapt for model migration</dt>
	<dt>EMFStore will use EMFCompare to create diffs</dt>
	<dt>EMFStore can built on EclipseLink for persistency</dt>
	<dt>EMFStore has a different focus than CDO:</dt>
	<dd>Continuous Offline Operation (like SVN)</dd>
	<dd>Interactive Model Merging</dd>
	<dd>Automated Model Evolution Support</dd>
	<dd>Tooling and Views: Commit/Update/Merge, Repo-Browser, History-Browser</dd>
	<dd>Slim but fully vertical integration </dd>


	<h2>Committers</h2>

	<p>The following individuals are proposed as initial committers to the project:</p>

	<dl>
	<dt>Maximilian Koegel, Technische Universitaet Muenchen - proposed project co-lead</dt>
	<dt>Jonas Helming, Technische Universitaet Muenchen - proposed project co-lead</dt>
	<dt>Otto von Wesendonk, Individual</dt>
	<dt>Florian Pirchner, redView</dt>
	</dl>

	<h2>Mentors</h2>

	<p>The following Architecture Council members will mentor this
	project:</p>

	<ul>
	<li>Ed Merks</li>
	<li>Sven Efftinge</li>
	</ul>

	<h2>Interested Parties</h2>

	<p>The following individuals, organisations, companies and projects have
	expressed interest in this project:</p>



	<ul>
	<li>Bauhaus Luftfahrt Germany, Gernot Stenz, http://www.bauhaus-luftfahrt.net</li>
	<li>Beople, Harald Stangl, http://beople.de</li>
	<li>EADS Germany, Matthias Buderath, http://www.eads.com</li>
	<li>EclipseSource, Jochen Krause, http://eclipsesource.com</li>
	<li>Edapt Eclipse Project, Markus Herrmansdoerfer, http://cope.in.tum.de</li>
	<li>Mangrove SOA Modeling Framework, Juan Cadavid, http://www.eclipse.org/proposals/mangrove/</li>
	<li>Instantiations, Steve Messick, http://www.instantiations.com</li>
	<li>Max Plank Institute for Physics, Prof. Bethke, http://www.mpp.mpg.de</li>
	<li>red-open, Ekkehard Gentz, Florian Pirchner, http://red.open.org</li>
	<li>redView, Florian Pirchner, Ekkehard Gentz, http://redview.org</li>
	<li>Steffen Stundzig, Itemis, http://www.itemis.com/</li>
	<li>Serano Colameo, itemis Schweiz, http://www.itemis-schweiz.ch</li>
	<li>Seissol Project, Technische Universitaet Muenchen, Department for Geophysics, Prof. Bunge, Dr. Martin Kaeser, http://www.geophysik.uni-muenchen.de/~kaeser/SeisSol/
	</li>
	<li>Technische Universitaet Muenchen, Chair for Applied Software Engineering, Prof. Bernd Bruegge Ph.D., http://www1.in.tum.de</li>
	<li>University Bonn-Rhein-Siegen, Software Engineering, Prof. Dr. Simone Bürsner, http://www.hochschule-bonn-rhein-sieg.de
	</li>
	<li>University Heidelberg, Chair for Software Engineering, Prof. Dr. Barbara Paech, Germany, http://se.ifi.uni-heidelberg.de
	</li>

	</ul>



	<h2>Changes to this Document</h2>

	<!--
	List any changes that have occurred in the document here.
	You only need to document changes that have occurred after the document
	has been posted live for the community to view and comment.
	-->

	<table>
	<tr>
	<th>Date</th>
	<th>Change</th>
	</tr>
	<tr>
	<td>DD-Month-YYYY</td>
	<td>Document created</td>
	</tr>
	</table>
	</body>
	</html>