Useful Solace Messaging Platform Features
This section describes the following key messaging features from the Solace Messaging Platform that are useful for Web Messaging use cases. This is not a complete list of features from the Solace Messaging Platform, nor is it a detailed presentation of each feature. The intent is to introduce the reader to key messaging features that may be of interest for Web Messaging applications, and then refer to the appropriate document for further information.
The Solace provides Java, C, .Net, and JMS messaging Application Programming Interfaces (APIs) for developing server-based applications, as well as source code for various sample applications to get you going quickly and easily. They provide all the information developers need to write and test server applications.
Solace routers support the ability to peer together to dynamically exchange topology and subscription information. This feature can be used to link together routers in the DMZ with those inside the intranet to:
- link DMZ routers to help reduce the flow of streaming data over the internal firewall of the DMZ
The internal routers could be in the same data center, or could be in remote data centers if required.
Subscriptions from Web messaging API clients are aggregated by the routers in the DMZ to reduce the subscription and traffic load on the internal messaging system, thereby ensuring a highly scalable solution.
Solace routers in the DMZ support the Lightweight Directory Access Protocol (LDAP) for authentication using the username and password model from Web Messaging applications. Thus, a centralized authentication repository can be used to perform all external user authentication.
This mechanism can also be used to support Single Sign On (SSO) authentication models whereby the Web Messaging application retrieves the SSO token from the SSO server and uses this token in the password field to connect to the DMZ Solace router. The Solace router uses LDAP to transfer the username/password==SSO Token back to the SSO authority to allow or disallow the login.
Per-user, per-topic customer access control rules for both publish and subscribe operations can be enforced by the Solace router by:
- using Access Control List (ACL) profiles
- implementing custom access control rules using the “On Behalf Of” subscription capability
ACL profiles are rules provisioned on the Solace routers. They are used to provide coarse-grained access control to topics based on the hierarchical nature of the topic structure. ACL Profiles contain the list of topics that a client is or is not allowed to publish to, and the list of topics that a client is or is not allowed to subscribe to. These rules are enforced by the router in real time as applications dynamically publish and subscribe. A given ACL Profile is typically referenced by multiple clients, so the rules are configured once for a “class” of user.
The “on behalf of” subscription feature allows a Subscription Manager application you write to:
- Receive all subscription requests from a set of clients.
- Then apply your own business rules to allow or disallow the subscription.
- Then add the subscription for the data “on behalf of” the client.
This feature is very useful where:
- tiered information is available, as in FX Single Dealer Platforms, and the client needs to receive the right “tier” of streaming data based on who the client is
- the number of rules and clients is very large
- the access control rules are not static
For example, in a foreign exchange Single Dealer Platform application, a client may want to receive streaming USD/CAD spread quotes, but he needs to receive the quote stream that is determined by his business tier. In this case, the Subscription Manager application, upon validating access to USD/CAD quotes, can add a topic subscription for the topic as appropriate for the business tier level of the client.
For an application example of how to use the “subscription on behalf of” feature, refer to the sample applications in the applicable server-side Solace messaging API.
In many applications where streaming quotes are to be delivered to end users, it is desirable to reduce the rate of updates to the end user to be less than the rate produced by the source—especially if the end user is human or reachable over a WAN or the internet. This is typical for both equity and foreign exchange market data.
Solace supports a feature called message eliding which allows a maximum per-topic message rate to be configured individually for each end user application. In this case, sources of market data can publish at the message rate they like, with some (perhaps internal) applications receiving the full unlimited message rate, while other applications (internal or external) can have this same message stream limited to the rate they desire—all without additional infrastructure—to ensure that these applications always receive only the most recent updates, rather than queued or outdated information.
SolCache is a software product from Solace that provides message caching and retrieval services. It caches up to a configured number of messages deep per topic for configured topics and makes them available to requesting clients. SolCache provides various plug-ins to allow customer-specific message handling – such as merging delta updates from a streaming publisher into a larger “initial image” stored in SolCache to create a complete book image from delta updates, for example.
SolCache is often used in applications such as price and odds distribution for client applications to acquire the latest value of some stock or currency pair without needing to wait for the next update message.
It is sometimes desirable to deliver high priority messages ahead of lower priority messages when there is congestion and queueing occurs. Such queueing can occur, for example, toward an internet application due to the lack of bandwidth or slow processing by the application.
For these reasons, the Solace Messaging System allows publishers to assign each message a priority which then causes higher priority messages to be delivered ahead of lower priority messages to end applications during congestion.