Messaging #1 - Service Topic Name Management

1310981705|%e %B %Y, %H:%M
Tags messaging

Back to list of posts

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

Add a New Comment
