Financial Information Systems

Object Oriented Paradigm

Through the API, applications have access to messages and their contents within the message store. Individual fields within a structured message such as a payment instruction can be read or updated directly, without the application getting involved with unpacking and parsing. The message store is really an application specific database. Although it is possible to implement messaging middleware on top of a relational database, SQL is not a good fit for the interface. The Object Oriented —container“ paradigm is a better model.   

In a message switch, the queues are usually pre-defined static structures. In Messaging Middleware, the queues are much more dynamic – the grouping and ordering of messages can be re-defined —on the fly“. This feature is utilised for describing, controlling and monitoring complicated Message Processing flows. Security and efficiency are enhanced by keeping the messages —within the system“ while they are being processed. The middleware acts as the responsible agency for the life of the messages under its control.

The middleware monitors processing states of the messages and as they become ready for their next stage of processing, will try to arrange for it to be done. This may be as simple as placing the message in the proper work queue and waiting for the appropriate program to come and pick it up. This is sometimes called —polling“ or a —pull“ model. Often the middleware takes a more active role and, depending upon the availability of resources, might actually notify or start the required process. This could be described as —event driven“ or —push“ model. Most complex systems contain examples of both push and pull type client interfaces.

The middleware‘s —Scheduler“ or —Dispatcher“ is the component that does this orchestration. The workflow routing and schedule is controlled by a set of rules that are defined as part of the configuration process. For example a rule might state that —When a message arrives in the ”reformat‘ stage, start the ”reformat‘ process and hand it the message.“

At any time, the system may be interrogated as to the current status of any message. As each processing stage is completed and each delivery is made, a log record is generated. If a human operator was involved in the process, their ID is included in the log entry.

Programs running on separate nodes, even portable computers, can be integrated into the messaging process. Messages that are delivered —outside“ of the system for intermediate processing can still be tracked and re-synchronised when they re-enter. This feature allows for truly —intra-enterprise“ messaging.

All of the mentioned integration and management features exist within a secure environment provided by the Messaging Middleware. All of the client applications must log on to the middleware server and be authenticated. The middleware checks the security profile record for functional and data access privileges that control what the application can do and what messages it can access. Some applications act as agents for users or other entities. In this case the user has to log on to the application, and the security profiles of both the user and the application are checked by the middleware. All access to the message store and other data is either through an API or data extraction done by the middleware.

The data within the message store can be encrypted while on disk and the data sent over the middleware client/server connections can also be encrypted. The encryption layer is replaceable, if necessary, to enable the use of different standards. The middleware server offers key management services. An efficient private session key encryption scheme is usually used.

As stated before, all of the messaging activity generates a complete historical log. After the processing of a message is complete, the message and its related audit trail are copied into an archive. In most financial applications today, this archive is written to optical WORM disks. Once written, these cannot be modified. All of the data is cross-indexed and can be retrieved very quickly by any number of search criteria. The message archives can be external to the Messaging Middleware, but there is much value in keeping them integrated.