-
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:
- 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.
- 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 (see user story #1 above)
- 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 import or export the 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...
Nuxeo view (might be completely different):
.
└── projects
├── proj1
│ ├── service1
│ ├── service2
│ ├── workflow1
│ │ ├── doc1
│ │ └── doc2
│ └── workflow2
│ ├── doc1
│ └── doc2
└── proj2
├── service1
└── service2
User's FS:
.
├── my_docs
├── programs
└── work
Nuxeo view mounted on user's FS:
.
├── my_docs
├── programs
└── work
└── projects
├── proj1
│ ├── service1
│ ├── service2
│ ├── workflow1
│ │ ├── doc1
│ │ └── doc2
│ └── workflow2
│ ├── doc1
│ └── doc2
└── proj2
├── service1
└── service2
Import & export are fully compatible with any desktop editor.
TODO Extraction to EasySOA Core model
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 Extraction 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 (import and export), 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 overview by Nuxeo
- 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 "transformation" 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.
TODO
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.
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 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
TODO
None.
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
The idea is to make the process of extracting information from the editor to an ECM generic, i.e. independent from the ECM model. One way to do this would be to introduce a well-defined, switchable "transformation layer" between the editor and the CMIS library calls.
Editor model ---[ECM-specific transformation]---> client-side instance of the CMIS model ---[CMIS calls]---> server-side ECM model
The goal for the CMIS calls would then be to make the server-side model an exact copy of the client-side model, i.e.:
- not only to add new information
- but also to remove obsolete information, such as removed subprocesses or service calls.
In order to fulfill the second requirement, we would need a way to identify objects to be removed, which by definition are not there anymore. This need stems from the fact we propagate a partial model to the ECM; the content repository may contain other objects which are not linked to automatic extraction. Several approaches can be considered:
- ECM-side memory: Mark objects and relationships that are created in the ECM by automatic extraction with a property linking them to the diagram (hash or so). This way, object/relationships that are not present in the local model anymore the next time we perform extraction will be detected and deleted. This creates constraints on the ECM model.
- Invariant rules: allow the transformation to also output update rules to the CMIS calls layer. For instance, it could specify that the model instance defines completely the relationship "easysoa:UseService"; thus, all server-side occurrences of this relationship related to objects in the model instance that are not themselves in the model instance should be deleted.