Internal vs. External
Internal CMS
The simplest CMS integration might involve embedding a JCR store into the portal and providing a simple WYSIWYG portlet for editing operations.
Jasig already has an incubating simple WYSIWYG CMS portlet which is capable of interacting with a JSR-170 content repository such as Jackrabbit. The simplest CMS integration might be to embed a JCR store into the portal, and then use this portlet as the front-end for editing operations.
This approach might be particularly compelling when combined with the delegated portlet management capabilities present in uPortal 3.2 and above. uPortal's new portlet management tools allow sufficiently-privileged users to create new portlets, then walk them through a content approval/publishing/expiration workflow. Permissions for each step may be delegated to groups of users by portlet category. Combined with a simple WYSIWYG portlet, these new management capabilities could provide powerful workflow control of content creation and editing that might meet the needs of most institutions.
In the approach described above, Jasig would likely clean up the existing portlet and modify it to present the current editing interface as the CONFIG mode. Jasig would also need to integrate a JCR store into uPortal and address import/export needs for the portlet.
External CMS
Simple integration : select & display content in uPortal
Simple integration means that contents are managed by contributors in an independant application (the web CMS) with no connection with uPortal (from technical and UI point of view). In this case, contributor has a poor view of what his content will look like when displayed in uPortal.
This simple integration assumes that the web-CMS supports CMIS (or proprietary similar) protocol able to browse sitemap or content repository.
Use case for contributor/administrator
A Contributer/administrator would add content in uPortal then select a Portlet dedicated to CMS content.
Then a widget should appear (preferably during the "add content" process) displaying one or many sitemap of external CMS. This widget would use CMIS requests to browse remote Web-CMS pages. Apache Chemistry project provides Java implementations of CMIS and may be used to develop such a widget.
Use case for visitor
Displaying content from a CMS for Portal user is simple. The portlet calls the page previously selected by the contributer, located on the remote CMS. This page is delivered in XML or XHTML format and rendered by the portlet to user.
Known Web-CMS/uPortal integrations
One known Drupal-uPortal integration uses Drupal to both create and manage content that will later be displayed in uPortal. A custom portlet demonstrated at the 2009 Jasig Unconferenceallows portal administrators to browse and select Drupal content from the portal. In this system, Drupal content is offered to the portal in XML format.
Another Ametys-uPortal integration has more or less the same approach. Ametys is used to create and manage content, and a XML-XSLT portlet is used to display content to uPortal user. Ametys content is offered to the portal in XML-Docbook format.
WYSIWYG integration : create, edit & display content in uPortal
Another CMS integration strategy would be to enable the portal to interact with an external content management system. Such an integration would preferably use the CMIS standard, though integrations could certainly exist that used some sort of product-specific library.
In this integration, contents are managed by contributors in uPortal environment. That means that even if actions call a remote web-CMS, contributor directly sees what content looks like in an environment very similar to uPortal.
Use case for contributor/administrator
A Contributer/administrator would be able to browse uPortal pages and activate content management tools for editable contents. 
When activated, contributor would be offered a bunch of tools dedicated to content management (asset managements, rich text editor, rights management, versionning, workflow...) applicable to its current content selection. In this mode, contributor/admin would be able to browse portal like a regular user, but would see any content, whatever its state in the worklfow (draft, published...).
Selecting an action on contextual menus can induce a pop-up to appear if action is simple (content validation, content deletion...) or the page to releoad and display a new page with other tools if action is more complex (content edition, right management on contents...).
Example of a content beeing edited:
Once edition of content is completed, and author click on save, page would disappear and go back to previous screen.
Technical issues
This use case induces some technical issues concerning interaction between uPortal and external CMS:
- Contributor mode is a mode where both uPortal rendering and CMS back-office exist in the same web page:
- Either this mode is hosted by uPortal (add-on in skin?, core feature?), which should be able to call menus from remote CMS, and associate actions with portlet declared as "content portlet". Such integration would not be generic for all CMS and would need uPortal to adapt to any new CMS.
- Either this mode is hosted by remote CMS, which should be able to associate its menus and actions with portlet declared as "content portlet" (could be done with HTML/Javascript declarations in "content portlet" rendering). As seen by uPortal, such integration would be generic. On the contrary for CMS, each CMS would have to integrate this mode.
- Mapping of content location inside uPortal sitemap, and CMS sitemap should be automatic: adding a new editable content in uPortal should offer to admin/contributor a few input fields to enter (Language, Title, Content Type...) and make remote CMS to create the content in its repository. This request could use CMIS protocol, and be generic for any CMS supporting CMIS for write actions.
- ...?
Use case for visitor
Mapping of contents between CMS storage and portlet location would be automatically managed. Hence the portlet would simply display a remote content (same as "simple integration" scenario):
The portlet (same as used for admin/contributors) should be "rights aware" and display content for visitors by calling remote CMS. The CMS would deliver it to the portlet in XML or XHTML format. The portlet would compute the final rendering in uPortal.
External CMS Case Studies
- UCI
CMS in other portals
Liferay includes an internal CMS which offers workflow capabilities, as well as some structure/template features somewhat reminiscent of Jasig's HyperContent project. Liferay's implementation also offers the ability to push content from a development environment to a production server via a administrative user interface that makes use of web service calls.