Adapter bridging bundle
The Adapter Bridging Utils bundle contains services for configuring bridging the standard Apama status reporting, legacy market data protocols, order management protocols, and an adapter whose service monitors are running in a non-CMF based correlator. Such configurations are often used when the adapter needs to be run on a particular host for security or network topology reasons, or to support multiple client applications (for example, multiple instances of the Algorithmic Trading Accelerator) connected to a single adapter.
All of the bridging services share a common architecture:
A client bridge service instance that
Runs in the application correlator
Listens for events that should be handled by the adapter service monitors
Forwards these events to the adapter correlator over a specific channel.
A service bridge instance that
Runs in the adapter correlator
Listens for events routed by the adapter service monitors that should be delivered to the application
Forwards these events to the application correlator over the specified channel.
A general principle of the bridging services is that to the application, the client side of the bridge should behave exactly like the adapter it is bridging to. Likewise, to the adapter the server side of the bridge should look exactly like a client application.
The bridging services operate at the level of individual adapter services, which are identified by the serviceId values used in status and legacy market data subscriptions, and also in order submissions. If you configure multiple bridging services to several adapters with the same service identifier (for example, several different FIX adapters); each bridging service will forward all requests for that adapter service. Therefore it is important that the adapter services themselves are able to correctly distinguish requests intended for each instance of the adapter service. These are the com.apama.statusreport, com.apama.marketdata and com.apama.oms packages, defined in the StatusSupport.mon, TickManagerSupport.mon and OrderManagerSupport.mon files in the Apama installation, respectively.
The bridging services rely on connections being made on specific event channels between the application and adapter correlators. The CMF does not provide any support for creating inter-correlator connections. It is the responsibility of the application builder to ensure that these connections are maintained, for example through custom actions in an Software AG Designer run profile.
It should also be noted that the current implementation of the bridging services is not parallel-aware, so these services should only be run in the main context.
Details of the status, legacy market data and order bridging services and their configuration are described elsewhere in this document. However, the Adapter Bridging Utils bundle does provide a generic service for creating a bridge for a named adapter service. The bridge is configured by sending a com.apama.adapter.bridge.ConfigureClientSide event to the application correlator and a com.apama.adapter.bridge.ConfigureServerSide event to the adapter correlator, specifying the service name (which must be the same on both sides) and the channel for the inter-correlator connection. These events will trigger creation of status, legacy market data and order bridges as well as monitoring of the bridge connection itself in both directions.