Skip to main content

Functionality and components

The MATP has a number of functional areas, each of which has its own set of JAR files. The purpose of separating the MATP into separate functional areas is to simplify and streamline installations to include only the necessary executable artifacts―especially Server components, which generally require database tables. Restricting an installation to the minimum required components simplifies maintenance and future migrations to new versions.

Each functional area is broken down into several different components, as described in the following sections. Each component within the functional area has its own JAR file.

Each function area has its own client. Clients often use the same physical connections but provide a distinct, parallel stream from other clients to maximize throughput.

Functionality​

Admin​

Manages Users, Groups, Permissions and similar functions.

All functions depend on the appropriate permissions.

Cluster​

Provides implementation and information about the status of the MATP cluster. The free Community Edition of the MATP always has a single cluster member.

DARE​

Provides order-routing services and execution-report management.

The DARE functional area has no specific client and uses the Trade Client for its inputs.

Eventbus​

Provides the event bus implementations for MATP components.

The Eventbus functional area has no specific client and provides services in the server space. Specific events are available via functional area clients.

FIX​

Provides client and server FIX implementations.

The DARE functional area, for example, uses the FIX client and server implementations to manage its FIX sessions.

Market Data​

Provides market data services for market data adapters.

The adapters themselves are typically implemented elsewhere, in their own JAR files. This separation maximizes implementation flexibility. Each installation can include only the relevant market-data adapters. The Market Data functional area contains the core services and clients.

Metrics​

Provides metrics services.

Metrics are collected in the MATP in great numbers and can provide very useful feedback on performance. The metric functional area currently has no client.

Photon​

Assigned to the user interface component for the MATP.

Photon is implemented in Java FX and uses the functional area clients to gather and present information to the user.

Strategy​

A key functional area, the strategy runs units of code the user provides to direct trading behavior.

The most common, but not only, use of strategies is for trading. The Strategy functional area depends heavily on Photon to upload strategies and control their lifecycle. It is possible to use strategies with a custom Strategy Client implementation and not use Photon, if desired.

Trade​

Provides support for sending trades and receiving execution reports. The Trade Client is used by Photon and the Strategy functional area as well as DARE.

Components​

Every functional area has the following components to handle different behavior. For example, here are the components for the admin area. Each of these subdirectories has its own JAR file:

$tree admin

admin/
├── admin-api
├── admin-core
├── admin-rest-server
├── admin-rpc-client
├── admin-rpc-core
├── admin-rpc-server
├── admin-server

  • API

    The API JAR in each functional area contains mainly interfaces and enums, and generally does not contain classes or other implementation artifacts.

The API must never contain server components and is designed to be shared by clients and servers. API JARs are often included in foreign third-party integration services. The API JAR is designed to be as lightweight as possible. The API JAR usually contains a Client definition.

  • Core

    The Core JAR in each functional area contains helper classes and basic implementation that would be shared by client and server artifacts.

The Core JAR is generally used by client implementations, but not third-party integrations. The Core JAR must never contain server-specific components.

  • Server

The Server JAR in each functional area contains heavyweight implementation that is designed to run on the server. The Server JAR contains all database-related artifacts associated with the functional area and is not designed to run outside of a server implementation. Due to the complex code and dependencies for functions like persistence and transactions, clients and third-party integrators should never require a Server JAR.

To avoid duplication, all business logic should be implemented in the Server JAR, not in the RPC (or REST) Server JARs.

  • RPC Core

    The default Remote Client implementation for each functional area uses gRPC. All functional areas have a gRPC implementation. Some functional areas have REST client implementations, but not all. The RPC Core implementation contains RPC-specific implementation artifacts that are common between the RPC Client and RPC server libraries.

  • RPC Client

    The RPC Client JAR connects to the RPC Server using gRPC. The RPC Client JAR is the implementation for the RPC Remote Client. Third-party integrators may use the RPC Client, but they often define an implementation of their own in a native language. The RPC Client represents an implementation defined in the API section of the particular functional area.

  • RPC Server

    The RPC Server JAR receives connections from RPC Clients using gRPC. This JAR should be used only in the MATP server. Each functional area has its own RPC Server and the Execution Container manages the incoming connections and forwards the data to the appropriate RPC Server implementation. RPC Server implementations should always perform permission checks. Business logic should not be implemented in the RPC Server. The RPC Server should call the Server implementation to complete requests.