The first public draft of WSRP 2.0 was released last week. It took over two years to agree on a number of features and details. It may be worth the wait as it is a major enhancement over WSRP 1.0. Since I'm directly involved in developing the spec, I'm breaking of my own rule of not make announcements on this blog, and making this annoucement.

Every other web developer that I talk to is trying to figure out how best to use Ajax in their apps either to provide some slickness to web apps, or to avoid total page refreshes. In most cases, writing the server side processing code is trivial. You can use JSPs, servlets, struts, JSF or whatever to process Ajax request, and return data (as XML) or markup (as HTML) fragments. Writing client side scripts is where all the fun is. But when it comes to portlets, server side processing for Ajax requests gets tricky. Portlet related standards like JSR168 and WSRP 1.0 do have some limitations in supporting server-side processing of Ajax requests. These specs leave out a few details that limit the use of portlets to process Ajax requests and return data or markup. Read on, if you are interested in finding out what works, what does not and why.

When the JSR168 effort was started, its primary goal was to offer a standard programming model, and avoid proliferation of proprietary programming models for creating portlets. This JSR almost achived these goals when the first version of the Portlet API specification was released two years ago. But it is now at the verge of getting fragmented. I think it is time to take notice.

Here are the slides of the Federated Portals session I presented yesterday at BEA World 2005. My goal was to answer three questions, viz, (a) why should anyone consider using federated portals, (b) what kind of things can go wrong when you switch from a non-federated environment to a federated environment, and (c) best practices.

My article on WSRP is being promoted on ONJava now. It is the third big image from the left titled "Web Services for Remote Portlets".

WSRP TC approved the WSRP 1.0 Primer for final public release yesterday. Here is the link: http://www.oasis-open.org/committees/download.php/10539/wsrp-primer-1.0.html

Yesterday, at XML 2004, OASIS conducted a WSRP interop demo between several producer and consumer implementations. This demo is similar to the one conducted at XML 2003 conference, but is more interesting because there are more implementations that took part in this demo, and touched upon some key features of the specification (such as styles, customization, different kinds of markup, etc.).

I just came across this long thread on stateful vs. stateless web services. The main question discussed in this thread was whether stateful web services can scale.

I think the answer is “it depends�?. It depends on how much state is maintained by the service (in memory) vs. how much state is transferred to the client. It depends on whether the client is pinned to the service instance holding the state or not. It depends on whether the client can effortlessly hold on to the state for the required duration.

Having taken a positive spin on how WSRP addresses UI reuse questions in a previous post, I would like to comment on its current limitations in this post.

WSRP 1.0 does address the core UI-reuse and aggregation questions well, but being a 1.0 specification, it leaves a number of issues open. The WSRP TC has been working on these open questions ever since WSRP 1.0 was released last year. So, some of these limitations may not be true once WSRP2.0 is released.

There are several implementations (see WSRP TC Home Page for a list full/partial implementations of WSRP 1.0) available (including one from my employer), and there are several projects underway, either prototyping or moving towards deployment of portals using WSRP. Most of these implementations and projects are wary of the limitations and working around those limitations by way of custom extensions or other implementation-specific solutions.

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.

Web Services for Remote Portlets 1.0 Primer finally entered public review on Sep 15, 2004. It was driven by a small number of people in the WSRP TC, took longer than originally planned, but I'm glad to see it publicly available.

Although the public review period ended last week, if you have any comments or suggestions, please feel free to email.