Microsoft has released their SharePoint 2010 CMIS Connector - a SharePoint solution that aids integration of enterprise content management systems.(CMIS stands for Content Management Interoperability Specification).

A number of vendors have signed up to the CMIS standard, including Liferay, Alfresco, Day Software, EMC (makers of Documentum) , FatWire, IBM, Microsoft, Open Text, Oracle and SAP. HP, who now own the TRIM Electronic Records and Document Management System, have previously stated that they intend to support the standard at some point.

I predict that strategically Microsoft will seek first to integrate with these systems, while later pushing them more and more 'backstage' and away from end-user functions. Microsoft want SharePoint and Office to be a user's first and only point of contact, not for example Alfresco's web based interface. To achieve this Microsoft will need to focus on the scalability, records management capability, and security of their SharePoint suite. In all three respects it lags well behind all the players mentioned above.

The perception of SharePoint is too often that it "does a little bit of everything and not very well". In federal clients there is often a belief that SharePoint is designed for a ad-hoc, less governed environments with small sized teams (10-20 people).Without appropriate procedural and technical controls a SharePoint deployment can quickly become a mess.

Rather than being packaged as a core part of SharePoint, their CMIS connector is included as part of a freely-downloadable package called the SharePoint 2010 Administration Toolkit. It will be interesting to see if Microsoft gives this work more visibility in the future.

At the moment various EDRMS vendors implement their SharePoint integration in different ways, and there does not appear to be a single agreed-upon approach for achieving integration. I have seen almost all of the major vendors' solutions and there is a lot of frustration about SharePoint's limited records management integration points. For example, how do you coordinate access control permissions between your SharePoint document library and your records management system repository? How should the structure of SharePoint sites be mapped to your Records Management System's file and folder structure? How should SharePoint content types, limited to a particular file format, be mapped to your business content types (presentation, meeting minutes, response to government entity, etc).

Anyway, here are some details about the CMIS connector. It's packaged into the toolkit mentioend above as a SharePoint farm-level solution file (spcmis.wsp) . If there is documentation included I could not find it.

So what do you get?  basically the CMIS connector adds some web services "behind the scenes" to your SharePoint sites, so that other applications can talk to SharePoint and get information about content and security permissions. The other thing included is a web part that provides visualisation of a CMIS repository.

Some more detailed technical info follows about the files contained:

Inside the solution is basically two features, the assemblies deployed, the CMIS Consumer Web part (CmisConsumerWP.dwp)..

.. and a set of items added to the SharePoint user interface ribbon, adding a set of tabs for CMIS - related actions.

The solution is added to the SharePoint farm by an administrator using the stsadm.exe command line tool. (stsadm -o addsolution -filename spcmis.wsp), and then can be deployed onto any selected SharePoint Web Applications by using the SharePoint Central administration page. Once deployed and the relevant features are enabled, the ‘producer’ part is there and ready for other systems to use, while the consumer web part is placed into the web part gallery.

The package is built up from a number of web pages, a set of web services, a CMIS consumer web part for visualising the content of a CMIS repository, and a set of .NET assemblies containing the application code and implementation of the services.

The services are implemented in the following files, which reflect the functions identified in the CMIS OASIS standard:

• ACLService.svc
• DiscoveryService.svc
• MultiFilingService.svc
• NavigationService.svc
• ObjectService.svc
• PolicyService.svc
• RelationshipService.svc
• RepositoryService.svc
• RelationshipService.svc

An ASP.NET HTTPHandler handles the CMIS REST interface, which exposes both SOAP and AtomPub APIs.

ASPX pages are used to provide an interface for checking in files, managing permissions, version history, and document / folder structure. The full set of pages are:

• ChooseCmisFolderPage.aspx
• cmis-core.aspx
• cmis-messaging.aspx
• CmisCheckInPage.aspx
• CmisCustomViewPage.aspx
• CmisEditPropertiesPage.aspx
• CmisLogOnPage.aspx
• CmisPermissionsPage.aspx
• CmisReplaceFilePage.aspx
• cmissoapwsdl.aspx
• CmisVersionHistoryPage.aspx
• CmisViewPropertiesPage.aspx
• CreateCmisDocumentPage.aspx
• CreateCmisFolderPage.aspx
• ViewCmisRepositoryInformationPage.aspx

And finally the four assemblies deployed to the Global Assembly Cache (GAC) are:

Microsoft.SharePoint.CMIS.Bindings, Microsoft.SharePoint.CMIS.Consumer, Microsoft.SharePoint.CMIS.Core, and Microsoft.SharePoint.CMIS.Data.