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.

WSRP
The benefits from portlet standardization go one step further with WSRP. Created by OASIS (a not-for-profit consortium of industry experts who develop e-business standards), WSRP specifies the remote rendering of portlets. BEA sits on the WSRP committee, and WebLogic Portal 8.1 supports WSRP as both a "producer" and "consumer" of remote portlets.

WSRP enables functionality that was previously extremely difficult to achieve, such as deploying portlets once but delivering them anywhere, bringing together third-party portlets, and enhancing interoperability between portals from different vendors.

For the first time, WSRP also gives customers a feasible way to build federated portals. Federated portals consist of a network of interoperating portals, whereby resources hosted in one portal can be made available in many (see Figure 1). There are numerous benefits to the adoption of federated portals, including portal rationalization and fewer IT-managed Web assets.

In the past, a portlet could only be consumed locally, in the same portal where it was hosted. With WSRP, a portlet can be hosted ("produced") on physically and logically separate infrastructure from the portals surfacing ("consuming") the portlet. Because of this innovation, WSRP has the potential to radically increase portal deployment flexibility.

Because a portal is able to draw content from a portlet in any location, business units can now write and maintain their own portlets. This can be done on each business unit's local infrastructure, so that all portlets within a single portal do not have to be deployed on a single portal instance. Updates and changes to content that were once difficult to make because of firewalls or differing deployment schedules, now can be made easily and quickly by each business unit. Business units achieve a previously unobtainable level of independence and flexibility.

In addition, by decoupling code from implementation and delivery, content can be syndicated easily. Developer teams can operate independently of business units, and business units can adapt quickly to shifting business needs without being hampered by questions of interoperability.

WSRP will lower the cost of portal maintenance. Portlets can be deployed on less expensive machines than those needed to run mission-critical portals, and the result is a reduction in the total cost of portal infrastructure and total downtime. Because portlets no longer need to be co-located with the portal, organizations can scale up their portals while leaving their remote portlets untouched. More heavily trafficked portlets can be separately provisioned with computing power. Version control problems are reduced or eliminated. Partners can manage their own portlets without having to share secure or proprietary information or infrastructure.

WSRP broadens the scope of resources available to a portal. Portlets can be produced or consumed from any J2EE portal or from any machine running .Net. Weblogic Portal 8.1 will be able to consume .Net applications. Existing portlets can be leveraged throughout an enterprise, no matter the enterprise's current portal vendor. Vendor lock-in is eliminated and IT spending is reduced, with less time wasted hosting and deploying duplicate portlets. Cost savings result from cross-vendor and cross-business-unit access to the same applications and data.

Although most portal industry players support WSRP, BEA is one of the few companies participating in interoperability testing of WSRP version 1.0 implementations.

Federated Portals
BEA is working with some of its most innovative customers to develop federated portal solutions using WSRP. Typically, the federated portal architecture involves large numbers of separately managed portals. Each portal acts as both a producer of portlets (for other portals), and a consumer of portlets (from remote portals).

For example, the marketing department portal may be consuming portlets from the engineering portal and at the same time provisioning portlets for the sales portal. A federated portal network thus allows business units to maintain and host their own portlets, thereby removing a burden from central IT and adding flexibility to the portal network as a whole. Federated portals have the potential to radically change how business partners consume each other's IT services.

Federated portal architectures also provide a mechanism for achieving enterprise portal rationalization. Through the WSRP-enablement of existing resources, customers can migrate users to an "überportal" that consumes these resources. WSRP also helps overcome a primary objection to portal rationalization, which is that a single portal is not a viable option for large, complicated businesses.

With WSRP, customers can standardize on a single portal framework across the organization (the überportal), within which many smaller portals consume each other's content. Thus, the goal of having each IT service deployed only once, and consumed consistently, is achieved without a monolithic portal deployment.

With its extensive experience in helping customers deploy the most complex bespoke software systems in the world, BEA is uniquely positioned to provide the best implementation of the WSRP standard—one that can support an enterprise-scale federated portal architecture.

Results
JSR 168 and WSRP are critical to the future of portals and to portal rationalization. Content and information can be managed at its native source, but accessed from any source. Business units can maintain control of content while others consume it, and developer teams can operate independently. The industry is moving toward a unified, federated portal framework, where sharing portal components paves the way for sharing business services. Federated portals allow for increased flexibility in the sharing of content between different business units and partners.

For example, a retail company may have a customer-facing portal that needs to integrate with a wholesale supplier. Through the remote rendering of portlets with WSRP, not only can the retailer's portal integrate directly with the supplier's portlets, but the supplier can still host, maintain, and update content independently of the retailer. JSR 168 provides value by eliminating vendor lock-in. By allowing a portlet to integrate with a portal from any vendor, code and hours of programmers' time will be saved.

About the Author
Rachel Greenblatt is a product marketing associate for WebLogic Portal 8.1.