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