CMIS Round Table
by Nuxeo - Open Source ECM on Dec 03, 2008
- 3,968 views
Interoperability is key to open source success in the enterprise applications field. Aside from the JCR (Java Content Repository) and its successor, JCR2, new standards or proposed standards are emergi...
Interoperability is key to open source success in the enterprise applications field. Aside from the JCR (Java Content Repository) and its successor, JCR2, new standards or proposed standards are emerging, such as CMIS (Content Management Interoperability Services), that promise true interoperability between proprietary (such as Documentum, Filenet or SharePoint) and open source (such as Nuxeo and Alfresco) ECM systems. Will this standards truly unlock information from their silos and enable ECM as the backbone for unstructured information in the enterprise? Participants of this roundtable, all of them involved in various standardization efforts, will present and discuss the pros and cons of the various approaches.
Accessibility
Categories
Tags
More...Upload Details
Uploaded via SlideShare as Microsoft PowerPoint
Usage Rights
Statistics
- Favorites
- 0
- Downloads
- 80
- Comments
- 7
- Embed Views
- Views on SlideShare
- 3,914
- Total Views
- 3,968
I'm not saying that connectors cannot be written, or that semantic difference cannot be overcome. I'm just saying that it's harder to do for JCR than for CMIS :) 3 years ago Reply
I completely disagree with the statement about the semantic mismatch
with (pre-)existing legacy content repositories and JCR.
I think that we have a lot of experience layering JCR on top of arbitrary legacy repositories since Day Software offers connectors for following 3rd
party repositories:
* Microsoft SharePoint 2003, 2007
* EMC Documentum 5.2.5, 5.3
* FileNet P8 Content Manager 3.5
* OpenText Livelink 9.5, 9.6, 9.7
* Vignette 7.3.0.5, 7.3.1
* IBM Lotus Notes 6.5, 7.0
* Interwoven TeamSite 6.5
http://www.day.com/content/day/en/products/crx/jcr_connectors.html
I feel like I will have to come up with a 'JCR loves CMIS' presentation
similar to 'JCR loves Atom' or 'JCR loves WebDAV' in the past. ;)
regards,
david 3 years ago Reply
Future versions of Nuxeo will be CMIS compliant, we're working on it. 3 years ago Reply
If you want to expose through the JCR API an existing repository that wasn't designed with JCR in mind, unless you're lucky you'll find that there are a lot of semantic mismatches between your data model and the one that JCR requires. They can be overcome of course, with programming you can adapt anything to anything, but that doesn't mean the end result will be 'natural' for your existing repository. If you want to store arbitrary nodes with arbitrary properties (which is what JCR clients expect), in an efficient manner so that they can be queried fast, and map that to your native repository's model, then you may find yourself having lots of mapping issues.
Nuxeo itself doesn't have this problem, our model is quite compatible with JCR, but a lot of other database and repository vendors will have models that simply don't match very well with what JCR expects, or for which the adaptation gets complex, with many intermediate nodes for each of the native repository's documents or records. JCR doesn't see this as a problem, having many nodes to represent data is the way JCR does things, but that's different enough that it may give pause to vendors.
The JCR API manipulates nodes with simple properties on them. That's about as fine grained as you can get, in a hierarchical model. I contend that vendors aren't that interested in having clients or servers talking at such a low level, using such a rich API. And the richer the API to implement, the more complex it is to get the exact semantics required. This is what I mean by 'too fine grained for high interoperability'. 3 years ago Reply
Could you explain what you meant by 'Constrains the storage model alot' - Are you talking DB or just figuring out what your object model should be?
'too fine grained for high interoperability' - ??????? 3 years ago Reply