Notification Protocol Overview

You are viewing an old version (v. 1) of this page.
The latest version is v. 6, last edited on Jan 30, 2013 (view differences | )
view page history | view next version >>

Notification Architecture

ICEpush provides a web-based asynchronous notification mechanism in support of pushing updates from a server-based web application to a client browser connected to that application. The mechanism includes both client and server constituents, and leverages long-polling over a blocking connection to deliver notifications asynchronously from the server to the client.

The core mechanism is purely for push notification, and carries only the minimum payload required to achieve it. An integration layer must be implemented around the core to provide payload processing. This integration will be specific to the client and server technologies used in the application's implementation. The intention is to provide specific integrations with a wide spectrum of RIA development technologies, with initial priorities focused on Java and JavaScript technologies.

The mechanism, in it's simplest form is illustrated below with both block and sequence diagrams.


Unable to render embedded object: File (simpleBlock.png) not found.



The core constituents include:

Push Client A JavaScript implementation that is included in the page requiring push. The Push Client is responsible for managing the blocking connection, and triggering payload processing when notifications are received.
Push Server An environment-specific library (Java, .net, PHP, ...) integrated into the web application to manage the blocking connection and listen for notification events. When notifications occur, the Push Server fulfills the blocked notification request.

The integration constituents include:

Payload Processing Business Logic A JavaScript call-back function associated with the notification, that is capable of retrieving the push payload, processing it, and affecting changes to the page DOM to modify the presentation.
Push Business Logic Framework and/or application specific business logic for pushing updates. This logic must be able to trigger push notifications based on some state change in the application, and then deliver the associated payload when requested.

Core Features

In order to achieve true asynchronous notifications from the server to the client using only standard HTTP communications, it is necessary to invert the protocol and use long polling, where a connection is held open in anticipation of a notification event that will complete the request/response cycle over that connection. There are a number of ramifications associated with these long-held connections that must be addressed by the core notification mechanism.

Connection Sharing

For a browser client viewing a single push-enabled page, two connections are required - one blocking connection for the push notifications, and one non-blocking connection for all other Ajax and user-initiated requests. As you extend beyond this simplest use case to multiple browser tabs open to the same application, or multiple push-enabled applications being viewed from the same browser, it is not feasible to open multiple blocking connections for each of the page views, as this will lead to connection exhaustion at the browse (IE allows only two connections to the same domain). Under these more advanced use cases it is necessary for the core notification mechanism to perform connection sharing to prevent connection exhaustion. For a single web application, connection sharing can be achieve entirely on the client side, but as you move into multi-application and clustered deployments, server-side connection sharing also becomes necessary.

Server-side connection sharing represents a clear delineation point between open source and commercial offerings, as it requires that elements of the notification mechanism be detached from the web application and deployed as a separate application or "Server". Some form of IPC is also necessary for these types of deployments, providing further delineation between open source and commercial deployments.
ICEpush must support the following use cases.

Applications Push Clients/Page Browser Views Open Source Commercial
Single Single Single
    Multiple
  Multiple (ie: portlets) Single
    Multiple
Multiple Single Multiple
degraded
  Multiple Multiple
degraded
Clustered Single Single
    Multiple
  Multiple Single
    Multiple

Graceful Degradation

When multiple push applications are detected in a configuration without a push server, a single application is elected to host the push connection and all other applications revert to polling on a configurable interval. A more advanced version of this feature would move the push connection to the application currently receiving user events, however the complexity of implementing this is likely not warranted given the existence of the push server.

Heartbeating

Experience has shown that long-held connections over the Internet can be unreliable, so it is necessary to perform heartbeating over that connection to keep it healthy. Heartbeating can also serve as a connection monitoring and status reporting mechanism. The ICEpush core will include configurable heartbeating and connection monitoring capabilities

ARP

Holding HTTP connections open at the server can have performance and scalability ramifications at the server. Typical HTTP processing maintains a thread per connections which can lead to thread exhaustion. Asynchronous request process can alleviate performance problems associated with blocking connections, but ARP mechanisms are typically proprietary and server-specific.

In the Java domain, the Servlet 3.0 specification unifies ARP support, so the Push Server implementation in Java will be able to leverage standards-based ARP APIs. Further investigation is required to understand how ARP support can be achieved outside the Java domain. It is also possible to implement a completely standalone Push Server that is deployed along side the application server and implements its own ARP mechanism specifically for handling the blocking connection.

Outside the standard Servlet 3.0 support for ARP, all other proprietary ARP integrations will be strictly confined to commercial offerings of ICEpush.
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

© Copyright 2017 ICEsoft Technologies Canada Corp.