by Jon Udell

Standards make portlets portable

analysis
Jan 9, 20042 mins

The freshly minted WSRP and JSR 168 standards bring new flexibility to portal development

Two new specifications, WSRP (Web Services for Remote Portals) and JSR (Java Specification Request) 168, promise to jump-start enterprise portal development. WSRP describes how to write Web services so that they can be consumed and presented by any WSRP-compliant portal server. JSR 168 enables developers to write a portlet once, which can then run on any J2EE portal server.

Version 1.0 of WSRP was published in September 2003; Version 1.0 of the JSR 168 was published in October. Because of the timing of these events, and because implementations of the two specs can work together, there has been some confusion about the role of WSRP. In WSRP lingo, a Consumer is what an end-user thinks of as a portal, specifically a Web site that presents collections of interactive parts, or portlets. And a Producer is a provider of portlets.

It’s true that a provider of JSR 168 portlets can be adapted to run as a WSRP Producer, and that a container of JSR 168 portlets — a Java portal server, for example — can be adapted to run as a WSRP Consumer. So, WSRP can be used to aggregate and recombine remote JSR 168 portlets. But it is not tied in any way to the Java-specific APIs that govern the interactions between portals and portlets in Java portal servers. JSR 168, by standardizing those interactions, aims to ensure that a Java portlet written for the WebSphere Portal Server will also work in an Oracle, BEA, or Sun portal server. WSRP’s charter is broader. A Java portal server can be a WSRP consumer, but so could a SharePoint server, or an application written using the portal framework in the forthcoming ASP .Net 2.0.

Although no Microsoft names appear on the WSRP specification, the program director for SharePoint recently became a member of the WSRP committee, and with or without Microsoft’s cooperation, it’s clear that integrating .Net with WSRP won’t be rocket science.

Politics of portals aside, WSRP broadens the role of Web services in an important way because WSRP aims to enable applications, not just raw methods and data, to flow across the Web services network.