More and more web sites are using portal functionality. Portals are perfect for building mashups and interactive web sites offering a lot of functionality in a single web page. Content is a vital part of most portals. Content management integration in portals has traditionally been treated different by different vendors and frameworks. Web Content Management System (CMS) vendors have tried to provide Portal like functionality in their systems. Portal vendors have been bundling simple Web Content Management Systems with their Portal products. Those of you who have experience with these kinds of systems, and needed both real Portal and real CMS functionality have most likely seen that this lead to challenges since few vendors deliver full scale solutions covering both CMS and Portal technologies. When trying to integrate a full-scale CMS into an Enterprise Portal, this can lead to:

• Complicated publishing process, since editors often have to work both in the CMS content creation tool and in a Portal configuration tool to place the content in the Portal
• Poor preview functionality since the CMS content creation tool cannot render the produced content in a portal context
• Tight coupling between the systems due to concrete content references throughout the portal

Main Part
Our client has a large Portal with 100s of pages and a high amount of content production. They use separate Portal and CMS technologies, and have experienced the challenges outlined above. We have run a project where our main goals and values were

• Making the editors' publishing process easier by letting them do all their work in one tool
• Being able to offer preview functionality inside the CMS content creation tool, showing the editors how their content actually will look in a full portal context
• Reducing the coupling between the Portal and the CMS

To accomplish this, we introduced the Template Based Content Rendering Pattern[1]. This is implemented using a Portal page with a grid of portlets that act as generic containers for any content. Each portlet has a portlet preference holding its coordinates in the grid, see Figure 1.

Each portlet knows how to fetch content, and knows how to render itself based on the type of content that is returned from the CMS.

This pattern leads logically to moving the metadata about content placement into the CMS. We have created a Page record in the CMS that has the same grid of content containers as the Portal page. The CMS Page's content containers are record fields holding ids to other content records in the CMS, like articles, images and so on, see Figure 2.

This way the Page record's container grid represents the content placement in the portal. Since the Page record is just another CMS record, it automatically gets all the goodies like historic versioning, rights management and publishing process from the CMS. This means that editors can have different rights on different pages in the Portal, and if layout changes over time, it is trivial rendering the portal exactly as it looked on a specific date.

The Page record enables preview of new content in a full Portal context. Now the content editors can preview full pages instead of just individual articles. By using the style sheets from the portal, the preview will be almost exactly like the real deal.

In addition to placing articles, images, link collections etc. on the Pages, the editors can also place applications onto the CMS content pages directly from within the CMS. Forms and different kinds of gadgets are examples of applications suitable for this. This is done through having separate record types for the applications inside the CMS. This way the applications can also be configured from the CMS having configuration parameters as record fields. We handle preview of the applications on the Pages by displaying application screenshots.

All or at least some of the Pages shall be reachable from the Portal's menu. To let the editors control the placement of the Pages in the Portal's menu, the Pages are organized in a tree structure within the CMS. This lets the editors decide which pages that shall be reachable directly from the menu and the ordering and structure of the pages within the menu. Pages not placed in the menu are reachable from content references (for example URLs) in other record types like articles and link collections. The tree structure also enables rendering the menu as part of the Page Preview.

The Portal gets the content part of its menu from the CMS. The tree structure described above is returned as a tree of Menu Items containing the content ids and the titles of the Pages. When the Portal's Menu Renderer renders the menu item for a particular content Page, it uses the page title as the menu entry. It also adds the Page's content id as a request parameter to the URL for the menu entry, see Figure 3.

One of our main goals was to reduce the coupling between the Portal and the CMS. The content redering portlets placed on the Generic content page help with this. All of these portlets contain the same Controller servlet. We created a content domain model with articles, images and so on to completely separate the Portal from the CMS' content representation which was XML. Figure 4 shows the classes involved.

Figure 5 shows the control flow for fetching the content for one portlet.

The ContentTemplateControllerServlet finds the placement of the portlet it resides in. This is specified by the portlet's slot portlet preference. This is passed down to the Portlet object. The Portlet object is responsible for finding the id of the content we are currently rendering. It uses the CMSHttpRequestParser to find the page id. It then calls the ContentCreator to find the contents for the specified slot.

The ContentCreator first checks the ContentCache to see if the slot's contents exist there. If it does, it returns the contents. If it is not found, it calls the ContentLoader to load the content for the specified page from the CMS. ContentLoader returns an xml string with the contents. The ContentCreator then calls the XmlContentUnmarshaller to unmarshal the xml string into content objects. It then puts the content objects into the ContentCache, and returns the contents for the specified slot from the ContentCache.

The ContentTemplateControllerServlet hands the contents over to the ContentForwardCreator to create the correct forward for the portlet. The forward knows which jsp that shall render the contents in the portlet.

This design isolates the concrete integration to the ContentLoader and the XMLContentUnmarshaller classes. This reduces the coupling between the Portal and the CMS for fetching and displaying of content to a minimum.

To maximize performance and minimize network traffic between the Portal and the CMS, a Content Cache is introduced on the Portal side. You see the Content Cache used in Figure 5. A configurable number of content domain objects are stored in the cache with the cache key being page id and placement (slot id). The cache uses a LRU (Least Recently Used) strategy to decide which elements to keep in cache. To make sure the cache is not updated more frequently than absolutely necessary, a push based cache update strategy is used. When content is added or edited in the CMS, the CMS calls a web service on the portal with the updated content. This web service then updates the Content Cache.

The CMS is fully responsible for deciding which content shall be displayed in the Portal, and where the content shall be displayed. This makes it possible to cleanly utilize CMS features that could otherwise leak into the Portal. Examples of these features are support for multiple languages and content personalization. This can be done through adding language code and user session data to the CMS query in ContentLoader.

Conclusion
We set out trying to ease the content editors' working day by letting them do all their work in one tool. We also wanted to reduce the coupling between the Portal and the CMS. We achieved this by combining the Template Based Content Rendering pattern with a clean domain model for working with content. The content editors now do all their content publishing, included full portal context preview for their content in the CMS, and we have gotten a cleaner and lighter Portal architecture that is able to utilize current and future advanced CMS features without adding complexity to the Portal.

[1] Thanks to Peter Lau, Oracle©, for a name for this pattern