Market Data: A challenge for most JMS implementations

If the benefits of the JMS standard are so obvious, why isn't JMS used for market data everywhere? The answer—as many experienced market data engineers have discovered—is that traditional JMS implementations just can't hack it. More specifically, they fail to satisfy five key requirements: publishing on demand, providing initial values for subscribers, enforcing content-based entitlements for fee-liable data, supplying efficient data quality indications, and providing sufficient performance.

  • Publishing on demand - Market data sources often have much more data than a given set of subscribers needs. Likewise, other publishers of dynamic data, such as internal analytics applications, only want to spend resources creating data streams for which there is downstream interest. For these reasons, dynamic data publishers typically follow an "on demand" model, only publishing data streams in response to requests from subscribers. The JMS publish-subscribe API, however, has no built-in way to notify publishers when subscribers come or go. While it is theoretically possible for all publishers to publish all available data, such an approach would be extremely expensive.

  • Initial values - In many cases, dynamic data consists of a large number of fields, a few of which update very frequently and the rest of which do not. The typical subscriber needs to receive the initial value for all fields followed by updates containing new values for those fields that have changed. However, in most JMS implementations, the anonymous nature of the publisher-subscriber relationship means that publishers are unaware of new subscribers. This means there is no automatic way for a subscriber to receive initial values and for those to be synchronized with updates.

  • Access control - Typical JMS solutions control access to topics based on the topic names. However, the number of fee-liable market data instruments is enormous and changes frequently. Administering market data entitlements based on names or symbols is just not practical. Data vendors typically require data to be permissioned on attributes of the content, not on names.

  • Data state - The JMS pub/sub API does not provide any explicit indication of publisher state. For example, if a publisher terminates abnormally for some reason, there is no built-in mechanism by which a subscriber would learn of this change. Users and applications would find themselves trading on out-of-date (stale) data, which can cost a firm millions.

  • Performance - Market data and other dynamic financial data typically involve very high rates of small, latency-sensitive messages. These attributes are different from the message types that JMS products typically handle. Most JMS products are therefore not optimized to provide the necessary performance for market data.
  • With the exception of performance, it is possible to work around these issues by creating additional, proprietary APIs on top of the JMS API. However, since applications would no longer be using the JMS standard, this would miss the entire point.

    Read about how MetaFluent JMS solves these issues...