RSBA Technology

This is the second in a series of blog posts covering key insights gained whilst working on design of low-latency high-volume distributed trading systems, focusing on the messaging middleware layer.

Topology By Configuration

SOA systems are defined by multiple endpoint-to-endpoint connections, bridged by a variety of intermediary brokers, gateways, bridges etc. For example, 29West uses WAN Gateways to bridge local multicast network traffic across data centres via more reliable TCP transport. Other examples include any broker – orientated messaging topology (e.g. Active MQ etc). The Open Source community is also starting to address this space with products such as RabbitMQ and ZeroMQ.

The messaging topology should be defined by configuration as far as possible. The configuration, controlling mechanisms such as topic subscriptions, list of publication topics, and topics to bridge across Gateways, should be deployed as an overlay; managed as a separate artifact to the application software. This provides several benefits:

• By centralizing implementation of messaging topology into a deployable artifact in its own right, it supports the programme – level management of the topic space itself (see above).
• Changes can be made rapidly in development and testing environments.
• Production messaging topology is put under same version control mechanisms (with rollback etc) as the application code itself.
• Supports development of management, monitoring and visualization tools - Comments: 0

RSBA Technology Ltd has provided consulting services to Tier 1 and 2 Investment Banks since 2009. Our focus has been on analyzing the requirements and project managing delivery of complex, multi-site real-time low-latency, high-capacity trading and workflow management systems for eFX businesses within the Bank’s Global Markets areas. In the course of this work, and in many years of experience prior to forming the Company, we have gained valuable insights and knowledge on how to effectively design, develop and deploy such systems in a highly competitive landscape.

This series of blog postings highlights some of these key insights related to the design of distributed trade workflow systems, in the context of low-latency, high-volume processing environments.

Service Topic Name Management

In a Pub / Sub – based SOA (Service-Orientated Architecture) architecture, different Service Components will be subscribing to subsets of data published within the system. Messages of specific content types are associated with specific Topics. Topics are used to determine which messages are processed by different Component types and instances (e.g. “FX.Spot.EURUSD” or “Exception.FIXGateway”).

To ensure the long-term expandability of the architecture, the topic namespace itself must be tightly controlled both technically and managerially. Although a SOA architecture supports low-coupling between Components and their respective development teams, it is essential that all current Components unambiguously define the topics of published messages, and register interest in receiving messages. Failure to so from day 1 leads to propagation of hacks and workarounds that materially impact the ability of the system to scale according to business demand.

A managed topic schema should be defined and published right at the start of the development of the SOA system; or should be retrospectively implemented in an existing system. This can be hierarchical, based on domain delimiters, with a “root” schema defining the overall structure and standards for developing sub-domain topic spaces by different teams below that.

Effort must be put in to model all the likely messaging paths and use cases between Service Components, and used to draw up a Topic Schedule. This should be maintained by a Design Authority as an important lifecycle artifact, and all development teams be made responsible for complying with the topic schema standards.

The topic identifiers, however structured, should not be directly exposed to the application layer. This allows:

1. Changes to the topic structure, and thereby the routing of messages, that is transparent to applications and business logic.
2. Inclusion of additional topic identifier sections required by the higher-level “Bus” functionality, such as component resiliency.

A possible message topic schema could incorporate the following elements within it:

1. Root domain (e.g. “FX”, “IR”, “Control”, “Exception”)
2. Publishing Component Identification (component type and instance information, should provide enough info to trace message originator to a specific process, such as physical location).
3. Business Partition (Logical description of message contents and / or channel)
4. Additional Parameters (additional flags and labels related to message routing, used for message subscription / forwarding purposes) . - Comments: 0

Welcome to our new website, powered by wikidot. Having all the content in one place, editable online, should ensure updates are more frequent than previously!

The Specification Cookbook still has pride of place in its own section; we are currently transferring and refreshing the existing material across from the previous host. - Comments: 1