Re: New Bridge and payload enumerators for OpenMAMA Thomson Reuters RMDS bridge

Les Spiro


You raise some good points, and I think you will be pleased with our implementation. 

Reuters started the modern market data platform, and we worked with Reuters in the pre-SSL days  when one of the R's in RRDP stood for Rich. During the intervening years as instrument lists and update rates increased and latencies dropped it is surprising how little the underlying concepts have changed in the Market data platforms and API's used by most applications.

Almost all general purpose multi-feed market data platform still carry the same model as Triarch:
- Applications Requesting or Publish an instrument on a service (or namespace).
        - Subscribers receiving an instrument specific stream in response to the request.
        - The stream provides Image and update messages.
- Stream (and sometimes Service) have states that correspond to  Live, Stale (expected to recover automatically) and Invalid/Closed.

So everything is the same on all market platforms, except of course when it isn't. 

Some of the multicast exchange feeds obviously have a very different structure. Also consider the most used market data API from the current dominant player,  The Bloomberg Terminal data feed. From a traditional market data point of view, the API  is little weird. As you probably know it has a mix of a normal market data real time stream coupled with a request-response mechanism for static data. The feed can have per user specific configuration, and can also be used to access to calculators.. Taking a pragmatic approach Tick42 have provided drivers for this feed, that present a standard market data style API, providing access to much of the feeds functionality. This approach has proved useful to large numbers of users, first in our Real Time Toolkit (RTT) product and latterly with our OpenMama Bloomberg API bridge.

Compared to the Bloomberg API the mapping between RMDS and OpenMama is actually very close.

To provide some concrete information on our Bridge:

   - We will be using the UPA API, and so we have a much closer match between the standard OpenMama bridge model and the API. Although providing an RFA bridge would also have been possible and performant

  - The goal of the Bridge is designed to allow existing Mama applications to work with existing Reuters applications. 

  - On the subscriber side this interchangeability is relatively straightforward, and our expectation is that an application currently subscribing to a data source on Mama should "just work" on using the RMDS bridge, allowing for a change in instrument names. 

  - For Flat/MarketPrice sources Subscribers can chose the level of field mapping they require, allowing users to chose to use native RMDS field names or map to using existing OpenMama field names.

  - The Bridge will support the By Level and By Order OMM profiles using MAMDA structure. We will not handle other OMM profiles in the first release.

  - As you point out, Mama publishers do pose bigger issues. Some interpretation and conversion of fields is required for requests and initial images, but processing updates (which is 99%+ of messages) is much more straightforward, and we do not expect a measurable impact on performance. 

We think that using OpenMama as a cross platform API must allow the selection of Platform and/or Transport to be easily deferred until run time and must not require development teams to produce multiple builds of their applications. We prefer the idea of a Bridge to a wrapper that implements the Mama API because it allows configuration to be controlled by standard files rather than having multiple implementations of the mama dll/so. Going forward delivering bridges also allows possibilities of creating Applications that can access multiple platforms through a single API.

Leslie Spiro

From: Mark Perkin <mark@...>
Date: Thursday, 6 June 2013 16:13
To: Tom Doust <tom.doust@...>
Cc: "Openmama-dev@..." <Openmama-dev@...>
Subject: Re: [Openmama-dev] New Bridge and payload enumerators for OpenMAMA Thomson Reuters RMDS bridge


We looked at doing this but couldn't see technically how it would fit. 

If we think of a typical market data system, it has three layers:

1. Payload 
2. Market data semantics (subscription management, entitlement, staleness controls, etc., etc. )
3. Transport

The openmama api has a specific protocol implementation for layer 2 (the Wombat market data semantics), whilst the bridges allow extensibility for layers 1 and 3. Layer 2 is baked into openmama. Via the bridges, you can use any transport and any payload but if you are writing to the openmama api you are using the Wombat market data semantics.

I could see how we could write a payload bridge to support Reuters Wire Format ( and the legacy Marketfeed). But I couldn't see how an RMDS transport bridge makes sense - since RMDS is not simply a transport (like PGM or TIBCO Rendezvous or AVIS), its a market system with its own market data semantics - i.e. its own subscription management, entitlements, etc.

For example, will an openmama advanced publisher using the RMDS transport bridge interoperate with a native RMDS subscriber written on  the Reuters API. For this to work the RMDS transport bridge will need to be much more than a transport - rather it will need to map the openmama protocol messages into appropriate calls to the Reuters API - effectively having a market data layer on top of another market data layer - wouldn't you be better off simply taking the openmama interface only (i.e. none of the openmama implementation) and then providing your own implementation on top of the Reuters API?

Of course we may have reached the wrong conclusion here. I'd be interested in the technical details of your proposed implementation if and when you are able to share those?



On 6 June 2013 13:28, Tom Doust <tom.doust@...> wrote:

Tick42 are developing a bridge for Thomson Reuters RMDS connectivity. The bridge will provide both subscriber and publisher capabilities and will support both flat and OMM structured data.


We would like to reserve the following middleware enumerator and payload key.




(and hence MAMA_MIDDLEWARE_MAX = 12)




I'll release a patch in due course.


Tom Doust

TOM DOUST | Head of Consultancy                                                                                                          


P: +44 (0) 1628 477444 | M: +44 (0) 7710 479924 | E: tom.doust@...


Openmama-dev mailing list

Join to automatically receive all group messages.