Portlet standard predicament

Two new industry specifications may standardize the logical separation of portal applications -- aka portlets -- from the portal servers that use their services. The benefits of such a separation are clear, but the choice of whether to adopt the Java Community Process’ JSR (Java Specification Request) 168 or OASIS’s WSRP (Web Services for Remote Portlets) is less certain.

Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld DOWNLOAD PDF Click here to download InfoWorld's special report Diving into portals

Why separate portlets from portal servers? The most obvious and short-term benefits come from improved scalability. In the traditional portal model, portlets ran on the same J2EE application server as the portal server, interacting via simple J2EE interprocess communication. However, as portal use grew, moving the portlet to another piece of hardware and accessing it remotely reduced processor utilization on the portal server. Also, departments within a business often want to write and maintain their own portlets -- something that’s hard to accomplish across cultural and technology boundaries if portlets must be deployed to a centralized “glass house” portal server, but it is easy to do if portlets are hosted separately.

It’s only recently that industry consortia began defining standard interfaces and communications protocols for running portlets remotely. But the two top specs, JSR 168 and WSRP, are more competitive than complementary.

WSRP was designed not only to allow remote portlet-to-portal communication via XML-based Web services but also to accommodate cross-platform portlets. Thus, a J2EE-based portal server could interoperate with a portlet running on a .Net machine as long as it exposes its functionality via WSRP-compliant Web services.

The rich WSRP specification defines the communications protocol as well as standardized behavior language for portal-to-portlet transactions, and it uses WS-Security to add encryption and authentication to portlet-portal transactions. WSRP is also extensible and defines a method of extending the behavior language.

That extensibility is its biggest weakness. For example, BEA could define a set of WSRP behaviors that exploit features of its portal server; portlets written to use those behaviors would not be interoperable with other portal servers and vice versa.

By contrast, JSR 168’s scope is more limited. It does not support cross-platform communications, Web services, or vendor-specific extensions -- and it is more likely to ensure broad interoperability, at least within J2EE-based portlets. JSR 168 is defined as a set of extensions to the Java servlets APIs (javax.servlet.portlet), which is easier to implement than WSRP; JSR 168 is already found on most J2EE-based portlets.

At present, there’s no means for making a particular portlet compatible with both JSR 168 and WSRP. And due to their different design goals, there’s no reason to expect a unified JSR 168/WSRP spec any time soon.

So the decision as to which remote protocol to use depends on your portal goals. Looking for cross-platform interoperability, or want to separate portals and portlets across the Internet? Use WSRP and be careful about vendor-specific extensions. Want to logically separate J2EE-based portals and portlets within a datacenter? Use JSR 168. Want the best of both worlds? Keep waiting.