Currently the ASF does not provide a single integrated solution for building a complete java enterprise portal but offers a toolbox of components which can be integrated in order to cover the needs of a complete portal system.
Some vendors already distribute bundled portal packages based on these technologies, like for example Xo3’s OpenJODA.
The following list is a non exhaustive enumeration of the compoments, all members of the Jakarta Apache project, that may used as a portal toolbox.
Tomcat
Tomcat is the Java Servlet 2.2 specification reference container implementation.
As such, it can be used as the base application server for serving the enterprise portal site, either stand-alone using the built-in HTTP server or in conjunction with an external HTTP server like Apache httpd 1.3.
Turbine
Turbine is a web application development framework.
It offers many useful features for building dynamic sites, like an integrated pluggable user management module, a powerful action model for reacting to user events and supports several templating systems (like Velocity, Webmacro, JSPs) to develop the site presentation.
Jetspeed
Jetspeed is a portal system built on top of the Turbine framework.
It offers the content aggregation and user customization features necessary for building a successful portal as well as simple headline syndication capabilities based on the RSS and OCS formats.
Jetspeed currently natively supports both HTML and WML clients.
Slide
Slide is a user content management system.
It can be used to build a complete backend content management system, if there’s no such system within the corporation.
Current integration between Jetspeed and Slide is experimental.
Building an EIP with Jetspeed
We will now present some facets of a portal project methodology which can be used for deploying an EIP inside a corporation. This method is specifically adapted to take advantage of Jetspeed built-in syndication features.
We will not cover in this document the resource allocation and server/network design phases as these are very dependent on the corporation existing assets and the project scope.
Objectives
In order to build a successful portal, it’s important to clearly specify early in the project life the goals and expected benefits of the site.
Portals are very general versatile tools. Ill-defined objectives may lead to a feature creep jeopardizing the project budget and schedule, or on contrary, build an incomplete site that doesn’t fullfill user expectations.
It’s usually a good practice not to be too ambitious in the first project and focus on building a vertical portal aimed for a restricted user and document base rather than trying to consolidate all your company data from the Office documents to the mainframe databases…
Planning
Planning has a critical importance in the success of the portal project.
This phase needs to list all the contents that will be presented in the final portal in order to identify :
internal content sources that may be syndicated
external content sources that need to be contracted
all the applications that will interact with portal
the existing user repositories which the portal will have to interconnect with
Once this list is built, the project planning team will also need to define the user management strategy to use for this portal as well as allocate implementation human and technical resources.
Portal content
Once the objectives have been specified, it’s necessary to identify the list of contents which will need to be available from within the portal, as well as identifying where within (or exterior to) the corporation these informations may be found and how to access them.
Such a list may adopt the following tabular format:
Name
The name is a short description of the data content referenced
Type
This field indicates the form the data is currently available in: DBMS, flat file, proprietary application format, etc…
Keywords
Keywords describe the main data topics. They may be used during the implementation phase as the basis for a content management taxonomy, if needed.
Location
The location field specifies where the information referenced is available and how to access it. It may be a URL for web content, a file server address, etc…
Access mode
The access mode specifies the status of the content, especially the access rights required and whether it’s suitable for syndication.
Update frequency
This parameter describes the typical life time of the content before a change occurs.
Typical list entries will look like:
Name : Corporate Press releases
Type: SQL database
Keywords : press, news, corporate
Location : http://mycorp.com/press/
Access mode : public
Update frequency : daily
Name : Online publication related to corporation activity
Type: Internet web site
Keywords : news,
Location : http://www.mynewssite.com/
Access mode : public
Update frequency : 1-2 hours
Name : Task list for project Jetspeed
Type: Corporate scheduling system (MS Exchange)
Keywords : personal, project Jetspeed
Location : HERMES Exchange server on DOMAIN domain
Access mode : restricted to user or project members
Update frequency : weekly
Name : Main competitors activity reports
Type: Office documents
Keywords : competitors
Location : ZEUS Netware file server
Access mode : any authenticated user
Update frequency : monthly
This list will be used during implementation as a content checklist for building the site but also to help identify the data sources that may easily be syndicated, those that can be accessed using the default portlets provided with the portal software and those that will require specific developments.
This list will also help to plan the user management requirements as it describes all the data sources authentication requirements the portal will have to work with.
Before the implementation of the portal, it’s also important to correctly plan the user management strategy to use, especially if the portal must display restricted access data.
Unless the company already has a single common user repository used by all applications, the portal will usually have to work with different existing incompatible user databases used by different applications.
In order to incorporate content from these applications and present a unified data view to the user, the portal designer may adopt 2 basic strategies :
consolidate all the user directories in a single unified source and use it for all applications,
build a new user directory for the portal, and map portal users profile with their existing profiles in the different applicative user databases.
Consolidation of the directories is of course the best possible solution, as it solves once and for all these issues, but actual implementation of this strategy in most corporations is such a daunting technical and organisational challenge that the “meta directory” approach is usually the only workable choice.
Such a scheme may be implemented in the following fashion :
When a new user first registers on the portal, he creates a new login and password which will be used for portal internal purpose (customization for example).
When this user needs to access a restricted content, the portlet will prompt him for his applicative authentication tokens, verify them with the application and store them in his profile.
The next time, this user connects to the portal, the portlet will transparently retrieve and use the remote authentication tokens to access the secure data and display the application content within the portal page.
Implementation of such a scheme with Jetspeed requires the remote authentication tokens to be stored in plain text in the user profiles. This may present security risks if the configuration database is not correctly protected.
Implementation
Once the portal contents have been identified and the user management strategy defined, it’s possible to start actually implementing the portal site.
This implementation will typically have 3 phases that may be undertaken in parallel :
build the syndication structure to import or reference locally as much content as possible
develop the additional portlets required to access non syndicated applications or data stores
build the site templates and define the default user profiles and displayed content
Syndication structure
Building a Jetspeed portal syndication structure is usually a three steps process :
add RSS descriptions for all the internal contents
define internal OCS feeds
register internal and external feeds with Jetspeed
Based on the content list built in the planning phase, we must first identify contents that are suitable for syndication. Such contents will typically have the following properties:
they are publicly available or, at least, don’t change based on the user profile
For all these contents, we can either create RSS channels in order to use headline syndication, or implement a full content syndication by modifying Jetspeed feed maangement.
RSS channel descriptions may easily be written, either using static manually edited files, or a web data access development tool like JSP, PHP, ASP, servlet, etc…
The following complete ColdFusion code presents a simple RSS dynamic page example accessing an internal press releases database :
select p.id, p.title
from press_items p
where
p.date_end < TODAY
and p.date_start >= TODAY
order by
p.date_published ASC
MyCom Press Releases
http://www.MyCom.com/
MyCom
http://www.MyCom.com/image/logo.gif
http://www.MyCom.com/
#items.title#
http://www.MyCom.com/press/#items.id#
Once these RSS channels have been defined, we must add them to an OCS feed that will be processed by Jetspeed.
For example, the previous RSS channel can be described by the following OCS fragment:
One this feed is complete, it may be registered in Jetspeed by adding the following keys in the JetspeedResources.properties file :
contentfeeds.feed.name=internal
contentfeeds.feed.internal.url=/ocs/internal.ocs
Jetspeed will then periodically download this feed, extract all the RSS channels and register them in its content registry. For more advanced syndication capabilities, it’s possible to extend Jetspeed default feed behavior by extending the ocs.xsl XSLT stylesheet responsible for parsing the OCS feed.
Using OCS feeds to distribute the channels also gives a great flexibility of deployment as they are automatically updated and re-processed by Jetspeed and thus, allow the content writers to dynamically and remotely add or remove channels from the portal.
Portlets and data gateways
For all the contents that can’t be syndicated, specific gateway portlets must be developed using the Jetspeed portlet API.
There are already several generic examples distributed with Jetspeed to help speed up the development of new component and a modules directory will be available shortly on the Jetspeed website that will reference third party contributed portlets.
Once these portlets are developed, they must be added to the jetspeed-config.jcfg content registry of Jetspeed, with some base operational parameters and meta-data :
Press database Press releases database
com.mycom.portlets.DBPortlet
Note that Jetspeed supports several type of registry entries, identified by the « type » attribute :
abstract: these entries may not be used directly by a user to produce content but can be used in other as base portlet definitions will be used by “ref” type entries.
instance: standard entry, capable of producing content for a user without any reference to another entry definition.
ref: this entry extends the definition of a base abstract or instance portlet and override some parameters of these portlets.
Site templates
At this stage, all the content should be available inside of the portal and it’s now possible to build the complete site, customize Jetspeed look and feel and build the default user portal profiles.
Jetspeed look and feel can easily be configured by modifying the default icons provided and configuring within the default PSML (Portal Structure Markup Language, aka “piecemeal”) file. This file describes all the available content in a given user profile, as well as the layout strategy and decoration elements for these portlets.
For example, the following PSML file specify that Jetspeed whould display four portlets (defined by the elements) for user raphael, presented in a grid layout (defined the element). One of these portlets is an application (IMAPMailCount) that requires user specific parameters.
This file is device independent and may theorically be presented for any device, but in practice the widely different client capabilities and limitations encountered between HTML and WML browsers make it preferable to define separate PSML files per device type.
A more complete description of the PSML format is available on the Jetspeed website [5].
At runtime, Jetspeed will chose the best PSML file for any given request. The default behavior for this selection process is to use the :
user agent capabilities
user language
user login, if any
to select the appropriate profiles. Portal implementors may modify this behavior by extending the base profiler component.
It’s also possible to completely modify the portal site behavior by directly using the Turbine development capabilities to extends the default Jetspeed navaigation and layout, or even to integrate the portal in a complex custom web application.
Deployment
Once the portal development is complete, it’s time to deploy it on one or several production servers. This process is easily accomplished by creating a custom Jetspeed WAR application archive, using the default build tools provided with the software.
This custom pre-configured WAR archive can then be automatically deployed and run in any compatible servlet 2.2 container such as Tomcat.
Perspectives
In this document, we’ve seen how Jetspeed can be used within a corporation to quickly build an enterprise portal using its headline syndication features. Such a portal may be deployed with minimal impact on the existing IT structure and very low development costs, thanks to the orthogonal nature of the RSS channels description.
However, in its current incarnation, Jetspeed still has several shortcomings that are currently being addressed by the development team and will be incorporated in the future releases:
better access control management integrated with the component system
Once these features are finalized, Jetspeed will provide a solid foundation for building comprehensive entreprise information portals, leveraging both the open Internet syndication portocols and an open vendor neutral portlet component API.
References
[1] C. Shilakes and J. Tylman, “Enterprise Information Portals”, Merryl Lynch Inc., November 16, 1998
[2] ICE, Information and Content Exchange, http://www.icestandard.org/
