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.

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.