Blogger: Larry Cannell
Since the content management interoperability standard (CMIS) is moving closer to becoming a reality, I began thinking again about how it might be used by commercial vendors and open source projects. The committee developing the CMIS standard described a number of use cases to help determine the most important capabilities that needed to be supported. However, what they came up with is a fairly barebones set of content management capabilities (primarily support for documents and folders). In short, CMIS is a simple application programming interface (API) that will be supported by Documentum, FileNet, SharePoint, or any content management system to provide a simple documents/folder-style access to their content. The basic capabilities provided by CMIS may prove either valuable as advocates encourage adoption of the standard or may prove limiting because some use cases require additional content management capabilities (such as common representations of content policies or workflow).
The potential applications that can use CMIS are seemingly endless, but we can start brainstorming them nonetheless. Will CMIS be the “SQL for content systems", enable a new collaborative presentation layer for content management systems, or possibly create a whole new category of application? Below are three categories of CMIS use cases, presented here to stimulate thinking and provoke dialog.
Server-to-server or portal scenarios: These are perhaps the most common scenarios referenced when CMIS is discussed. Use cases include presentation of content by portals and other forms of content aggregation, like search or mash-up applications. Historically, we can look towards SQL as an example of how CMIS may evolve to support these use cases. Of course, the SQL standard was overwhelmingly successful, resulting in an uncountable number of applications that store data in databases (to the point where many of us may not remember how data was stored before SQL-based databases).
It may also take a path similar to that of portal standards (JSR 168, JSR 286, or WSRP). These standards have proven useful but have not seen near the same level of success (as SQL). We can also look towards JSR 170 (Java Content Repository) as another possibility. However, CMIS will have to continue evolving new capabilities (in future versions of the standard) to get to the same level of sophistication as JCR. Regardless, for many enterprise-developed applications involving similar use cases, CMIS will likely be quite useful.
A collaborative front-end to a repository: Another use case considered by the committee was “Collaborative Content Applications.” Although details behind this scenario are sketchy, most references assume this involves using CMIS to support a wiki or other type of collaborative workspace. Imagine a collaborative workspace product (like SharePoint or Quickr) presenting links to documents stored in a CMIS-compliant repository. However, it is difficult to see this scenario evolving beyond simply referencing external documents (rather than authoring or managing external documents) unless a future version of the CMIS standard includes support for access control and other management structures.
Lightweight desktop clients: Although not considered an initial use case by the committee, a CMIS-based desktop client market may evolve. Consider the evolution of RSS. Initially, a protocol developed to support syndication of portal content, its popularity caught fire when blogging platforms adopted it and aggregator clients were developed. Companies such as Generis and WeWebU have plans to develop or enhance their existing desktop clients with CMIS (thanks to Word of Pie for pointing this out).
Using CMIS with a desktop client also eliminates a particularly thorny challenge. Authenticating a user running a desktop client accessing a content system via CMIS is much easier than in server-to-server scenarios because of the use of single sign-on systems that can pass a user’s logged-in identity through the web browser to a web application. This is not part of the CMIS standard, but rather uses authentication that comes along with the HTTP protocol (in Apache, this is done via the REMOTE_USER environment variable). An example of how this can be done is an intranet that uses Windows Domain single sign-on that is passed on to a server that supports this form of authentication (e.g., like a SharePoint server) to retrieve an authenticated RSS feed. Alternatively, the desktop client could store the username and password (e.g, like FeedDemon does). In the server-to-server scenarios, there is significantly more effort required to delegate the desktop user’s credentials through a portal or web application, which the web application uses to authenticate with the content system on the user’s behalf.
This is a case where simplicity may prove valuable. Think how simple and lightweight RSS is, but now enable it with basic traversal of folders and fetching of content. We may be surprised what lightweight desktop clients emerge.
Finally, these are only client scenarios (applications that consume CMIS services). There is nothing that says a CMIS server application must be provided by a traditional content management system. At this point the services provided by CMIS are so primitive that they could conceivably be provided by many types of applications. In fact, there is already an implementation of a CMIS server based on a file system.
The passage of CMIS as a standard, and the broad support it has received so far, may turn out to be a major inflection point, but in ways we did not anticipate. Let the innovation begin!
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=a63dadaf-8ef2-481b-9dd6-542348da84b1)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=9579cc42-cfe9-44d5-8760-6db826addb2d)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=3a3507e1-3a20-440c-928a-7876e702cab4)
