Yesterday, I was tipped by one of my ex-colleagues at BEA that both JSR-286 and WSRP 2.0 have been finalized and submitted for voting by JCP and OASIS respectively. I was an active contributor to both these specifications till mid 2007. Congratulations to both the working groups!

Over at Ajaxian, there is a post written about reinventing XMLXttpRequest. This so-called corss-browser implementation is nothing but a wrapped XMLHttpRequest object, which is implemented in JavaScript with some of the methods wrapped partially to do some interesting things. The code is posted at http://code.google.com/p/xmlhttprequest. While at BEA, I took a similar approach for letting aggregation frameworks (such as portals) manage XMLHttpRequests between browsers and web applications (such as portlets). The approach turned out to be successful. It allowed portlets use a wrapped XMLHttpRequest directly or via Ajax frameworks such as Dojo in a loose-coupled manner. Some "security experts" also called wrapping XMLHttpRequest a security risk!

However, due to the way the XMLHttpRequest is currently drafted and how it is implemented in browsers, making such wrapped implementations conform to the XMLHttpRequest specification is impossible unless the wrapped object is implemented natively and not in JavaScript. Here is why.

At BEA, we recently released a patch for WebLogic Portal 10.0 to support the XMLPortletRequest interface as an alternative to using XMLHttpRequest with portlets. See Ajaxifying Portlets - Part 1: Unmanaged Ajax and Ajaxifying Portlets - Part 2: Managed Ajax for more info.

Here are the slides for my session at JavaOne 2007. The topic was using Ajax programming styles with portlets.

In my previous post, I discussed the key problems in using XMLHttpRequest within portlets and other similar widget-style components. The programming model used for XMLHttpRequest interferes with the way portals aggregate pages, and provide other features like inter-portlet events, state management etc. In this post, I would like to discuss the script interface XMLPortletRequest. Before we begin, note that, although I am describing this interface in the context of portals, the idea of a wrapper interface such as XMLPortletRequest over XMLHttpRequest can be used to solve a number of use cases related to widgets and browser-side components. I will discuss more about those possibilities in a later post.

Starting with this post, I would like to describe a new script interface called XMLPortletRequest. The intent of this interface is to provide a means for portlets to implement asynchronous and/or partial page updates within the portal/portlet paradigm, and yet remain compatible with Ajax toolkits and portlet bridges (JSF, Struts, Spring MVC etc.). I developed this approach several months ago, and the portlet-related specification groups, viz., JSR-286 in the Java-land, and WSRP in the language-agnostic web services land, are actively considering this interface as the basis for building Ajax-related solutions. Some specifics of this model are still being debated in these groups, but the semantics of the model are more or less finalized. Please read on for some background and details.

The two-phase life cycle model of portlets is a strange beast to explain to web developers. The most often heard complaint is that this model is quite unnatural for web developers. Why would any web developer want to split the simple GET and POST requests into "render" and "action processing" phases so that some portal can render it correctly? On the surface, this looks like a harsh requirement that portals impose on web app developers. A few months ago, one of my colleagues tried hard to convince me (unsuccessfully, of course) that the portlet programming model is broken, and that the portal guys got it completely wrong. I heard similar stories from portlet bridge developers whose main struggle is to some how bend over backwards to get JSF, Struts, and even ASP apps fit into the two-phase lifecycle of portlets. This exercise is easier described than done.

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.).

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.