Portals and content management systems are widely used in organizations today. For many, the desire to integrate them into a single collaborative environment is critical. But there's a lot to think about before moving forward. In this article we cover the basic considerations for integrating a CMS into an enterprise portal.

A Use Case for Integration

Collaboration is no longer just a buzz word; it is now an enterprise need. Some enterprises have already started seeing the benefits of collaborative work environments. They know that content management plays a very important and crucial role in building a successful collaboration environment by improving processes, increasing employee efficiency and productivity, and lowering costs.

A typical business use case around how content lifecycle plays a role in a collaboration environment would be:

  • A user logs in enterprise one stop portal
  • They create and manage content (check-in, check-out, update metadata, tag)
  • They then share the same content via Wikis, Blogs, Message Boards, Discussion Forums, etc…
  • In some cases they may submit content for formal review and approval via some workflow
  • They may also comment and/or rate other content
  • When they have finished, they log out of the portal

Today almost every Content Management System offers its own user interface that integrates content management and community/collaboration features. WebTop, damTop and CenterStage are examples of collaborative tools for EMC Documentum; Alfresco Share an example for Alfresco.

While these may be feature rich interfaces, an enterprise may not want to add another collaboration tool outside of their portal for managing content. The challenge then becomes how to enable content management capabilities via a one stop enterprise portal.

Integrating a CMS repository with a portal solution provides the following benefits:

  • Create, manage and most importantly collaborate on content within and across the community from a single stop enterprise portal enabling collaboration across the organization.
  • Effectively utilize social collaboration tools -- wikis, blogs, message boards -- from the portal framework by attaching content that is already created and managed within the CMS Repository.
  • Take advantage of better governance, security and compliance policies (retention etc) for their content. People and communities can collaborate and share content based on standard rules .
There are several key architecture and design decisions that need to be evaluated to come up with a robust integration solution between your content management system and your portal:
  1. Define the business specific coarse-grained CMS service to be consumed by portal service
  2. Evaluate and decide on the technology option to implement and host the CMS service
  3. Evaluate and decide on the technology option for writing portlets for content management
  4. Decide the option/strategy on SSO (Single Sign-on)/Authentication from the Portal to the CMS
  5. Define the strategy for Community, security/authorization management

1. Define the business specific coarse-grained service to be consumed by portal layer

Almost all Content Management providers expose their services as web services that can be consumed from any client application (like a portal). But these services tend to be atomic in nature with the lowest granularity. As a result, business specific custom reusable composite services may need to be designed that will call these atomic services.
 
PortalCMS_ESB.jpg

2. Evaluate & decide on the technology option to implement & host the CMS service

There are multiple technology options to implement the CMS Service:

CMIS

Content Management Interoperability Services (CMIS) is a technical specification for integrating with a ECM (Enterprise Content Management) repository via Web Services. It is a language-independent, repository-independent API for content management. The objective of the CMIS standard is to define a common content management web services interface that can be implemented by a content repository vendor, enabling service interoperability across repositories through standard SOAP and Restful Bindings.

This might be the best option to go with for implementing the common reusable services for any portal or third party integration. The back-end repository can be changed at any time without design and code rework on the front-end system.

CMIS Version 1.0 is just out for public review. Though the vendors have started building their CMIS implementations based on the draft spec, it may not be mature enough and production ready very soon. However, enterprises can start using vendor provided draft implementations for non-critical business applications.

It is important to note that CMIS will enable only standard content management capability. Most content management systems have more rich functionality; functionality that, if required by the enterprise, will require additional custom development.

SOAP

Most Content Management Vendors expose repository capabilities as standard SOAP-based Web Services. This might be another good choice to use as integration strategy. The downfall is that the enterprise will be locked down to a specific vendor.

REST

Some vendors also provide the repository capabilities as REST services. REST is lightweight and simple to use. However, sometimes it is not a good idea to send large amounts of data/content via uri. Like other REST Services, transaction and security management might be harder for a large enterprise implementation. And once again, the enterprise will be locked down to a specific vendor. 

The OOTB/Custom services can be deployed in standard Application Server Container (like JBoss, Oracle, WebSphere, Tomcat, etc…) or any Enterprise Service Bus. Services can be made available via a standard SOA (service oriented architecture) registry taking advantage the company’s existing standard SOA governance model.

The appropriate Web Service client must be generated from the service WSDL via JAX-WS or Axis, or some other tool. This would be consumed from Portlet Service.

Portal_CMS_ServiceBus.jpg

3. Evaluate & decide on the technology option for writing the content management portlet

A Portlet Action and Service needs to be designed to call the underlying CMIS, CMS Web Service or REST service. In many cases an enterprise may already have a portal platform, so content management features will need to be enabled for that portal.

Here are a couple of ways to do this:

Vendor Supplier Portlets

Some CMS vendors provide a JSR portlet, but it may or may not match what the enterprise is looking for from a collaboration perspective. It’s not as simple as taking the vendor provided portlet and dropping it into the portal platform. Aside from usability and functionality, authentication, security, transaction and other features need to be aligned with enterprise’s strategy. In most cases some work need to be done.

Write Your Own

An enterprise can decide to go ahead and write its own portlet to meet the business need. There are multiple choices to write a portlet :

  • Pure JSR 168/286 Portlet (with JSR Tags)
  • Struts Portlet (JSR 168/286 compliant)
  • Struts Portlet using Container Provider/Vendor API
  • JSF Portlet (JSR 168/286 compliant)
  • JSF Portlet using container Provider/Vendor API)

The JSF or Struts framework have their own strengths. You should design and develop JSR compliant portlets. The portlets should not be tied with the CMS vendor’s specific APIs so you don't loose portability. Pure JSR portlets might be the best choice, but JSR Complaint Struts portlets or JSR compliant JSF Portlets might be used as well.

Portal_CMS_AppServices.jpg

4. Decide the strategy on SSO/Authentication from Portal to CMS

User sessions need to be created in the CMS repository to do any kind of CMS related operation. If the portal solution is already integrated with an SSO infrastructure (OAM, Netegrity, etc…), this will be easier to do. The SSO Provider can generate the token, and that token can be passed and used to create a session for CMS related operations. A plug-in may need to be written in the content management system to authenticate the SSO token (if a plug-in is not already available for the specific SSO provider).

If the portal solution is not integrated with an SSO Provider, the named user Authentication approach can be followed. A generic userid/password combination is stored in the service code and the CMS session can be established using this generic id when required. This generic user is going to run all the services on behalf of other users. The SAML standard also can be used to establish a CMS session.

Portal_CMS_UseCase.jpg

 

5. Find the strategy on Community, security/authorization management

There are portal solutions -- such as Liferay -- available today that come with built in community concepts. Also any enterprise can build community capabilities within the enterprise portal. And most content management system also offer collaboration services and features. There are a few choices available to bridge the gap:

  • Have the portal be the single source of truth for community. So the community and its governance, security, creation, modification and deletion capabilities would be propagated to the CMS real time via the portal.
  • In cases where the portal will not be the single point of entry for the content management system, community capabilities and security would also need to be created and managed in the CMS. In that event, portal community and security information will need to be brought in sync.

Conclusion

Integrating a content management system with an enterprise portal solution is not trivial as it involves integration between different products. But a successful integration backed by a solid business goal and technical architecture can bring the business value right way and improve the overall organization performance many fold.