Helping Portals Work And Play Well Together

Enterprise portals are no longer just content delivery mechanisms. Portals have become platforms for accessing information and consolidating and integrating IT infrastructure. In the past few years, however, autonomous and decentralized departments have been deploying their own enterprise portals, most of which have been unable to work together. The analyst firm, Gartner, refers to this trend as “stovepipe portals.” The proliferation of these independent portals has made sharing information more difficult. To solve this problem, companies must be able to deploy federated portals and adopt standards-based platforms that can aid information unification.



Federated Portals

Gartner defines federated portals as decentralized networks of portals working together. Most portal solutions today are deployed in a single portal server, wherein the portlets are installed in the same machine and are hardwired to the same server

Based on Gartner’s definition, a federated portal permits portlets to reside on different machines across the organization. These remote portlets may even be other portal installations, referencing other portlets.

There are several advantages to the federated portal approach including the following:

  • No local installation of portlets is required, meaning reduced downtime for production systems, particularly when new or updated portlets have to be installed
  • Portlets can be shared by several different portals, enabling departments to share information and applications
  • When upgrading to a new version of the portal software, the portlets do not need to be re-installed or re-configured
  • The portal becomes interoperable with other portals. In fact, the portal only needs to communicate with other portal interfaces enabling the sharing of different portlet technologies including Java, C#, and .Net

In addition, federated portals can support remote portlet providers. Remote portlet providers are related portlets grouped together in a separate server or a portlet container.

The advantages of a federated portal with remote portlet providers include:

  • Searching for new portlets becomes easier, because related portlets are grouped together
  • Developers can concentrate on writing portlet code, instead of the interface to the portal, because remote providers abstract the communication layer between portlets and the portal
  • Portlet developers can apply default settings to sets of portlets and have the option of changing settings on individual portlets, resulting in more efficient portlet development

Federated portals are a powerful concept that can facilitate cross-organizational access to remote content. However, to aid portal interoperability, standard portlet interfaces and communication mechanisms are also required. Two portal standards have emerged: JSR168 and OASIS WSRP.

The Portal Standards

JSR168 is a Java Portlet Specification that defines a set of Java API's for portal computing and addresses content aggregation, personalization, presentation and security. The specification was to be published in the summer of 2003. While JSR 168 defines the coding of portlets, OASIS WSRP defines a protocol for communicating with the portal.

The OASIS (Organization for the Advancement of Structured Information Standards) WSRP (Web Services for Remote Portlets) defines an XML and Web services standard that allows the “plug-n-play” of Web services with portals or other intermediary Web applications. The final draft is expected to be published in early 2003.

The portlet provider uses WSRP SOAP to communicate with the portal. Within the provider, the SOAP request is passed to a translator, which converts it into a JSR168 Java method call. The appropriate portlet is executed and the content returned through the translator, as a WSRP SOAP message.

Considerations for Enterprise Portal Implementations

Federated portals and the adoption of standards are key factors to portal interoperability and information unification. However, portal vendors will need some time to incorporate standards specifications into their particular solutions. What should organizations consider when evaluating a portal solution? How should they prepare to migrate to a standards-based portal?

First, organizations must consider portal vendors that actively participate in and support both standards. Most likely, the participating vendor’s requirements will be embodied within the specifications. Second, companies must consider a portal solution whose architecture supports federated portals and resembles that of a standards-based portal. Finally, organizations must look for vendors that support both standards-based and non standards-based portlets within their portal offerings. Companies will want to preserve their existing investment in portlets and not be burdened with huge development costs when migrating over to a standards-based enterprise portal.

About the Author

Paul Narth is Senior Manager of Oracle Portal Product Management. He has been with Oracle for over nine years, initially in a Support capacity with Oracle U.K., before moving to the U.S. to head-up Product Management for Reports, and now for Portal Web Application Development. Before joining Oracle, Paul worked as a Software Developer at BT Research Laboratories in the UK specialising in application development with Oracle technologies.

More by Paul Narth