Portal Standards
The answer to portal interoperability?

By Sue Vickers 

As demonstrated by the emergence of multiple portal initiatives within organizations today, the benefits of enterprise portals are clearly understood. It's common to see several enterprise portal platforms deployed throughout an organization. However, many companies are attempting to standardize on one portal framework but are challenged with integrating disparate portal instances. Each portal instance requires developers, partners, system integrators, and independent software vendors (ISVs) to develop portlets using proprietary application program interfaces (APIs) that support only a single portal platform (see Figure 1). Thus, portlets built for one portal platform will not interoperate with another portal platform.

Developers find themselves building the same portlet many times to support the APIs of multiple portal vendors. More important, developers are not the only ones affected by proprietary APIs. Portal page designers and administrators looking to build an enterprise portal are often faced with a limited number of available portlets from a particular portal vendor. The solution to these challenges lies in the form of two complementary portlet standards: Web Services for Remote Portlets (WSRP) and Java Specification Request (JSR) 168, which enable the development of interoperable portlets. With these standards, portlets built for one portal platform can be rendered on a different portal platform as long as the vendor supports one or both of the standards.

The availability of these standards dynamically changes the landscape of the portal market. When deploying enterprise portals, organizations will have a wide array of standards-based portlets to choose from. Portlet providers won't need to invest resources and build APIs for each vendor platform (see Figure 2). In short, building portal pages becomes as simple as selecting portlets from a portal repository or catalog.

Overview of WSRP and JSR 168
WSRP is a Web services standard that allows the plug-and-play of visual, user-facing Web services with portals or other intermediary Web applications. Because it's a standard, WSRP enables interoperability between a standards-enabled container and any WSRP portal. JSR 168 is a specification that defines a set of APIs to enable interoperability between portlets and portals, addressing the areas of aggregation, personalization, presentation, and security.

Similar to other industry standards, WSRP and JSR 168 are closely related. What is the relationship between WSRP and JSR 168? WSRP is governed by the OASIS technical committees and JSR 168 is governed by the Java Community Process (JCP). These two standards work in conjunction to support portlet and portal interoperability. WSRP is a universal communication protocol between portals (consumers) and portlet containers (producers) of any type. JSR 168 is a Java API that standardizes Java portlets and allows developers to build interoperable portlets. It's important to note that one standard does not require the other. A portal can support JSR 168 and not support WSRP. A WSRP-enabled portal can consume portlets of any type including Java and .NET. The producer simply needs to provide a set of Web services interfaces that include self-description, markup, registration, and portlet management. Developers who build producers based on .NET can register their portlet on the same portal as a developer who has registered a Java producer, as long as that portal supports WSRP.

For example, two developers, developer A and developer B, have built portlets based on at least one of the standards. In addition, there are two portals: portal1 uses WSRP to communicate to portlets remotely (supports WSRP and JSR 168) and portal2 supports only local portlets and cannot communicate with portlets remotely (supports JSR 168, but not WSRP).

Developer A creates a portlet based on JSR 168 and hosts this portlet on an application server. The developer wants to render this portlet on two portals. Developer A provides a WSDL URL to portal1 to register the portlet and add it to a page. Portal1 doesn't care that this portlet is Java since the portlet is remote and communication is done through WSRP. Therefore, its implementation language doesn't matter. Developer A then deploys the portlet into portal2 locally and maps directly to the portlet,rendering the content by making direct calls to it. This developer was able to create the portlet once and make it available to two different portals, although one supported WSRP and JSR 168, while the other supported only JSR 168.

On the other hand, developer B creates a portlet based on .NET, but has deployed it to a container that is WSRP enabled. The developer is able to render this portlet on portal1 since the container is WSRP enabled and the portal does not care that the portlet is implemented in .NET. The developer cannot render the portlet on portal2 because this portal does not support WSRP or .NET.

WSRP provides:

* A WSDL interface description for the invocation of WSRP services
* Markup fragment rules for markup emitted by the WSRP services
* The method to publish, find, and bind WSRP services and metadata
* Interactive, user-facing Web services to be easily plugged into standards-compliant portals
* Parameters that developers and page designers use to create and publish their content and applications as user-facing Web services
* Ways in which page designers and portal administrators find Web services through a catalog, repository, or UDDI and publish them directly into their portal without any programming
* Portlets to make content available for consumption by other portals as Web services
* Standards that allow portlets of different languages to be rendered equivalently on any portal server that supports WSRP
* Support for remote portlets or the ability to store the application in one central location and render at multiple portal servers

JSR 168 provides:

* The portlet API (portlet container) that provides a runtime environment to invoke portlets. Developers use this API to program portlets that render on compliant portals.
* A URL-rewriting mechanism for creating user interaction within a portlet container.
* Security and personalization of portlets.
* A common API for interoperability and portability of Java portlets between portal vendors.

Portal Standards Free Up End Users
With the approval of WSRP in September 2003 and JSR 168 in October 2003, an overwhelming power was passed to end users. They now have the freedom to build portal applications without being tied to a portal vendor's platform. These standards force portal vendors to focus more on application-level features and functionality. Portal vendors must now compete on the basis of their total offering, including high availability, performance, and integration with other components that offer such features as caching, security, and wireless support.

Comparison Between Proprietary APIs and Standard APIs
The portal standards provide a full set of features and functionality, but may not offer all of the capabilities that are available from other vendors' proprietary APIs. The strength that these standard APIs have over proprietary APIs is compatibility. In addition, portal standards also offer the following capabilities:

* Edit defaults
* Customization
* Expiry-based caching
* Private parameters and events
* URL rewriting
* Single sign on (SSO) integration
* Resources "proxying"
* Internationalization

What should consumers consider when deciding which APIs to begin building upon today? Here are some considerations:

* Investigate functionality available versus "must-have" requirements. Can I live with the functionality the standards currently have?
* Is supporting multiple portal platforms really a requirement? This requirement is especially important for portal partners, ISVs, and system integrators, but not always important to other portal consumers. If not a heterogeneous environment, how often should you change portal platforms?
* Remember that vendor APIs are often backward compatible. Using your vendor's APIs today doesn't prevent you from upgrading tomorrow.

The standard committees are already looking at the next release of these standards: WSRP v2.0 is planned for early to mid 2005.

Building Standards-Based Portlets
Many vendors today support JSR 168 and WSRP in many different forms. Developers have multiple options for building standards-based portlets, deploying to a suitable container, and testing on a portal server that supports the standards. As an example, let's look at building JSR 168 portlets and rendering them on portals that support WSRP.

The example below uses a portlet wizard that runs on top of a portlet container. The wizard simplifies port-let development by creating a "hello" portlet skeleton and provides the basic import statements and methods for rendering the application as a portlet. The result is the same as writing a "hello world" portlet manually and is very similar to any standard JSP, with a few differences such as an import of javax.portlet, use of PortletConfig, and portlet styles (portlet-font). The end result of this portlet is "Welcome, this is the show mode" (see Listing 1).

Once this JSP is deployed to a JSR 168 portlet container, it is interoperable. The nice feature about WSRP is the remote portlet capability. The portlet is deployed in one central location and available to multiple portals at the same time without moving the application to each portal server. The portal server communicates to the producer using a WSDL URL (see Figure 3). An example is http://myserver.mydomain.com:8888/myapp/portlets?WSDL.

Using the WSDL URL, with an output similar to the one below, the portal server can ascertain registration properties and configuration mappings (see Listing 2).

Now it's easy for developers to add their business logic to the portlet and build a fully functional enterprise application. The Java code is the most important piece from a development perspective; however, from a deployment perspective, it's important to note the definition file that defines and describes the portlets. This file is called portlet.xml and Listing 3 shows how this file maps the container to your applications.

Considerations for Enterprise Portal Implementations
Portal vendors will need some time to incorporate standards specifications into their particular solutions. Thus, 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 nonstandards-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.

The proliferation of multiple portal platforms within an organization has made it difficult to integrate and standardize into one portal framework. Portal standards such as WSRP and JSR 168 provide organizations with a solution for enabling portal interoperability. These complementary standards provide the facilities that allow portlets built for one platform to be reused within another standards-based portal deployment.

Companies that are evaluating portal products must consider vendors that offer support for these standards and thus avoid being locked into proprietary systems. By deploying standards-based enterprise portals, organizations can not only leverage existing investments and reduce development costs, but also extend their portal functionality using other standards-based technologies.

# OASIS/WSRP committee and specifications: www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp
# JCP public JSR 168 site: www.jcp.org/en/jsr/detail?id=168

About the author
Sue Vickers is a group manager for Oracle Application Server Portal and has been with Oracle since 1998. Her team specializes in declarative and programmatic portlet development as well as application integration. She works closely with the Oracle development team that actively participates on the committees for JSR 168 and WSRP. Sue joined the Portal team from Oracle Support, where she was the WebDB team lead and an award-winning analyst. (more)

Related Sites
Figure 1
Figure 2
Figure 3
Source Code

Questions or problems regarding this web site should be directed to abeckman@outdoorssite.com.

Copyright 2008 Art Beckman. All rights reserved.

Last Modified: March 9, 2008