the real-time web - speed up your enterprise

7/31/2019 The Real-Time Web - Speed Up Your Enterprise

1/10

T

A Tavendo Whitepaper

July 2012

The Real-time Web: Speed up your enterprise

Gain new ground, leverage investments: adding Real-time features

to business applications using Web Message Brokers.


2/10

T

Summary

Companies today operate in an environment that is changing ever more rapidly. Quickmarket shifts in a globalized economy, rapid technological change and increased

customer expectations all mean the speed of doing business has increased.

Using information in real-time enables the fast reaction times necessary to stay

successful in this environment.

Making information immediately accessible to users, and bringing it to their attention,

is an essential part of this speeding up of the enterprise. Real-time display of data in

business applications allows faster and more informed decisions.

Acting fast on information also involves communicating faster and more focused with

co-workers. This is enabled by real-time features in business applications such asactivity streams, presence indicators, instant messaging and collaborative whiteboards

and document annotation.

This whitepaper examines problems with implementing real-time features on existing

platforms for web applications. It then evaluates solutions that enable easy addition of

these abilities without affecting present functionality of existing applications.

Contents1 Real-time ready business applications ...................... ............................ ................... 3

1.1 Instant display, faster decisions ..................... ........................... .................... ........ 3

1.2 Real-time channels, better communication ......................... ............................ ..... 3

2 Problems with existing application platforms ......................... ............................ ..... 4

2.1 The Request & Response paradigm ....................... ............................ ................... 4

2.2 Working around the Request & Response paradigm .......................... ................... 4

2.3 Evented networking a new foundation ..................... ........................... .............. 5

3 Costs and risk of changing an application platform ......................... ......................... 6

4 Extending existing applications with a Web Message Broker ........................... ........ 7

5 Deployment options for Web Message Brokers ........................... ............................ 8

5.1 Cloud Service ............................ ...................... ............................ .................... ..... 8

5.2 Installed Software ........................ ...................... ............................ ................... ... 9

5.3 Virtual Appliance .......................... ...................... ............................... ................... 9

6 Tavendo WebMQ An enterprise Web Message Broker virtual appliance ...... ...... 10


3/10

T

1 Real-time ready business applicationsThe environment in which today's companies operate is changing ever more rapidly. Aglobalized economy results in quick, often fundamental shifts in markets. Both the rate

of technological change and the rate of adoption of these changes keeps increasing.

Customers and clients, with their fast-paced lives and accustomed to instant

information dissemination, expect ever faster reaction times from businesses.

To stay successful in this environment, companies need to bring all aspects of their

business up to speed. They need to update their operational processes, corporate

strategies and business models quickly in response to changes in the market.

This speeding up the enterprise requires a move to collecting, processing and

distributing data in real-time. Current information needs to be immediately accessible

to users, and these need to be able to share insight and coordinate responses instantly

and with minimal friction.

1.1 Instant display, faster decisionsWith today's pervasiveness of computer technology, the collection and processing of

information just as it arises is increasingly the norm. Computerized workflows, a

proliferation of connected sensors, and the spread of mobile terminals mean that few

events are not registered electronically as they occur. Back ends are now being

engineered to process this information immediately, allowing constantly updated

analysis. Fully utilizing this stream of information requires that the results of this

instant processing are accessible in the front end in the business applications.

Reaping the benefits of real-time information demands real-time display of data.

Eliminating the time-delayed nature of traditional data displays enables users to

directly view the current state of the business. They can see changes as they happen,

instead of limiting them to static snapshots updated infrequently or even only

manually. This allows immediate detection of trends, developing problems and

opportunities, leading to faster and more informed decisions

1.2 Real-time channels, better communicationIn a networked company, acting fast on information also means communicating faster

and more efficiently with coworkers. Real-time features embedded within business

applications play an important part in achieving this.

Activity streams help orient users about what their coworkers are doing, giving context

and background that helps ease coordination. Presence indicators allow

communications to be initiated at opportune times, and via a suitable channel. Instant

messaging adds a channel that is more immediate than email, does not require the full,

exclusive attention of a phone call, and is easily open to multiple simultaneous

participants. Collaborative whiteboards or document annotation increase the


4/10

T

bandwidth of communication, permitting cooperation at a level that previously

required face-to-face meetings.The embedding of real-time features directly into business applications allows a

communications infrastructure in which friction for sharing is reduced, and information

is exchanged immediately when needed.

2 Problems with existing application platformsThe basic paradigm that traditional Web applications are based on is limited, and a

change of paradigm is needed to extend these application with real-time features.

2.1 The Request & Response paradigmWeb applications are based on a server-client model. Within this relationship,

interaction is based on a request & response paradigm. Requests for information by the

browser client are answered by the server.

The first evolution of Web applications from just a display of completely static web

pages to the inclusion of client-side logic in the browser has not changed this model. It

gives the client powerful abilities to locally process and react to user input, enabling

fast client-side interaction. However, changes to data on the server are still only

received as the result of a client request. In applications employing the request &

response paradigm, the server cannot push data to the client.

2.2 Working around the Request & Response paradigmThe limitations of existing web technology have led to a multitude of work-arounds

that attempt to simulate the push of information and overcome the limitations of the

Request & Response paradigm. Being based on that paradigm, they all need to employclient-side initiated connections to do so.

The simplest variant, supported in principle on any existing platform, is frequently

polling the server.

Browser Web Server

Browser Web Server

Request

Response


5/10

T

In practice implementations of polling face significant problems. High-frequency pollsby large numbers of clients cause high network loads, especially due to the fact that the

HTTP protocol has a large header overhead. While this may often be less significant on

intranets, the server load these massive numbers of connections used in polling result

in leads to problems.

Browsers request pages or resources from a web server only as needed, i.e. quite

infrequently. Web servers are optimized for serving the requested resources as quickly

as possible. Polling raises the frequency of requests to levels that is orders of

magnitude above that for a regular Web client. This can quickly exhaust the available

resources on the server.

High-frequency polling by clients also causes massive numbers of requests to back-end

databases that have to provide the data to fulfill these requests, quickly bringing these

system to their limits.

Modifications to the polling model tweak the handling of responses, delaying them

until a change in the requested data has occurred (long-polling), or delivering

responses in increments, never closing the connection (HTTP streaming).

These modifications to basic polling require support from the platform and

infrastructure the Web application runs on, and only serve to reduce the latency in

transmitting information. None of them addresses the problem of server load because

of the number of open, long-lived TCP connections, or of the demands on back-enddatabases. All work-arounds based on the request & response paradigm dont scale on

classic web server platforms built for request & response.

2.3 Evented networking a new foundationReal push by the server in Web applications requires a different design from the

request & response paradigm: a connection that allows the server to initiate the

sending of information.

This has led to the design of a new protocol, WebSocket, an IETF standard with full

support in all modern browsers. WebSocket is engineered from the ground up for the

real-time web: Persistent, long-lived connections and low latency allow information tobe transmitted immediately, and a low overhead per sent message reduces the

network load. It is bi-directional, so that sending of information can be initiated both by

the client and the server.

This new type of connection, which enables client and server systems where

information may be sent by either party at any time, requires a different server

architecture, based on evented networking.

On the client side, in the browser, the asynchronous programming that evented

networking requires has always been present because of its necessity for event-driven


6/10

T

user interfaces. With WebSocket support built in, browser clients now naturally also

support evented networking.

On the Web server side, in the majority of cases evented networking and asynchronous

programming is not part of the platform. At the networking level, the change from

supporting large numbers of requests over short-lived connections to large numbers of

persistent connections with bi-directional communication requires a fundamentally

different design. Adding real-time abilities on a production scale cannot be done by

adapting existing server-side application code it requires a different application

platform. In most cases this also requires a rewrite of the application.

3 Costs and risk of changing an application platformAny rewrite of existing software poses significant challenges and risks as well as

requiring a sizable investment.

A rewrite to include real-time features has to meet additional challenges:

Adding support for WebSocket does not mean just adding another protocol. It also

requires support for a large number of persistent concurrent WebSocket connections.

Conventional Web servers are not built to support these. The ability to handle these

numbers of connections necessitates deep changes to the server platform, down to

modifications how the OS's networking API is used. The common model of having one

processor thread per TCP connection needs to be exchanged for a model that allows

single threads to serve thousands of connections. This means either extensive

modifications, or, more often and realistically, a change of the server platform.

Asynchronous programming, needed to handle evented networking, is a new paradigm

when it comes to Web servers. Adopting this technology in the course of a rewrite of a

business application necessitates acquiring expertise in this field in-house in the course

of the project, or find specialist external support.

Classic Web applications request information when needed, and the server only needs

to respond to these requests. With push there is a need for server-side logic to handle

administration of the clients and to ensure the information is pushed to the correctrecipients. Implementation of this logic requires a significant additional effort on top of

redesigning the existing application to handle the real-time push itself.


7/10

T

4 Extending existing applications with a Web MessageBroker

Extending existing Web Applications with real-time features means finding a solution to

the basic challenge that traditional web servers cant push to a client, and to do so in a

way that does not require changing the application platform or changes to the existing,

functioning core of the application.

Adding a Web Message Broker as an external component fulfills these requirements.

The Web Message Broker only mediates the connections that relate to the real-time

information. Existing communication between the browser client and the server

remains unchanged, and all present application functionality continues to function as

before.

The Web Message Broker is connected to both the client and the server:

The browser as a client initiates the connection to the Web Message Broker. This

connection is based on WebSocket, and thus bi-directional. The Web Message Broker

can actively push information to the client over the connection. The functionality for

WebSocket is already built into the browser, and the client connection to the Web

Message Broker can thus be easily established.

The connection between the Web application server and the Web Message Broker is

via a REST API. In this context the Web application server acts as a client and initiates

the connection. On the Web server side, existing technology for establishing outgoingHTTP connections is utilized. The push occurs in real time, since the Web server

initiates the sending of the information. The information is sent just once to the Web

Message Broker, irrespective of the number of connected clients, avoiding problems

with large numbers of concurrent TCP connections.

The burden of maintaining these large numbers of concurrent connections and

dispatching massive numbers of messages to the clients is shifted to the Web Message

Broker which is optimized for this purpose. As a specialized application, the Web

Message Broker further provides all the logic for administration of the client

connections and ensuring the correct message distribution.

Browser Web Server

HTTP

Message

Broker HTTPWe

bSocket


8/10

T

5 Deployment options for Web Message BrokersOne basic differentiation between Web Message Brokers is how the functionality isdelivered. In addition to the traditional model of software installed by the user, there

are now also cloud services and virtual appliances. With very distinct advantages and

disadvantages to each, selecting the deployment model may be a first necessary choice

when looking for a Web Message Broker.

The optimal deployment model depends on various factors. The fitting solution has to

be determined for each use case, based on the specific requirements.

5.1 Cloud ServiceFor many businesses, cloud services have quickly turned into a viable choice for the

delivery of software functionality. With a cloud service, the Web Message Broker

software is run by the service provider, and accessed via the internet. For an

application such as a Web Message Broker, which only interfaces via the network, this

is, in principle, a natural and unproblematic model.

Cloud services offer obvious advantages concerning ease of deployment. There is no

necessity to install or configure the software, to apply updates, or to keep the server

hardware running. Starting to use a cloud service is as easy as signing up for an

account, entering payment details and starting to push messages.

With the monthly plans that most services offer, and which are usually in some waytiered according to usage of the service, there is very little or no upfront investment,

enabling low-cost small-scale test deployments, and easy ramping up to full-scale

usage.

Depending on priorities and requirements, these advantages may be outweighed by

inherent problems this model brings with it.

All operational control lies with the cloud service provider. There is a complete

dependence on his efforts to ensure the availability and the quality of the service. And,

as in any fast-developing new field of business, the continued existence of the service

provider may not be a given.

The routing through the internet and through the servers of the service provider

introduces problems regarding data privacy and security. The data necessarily leaves

the control of the company.


9/10

T

The consequences depend on the types and importance of the data and the regulatory

environment of operation. The risks involved with transmitting core non-payment userdata may be acceptable for an online gaming company, while any data leaving the

company at all may not be legally permitted in a tightly regulated field such as health

care or financial services.

While the cost structure of cloud services allows for low initial investment, calculating

future cost may present considerable uncertainty in cases where no initial prediction of

messaging volume can be made, or for businesses that operate in fields with very

volatile demand.

5.2 Installed SoftwareThe classic setup for any business software is to install and configure it on companyservers. Traditionally this was on local dedicated or shared hardware, but hosted

servers and hardware virtualization are now additional possibilities.

This setup gives full control over all aspects of the deployment, from the hardware

platform to the network connection. The installation can be configured and optimized

to suit specific the specific requirements of the use case. Availability and quality of

service can be assured. Depending on the chosen solution, messages can be

transmitted entirely in-house via an intranet, or the infrastructure can be extended to

the internet. Control over the data can be retained even then, be it via VPN or TLS.

External access to the data can be fully prevented.

The flipside of full control is having to manage all aspects of the software deployment.

Servers may need to be purchased and maintained, and the software installed and set

up on them. This can be a demanding and lengthy process, including debugging

software or hardware incompatibilities, and optimizing the entire system for safety and

performance. It may even necessitate the use of outside expertise. Updates need to be

applied throughout the lifecycle of the software, and bring with them the possibility of

new incompatibilities and problems across the entire system.

With commercial software, a fixed price for the functionality is usually given, enabling

precise advanced financial planning. This purchase price for the license often

represents a significant upfront investment before the validity of the solution has been

proven.

5.3 Virtual ApplianceA virtual appliance is a specific form of delivery for software which significantly reduces

the setup and maintenance problems of installed software.

With a virtual appliance, the entire software stack is delivered as one: the application

with all its dependencies as well as the operating system it runs on. This is packaged as

a virtual machine image, pre-installed and set up. The appliance is downloaded,

imported into the virtualization platform of choice, and run.


10/10

T

This eliminates not only complicated and error-prone installation processes, but it

enables the delivery of a system that only contains necessary parts. This system can be

optimized for performance and security, and eliminates hardware and software

incompatibilities. Updates are delivered for the entire appliance, so there are no

update problems through untested local incompatibilities.

A virtual appliance delivers the control and data privacy of installed software without

the hassle for actual installation and setup.

6 Tavendo WebMQ An enterprise Web Message Brokervirtual appliance

With WebMQ, Tavendo offers a Web Message Broker that is delivered as a virtualappliance.

A primary design goal was enabling to extend existing Web applications with real-time

functionality. WebMQ has a wide feature set, such as handling client authentication,

rights management for clients and servers and built-in DoS protection. It offers easy

administration via a graphical appliance Web UI that can be run in any browser.

For more information, and to see whether Tavendo WebMQ fulfills your specific needs

for a Web Message Broker, visit http://tavendo.de/webmq.

Dependencies

OS

Application

Virtual Appliance

Virtualization Layer

Shared Hardware Resources

Dependencies

OS

Application

Update

the real-time web - speed up your enterprise

Documents