Direct from Web 2.0

Internet Messaging Bus – Web 2.0 Communication Layer

April 15, 2007 – 7:18 pm by coachwei | Category WebDev |

In my previous post, “Web 2.0 Re-examined: the Paradigm Shift, Technology Stack and Business Value “, I described a “Web 2.0 Technology Stack ” that contains three building blocks: Application Client Container, Internet Messaging Bus and Enterprise Mashup Server. In this post, I’ll explain more in detail of what an Internet Messaging Bus is.

What is Internet Messaging Bus (IMB)?
Internet Messaging Bus refers to a software architecture construct that sits between a standard web browser and standard web server for providing enhanced web communication functions beyond the typical HTTP request/response processing, such as server push and message reliability, while still leveraging the standard HTTP protocol.

IMB Features and Functionality
Built on top of HTTP (and HTTPS), Internet Messaging Bus is an enhanced communication layer that delivers reliability and two-way communications in addition to HTTP’s request/response processing.

Though highly desirable for JavaScript/Ajax based web applications, IMB implementation is not limited to JavaScript/Ajax. As a web messaging layer, IMB can be implemented using Java or C#, and used either within a browser environment or outside of a browser environment. For example, a Java-based IMB implementation can provide messaging support for browser-based Java rich internet applications or desktop-based Java rich client applications.

IMB provides the following services:

Reliable Messaging:
- Once and only once message delivery: Without IMB, a user request may arrive on the server side more than once if some network problem caused the message to be cached and delivered more than once. IMB can guarantee messages to be delivered once and only once.
- Guaranteed order of message delivery: Without IMB, if the user submits two requests in a row, there is no guarantee that the first request will arrive at the server before the second request. IMB can guarantee the order of message delivery.
- Guaranteed message delivery: Without IMB, if there is a network problem (either with the ISP or within the corporate network itself), a request may be lost. IMB can overcome such network problems to provide message delivery guarantee.
Flexible means of communications:
- Client-initiated communications: client pull and polling
- Client-initiated communications: Server push
- Publish and subscribe
- Broadcasting

How Does IMB Relate to HTTP, Comet, ESB and JMS?

HTTP Hypertext Transfer Protocol (HTTP) is the standard protocol used to transfer or convey information on the World Wide Web. HTTP uses a request/response model for communication between clients and servers. Its original purpose was to provide a way to publish and retrieve HTML pages. However, HTTP has several major limitations in the context of web 2.0 applications:

Lack of support for two-way, real time communications: HTTP requires the browser to initiate an HTTP connection to the web server in order to receive data. The drawback of this approach is that the page displayed is updated only when the user explicitly refreshes the page or moves to a new page, which unnecessary roundtrips and undesirable latency.
Lack of messaging reliability: HTTP is based on TCP/IP. Though TCP guarantees the reliability at a packet level (TCP/IP splits a message into small packets for delivery, and makes sure these packets are delivered reliably), it does not guarantee reliability at a “message” level. For example, the same massage would be delivered to the web server twice if two network devices employ “store and forward” techniques for message delivery without proper coordination.

IMB fixes both HTTP problems. On the other side, IMB is built on top of HTTP and thus it works on existing browsers, web servers, firewalls, proxy servers, etc without the need to change any existing web infrastructure.

Comet
According to Wikipedia : Comet is a programming technique that enables web servers to send data to the client without having any need for the client to request it. It allows creation of event-driven web applications which are hosted in the browser. Comet enables “two-way, bi-directional communications” beyond the standard HTTP request/response. Though still emerging, Comet breathes fresh air into the World Wide Web and inspires new class of applications.

Comet is part of the built-in features for IMB. Beyond providing Comet-style real time communications, IMB also addresses another important aspect of messaging: reliability.

Enterprise Service Bus (ESB)
An ESB generally provides an abstraction layer on top of an implementation of an enterprise messaging system which allows integration architects to exploit the value of messaging without writing code. Contrary to the more classical enterprise application integration (EAI) approach of a monolithic stack in a hub and spoke architecture, the foundation of an enterprise service bus is built of base functions broken up into their constituent parts, with distributed deployment where needed, working in harmony as necessary.

ESB is typically used for “server to server” communications that both end points require ESB software to be installed.

IMB is for “client-server” communications over the Internet that software installation on the client side is typically not possible.

IMB is a messaging system while ESB is a higher level construct than a messaging system. ESB provides architecture as well as high level services such as “integration” services on top of an enterprise messaging system.

IMB and ESB can be connected together to enable real time message flows between web clients outside of firewall and servers inside firewalls.

Java Messaging Service (JMS)
The Java Message Service (JMS) API is a Java Message Oriented Middleware (MOM) API for sending messages between two or more clients. JMS is a specification developed under the Java Community Process as JSR 914. JMS is typically used for “server to server” communication where JMS software can be installed on both end points.

IMB and JMS can be connected together to enable real time message flows between web clients outside of firewall and servers inside firewalls (with appropriate security governance).

Nexaweb’s IMB Implementation
At Nexaweb , we took a fairly systematic look at the web communication layer in 2002 and 2003. While recognizing the limits of HTTP, we also recognize HTTP is the foundation for the Web and compatibility with the existing web infrastructure is important for enterprise deployment. Nexaweb Internet Messaging Bus was created and built on top of existing HTTP so that it works across the Internet without the need to make any changes to an existing web infrastructure.

Since 2003, Nexaweb Internet Messaging Bus has been one of the three building blocks of the Nexaweb Platform . Nexaweb implemented IMB support within Nexaweb Server (a Java Servlet that provides Enterprise Data Services ) and all of the client engines within its Universal Client Framework (UCF) :

Nexaweb IMB supports both “Comet” as well as reliable messaging:
1. Reliable Messaging:
  - Once and only once message delivery
  - Guaranteed order of message delivery;
  - Guaranteed message delivery
2. Flexible means of communications
  - Client pull (request/response) and polling
  - Client-initiated communications: Server push
  - Publish and subscribe
  - Broadcasting
Nexaweb IMB support Java, Ajax and Offline computing: Nexaweb Ajax Client, Java Client as well as Desktop Client all implement support for IMB, enabling reliable real-time messaging cross different client technologies and different application deployment options.
Compatible with existing web infrastructure: Nexaweb IMB works with any existing infrastructure without any change required: no need to change firewall configuration on either client side or server side, no need to open a new port on the server side, no need to change proxy server and load balancing hardware, etc. The entire Nexaweb system is deployed into a standard Java EE web container as a WAR file.
Any to any messaging: Nexaweb IMB enables real-time communications from client to server, but also from server to client, client to client, and server to server in a clustered server environment.
Reliability, performance and scalability:
Typical scalability and reliability designs from existing web infrastructure are based on Web 1.0’s “request/response” model and thus does not work for “comet” style push based applications. Nexaweb IMB implementation addressed these issues by complimenting what is built into existing Java EE infrastructure, and enables standard server clustering, load balancing and failover for web 2.0 applications.

How Does Nexaweb IMB Work
Each end point of a Nexaweb IMB implements a message queue. The behavior of this message queue can be declaratively or programmatically configured. When a sending party is sending a message, the message will enter this queue first within a unique ID assigned to this message. The message will stay in the queue until the receiving party has confirmed that this message has been successfully received. In a clustered environment, message queues are automatically replicated by Nexaweb Server across the cluster.

Using Nexaweb IMB, each message is assigned a unique ID. The unique ID is associated with a message sequence number. By keeping track of message ID, Nexaweb Platform is able to identify whether a message is missing or a message is out of order. If a messaging is missing, the receiving party will notify the sending party to re-send the message. If a message is out of order, the receiving party will correct the order before delivering it to its destination.

Under the hood, Nexaweb utilizes a lightweight XML-based protocol. The protocol defines metadata information such as message ID, message confirmation, request to re-send a particular message, ping, connection control, etc. The payload of a message can be anything: binary, text, JSON, HTML, XML, serialized Java object, etc. When a message is sent, the payload is combined with metadata information defined by the protocol, all delivered over a standard HTTP connection.

There are lots of factors in a real world deployment scenario that impacts how messages should be delivered. The options include client pull, polling, long polling, server push, persistent connection, etc. But no single option can work universally. For example, some proxy servers will close a connection after it has been idle for certain duration, and some network devices performs data caching that would interrupt real-time data delivery. Nexaweb Platform has been designed to take all these factors into consideration. Based on configuration policies, Nexaweb Platform intelligently determines the best way to deliver messages according to the actual network environment characteristics.

How to Use Nexaweb IMB
Nexaweb IMB functionality is exposed to developers as APIs on both the client side and server side. Using these APIs, developers can send/receive/publish messages. Developers can also specify policies in configuration files to customize the behaviors of the Internet Messaging Bus to fit into application deployment requirements. Please check documentation for more information:

Client side API: com.nexaweb.client.netservice, com.nexaweb.messaging.MessageListener
Server side API: com.nexaweb.messaging.MessageListener, com.nexaweb.server.messaging , com.nexaweb.server.pushconnection , com.nexaweb.server.pushconnection.flushpolicies
Policy-based configuration

Reliability, Performance and Scalability
“Server push” (Comet) brings unique challenges to application scalability and reliability.

Traditional web clustering, loading balancing and failover capabilities are designed for the “request/response” model. For example, the typical load balancing system would distribute different requests to different servers according to algorithms such as “round robin” algorithm. But “server push” functions are not taken into consideration in such load balancing systems. Another example is failover. A Java EE server cluster such as a WebLogic cluster would automatically failover a session to another server instance in a cluster if the original server instance for this session failed. However, if the session has a “server push” feature, the WebLogic cluster will not be able to handle the “failover” of this server push feature.

Nexaweb built clustering/failover support on top of existing Java EE’s clustering capability to address the unique challenges associated with “comet” style applications. In a clustered server environment, Nexaweb server automatically replicates the message queues across different servers. When a failover happens, messages will be transparently available on the new server instance. When a “server push” connection is broken, the Nexaweb Client and Nexaweb Server will automatically establish a new server push connection when necessary. Nexaweb Clustering support has been tested and field deployed at many customer environments worldwide since 2004. Nexaweb applications with clustering support have been successful deployed on top of almost all the major Java EE infrastructure, including Oracle application server, WebLogic, Websphere, NetWeaver and JBoss. The scale of deployment ranges from two server nodes that only provides load balancing (without session failover) to 32 server nodes that are fully clustered providing real time failover and load balancing, supporting thousands of user sessions on 24X7X365 basis.

In real world deployments, there are a lot of additional challenges for “comet” style server push applications. For example, some proxy server will automatically disconnect an HTTP connection, and some web cache software and/or hardware will not deliver content until it has reached a certain size (some internal buffering requirement). Some web accelerator systems perform compression which disrupts real time HTTP messages. Nexaweb IMB implementation has built support to address such scenarios in order to guarantee performance and reliability, and has been fairly well proven in the field.

Nexaweb IMB Examples
Nexaweb Internet Messaging Bus has been deployed by many customers since 2004. A leading example is Bank of Tokyo-Mitsubishi UFJ (BTM) . With over 35,000 employees, 672 branches in Japan and 113 overseas branches, BTM is the world’s biggest bank. BTM deployed an Institutional Foreign Exchange Mashup application with Nexaweb’s Enterprise Web 2.0 Platform. The application is being used by thousands of corporate customers over the Internet worldwide.

Nexaweb IMB enables some key features required by this application:

Real-time currency rate streaming over the Internet: Displays currency pairs with price and term of pre-reserved currency rate.
Asynchronous Update of Transaction Logs: Eliminates the need to refresh Web pages, ensuring up-to-the-minute market details.
Online Corporate Chat: Supports real time collaboration of institutional foreign exchange trading

Here are some online demo applications that use Nexaweb IMB feature: