headerphoto

MessageManager Architecture

The MessageManager consists of 3 distinct components: the web server, the database and the communications server(s). Depending on the requirements, these components can be installed on a single machine or distributed on several systems.

Components

The Web Server

All message formatting and validation is done on the web server by use of XML/XSLT. This makes it very easy to update message standards or deliver small fixes (just copy the files to the server). Depending on the number of required concurrent users, the load can be spread to multiple servers. As the web server communicates only with the database, it is also easy to implement a stand-by web server, which takes over if the main web server fails.

The Database

Currently supported databases are SQL Server (7 upwards) and Oracle (8.1.7 upwards). The database can be run on another machine (various platforms possible, existing installations for Oracle: True64, AIX and Solaris). Standard replication and backup features of the database can be used.

The Communication Server(s)

Background processes are known as MessageManager Servers (this does not mean that each process must run on a separate physical server - but it is possible, if required). MessageManager servers are typically installed as Windows Services.

The minimum configuration consists of:

  • TargetServer (sends incoming messages to/from the target defined by routing rules),
  • TargetPrint (automatic printing of messages),
  • at least one MMServer (sends and receives messages to the network) for each application, i.e. MMSwiftServer, MMSicServer and/or MMSecomServer.
  • Optionally a HostLinkServer can be implemented (currently support for automated file-transfer, MQSeries or our popular, reliable and cost-effective shared database tables).

Scalability, Scenarios

Single Server

All 3 components installed on one physical server: typical configuration for small scale-operation, e.g. SWIFT only, 5 users, no host connection ("stand-alone") or automated file-transfer.

Gateway with Standby-Server

All 3 components on separate physical servers (database server will usually be shared with the customer's standard applications). If multiple applications with high throughputs are needed, then they can be spread onto different physical servers. One server can function as backup for another, or separate standby servers can be implemented. Windows server clustering is supported.

Security

Encryption

We use 128bit SSL encryption by default, even in an intranet environment.

Authentication

For additional security (e.g. for use over the internet), client certificates and reverse proxy are used. A security server (using token authentication) can optionally be installed.

Authorisation

All users and remote processes are secured with user-id and password, which are controlled on the application level (with detailed permission level settings).