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.
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.
E-mail
Printer Friendly
Reprints
(InfoWorld) - In the litigious world we live in, deploying a unified communications platform in your enterprise could...
