Web Messaging Architectures

This section describes the architecture of typical Solace Web Messaging systems.

Internal Web Application Deployment Architecture

In the following figure, server applications within the data center communicate with each other through an internal messaging system—the Solace PubSub+ messaging infrastructure—in the normal distributed systems manner. These applications can be written in Java, .NET, C++, or other convenient languages, and the messaging system provides services such as pub/sub, request/reply, and various messaging qualities of service such as persistent and non-persistent messaging.

Desktop users can use traditional thick GUI in .NET or Java to interact with the back end server applications to request information, perform transactions, and receive real-time streaming updates.

With Web Messaging, mobile and browser-based applications can also connect directly to this same messaging platform without requiring an additional web fan-out tier between the browser/mobile and the internal MOM. This allows organizations to take advantage of the many benefits of web UI technologies, such as zero-footprint application install and ubiquitous deployment, within their organization using a clean and simple architecture.

The user accesses the web application by clicking a link or entering a URL on their browser or starting a mobile application. For browser-based applications, the browser performs HTTP GET operations to download the web application (for example, JavaScript). The web application and any static content are served from a standard web server and not by the event broker to allow maximum flexibility in managing and deploying applications.

The web application in the browser or mobile device uses the JavaScript API to connect and authenticate to the event broker, and all real-time communication with the server applications goes through the event broker not the web server.

The JavaScript API automatically uses the most efficient communication transport allowed by both internet intermediaries and the browser/mobile without needing any intervention from the application. See Web Transport Protocols more information on web transports.

Since Solace Web Messaging supports Cross Origin Resource Sharing (CORS) and Adobe’s cross-domain policy, the web server that downloads the application need not share the same DNS name as the event broker, and no reverse proxy is needed between the browser/mobile and the event broker. See Cross Origin Resource Sharing – CORS for more information on CORS and Same Origin Policy.

Once authenticated, the web application uses its JavaScript API to communicate directly with the event broker to register topic subscriptions and receive messages published on those topics from any publisher.

The same JavaScript is used to send a request to back end services and receive the reply to this request.

Internet-Based Web Application Deployment Architecture

This section describes how internet-based browser and mobile users can access internal applications.

As shown in the following figure, external browser users download web applications over the internet by clicking a link or typing in a URL. The web application is dynamically served by a web server typically within the Demilitarized Zone (DMZ) of Company A. These web applications use a Solace Web messaging API to connect to an event broker inside Company A, and subscribe to topics of their choice to receive streaming updates or engage in a request/reply interaction with some back end application in the data center of Company A. This real-time streaming connection may need to pass through various internet intermediaries such as HTTP proxies, firewalls, and HTTP load balancers. This is all handled by the Solace JavaScript API without intervention by the application developer.

Although not technically required, event brokers providing messaging services to external/internet users are typically deployed within the DMZ as a result of enterprise security practices. The DMZ appliances are then configured to be peered with the intranet event brokers so that communication can be both automatically and securely performed between server-based applications and external web applications.

Multiple event brokers are typically deployed within the DMZ for fault tolerance and load balancing purposes. Session Load Balancing to DMZ Appliances describes how to load balance sessions to event brokers and Network-Level DMZ Connectivity Architecture explains network architectures used in the DMZ.

The topic routing protocols that run between the event brokers allow automatic discovery and dynamic propagation of client topic subscriptions for both publish/subscribe and peer-to-peer message exchanges. Thus, the only messages flowing from the intranet event brokers to the DMZ event brokers are those for which there is at least one interested internet user, which reduces total bandwidth requirements and load.

Messages are fanned out to internet users by the DMZ event brokers based on subscription interest. Similarly, messages from internet users can be sent to internal applications (typically a request/reply message exchange pattern) and these messages are routed (and perhaps load balanced) by the event brokers to the correct server application based on the topic in the message, with the reply routed back to the requesting internet user.

If transport security is required by the web application, Secure Sockets Layer (SSL) encryption is performed by the Web messaging API using the facilities of the browser or mobile operating system. This SSL connection is typically terminated at the external firewall of Company A. This allows all internet security (for example, certificate management, Denial of Service (DoS) attack prevention, access controls) to be managed from a single point in the infrastructure (because messaging is typically just one of many internet services).

Using Solace Only for Web Messaging

The following figure shows how Solace Web Messaging can be used with an existing non-Solace intranet messaging system.

In this case, a software messaging adaptor or bridge must be implemented that uses the messaging API of the internal messaging system on one side, and a Solace messaging API on the other side, to bridge communications between the two messaging systems. Web applications communicate with the Solace DMZ event brokers using Solace JavaScript APIs. The messaging adaptor transforms messages to and from the internal messaging system to allow bi-directional communication.

Cross Origin Resource Sharing – CORS

Cross Origin Resource Sharing (CORS - http://en.wikipedia.org/wiki/Cross-origin_resource_sharing) is a web browser technology specification that defines ways for a web server or a device like the event broker to allow its resources to be accessed by a web page that was served from a different domain/web site. It provides a way to create a web application that uses the resources of multiple web sites in a Web2.0 manner.

The event broker supports CORS for JavaScript. CORS support on the event broker allows a web application retrieved from a web server using one URL to access the event broker using a completely different and unrelated URL without requiring an intermediate reverse HTTP proxy, as shown in the figure in Internal Web Application Deployment Architecture.

Without CORS support, browsers adhere to the Same Origin Policy (http://en.wikipedia.org/wiki/Same_origin_policy) which prevents a web application served from one (web) site from accessing resources of a different (web) site due to security concerns.

Web Transport Protocols

Raw TCP cannot be used from browsers and cannot pass through HTTP proxies and other internet intermediaries. HTTP must be used in these situations. Before the advent of WebSockets, the HTTP protocol and its support in browsers and internet intermediaries did not natively support asynchronous, bidirectional communication between a web application and a web server, as is required by messaging applications. HTTP only supports client initiated request/reply. Various techniques need to be applied to be able to support asynchronous bidirectional communication over an HTTP transport. These techniques vary based on the client runtime and feature support in intermediaries. Solace Web Messaging handles this automatically for applications so application developers can be free from needing to worry about such transport complexities and can instead focus on their business application.

Solace Web Messaging automatically determines the most efficient web transport protocol to use to carry messages to/from a browser or mobile application when the session is connected by the application. The most efficient transport protocol used in any particular situation depends on a combination of the runtime container (browser type and version, mobile framework, mobile OS) and any internet intermediaries (proxies, load balancers, firewalls). Internet Explorer 8 and 9, for example, do not support the WebSocket protocol for JavaScript applications so only a Comet/Long Polling transport can be used. Chrome, Safari, and other modern browsers allow the Solace API to use WebSockets to provide a more efficient transport from the event broker to the browser/mobile.

The “best” transport to use is automatically determined by the JavaScript API without the application needing to be involved, although the application can choose to influence this using the transportProtocol session property. Applications can determine which transport protocol is currently in use by a session by querying the transportProtocolInUse session property. Similarly, the protocol in use for a given connection can be viewed from the event broker using the show client <name> web-transport CLI command.

The web transports supported by Solace Web Messaging are listed below in order of most efficient to least efficient. In all cases, the transport channel can be SSL encrypted or clear text as directed by the application when the session is established.

WebSockets – WebSockets is a wireline protocol defined in IETF RFC 6455 as well as a browser API defined by W3C. Applications using Solace web APIs do not use the WebSocket API, rather the Solace API uses the browser’s WebSocket API (when available) to produce the WebSocket wireline protocol interactions with the event broker and applications use a Solace Web Messaging API. WebSockets is the most efficient and lowest latency web transport. Guaranteed messaging requires the use of Websockets. Direct messaging can use any of the listed web transports.

HTTP Streaming – HTTP Streaming is a form of long polling where HTTP Chunked Transfer Coding (see RFC 2616) is used by the event broker to send a stream of Solace messages from the event broker to the web client without needing to terminate the HTTP response. It is therefore more efficient than Comet for streaming data to web clients.

HTTP Comet Binary – HTTP Comet is a simpler form of long polling, which is used when a more efficient transport is not available. In this mode, multiple Solace messages can be packed in a single HTTP interaction however the HTTP reply from the event broker is not long running as with HTTP Streaming – it is terminated with each group of messages sent to the web client and a new HTTP long poll is applied by the API. In the Binary mode, the payload remains as binary data for increased efficiency.

HTTP Comet Base64 – This mode of Comet is the same as HTTP Comet Binary except that the HTTP payload is Base64 encoded due to the fact that some older browsers do not support binary HTTP payloads.

Support for the different transport modes across Solace messaging APIs is shown in the following table.

		Web Transport
		WebSockets	HTTP Streaming	HTTP Comet Binary	HTTP Comet Base64
Web API	JavaScript
	Node.js
	iOS
	.NET
	C
	Java RTO
	JCSMP

Multiple Applications Sharing the Same Infrastructure

In some cases, especially for private cloud infrastructures, there are several distinct applications that require web messaging. In this case, as shown in the following figure, service can be provided to these multiple applications on the same shared Solace infrastructure using a feature called Message Virtual Private Networks (VPNs).

Message VPNs provide a method of virtualizing an event broker so that multiple application groups can share the same physical event broker while still being isolated from each other, like Virtual Local Area Networks (VLANs) on an Ethernet switch.

The following figure shows an example of three applications with server applications and web clients sharing the same DMZ and internal messaging infrastructure. Each application is deployed within its own Solace Message VPN which spans both the DMZ event brokers and the internal event brokers as a result of the Solace routing protocols.

Back end server applications connect into their own Message VPN and offer streaming data or request/reply services using topics that are only accessible by applications in this same Message VPN.

When web applications establish a session with an event broker in the DMZ, they provide their Message VPN name along with their username and password. This locks them into a virtual partition of the event broker specifically for their application, allowing them to communicate only with the back end processes that are providing service for this application but no others.

Session Load Balancing to DMZ Appliances

The format of URLs used for Web Messaging is completely determined by the system architect.

When Web Messaging is deployed for access by browser or mobile applications within an enterprise, as in Internal Web Application Deployment Architecture, there are no additional considerations.

When Web Messaging is deployed for internet access, as in Internet-Based Web Application Deployment Architecture, information about these URLs must be configured on both the event broker and the HTTP load balancer to allow the system to

load balance new Web Messaging sessions among the several event brokers in the DMZ, and
ensure that HTTP requests from established messaging sessions are routed in a “sticky” manner to the same event broker that received the session initiation request.

The event broker is configured via the web-url-suffix command. Example configuration for an F5 Big IP firewall is provided in Using F5 Big-IP as a Load Balancer for External Internet Connectivity.

The URLs to consider and associated rules are:

URL used to get the web application
Format: https://<hostname>/<download-my-app-from-server>
This URL is the one used by the user to “GET” the browser application. Because the event broker does not serve static content to browsers, this URL must be served by a separate web server as shown in the figure of Internal Web Application Deployment Architecture. This URL does not apply for non-browser applications. This URL is visible to the application user.
For example: https://my-company.com/download-my-sdp-application
URL used to initiate the messaging session
Format: https://<hostname>/<application>
This URL is not seen by the application user, but is provided by your web application to the JavaScript API through the url session property. This URL identifies a set of possible event brokers to connect to.
Configuration of the external load balancer for this URL must allow incoming sessions to be load balanced among the IP interfaces of applicable DMZ event brokers for that application. For example, referring to the figure in Network-Level DMZ Connectivity Architecture, to load balance sessions for <application1> among both event brokers in the DMZ, this URL needs to be mapped with a load balanced distribution method to all of (IP-2 to IP-5) and (IP-7 to IP-10).
For example: https://my-company.com/my-sdp-application
URL used after messaging session initiation
Format: https://<hostname>/<application><web-url-suffix>
This URL is not seen by the application user or your application. It is used by the JavaScript API to send subsequent HTTP requests to the specific event broker that received its session initiation request. This provides a “sticky” communication between this API session and the particular event broker.
The “web-url-suffix” value is configured on each DMZ event broker using the “web-url-suffix” command within the “web-transport” configuration. Cookies and other such mechanisms are not used to provide session stickiness since these can be disabled in browsers.
The web-url-suffix configuration rules are:
1. The “web-url-suffix” value must uniquely identify a particular event broker among all other DMZ appliances (for example, the hostname of the appliance) to effect session affinity.
2. The suffix can be any valid URL suffix syntax, but for convenience and readability is often in the form of a URL parameter (for example, “?appliance=Prod-DMZ-123”).
3. As part of the session initiation process, this suffix value is returned by the event broker to the JavaScript API and then used by the API in subsequent HTTP requests for this API session. No application involvement is required.
4. This URL must be configured on the external firewall to map to only the IP addresses of this particular event broker, but it can map to any or all of the externally-facing IP interfaces. For example, referring to the figure in Network-Level DMZ Connectivity Architecture, the “web-url-suffix” for the left-most appliance could map to all of IP2 through IP5.

In summary, the “web-url-suffix” is:

determined by the system architect to uniquely identify an event broker in the DMZ
configured on the event broker through the “web-url-suffix” command
configured on the external firewall along with the application URL root to map to the IP addresses of the specific event broker
completely invisible to the application

Provide feedback