Two new specifications - Web Services for Remote Portals (WSRP) and Java Specification Request (JSR) 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 website that presents collections of interactive parts, or portlets, and a "producer" is a provider of portlets.
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.
However, 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 standardising those interactions, aims to ensure that a Java portlet written for the WebSphere Portal Server will also work in an Oracle, BEA Systems or Sun Microsystems 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 co-operation, it is clear that integrating .net with WSRP will not 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.
Jon Udell writes for InfoWorld