Delivering the IST Web Site

Delivering the IS&T web site

This document summarizes my thoughts on how to provide a delivery or run-time environment for the IS&T web site/app. Here are some of the considerations, based on what we know of the current site and the proposed design work from Tank.

• Pages are a mix of largely static content and sections of "dynamic" content.
• The dynamic sections, along with other features like searching, imply "subsystems" - data sources and methods of retrieval - that each require analysis and design work.
• The content must be searchable.
• We must preserve the ability to preview the content in the CMS.

Portal solution

On first looking at the new design and wireframes, the component-like structure of the pages seemed to lend itself to a portal product as a solution. The separate sections for System Status, Highlight etc, that can appear on multiple pages evoked a portal-like structure.

I spent some time looking at Liferay, an open-source portal product that seems to be well-liked according to what I could find on the web. Although documentation was lacking, in some ways this would make a good platform for the web site delivery. Portlet widgets are available out of the box to present RSS feeds, etc, and we could easily develop portlets of our own to interact with other kinds of data sources.

However, this kind of solution would seem difficult to integrate into Alfresco to provide a previewing capability. In order to preview, we would probably have to embed Liferay into the IS&T web project in Alfresco and it seems like that might not be a good idea. Particularly as Liferay provides for using Alfresco as a CMS data source and would embed Alfresco to do that.

In addition, Liferay (and other portal products) is an unknown quantity to us - we don't know how stable or robust it is, and how it would perform under heavy load.

Given the above, it might be risky to decide to use a portal at this point.

Home Grown Web App

The solution that seems to make most sense, in terms of our experience, the ability to perform well under load, simplicity, and integration with Alfresco, is a Java/JSP solution.

The web app could either use the CMS directly as a datasource, or it could use an exported dataset. If we use the CMS as a runtime datasource it would be far preferable to use a standard API, not a proprietary API. This would imply remote JSR-170 access to the Alfresco WCM, not a feature that is currently present. Indeed, the remote JSR-170 API for the core Alfresco CMS apparently has problems and might not be usable.

Exporting the data would be safer. I envision exporting XML data to an XML aware database (like Oracle) and driving the web app off of this. The web app would then be independent of the particulars of the CMS, which would be a good thing. One issue this approach raises, though, is how would we provide a search capability? If deployment instead resulted in individual jsp pages, the content could be indexed and searched using Google.