5 Things to Consider when Integrating your Content Management System and Portal

By Ghosh Palash | Published Mar 9, 2010

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:

Define the business specific coarse-grained CMS service to be consumed by portal service
Evaluate and decide on the technology option to implement and host the CMS service
Evaluate and decide on the technology option for writing portlets for content management
Decide the option/strategy on SSO (Single Sign-on)/Authentication from the Portal to the CMS
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.

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.

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.

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.

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.

About the Author

Palash Ghosh is a BEA Certified Enterprise Architect, IBM Cerified OOAD & SOA Soln Designer and has more than 11 years of software architecting, designing, management experience working with the global fortune 100 companies focusing on providing business and technology solutions across diverse range of technologies. He is currently leading multiple initiative(s) in ECM, Portal, Collaboration & SOA/BPM space for fortune 100 Companies. His current interests include SOA, cloud computing.

Read More About:
cmis, collaboration, content integration, enterprise cms, portal, rest, web cms, web services

Was this article useful?

Email It

Buzz it

Tag It

Stumble It Subscribe to the CMSWire RSS feed...

Add RSS

9 Reader Comments

1 |

Rajkumar Balasubramanian — March 10, 2010 3:58 AM

I have been working with Palash for some time now. He has done an excellent work and this article just reflects it. Palash, the article is simple, yet excellent and more informational to read about. Wish you publish more.

2 |

Arje Cahn, CTO of Hippo — March 10, 2010 6:19 AM

This post clearly describes the problem that I see with all current portal implementations: they treat content as “just another application running inside a portlet”. When we stick to this paradigm, it will kill Portal. Content behaves very different from legacy apps, and simply offering a contextually disconnected content management portlet is not enough. Content deals with semantics and relationships: users expect a portal to be smart enough to render content that is related to the apps they see right there on their screen, and they expect content to be reused across different sections in a portal, wherever that makes sense. Not to mention user-generated content.

Wikis gave users the possibility to quickly create and collaborate on content, but they don't come with the visual application integration that Portals offer. And they lacked the degree of control of a decent content management system. Integrating Portal and CMS is more than just adding a 'content portlet'. Adding an in-context application to a Wiki page would be more in line with how users think. They navigate your online consumer portal, find a page that answers their question and then they want to act on it directly. The FAQ page on “How to request a new password” should render the “New password” portlet in-line with the article. This is just an example - but this is clearly the direction Wikis are heading as they're maturing towards something that resembles an integration of Portal and CMS, and they're leaving traditional Portals way behind.

Portal vendors need to move towards the Content Driven Portal. At least, this is direction we've chosen to go with Hippo Portal (http://www.onehippo.com). Users want URLs that make sense, that say something about the information that can be found on a page. They want to pop the URL of a portal page into an email and send it to someone else and it should just work - within the appropriate security constraints of course. What applications are shown on the portal page should follow the context, not the other way around. People got used to this concept during the Wiki revolution, and they'll never want to go back.

3 |

Narayana Murthy — March 10, 2010 9:34 AM

Palash,
This is a great article with use cases and technology articulated very well. Excellent job.

Murthy

4 |

Sentil — March 11, 2010 9:00 AM

Palash,

Thanks for sharing. It is a good and very useful article for people like us, who are working in CMS and Portal integrations.

5 |

Doug Girvin — March 16, 2010 1:52 PM

I enjoyed your article but it left me wondering about why we need to approach CMS and portals in this way. With the rise of SaaS platforms, it is now possible to completely avoid the need for integration, middle ware and expensive services - not to mention long lead times - that riddle web and portal projects. We've built a comprehensive CMS (OrchestraCMS) that leverages the Force.com platform, including Customer and Self-Service Portals.

This allows the seamless management of static web content along side custom content driven by the integrated portals, CRM, Customer Support and virtually any other data stored on the platform. Built in workflow, approvals and analytics allow for integration of applications and data that may not be aware of one another. All of this contributes to an integrated approach to IT, business processes and web integration of those.

I believe that the CMS industry needs to change its thinking as most ECM/WCM vendors look like the ERP vendors in their architecture. And we know how well the ERP space is doing today. Best of breed thinking has resulted in the dis-integration of data, the rise of complex, expensive middleware and the virtually unmanageable result that IT departments are left with.

I think that the CMS space is ripe for disruption. The complexity shown above is proof of that IMHO.

6 |

William van Strien — March 17, 2010 3:13 AM

Good article. However, I miss the consideration of applying a product/platform which contains both integrated CMS and portal capabilities. In particular, the consideration of MOSS 2007, and fortthcoming SharePoint 2010. What are your thoughts regarding them?

7 |

Doug Girvin — March 30, 2010 10:14 PM

To Williams comment above, the question about portal integration with a CMS is, 'what are they integrated with?'. If not your enterprise data, business processes and transactions, what's the point of integrating a portal into a standalone CMS?

8 |

Palash Ghosh — April 7, 2010 2:30 AM

Well, let me give you an example — the Liferay (portal) platform already provides some CMS capability and the underling CMS product it uses is Jackrabbit.

But the bigger question is do you think big enterprises will rely on Jackrabbit as
their Enterprise CMS platform? Another way of looking at this: Are big enterprises already using DCTM/FileNet/Alfreso/Day going to move to Jackrabbit as their CMS repository, to use Liferay's built-in CMS capability?

So yes, small or medium size companies can stick to MOSS (or Liferay/Jackrabbit) as their enterprise CMS. But at the end of the day these technology/tool decisions will mostly depend on:

1) Whether you are really looking for enterprise scale, and enterprise features (technical & functional) or will some basic functionality suffice?
2) The current or target environment where the solution is going to sit

9 |

Steve Odart — April 8, 2010 6:13 AM

I think you are on the right track with regards the technology approach. I have often found that the business requirements of an organisation are of equal importance. Reduced cost of ownership, leveraging existing technologies that have not yet been written down, and future proofing the technology stack are all key considerations.

It is interesting that you reference Alfresco - we have seen that one of the key attributes of leveraging an open-source ECM product, potentially integrated with an open-source portal is as much to do about avoiding vendor lock in, as it is to do with features/functionality.

Any organisation that is going to undertake a significant project around managing their complete content lifecycle are all looking at ensuring that their destiny is ultimately in their own hands.

We are currently implementing a number of global Alfresco instances, leveraging portal front ends and an ESB architecture.

Leave a Response

Job Openings View all | Post a job | RSS

Featured Events View all | Add event | RSS

Aug 5, 2010 – Webinar: How Combining Enterprise CMS and BPM Boosts IT Efficiency
Sep 19, 2010 – Oracle OpenWorld 2010
Oct 7, 2010 – HartmanEVENT 2010 - Social Media & Mobile Usability

Name:		Email:
Website:
Your Thoughts:
	Remember me? Yes No

Stay Informed