Skip to content

Messaging-Layer.md

Latest commit

 

History

History
98 lines (63 loc) · 7.25 KB

Messaging-Layer.md

File metadata and controls

98 lines (63 loc) · 7.25 KB

Requirements for TMI (Message Bus)

Contents

Overview

Within Trading Systems various independent ticketing, trading and order management client applications needs to communicate with TMS in a unified manner. We need an integration /service architecture that enables those applications to coordinate in a loosely coupled fashioned and provide channels in order to support different messaging paradigms.

TMI can act as message bus, which is a combination of a common data model, a common command set, and a messaging infrastructure to allow different heterogeneous systems to communicate through a shared set of interfaces.

A message bus can be considered as a universal connector between the various enterprise systems, and as a universal interface for client applications that wish to communicate with TMS and with each other. A message bus requires that all of the applications should use the TMS messaging model. TS applications adding messages to the bus may need to depend on message routers to route the messages to the appropriate final destinations.

Objectives

Main design objectives of TMI messaging interface:

  • Fast and High-Throughput : This is the top priority feature, without this capability, the system will be easily overwhelmed by flooding data continuously generated by hundreds of producers, it is expected that both enqueue and dequeue speed should be close to O(1) memory access.

  • Persistent and Durable : Any data loss should be avoided as far as possible. Also, downstream consumer can crash therefore is common,should persist messages on disk longer than the maintenance(or system recovery) window, to let backend systems continue to consume messages when they are up again. Regarding durability, TMI should ensure the persistence of the message even the service process crashes.

  • Separation of Producers and Consumers : TMI should separate messaging producers and consumers using pub-sub style exchange pattern, each one can work without knowing the existence of the others, such kind of loosely coupled architecture can make the whole system robust, horizontal scalable, and easy to maintain.

  • Realtime: Messages produced by producer threads should be immediately visible to consumer threads, this feature is critical to event based system like Complex Event Processing(CEP) system.

  • Distributed: TMIshould explicitly support partitioning messages and distributing consumption over a cluster of consumer machines while maintaining per-partition ordering semantics.

  • Multiple Client Support : TMI should support easy integration of clients from different kinds of platforms(such as C++,Java, Python, etc), it’s desirable that producers and consumers can be auto-generated from TMI service interface, by leveraging technology like Thrift RPC.

  • Flexible consuming semantics: TMI should support typical consume once queue, fanout queue, and provides more flexible consuming mechanism like consuming by index.

  • Light Weight: The footprint of TMI binary should be light, and the interface exposed should be simple and be understandable by normal user.

  • Common Data Model : usage of the underlying data model in order to communicate with various TMS domains

  • Technology Abstraction: provide abstraction layer on top of the underlying technology implementation

Underlying, TMI can expose functionality of the following components:

  1. Persistent Queue : Physical implementation of logic topic, internally use memory mapped file, automatic paging and swapping algorithm, sliding window, index based access for fast queue operation while use memory in an efficient way.

  2. Thrift based Interface : Simple RPC based API exposing queue service to external clients, exposing rich message level objects generated from the underlying TMS domain model.

  3. Producer Client : Wrapper around underlying producing API, in order to provide simplified and uniform interface for developers, also provides advanced partitioning, batching, compression and asynchronous producing features.

  4. Consumer Client : TMI consuming API, should provide simplified and stream style consuming interface for developers, supporting advanced distributed consuming, multi-threads concurrent consuming, group consuming features.

  5. Management and Monitoring : Server management and JMX based monitoring interface.

Design Consideration

1. Types of Channels - the following types of communication channels should be supported in order to provide several messaging paradigms

  • Pub-Sub Channel
  • Request-Reply Channel - notification or acknowledgement arrives on a different channel, asynchronously
  • Data Streams Channel - once a channel is established between two endpoints, data gets pushed through the pipe. No throttling. The consumer may need to implement filtering and throttling in this case.
  • Data Channel - The receiver must know what type of messages/events it is receiving hence it will subscribe/listen to domain outbound channel for domain specific messages
  • Error Channel - Will be used to notify publishers and consumers of any errors
  • Synchronous Request/Reply Channel (can be provided by underlying Bass call)

2. Domain interfaces - TMI will provide domain specific interfaces, based on the underlying message model

3. Support for multiple language implementation

4. Message Filtering the following message filtering criteria should be provided

  • A subscription filter policy either matches an incoming message, or it doesn’t. It’s Boolean logic.
  • For a filter policy to match a message, the message must contain all the attribute keys listed in the policy. Attributes of the message not mentioned in the filtering policy should be ignored.
  • The value of each key in the filter policy is an array containing one or more values. The policy matches if any of the values in the array match the value in the corresponding message attribute.
  • If the value in the message attribute is an array, then the filter policy matches if the intersection of the policy array and the message array is non-empty.
  • The matching is exact (character-by-character), without case-folding or any other string normalization.
  • The values being matched should follow JSON type rules: Strings enclosed in quotes, numbers, and the unquoted keywords true, false, and null.
  • Number matching is at the string representation level. Example: 300, 300.0, and 3.0e2 aren’t considered equal.

Usage of message filtering is recommended into a single topic only when all of the following is true:

  1. Subscribers are semantically related to each other
  2. Subscribers consume similar types of events
  3. Subscribers are supposed to share the same access permissions on the topic

Technology Stack

  1. Apache Thrift
  2. RabbitMq
  3. Apache Kafka to provide streaming services
  4. BB Bass for synchronous request/reply (REST and Native BASS SOAP)

1 2 3