subbu.org

I began working with WSRP about two years ago. At that time, the specification was evolving. The specification draft seemed cryptic to read, and I spent several weeks trying to reason out the spec. It turned out that the technical problems WSRP is trying to solve are easier to understand, but not some of its applications. After spending long hours implementing the specification at BEA, and after discussing this topic with several people, I began to understand some of the implications of using WSRP.

When you think of XML, SOAP and web services, the first thing that comes to mind is interoperability. We want to use web services to let desperate systems work with each other exchanging data in some platform-neutral form. There is no doubt that interoperability is the biggest gain for some web services deployments today. It is easy to conclude that WSRP solves the same problem for portals. Portals can consume UI (portlets) built on different portlet containers using WSRP in a standards-compliant manner. Interoperability is important in a non-homogeneous environment, but it may not be a reason enough to adopt a technology like WSRP in homogeneous environments.

The first advantage is the kind of decoupling that WSRP can provide. In fact, to my experience, most people find such decoupling more exciting than interoperability, at least in the case of portals. Why is that more exciting? Imagine several teams of developers building portlets in different functional areas, each with their own release/upgrade cycles. Each of these teams can independently build and deploy portlets without disturbing others. In a J2EE like-environment, this makes the release process (including the scary dev to staging to production process) a whole lot easier. Each of these teams can independently add or replace portlets without bringing the entire system down.

Another advantage is reuse. You can deploy your portlets once, and use those portlets wherever you like without physically moving those everywhere. This saves a lot of time and effort. Instead of managing “n�? installations, you have to deal with just one installation.

Before getting into WSRP, I was not a complete believer in loose coupling and reuse. These are nice principles, and make sense in most cases, but we end up breaking these principles for the sake of delivering useful and usable software. The reason is that loose coupling and reuse of software that involves user interactions is difficult to achieve. That is why, there is so little reuse and so much coupling at the UI level.

WSRP makes a fair attempt at this problem by attacking it at a more abstract level. Instead of inventing markup languages for construcing UI, it defines a set of web services that can be used to move UI and user interactions from place to place. It does not matter what goes on inside that UI, or how that UI is generated, or how users interact with it. All that matters is an end-point that can expose UI via web services. To me, this is a more interesting and challenging problem than interoperability.