How Portal Standards Enable Reuse
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. 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.
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