OpenAjax Alliance has been growing well with over 70 members. The initial OpenAjaxHub received immediate community response - most are positive and a few responses were negative but turned out to be very helpful. Over ten Ajax offerings demonstrated support for OpenAjaxHub already (such as Apache XAP, Dojo, Nexaweb AjaxClient, Tibco, etc). Addressing the feedback received so far,  the upcoming release of OpenAjaxHub 1.0 in the next few months is going to be really good - tiny footprint (under 5KB), focused on interoperability and event propagation between Ajax widgets and highly functional .

CommunicationHub is another part of the technical work that OpenAjax Alliance has been working on. The goal of CommunicationHub is to identify and propose solutions for communications related interoperability issues, eventually leading to the formation of a working group around this area. The CommunicationHub Task Force consists of 19 members currently(Dojo, LightStreamer, SAP, IBM, Nexaweb, WebTide, OpenSpot, IceSoft, DWR, Tibco, VertexLogic, Adobe, eclayer, Zend, Oracle, OpenLink, coradiant, etc) and I chair the task force.

Based on the last few month's discussion, the task force is gradually converging onto a common problem defintion. Here is a draft document that outlines the problems we identified and we should target at. The objective of this document is to:

• Identify the problems with web communications that OpenAjax Communication Task Force should target at;

Technical Background

While non-HTTP based communication and messaging is possible from Ajax-like clients, they do not fall within the charter of the OpenAjax Alliance. For the purposes of this paper, we restrict our consideration to messaging that is transported over standard HTTP.

The followings are some of the technical background that introduces challenges associated with communicaitons:

Connection Limits

• Browsers commonly have a 2 connection limit per every host they connect to. These connections are shared between all uses on the browser and if a connection is in use, the requests are pipelined or queued waiting for the outstanding requests to complete.
• Two HTTP/1.1 connections is sufficient for efficient two-way messaging
• The use of Ajax Push techniques puts significant additional load on network infrastructure. Traditional web applications typically have less that 0.1 requests outstanding per user. For Ajax Push, this increases to over 1.0 request per user and thus represents at least a 10 fold increase usage of network resources.
• Increasing the per host connection limit is not a satisfactory solution as an increased limit
  • is not justified on messaging needs.
  • will further increase network and server load
  • will only delay rather than avoid resource starvation.

Multi window/tabs

• Windows/tabs cannot communicate with each other, so it is impossible to share connections without browser support.
• Browser support for sharing connections is closely linked to requirements for browser support for XSS.
• A server can detect if multiple long polls are coming from the same client and gracefully fail: either by falling back to polling or informing user of the duplication.

Cross Site Messaging

The XSS "hacks" available for Ajax Push require significant support from the server side so that script can be injected. It will be difficult to get general acceptance of such techniques.

Problematic Use-Cases

Client side Ajax Push interoperability

scenario

two or more Ajax Push frameworks within a single Ajax client application.

issue

Each frameworks initiates a long poll and consumes the browsers per host connection limit.

comment

A mechanism to share long poll requests may be required.

Client side Ajax Push multi-tab/window usability

scenario

An Ajax Push based application is opened in two or more tabs/windows of the same browser.

issue

Each instance of the application is unaware of the others, initiates its own long poll and thus consumes the browsers per host connection limit.

comment

A solution to detect/handle multiple instances may be required.

Server side Ajax communication interoperability

scenario

An server uses portlets or server side mashups to combine multiple Ajax components into a single page/application.

issue

The client side components will be unaware that the page URL is shared by other components and frameworks and may attempt to use the source URL to communicate with their server-side components. The portlet or mashup will not be able to differentiate requests targetted as component to component communications vs requests to refresh the entire page.

comment

A mechanism to address messaging to components may be required that can pass portlets and mashups without knowledge of the Ajax frameworks.

Service side Ajax communication efficiency

scenario

An Ajax application that is composed of multiple components with server side elements.

issue

Some event on the client side may cause all those components to attempt to refresh their state from the server side, so multiple requests to the server will be made and significant latency may be experience.

comment

A batching mechanism may be required.

Proposal(s)

To de developed.

References

This is largely based Greg Wilkin's original essay [Interoperability Communication] written in October 2006.