-
Notifications
You must be signed in to change notification settings - Fork 8
Import and export of workflow files from to EasySOA
This page is about technical solutions to provide seamless import/export of workflow files from/to EasySOA. The goals, extracted from EasySOA and workflow build process, are the following:
- File saving/loading: Architects shall be able to work on workflow files (business, technical and executable files) stored on EasySOA as easily as if they were stored locally.
-
Model synchronization: When files are transfered to EasySOA, their content shall be reflected to [EasySOA Core model](Final soa model design). In particular, the folowing information shall be taken into account:
- workflow context information
- business process hierarchy (which processes are called from a given process)
- service use by (technical) workflows
- Constraints:
- The feature shall be available when using "vanilla" (not EasySOA-branded) editors
- at least the solution should provide a "fallback" mode to slightly modified editors, lacking some features but still providing file transfer.
- at best the solution should provide partial or full functionality to any editor without requiring any change
- Workflow files shall be versioned, i.e. each past version of the files shall be available as well as the current version.
- (optional) An offline mode should be available, while keeping the data's consistency -- to avoid spreading data on several storages.
- The feature shall be available when using "vanilla" (not EasySOA-branded) editors
Mount a remote Nuxeo view on the user's filesystem. Then, editors work as usual: they are "fooled", since they don't "know" about EasySOA. Users could browse this filesystem to save/load files at relevant places.
To improve user-friendliness, we could add wizards in editors to create the files in the right folder (based on the mountpoint, project name, workflow name, and so on).
Since mounting filesystems on one another is typically an operating system job, the client-side solution will depend on the user's OS.
- On Windows, network drives
- CHECKED On Linux, davfs with possibly other solutions, including graphical front-ends (in GNOME's Nautilus for example)
- On Mac OS X, Finder seems to support WebDAV mounting natively.
- On other platforms, well, who knows?
WebDAV seems supported in Nuxeo. There is some documentation about working with WebDAV in Nuxeo, too.
Working this way would probably induce some limitations; for example, we may need to create "Workflow" items in Nuxeo before being able to create workflow diagrams at the right place.
TODO
- can we use webdav to change file "properties"?
- Yes we can, but not relationships. See http://www.slideshare.net/nuxeo/cmis-overview
- WebDAV spec: http://www.webdav.org/specs/#dav
- Otherwise, there's still workflow definition parsing...
Saving & loading are fully compatible with any desktop editor.
TODO Synchronization to EasySOA Core model
TODO
Versioning would be handled by Nuxeo, and should work out-of-the-box.
On Windows, the Briefcase ("Porte-documents" in french) enables working on cached versions of online documents. According to Alfresco's documentation, simply mounting a WebDAV space as a shared network drive would do the trick (this seems too simple, though).
On Linux and Mac OS, we still need to find a solution. TODO
TODO Synchronization to EasySOA Core model
Use CMIS technology to allow the editor to access Nuxeo. Insert a plugin in each editor, which uses a library performing file transfer with Nuxeo (saving and loading but also property/relationship changes), which itself uses CMIS technology. The plugins integrate the library in editors (with some UI modifications) and thus enables users to use remote files.
For editors which can't be modified, Nuxeo's web interface is used to upload or download files.
TODO: refine this idea. Note (mdutoo): better for integrating ECM into applications See also:
- EFS
- EFS-CMIS
- CMIS in Nuxeo
- CMIS Workbench (a CMIS client, useful for tests)
- a CMIS tutorial
CMIS allows transfering files using either a REST API or a SOAP API.
It probably wouldn't be trivial, as the diagram would have to be "split" into several documents in EasySOA, each of them having relationships. These relationships would have to be managed, especially when updating.
The whole "model synchronization" logic would have to be handled directly in the editor using the CMIS API, since CMIS allows to create/retrieve/update/delete objects and relationships, but not to call "business-specific", server-side methods.
By packaging the generic (editor-independent) parts of this feature as a library, we could probably get other Eclipse-based editors to work in a "fallback" mode with minimal, non-intrusive changes. It is highly unlikely, though, that we'll be able to integrate editors without any changes, or to integrate non-Java editors without major workloads.
According to a CMIS overview by Nuxeo, CMIS is implemented by, at least:
- Nuxeo
- IBM Filenet
- EMC Documentum
- Microsoft Sharepoint
- Open Text
- Alfresco
Versioning would be handled by Nuxeo, and should work out-of-the-box.
However, it seems CMIS does not support tree versioning. See this CMIS tutorial, where it's said that only Documents (leaves) can be versioned. It might not be that bad if we consider that trees are only versioned when releasing
TODO
Apache Chemistry's OpenCMIS doesn't seem included in Orbit (see orbit CVS)
Same as solution 2, but the plugin would use Nuxeo-specific protocols instead of using the CMIS standard.
This would, in particular, allow using Nuxeo's Content Automation in order to move the EasySOA-related business logic to the server side.
TODO
TODO
See same section in solution 2.
Non-existent.
Versioning would be handled by Nuxeo, and should work out-of-the-box.
TODO
TODO
In order to add offline support to any solution, we could set up a local instance of Nuxeo on each designer's machine, and keep it in sync with the central instance when the network is on.
It doesn't seem feasible though, since an old version of Nuxeo's documentation mentions it but in read-only mode. I (Y. Rodière) could not find a matching page in the current documentation), though. The closest matches were:
- a page about Android sync, which mentions "offline usage"
- a page with an "offline client" section, which, sadly, is empty
We want not only to save workflow files to an ECM, but also to be able to alter the ECM's model to reflect the current workflow configuration. We'll call this process "model synchronization".
In this section, we discuss how to make the process of synchronizing information from the editor to an ECM generic, i.e. flexible enough to be able to be adapted to any server-side model (we'll call it an "implementation").
Our goal is to update the ECM-side model to reflect the current state of the editor-specific workflow model, e.g.:
- add new information to the ECM
- but also update existing pieces of information in the ECM (from previous syncs)
- and remove obsolete pieces of information in the ECM (from previous syncs), such as removed subprocesses or service calls.
- while keeping user-added pieces of informations (comments added directly on the ECM, ...)
We do not want bi-directional synchronization: non-conflicting changes in the ECM must be preserved (see last bullet point above), but do not have to be propagated to the workflow file.
In order to build a generic implementation, we need to reduce coupling between the editor's model and the ECM's model. This can be achieved by introducing a well-defined, switchable "transformation layer" between the editor and the actual synchronization layer (which uses CMIS). The transformation layer would map the editor's model to an instance of the CMIS model which would then be processed by a generic CMIS synchronization layer:
Editor model ---[implementation-specific transformation]---> client-side, implementation-specific instance of the CMIS model ---[synchronization (CMIS calls)]---> server-side, implementation-specific model
We can imagine that there's probably still some implementation-specific behavior in the synchronization layer. For example, different implementations may need different ways to resolve conflicts automatically. This could be modeled by a set of rules to be provided by the implementation-specific part:
Editor model ---[implementation-specific transformation]---> client-side, implementation-specific instance of the CMIS model --\
|
+--[synchronization (CMIS calls)]---> server-side, implementation-specific model
|
implementation-specific synchronisation rules --/
The next subsections detail the important aspects of the generic synchronization, and details the types of rules to be handled.
In order to do proper "updates", as opposed to simply adding new objects in the ECM, we need a way to identify the server objects that "are the same" as local objects. These objects may be renamed, and potentially a lot of properties can change between two saves.
Solutions:
- Use pre-existing editor-specific IDs in the ECM. Requires changes in the implementation model.
- Use CMIS IDs already available in the ECM and store them in the workflow file. Requires changes in the editor model.
We need a way to keep the server model consistent, i.e. we should not only add & update information, but also remove obsolete information.
In order to do this, we need a clear definition of what's only automatically-generated data (which should be automatically removed if necessary) and what might be user-generated data (which should be left alone unless instructed otherwise).
Solutions:
- Per-type rules: this type of relationship (or document, or property) is automatically generated, that one is not. May be incompatible with some models where some relationships are both modified by users and automatic processes.
- Per-object rules: this object matches the rules (a property has the correct value), so it's been generated. May require implementation model modification to add dedicated properties (e.g. "isGenerated").
In practice, a combination of both might be ideal. We could then specify "general rules" per type and "exceptions" per object.
The behavior to adopt when automatically generated data (from the editor model) conflicts with potentially user-defined data might change from a user to another, and from an entity (document, relationship, property, ...) to another.
We can imagine at least three potential behaviors:
- resolve in favor of the editor (overwrite)
- resolve in favor of the ECM (don't change)
- ask the user to choose
The actual implementation of import/export in an Eclipse editor may take different forms, from the user point of view.
- Remote resources configured in the project properties, which would be loaded and saved transparently. According to the IFile interface definition, files can be remote, but it seems like a temporary state for not-fetched-yet resources. This could b handled at different levels:
- at editor level. A specific editor which would then provide directly the model to the sync facility
- at filesystem level, using Eclipse File System. See Eclipse help on contributing an alternative filesystem. This subsection dealing with cross-filesystem projects (using links) and this page dealing with linked resources may be especially useful.
- Imported resources, using the import wizard.
- Synchronized resources. The ECM would act as a Git or SVN repository. This involves team support in the plugin.
See also PTP remote projects.
When a save is requested for a given part, org.eclipse.ui.ISaveablePart.doSave(IProgressMonitor monitor) is called. For WEEditor, the method then calls org.eclipse.emf.ecore.resource.Resource.save(Map, ?> options) on both the diagram and the model resource. Here is an excerpt of this method's Javadoc:
An implementation typically uses the URI converter of the containing resource set to create an output stream, and then delegates to save(OutputStream, Map).
The URIConverter interface seems to be implemented by org.eclipse.emf.ecore.resource.impl.ExtensibleURIConverterImpl only, and this class delegates most of its job to org.eclipse.emf.ecore.resource.URIHandler. URIHandlers are mainly responsible for creating input and output streams as well as deleting the content pointed by a URI. Default URIHandlers are the following:
- ArchiveURIHandlerImpl (archive:/ , for zipped files?)
- EFSURIHandlerImpl (Eclipse File System)
- FileURIHandlerImpl (file:/)
- PlatformResourceURIHandlerImpl (platform:/)