Enterprise

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