The emerging Content Management Interoperability Services (CMIS) standard was the main buzz at the AIIM conference in Philadelphia this week (followed closely by social networking and Enterprise 2.0). Why does CMIS garner so much attention? Because as EMC’s David Choy said, “Unless they are starting from scratch, everybody implementing ECM has an interoperability problem.”
The impact of the problem depends on who you are and what you’re trying to do. If you use one ECM repository for email archiving and another to manage the content on your web site, it doesn’t really matter that the two repositories aren’t interoperable. But what if you have a portfolio of web sites and asset repositories across a variety of platforms and you need to share content across all of them? Then it’s a problem.
Customers in this situation have all kinds of issues they have to deal with, but several come down to a few basic needs having to do with interoperability:
- It needs to be easy for front-ends to store and retrieve content across multiple repositories (different platforms)
- It needs to be easy to move content between repositories
- It needs to be easy to find interesting and relevant content (which I may then want to access from the front-end or send to some other repository)
This multi-site/multi-repository problem is common, and at Optaros, we think we can help address it with tools and services that are, in many cases, driven by CMIS.
Front-ends
I’ve met with clients who’ve invested a lot of time and effort in a custom front-end for Vignette, for example. Over time, they’ve added additional systems to manage assets but the front-end is forever tied to Vignette. Sure, they could introduce a services layer that abstracts the repository, but each time they add a new kind of repository, that’s more development they have to do. CMIS provides a standard way of interfacing with all CMIS-compliant repositories, so the amount of repository-specific coding you have to do is reduced.
At Optaros, we’re developing CMIS adapters or integrations and releasing them as open source so that popular front-ends can get to content more easily. (See Drupal CMIS). We think there’s probably also a case to be made for a CMIS-based “content bus” that front-ends and compliant repositories could plug into.
Replication
What if you want to move content between repositories? I’ve talked to folks who have Drupal web sites, but they’d like to take some of the user-generated content that comes from Drupal and treat it more formally–like maybe they want to route it through an internal workflow, tag it, and then make it available to some of the other sites in their portfolio that might or might not be Drupal. CMIS gives us a common way to export and import content (through ATOM XML). Throw a transformation in the middle to handle schema differences and you’ve got yourself a CMIS-based replication engine that can move content between different kinds of repositories.
We’ve built a basic synchronization between Alfresco and Drupal as part of the Drupal CMIS and Alfresco modules, but we think this kind of functionality should be separated out and treated more generically–like a replication server that could sit between any number of CMIS-compliant endpoints.
Feeds & Search
How do you know when new content you might be interested in shows up in one of the numerous repositories you have in your environment? One answer is search. Initially, I was thinking a federated search server based on OpenSearch would be worthwhile but I think at this point, most people are just indexing everything rather than taking a federated approach.
Search is good when you are actively looking for specific content, but people (and systems) need to find content they are interested in as it becomes available. CMIS returns data as ATOM XML. That means you can use the same RSS/ATOM feed aggregation tools and techniques you use to track news to track content updates. This isn’t new–you’ve always been able to bolt on RSS feeds to your content repository by using the repository’s API to query for content and return it formatted as a feed, but CMIS gives us this “for free”.
So as CMIS becomes more widely adopted, we may see a big increase in the amount of ATOM/RSS flowing through the Enterprise as people begin to use feeds to discover new content. An Enterprise RSS server would seem like a good tool to leverage to aggregate the feeds coming from various content repositories across the content domain. It could also be used for other non-CMIS related feeds which will also surely increase as Enterprise 2.0 adoption spreads.
Most of the feed aggregation functionality available today is embedded within broader platforms (RSS portlets, for example). At Optaros, we think that, like replication, feed aggregation should be split out into a dedicated service. Think “Google Reader for the Enterprise”, essentially. There are proprietary systems out that that do this but no open source alternatives that are more than just personal feed aggregators (at least that I could find) so we may have to develop this.
Services-Oriented Content Management
These individual services–CMIS adapters, Replication, and Feeds–are part of a Services-Oriented approach to Content Management. The services are interrelated, and there are others I haven’t discussed, but the idea is that this type of approach can make a multi-silo’d content domain much more manageable and useful. Some of it depends on CMIS and some of it doesn’t. These ideas are still being hammered out so if you have interest in any of it, please let me know.
It’ll be interesting to see what happens as CMIS moves through additional iterations and ultimately becomes ratified hopefully by the end of the year.
For more info, see:
The Apache Chemistry development team is pleased to announce that the 0.4 incubating release of cmislib, the Python client API for CMIS, is now available for download. You may have to use one of the backup servers until the mirrors fully update. Alternatively, you can use easy_install to install cmislib by typing “easy_install cmislib”.