FIX implementation: Cost cutting proposal part III

on
In many cases I have seen firms that seek to capture FIX messages in log files which are then flattened and loaded into a relational database such as Oracle, MSSQL, Sybase etc.


Third and last post in this series for the time being.  This is a lot easier to implement compared to Cost cutting proposal part I and Cost cutting proposal part II.
The proposal here is to replace the RDBMS with a document store database such as MongoDB. 
 
In a normal FIX workflow there will be something along these lines:
  1. OMS connects to FIX engine using middleware such as AMQP, Solace Systems, TUM, TIB R/V. Data is represented in XML or middleware specific format.
  2. FIX engine subscribes to middleware and has an in-process adapter to parse out the middleware message into whatever internal representation the FIX engine uses.
  3. FIX engine connects to counterparties, receives FIX messages and then transforms them into middleware format.
  4. A middleware listener picks up the messages passing back and forth and flattens them into a format that can be loaded into a relational database.
The proposal is for this:
  1. MS connects to FIX engine using middleware such as AMQP, Solace Systems, TUM, TIB R/V. Data is represented in XML or middleware specific format.
  2. FIX engine subscribes to middleware and has an in-process adapter to parse out the middleware message into whatever internal representation the FIX engine uses.
  3. FIX engine connects to counterparties, receives FIX messages and then transforms them into middleware format.
  4. A middleware listener picks up the messages passing back and forth and flattens them into JSON or BSON format that can be loaded into MongoDB
Over time the entire message flow could be moved to use JSON or BSON rather than XML or a proprietary format.
 
How does this save costs?
  1. Remove RDBMS license fees
  2. Remove spaghetti code of adapters
  3. If the FIX<>JSON/BSON adapter is written correctly it can simply parse out FIX ATDL, custom fields data and FIX repository data to represent messages correctly.
  4. Allow for further developments to include web based technology to interact with the FIX stack
Arguably point 4 is the big winner - get the FIX stack to start speaking JSON which is the default language of data representation within most modern web frameworks.