The answer to portal interoperability?
January 5, 2005
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
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.
* A WSDL interface description for the invocation of WSRP services
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
Portal Standards Free Up End Users
Comparison Between Proprietary APIs and Standard APIs
* Edit defaults
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?
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
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
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.
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.
Questions or problems regarding this web site should be directed to firstname.lastname@example.org.
Copyright © 2008 Art Beckman. All rights reserved.
Last Modified: March 9, 2008