Web Messaging Overview

Solace Web messaging provides the ability for applications in browsers and mobile devices to receive real-time updates of information pushed to them asynchronously from server applications in a data center over a web infrastructure composed of HTTP proxies, load balancers, and firewalls. It also allows browser and mobile applications to perform request/reply and other message exchange patterns with datacenter applications.

Web Messaging is frequently used to provide a real-time, dynamically updated user display of information for applications such as:

displaying foreign exchange currency spreads in a Single Dealer Platform
displaying equity stock prices for retail equity brokerages
updating bids for an online auction
updating the real-time location of a moving object on a map
online chat applications
sending status alerts about a condition of interest

In these use cases, the real-time information is dynamically sent by a server application in the data center and received by all browser and mobile clients interested in, or subscribing to, this information no matter what the internet connectivity is between the server applications and browsers or mobile devices.

What is Solace Web Messaging?

Solace Web Messaging is a data movement infrastructure composed of software Application Programming Interfaces (APIs) in various languages and the Solace PubSub+ event broker. Together, they form an application-to-application messaging fabric that allows server-based applications in a datacenter to communicate with each other as well as with browser and mobile applications over a web infrastructure of proxies, firewalls and HTTP load balancers.

This infrastructure can be used for two main types of applications:

To asynchronously stream real-time updates to internet client applications for applications such as financial trading, gaming, betting, auctions, taxi and bus location alerts.
As an alternative to traditional web infrastructures to enable server, browser, or mobile applications to interact with each other using a single uniform messaging paradigm. This is as opposed to using messaging between server applications and web forms, JSPs and servlets between web components which in turn use messaging toward the server applications. This is quickly becoming an attractive architecture as browser and mobile applications become more demanding, their devices become more powerful, and there is an increasing need for device independence.

Support for rich messaging features, built-in high availability, robustness controls and the ability to connect 200,000 concurrent client sessions on a single event broker make this an ideal infrastructure for large-scale mission-critical web applications.

Browser and mobile applications use APIs in JavaScript/HTML5 running in any modern browser (such as Chrome, Safari, Internet Explorer, Firefox) to communicate through messaging directly with server-based applications in the datacenter. This is as opposed to using XHR to send HTTP commands to a web server, which then relays them on to server applications.

A key advantage of Solace Web Messaging over standard HTTP is that it allows server based applications in a datacenter to asynchronously send real-time updates to browser and mobile applications over a web infrastructure. Web transport techniques (known as Comet, Long Polling, HTTP Streaming, HTTP Push, and WebSockets) are used by the event broker and Web messaging APIs to provide asynchronous updates to HTTP client applications.

However, Solace Web Messaging provides far more than this. It provides a complete topic-based, publish/subscribe messaging fabric with ubiquitous reach between browser/mobile applications and server applications without needing any other infrastructure or bridging software. No web streamers, no web servers, no gateways to integrate with other messaging systems.

Web Messaging can be used to provide connectivity to browser and mobile apps both within an enterprise, as well as over the public internet.

As shown in the following figure, Solace Web Messaging both in the DMZ toward the internet combined with Messaging Oriented Middleware (MOM) services provided by event brokers inside the datacenter support this ubiquitous application messaging fabric.

With Solace Web Messaging, both the server and web applications benefit from a functionally rich messaging API and message system capabilities that can be used by applications whether inside the data center or over the internet. The Solace architecture allows application designers to seamlessly extend the reach of their server-based applications not only to desktop users within their intranet, but also to customers, employees and partners over the internet through desktop and mobile applications. Extending an integrated messaging paradigm all the way to browser and mobile applications with a single infrastructure allows architects and developers to focus on their business problem rather than the plumbing of application communication.

Programming Model with Solace Web Messaging

Solace Web Messaging can be used by mobile and browser applications instead of typical XHR GET/POST operations to perform all interactions with back end server applications – and for message exchange patterns not supported by HTTP.

Browser, mobile, and server based applications all use Solace messaging APIs in the language of their choice to first establish a session with an event broker. As part of establishing a session, the client application authenticates to the message bus using username/password which the Solace PubSub+ appliance validates against either its internal or an external identity management system.

Once a session is established, publishing applications can send messages addressed to “topics”, and consuming applications can subscribe to topics to receive the messages of interest without connecting directly to the publishing application or knowing anything about the publishing application. As such, once the web application in JavaScript is downloaded to a browser, all interactions with back end systems can be done using the Solace messaging API. Whether to receive real-time updates or to perform request/reply interactions with back end services, thereby replacing the typical HTTP GET/POST methods to web servers, Solace Web Messaging can be used to provide uniform access to any service from any channel/device.

For example, topic-based messaging is what is used by the Java Message Service (JMS) specification, and is widely used by Message Oriented Middleware (MOM) products, including those offered by Solace. This topic-based messaging paradigm is more powerful than the semantics of HTTP as it can be used for:

Publish/subscribe (that is, one-to-many message exchange patterns) where the topic of a message indicates the type of data being carried, such as a bid or ask for a particular equity symbol or a foreign exchange currency pair. This information is asynchronously published in real time by a back end application within the data center. It is typical for such a message to be delivered to multiple consuming applications either inside the enterprise or over the internet. These updates allow Graphical User Interfaces (GUIs) to provide a responsive, real-time, dynamically updating display of relevant information.
Point-to-point request/reply interactions where one topic indicates a well-known “service” that is to handle the request, and another topic uniquely identifies the requestor to whom the reply is to be sent. These applications can then communicate “point-to-point” without needing to establish a connection to each other. This message exchange pattern can be used, for example, to query the status of a trade, or retrieve a stock price chart, or verify the status of a payment or an auction bid.

In typical web applications, point-to-point request/reply interactions are accomplished using normal HTTP GET/POST commands sent from the browser into the web server tier, which could then either:

do a database lookup directly, or
(more typically) translate this request into some internal format that is then sent toward the back-end application tier through a messaging system. The messaging system reply is correlated with the original HTTP GET/POST request by the web server and sent back to the browser.

In the Web Messaging model, the heavy processing and integration in the web tier is removed in favor of intelligent front-end applications that know how to send messages on well-known topics, which are then routed in a loosely coupled manner by the Solace messaging system to applications in the back end. With the advent of web applications that are more intelligent and feature rich than static HTML, using a messaging-based application architecture is much more efficient than using web servers to perform data conversion for all the same reasons that messaging has long been used by thick client front ends.

However, dynamically updating information is much more difficult for traditional web applications to support due to the client-driven request/reply nature of the HTTP protocol. This type of asynchronous, streaming of real-time messages is a key problem solved by Solace Web Messaging.

In practice, browser-based Web Messaging applications typically use a combination of the following techniques:

HTTP GET operations to a traditional web server to download the browser application (for example, JavaScript), as well as any static data, such as forms and images.
Web Messaging to subscribe to and receive asynchronous updates from server applications.
Web Messaging to submit requests for data or processing to back end server applications. For example, to buy or sell securities, bid at an auction, or download a graph that will be dynamically updated.

Web Messaging is also well suited for mobile applications wishing to receive real-time updates where the more traditional HTTP/HTML/XML environment may not be as convenient for request/reply interactions.

In addition to pure communication and connectivity, Solace Web Messaging provides many features typically required by real-time streaming applications such as:

data access security controls
per-client rate limiting
prioritized message delivery
runtime-independent and self-describing data types for cross-platform interoperability

Publish / Subscribe Message Exchange Pattern

One capability that Web Messaging provides that cannot be accomplished with standard XmlHttpRequest() is real-time streaming to a browser – also known as HTTP Push. This type of 1-to-many message exchange pattern is typical of publish/subscribe messaging systems and is often used in stock or FX front ends as well as in chats, online betting and auctions.

With Web Messaging, browser and mobile applications use a Solace API to dynamically subscribe to (and unsubscribe from) the hierarchical topics of their choice, even using wildcard subscriptions, to allow messages published on only those topics of interest to be asynchronously delivered to the application. These applications do not need to worry about the transport mode, about message delineation and marshalling and subscription management – this is all done by the Web Messaging infrastructure.

Request / Reply Message Exchange Pattern

In addition to asynchronous publish/subscribe messaging, Solace Web Messaging can be used to perform request/reply message exchanges to get information from or send information to server applications similar to the way XHR is used to send HTTP GET and POST commands. For example, an application could send a message to retrieve the current state of the user’s blotter or portfolio – similar to sending an HTTP GET – with the blotter or portfolio information returned in the reply. Similarly, an application could send an order message to an Order Management System (OMS) application to buy or sell a stock and receive the status in a response – similar to sending an HTTP POST. In addition, if the order does not fill immediately, then Web Messaging can be used by the OMS to send real-time updates to the issuing client application as the order changes state with partial fills, for example.

With a Web Messaging architecture, there are no web servers or web server applications that need to be implemented, deployed and managed other than to serve static content. All application communication uses only a Solace messaging fabric as infrastructure.

Applications address request messages to a well-known topic which identifies the service of interest rather than to a well-known URL which must then be translated by a web server to an internal application name or bridged to an internal messaging system. Messages are sent using the Solace sendRequest() API method rather than using XHR. The reply, along with the associated context for the original request, is returned in a callback or delegate function provided by the application.

Applications can have several requests outstanding at any given time and the responses come in without any ordering dependencies, unlike some cases with HTTP.

Each request message is sent with a ReplyTo field which identifies who the reply is to be sent back to by the server application handling the request. This ReplyTo value, in the form of a “#P2P/…” topic, is generated automatically by the Solace infrastructure and uniquely identifies this particular API session, making it simple for applications to send requests and receive the associated reply. This default ReplyTo value can also be overridden by the application.

Provide feedback