Architecture and Deployment

The SubMan API is the externally visible element of the Subscriber Management interface. The interface uses a standard client-server model, where a MATRIXX gateway is the server and any external application that needs to access and manipulate data related to subscribers and groups is the client. The SubMan AP has two language bindings: Java and REST.

The SubMan API is supported through gateway interfaces that provide communication paths over standard internet protocols, such as TCP/IP and HTTP. The type of binding determines the exact invocation method used, for example, a URL over HTTP for the REST binding.

When an external application sends a message, the gateway converts the request into MATRIXX Data Container (MDC) format and sends it to the Charging Server, which performs the necessary data operation. After the operation completes, the Charging Server returns a response to the client through the gateway. Each request is a transaction and either succeeds entirely or it fails entirely.

Note: If a client loses a connection after sending a request, but before receiving a response, the request continues and either succeeds or fails. In this situation, retrying the request (for example, during a purchase or top-up operation), could result in two requests (for example, two purchases).

The implementation of the gateway layers must adhere to company security requirements. In a production environment, this consists of the following:

  • Locate MATRIXX Engine in a secure LAN segment that only allows access to the engine from defined external resources, like a Diameter server and the MATRIXX gateways and web apps. All requests to MATRIXX Engine should come from these defined resources.
  • Locate the Gateway Proxy (part of the Business API Gateway) on an off-engine pod and act as a proxy between external applications sending non-usage requests to the engine and MATRIXX Engine. The role of the Gateway Proxy is to support the execution of the specific gateway processes, manage the SubMan API load, and implement security. A MATRIXX Engine installation can contain multiple Gateway Proxies. Each one communicates with the engine through the Traffic Routing Agent (TRA) load balancer so traffic is distributed across all processing pods.
    Note: For demonstration and test environments that run a single MATRIXX Engine, MATRIXX gateways and web apps can be installed on the same pod and configured to communicate directly with MATRIXX Engine.
In Figure 1, the Gateway Proxy is located on an off-engine pod and acts as a proxy between external applications sending non-usage requests to the engine and MATRIXX Engine.
Figure 1. Communication through the Business API Gateway

The location of MATRIXX gateways and web apps can vary depending on the trusted nature of the site accessing the server. For example, if the supported application is a trusted CRM, the security requirements might not be as stringent. For untrusted sites, such as external CRM applications or portals, the security requirements must be much more stringent to avoid data corruption. A MATRIXX Engine environment can include multiple Gateway Proxy hosts to handle larger data loads.