email article printer friendly more resources

JSR 168 and WSRP: Setting High Standards
New standards fundamentally change the portal landscape
by Rachel Greenblatt

October 13, 2004

You need standards. Why? Have you ever experienced the pain of trying to integrate with a business partner's portal—maybe one who has a firewall and runs .Net machines? Have you ever spent weeks deploying a personalized portlet for one business unit, only to discover that you need to painstakingly redo that programming to deploy the portlet for five other units with different portals? Have you ever wanted to deploy a portlet in a portal outside your enterprise?

Standards ease portability and interoperability headaches, and with the widespread adoption of portal standards JSR 168 and Web Services for Remote Portlets (WSRP), the pain from these tasks is all but eliminated.

Together, these new standards are causing a fundamental shift in the nature of portal deployment, and a concomitant upheaval in the portal vendor market. Instead of choosing portals for a discrete set of features, such as number of portlets, customers are increasingly choosing portal technology based on its overall architectural fit within the enterprise.

JSR 168
JSR 168 is a Java Specification Request (JSR) that establishes a standard API for creating portlets. BEA has participated in the Java Community Process's creation of the JSR 168 standard, and WebLogic Portal 8.1 supports JSR 168.

The primary value of JSR 168 derives from its widespread adoption by independent software vendors (ISVs). Before the adoption of JSR 168, enterprise application vendors had to support a separate set of portlets for each vendor portal. Supporting separate sets of portlets from multiple portal vendors causes headaches in areas such as business intelligence, content management, search, and analytics.

JSR 168 is a panacea to this problem for ISVs, who now need to support only one set of portlets. As a result, many more ISVs are providing their own generic, out-of-the-box portal integration components. This is a hallelujah moment for customers, since out-of-the-box application integration is now available regardless of which portal vendor is chosen.

JSR 168 is designed to achieve interoperability between portlets, Java-based portal servers, and other Web applications. By adopting this standard, BEA protects customers' current portlet investment by curtailing vendor lock-in. The majority of commercial portal products today support JSR 168, so customers who develop JSR 168-compliant portlets can move them from one vendor's portal to another. In addition, customers now have access to a rapidly growing set of out-of-the-box, standards-compliant, ISV-supported portlets.

According to the Java Community Process, JSR 168 portlets have a simple, standard API to any portal client, support multiple types of clients (multidevice, multibrowser), support localization and internationalization, allow for hot deployment and redeployment of portal applications, and contain declarative security (identical to the mechanism found in the servlet and enterprise JavaBean specifications).

The primary benefit derived from JSR 168 is interoperability achieved by standardization. Portlets developed for one portal vendor can be easily deployed in a different vendor's portal, and this standardization simplifies upgrading existing systems, as well as developing new ones.

Most major portal vendors have announced plans to support the JSR 168 standard, and the following ISVs are making their applications available as JSR168-compliant portlets: Bowstreet, CoreMedia, Citrix, Digital Harbor, Documentum, EDS, Fatwire, Filenet, Fuego, Macromedia, Interwoven, HP, MobileAware, Pegasystems, Orbeon SAS Institute, Stellant, Saba, Sybase, Tarantella, Sun, and Vignette. Because more ISVs are supporting JSR 168 all the time, check the JSR 168 site (see Resources) for a complete and up-to-date list of supporters.

JSR 168 means that the battle for dominance in the portal market no longer depends upon which vendor has out-of-the-box integration with the largest number of ISVs. Instead, standardization levels the playing field by allowing ISVs to support their own portlets. Customer risk and cost are reduced, and portal vendors will no longer be selected based on their portfolio of prebuilt portlets. When choosing a portal vendor, the main decision point will be how well that portal product fits into that customer's enterprise architecture.