How Portal Standards Enable Reuse

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

In my previous article, “Reuse and the Portal Onion,” you were introduced to the conceptual model of a portal onion that illustrates how a portal framework enables reuse of front end web application assets across the user experience, portlet catalog, common services, and foundational architecture layers of the onion.

In this article, you will turn your attention to the second layer of the onion, called the portlet catalog, which provides a rich set of sales, service, billing, content, workflow, and other functionality that can be reused and configured at the outer user experience layer. This layer is supported by the underlying common services and foundation layers. The catalog itself is comprised of a set of portlets or interactive application components that can be plugged into the portal framework.

Figure 1: The Portlet Catalog Layer of the Onion

There are two portal standards that enable reuse of portlets in the catalog. The first is a Java Community Process standard called JSR 168 that enables component level reuse of portlets. The second is an OASIS standard called WSRP (Web Services for Remote Portlets) that enables service level reuse of portlets.

In this article, you will examine these complementary standards to gain an understanding of the characteristics of each. You will also review common non-standard approaches to portlet reuse and understand the tradeoffs. Finally, you will consider guidelines for utilizing these standard and non-standard approaches to building out your catalog of reusable portlets.

Component Level Reuse through JSR 168

JSR 168 is a Java standard that specifies the interfaces by which local portlets plug into their portal containers. By adhering to these standard interfaces, portlets can be created or obtained from third parties that will run on various commercial and open source portal frameworks.

Figure 2 illustrates a number of JSR 168 portlets deployed in business to consumer (B2C) and employee (B2E) portals.

Figure 2: JSR 168 Component Reuse

Observe that the Billing and Content portlets are components within each portal deployment. You might consider JSR 168 a form of “cut and paste” reuse where portlets from the portlet catalog are deployed and configured as appropriate in different portal containers.

Some of the JSR 168 portlets shown in this example may have been obtained from third parties. For example, the Content, Worklist, and CRM Portlets may have been obtained from commercial or open source providers. Other portlets such as Billing and My Account may have been custom built.

JSR 168 has been largely successful in enabling reuse and interoperability between portlets and portals through its set of interfaces for aggregration, personalization, presentation, and security[1]. However, since its release in 2003, additional functionality gaps have been addressed through proprietary implementations. JSR-286, released in 2008, addresses many key gaps such as standardizing the interfaces for inter-portlet communication. In addition, JSR-286 and WSRP 2.0 have been strongly aligned.[2]

Although in general JSR 168 specifies the interfaces for local portlets, note that there are some remote implementations.

Service Level Reuse through WSRP

Web Services for Remote Portlets, or WSRP, is a complementary standard to JSR 168 that specifies the interfaces through which remotely running portlets plug into portal containers.

Figure 3 illustrates a common Billing portlet shared between multiple heterogeneous portals through WSRP.

Figure 3: WSRP Service Reuse

Because WSRP is based upon web services, it has the notion of consumers and producers. A single producer can serve multiple consuming portals. A producer may be based upon either J2EE or .NET. Each consuming portal may configure the remote portlet according to its desired user experience. Consuming portals may also be either J2EE or .NET. Consuming portals may even consume portlets deployed outside the firewall.

WSRP 1.0 was released in 2003, and, like JSR 168, has been successful in enabling reuse and interoperability between remote portlets and consuming portals.[3] As with JSR 168, functionality gaps in the specification required proprietary extensions. WSRP 2.0 was approved as a standard in 2008, and addresses key gaps such as inter-portlet communication as did its sister JSR 286 specification.[4]

Many WSRP implementations make enablement of a web application or local portlet a trivial task. On this note, consider that a given portlet can be both JSR 168 and WSRP, although a WSRP portlet need not be JSR 168.

Although in general WSRP specifies the interfaces for remote portlets, note that there are some vendors that provide the option for local deployment to optimize performance.

JSR 168 and WSRP Compared

The following table shows some of the differences between the complementary JSR 168 and WSRP standards.

Non-Standard Approaches to Portlet Reuse

Although this article is about reuse through portal standards, a mention will be made in regards to non-standard approaches to portlet reuse. In developing your strategy for building out and reusing your portlet catalog assets, a balance needs to be struck between idealism and pragmatism. Often, a non standard approach may be the right thing to do due to time, budget, or other goals and constraints.

Proprietary Portlets

Proprietary portlets may be considered because of the developer productivity gains and because of limitation of certain capabilities with strictly adhering to standards. Often, proprietary portlets can still be exposed through WSRP, allowing interoperability with heterogeneous portal environments.

Web Parts

The Microsoft equivalent to a portlet is called a Web Part. Web Parts could arguably considered standards within the Microsoft ecosystem and a Microsoft-based portal would utilize them heavily.

Poor Man’s WSRP: IFrames and Web Clipping

IFrames are HTML elements that allow an HTML document to be embedded within another document. IFrame portlets may be used to expose an existing application as a portlet, eliminating the need to re-write the application, at least in the short term.

Web Clipping is a technique to extract portions of a web page, eliminating extraneous graphics, headers, footers, and navigational elements. Web Clipping portlets may be used to leverage functionality embedded in existing applications and re-brand them per the portal.

Both IFrame and Web Clipping approaches expose remote applications as portlets and in a sense can be considered a poor man’s WSRP consumer. Each approach limits the ability to fully integrate the portlet into the user experience by skinning it and sharing context through a standard inter-portlet communication mechanism.

In some portal implementations, portlets are URL addressable. This can be considered a poor man’s WSRP producer because it allows portlets to be consumed by non-portal web applications through simple Ajax and an IFrame.

Rich Internet Applications (RIA) seek to create a more stateful client application in the browser that has features and functions, such as drag and drop, more typical to traditional desktop applications. RIA implementations are varied and may be based upon Ajax, Flash, Silverlight, Java applets, or other technologies. RIA-based portlets are another non-standard approach to consider in creating certain portlets in the portlet catalog to meet usability requirements.

Guidelines For Using Standard and Non-Standard Approaches

If your organization is utilizing a portal framework to improve user experience, simplify development, and enable reuse of front end web application assets across customer, partner, and employee user experiences, you will need to establish guidelines for using JSR 168, WSRP, and non-standard approaches to build out your portlet catalog. The following set of questions is a starting point to guide you in defining the strategy for your organization.

1. Do you have a notion of a portlet catalog? More important than your reuse mechanism is whether you have the notion of a portlet catalog in the first place. You should always consider what you want to reuse before you determine how you are going to reuse it. In most organizations, there is a compelling reuse story and a portlet catalog can help guide reuse efforts.
2. Does your ecosystem include vendors and open source providers that offer portlets? Many vendors and open source providers of content management, business process management, business intelligence, CRM, and other software systems provide JSR 168 portlets. This is an ideal situation for incorporating functionality from these systems into the overall consumer, partner, or employee user experience. Deployment and release concerns are less of an issue for these components that do not frequently change.
3. Do you have multiple teams contributing to the portal? If multiple teams contribute to the portal, which is often the case, WSRP can simplify release management because there is a single deployment of the portlet application, separate from the portal deployment. This allows teams to be on different release schedules. In addition, a single set of scalable infrastructure can be designed for the producer portlet and its multiple consuming portals.

   Use of a common portal framework can work well when portions of development are outsourced to other teams, with the remote teams adding portlets to the catalog which plug into the common portal framework and set of common services.

4. Do you have heterogeneous portal frameworks? In large organizations, multiple portal frameworks may be in use. If teams want to share assets across portals, either WSRP or JSR 168 might be employed. As noted above, WSRP often can simplify release management, particularly for assets that change regularly.
5. Is portal provider lock in a concern? Proprietary portlets may offer additional functionality or developer productivity improvements. You will need to weigh the potential benefits versus vendor lock in. As long as the proprietary portlets can be WSRP enabled, they will be able to be leveraged if a different portal provider is used in the future.
6. Does your organization utilize .NET? A pure .NET shop is going to choose a proprietary technology for its pluggable components called web parts. It may potentially consume some WSRP assets within or outside of the organization. In many portal implementations, a portlet is URL addressable and also may be consumed into a .NET application with simple Ajax. Similarly, a .NET application may be exposed through WSRP if required by an external organization.

   A shop with .NET teams that will contribute assets to its J2EE portal will need an architecture for making their .NET applications WSRP producers. Another approach to leverage existing .NET applications would be one of the “poor man’s” WSRP approaches discussed earlier. Finally, adapters to SharePoint assets are available in many portal frameworks, allowing development of a custom portlet which leverages SharePoint content.

7. Does your organization have high security requirements? If you have multiple teams and perhaps sourcing providers contributing to the portal in a high security environment, you would do well to stick with standard WSRP or JSR 168 implementations and not venture into non-standard approaches.
8. Do you have applications that may be leveraged by IFrames or Web Clipping? If you have existing assets that you want to leverage through the portal, IFrames and Web Clipping should be considered. The limitations of these approaches in the user experience and integration with the portal should be weighed versus the speed and cost of initial deployment. IFrames and Web Clipping might be phase 1 of an incremental approach to re-write these applications as standards based portlets.

Summary

A portlet catalog is comprised of a set of portlets or interactive application components that can be plugged into the portal framework. These portlets may be obtained from third parties or custom built by multiple teams, and may be configured for use across consumer, partner, or employee user experiences.

JSR 168 is a Java standard that specifies the interfaces by which local portlets plug into their portal containers. WSRP is a complementary standard that specifies the interfaces through which remotely running portlets plug into portal containers. Each of these standards enables reuse of portlets in the portlet catalog. JSR 168 provides a component level reuse mechanism, whereas WSRP is a form of service level reuse.

You reviewed the difference between these two complementary portlet standards to understand how each might be used as part of an overall reuse strategy. You also considered many non-standard approaches such as proprietary portlets and their pragmatic use. Finally, you perused a list of starter questions to guide you in development of your portlet catalog reuse strategy.

Have you defined a portlet catalog as part of your portal reuse strategy? Have you developed guidelines for building out portlet catalog assets using standard and non standard approaches? If not, consider how portal standards might help your organization attain higher levels of front end web application asset reuse. The rest is up to you!

References

1. JSR 168: Portlet Specification: http://jcp.org/en/jsr/detail?id=168
2. JSR 286: Portlet Specification: http://jcp.org/en/jsr/detail?id=286
3. Web Services for Remote Portlets Specification: http://www.oasis-open.org/committees/download.php/3343/oasis-200304-wsrp-specification-1.0.pdf
4. Web Services for Remote Portlets Specification v2.0: http://docs.oasis-open.org/wsrp/v2/wsrp-2.0-spec.html

About the Author

Jeff Ryan is an enterprise architect with twenty-four years experience architecting and implementing thoughtful solutions to business problems. Jeff uses the concept of the portal onion and portlet catalog described in this article to explain how portal standards enable reuse to business and IT stakeholders. Click here to browse Jeff’s catalog of articles on enterprise architecture, front end architecture, portal, SOA, Java, XML, and XSLT.