From MemberWiki

Contents 1 OpenAjax Communication TF: Problem Defintion 1.1 Introduction 1.1.1 Technical Background 1.2 Problematic Use-Cases 1.2.1 1. Client side Ajax Push interoperability 1.2.2 2. Client side Ajax Push multi-tab/window usability 1.2.3 3. Server side Ajax communication interoperability 1.2.4 4. Service side Ajax communication efficiency 1.2.5 5. Cross frame communications 1.3 Proposal(s) 1.4 References

OpenAjax Communication TF: Problem Defintion

Introduction

This article defines the problems that OpenAjax Communication Task Force is trying to solve.

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

• It is difficult and non-standard for Windows/tabs to communicate with each other, so it is complex 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

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

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

3. 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 targeted 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.

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

5. Cross frame communications

scenario

An Ajax application that is composed of multiple iframe (or frame) components and these iframe components need to communicate with the parent frame or each other;

issue

If all iframe components and the parent frame use OpenAjax CommunicationHub, they should be able to communicate with each other automatically (if they all come from the same domain); However, if the come from different domain, the cross-site communication is not allowed as a security constraint.

comment

Not sure whether we should provide a solution here. We should talk to the Security Task Force on the one side. On the other side, take a look at Dojo etc to see whether their techniques are suitable here.

Proposal(s)

• Communication API Proposal
• Communications Events Proposal

References

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