Middleware is software that lies between an operating system and the applications running on it. Essentially functioning as a hidden translation layer, middleware enables communication and data management for distributed applications.

It’s sometimes called plumbing, as it connects multiple applications together so that data and databases can be easily passed between the “pipe”.

Whereas traditional 'integration strategies' would involve developing an 'interface' between two applications, often via a pre-defined data file, middleware provides the platform to design the flow between the two (or more) applications without either being directly connected.

We often refer to middleware software as being the Integration Platform as effectively it allows system architects to design simple or complex workflows. It is a development environment that is vendor-neutral, meaning that much of the work and control can be managed by the consumer of the services.

ITAS Components

Subscribers to Enterprise services ITAS API and DQS will benefit from direct access to the Events Engine, meaning that self-service management of alerts published by ITAS can be achieved.

Scenario

Client A wishes to build a workflow that is triggered by the creation of a Physicals Contract. The requirement is for the Risk Manager to receive a notification and simultaneously send the core details to an external planning tool.

If the Risk Manager is a registered user of Trader Desktop he/she has the option of self-subscribing to this specific alert (Topic 2-220) and choosing to receive the notification by email or Desktop Alert.

This works as the Trader Desktop is managing the subscriptions for the user; in this case to Topic 2-220. The Application that creates the Contract (e.g. TRADE) will publish the alert to Topic 2-220. All subscribers to Topic 2-220 will receive a copy of the alert as distributed by the Events Engine. Users subscribing via Trader Desktop will then receive that alert.

However it may be that the notification needs to monitored externally and this is where middleware can be used. For both of the requirements of this scenario it is necessary to know when the contract has been created. As above, the publication to Topic 2-220 will happen via the Application but instead of Trader Desktop intercepting the alert, an externally managed subscription can be setup within the middleware. On peek an alert can be received and, in this scenario, the Trading Entity and Contract ID identified.

Further information can be gleaned by directly accessing the underlying contract data via the ITAS API or DQS. The data required, its purpose and further workflow stages are fully controlled within middleware.