Novel JMS API for Standardized Access to Financial Market Data System

• US 20100299680A1
• Filed: 01/25/2008
• Published: 11/25/2010
• Est. Priority Date: 01/26/2007
• Status: Abandoned Application

• Current Assignee: Metafluent LLC
• Original Assignee: Metafluent LLC
• Inventors: Macgaffey, Andrew, Lankford, Peter
• Application Number:
  US12/448,485
• Publication Number:
  US 20100299680A1
• Time in Patent Office: Days
• US Class Current: 719/328
• CPC Class Codes: G06Q 40/04 Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange

Abstract

The invention provides a system and method whereby an Application may use a standard API to access and deliver financial market data from multiple proprietary Market Data Systems. In the preferred embodiment, a JMS API is used, along with a small set of conventions, that enable an application to access market data from Market Data Systems though a standardized interface using the JMS publish/subscribe paradigm, and wherein said standardized interface relies on a small set of conventions to convey market data semantics via the standard JMS message property construct.

Claims

1. An improved system for delivering market data from Market Data Systems to an application, where the Market Data Systems have proprietary APIs, and where the application where the improvement is data access and delivery via a standards-based API, such that an application can use a single API to access multiple different Market Data Systems or switch from one Market Data System.

2. The system as in claim 1 wherein the standards—

based API is a JMS API, and wherein some programming library delivers market data from Market Data Systems via the JMS API, enabling an application to access market data from Market Data Systems though a standardized interface using the JMS publish/subscribe paradigm, and wherein said standardized interface relies on a small set of conventions to convey market data semantics via the standard JMS message property construct.

3. The system as in claim 2 wherein the set of conventions is as follows:

Message type, to distinguish different types of messages {status, image, update, stream update};

Status code, to convey request responses {ok, invalid, denied, closed};

Data condition code, to convey data condition {ok, stale};

Text, to convey information text for human users;

Data stream id, to differentiate multiple data streams on one topic; and

Next/previous stream ids, to convey ordered collections.

4. The system, as in claim 2, wherein said interface delivers market data from Market Data Systems to an application as JMS MapMessages.

5. The system, as in claim 3, wherein Market Data System includes Reuter'"'"'s Market Data System (RMDS).

6. The system, as in claim 3, wherein Market Data System includes at least one of any of the following:

market data middleware, real-time datafeed, direct exchange feed, order management system, complex event processing system.

7. A method whereby an Application may, using a JMS API, subscribe to market data in one or more Market Data Systems, and deliver data to a User by output means such as computer display, where such Market Data Systems may use APIs different from each other and proprietary, said method comprising the steps of:

a) Application allocates a TopicConnectionFactory;

b) Application requests a TopicConnection from the TopicConnectionFactory;

c) TopicConnectionFactory allocates a TopicConnection;

d) TopicConnection authenticates Application;

e) Application “

starts”

the TopicConnection;

f) TopicConnection allocates any necessary resources so as to maintain and operate a connection to the underlying Market Data System;

g) Application requests a TopicSession from the TopicConnection;

h) Application requests a Topic from the TopicSession;

i). TopicSession allocates and saves a reference to the requested Topic;

j) Application obtains a TopicSubscriber for the Topic from the TopicSession;

k) TopicSession initiates a subscription with the underlying Market Data System, mapping the Topic name to the naming conventions of the underlying Market Data System as required;

l) TopicSession receives messages in the underlying native format of the Market Data System and converts said messages to JMS MapMessage with the appropriate application-level conventions;

m) Application receives a stream of MapMessages via the TopicSubscriber and interprets the message properties according to the application-level conventions, and uses the MapMessage interface to access data values by name;

n) Application uses the TopicSession to un-subscribe from the Topic; and

o) TopicSession tracks the number of active subscriptions and, when the number is zero, releases any subscriptions and associated resources allocated within the underlying Market Data System.

8. The method of claim 7, wherein the appropriate application level—

conventions of step l) are selected from the following set;

Message type, to distinguish different types of messages {status, image, update, stream_update};

Status code, to convey request responses {ok, invalid, denied, closed};

Data condition code, to convey data condition {ok, stale};

Text, to convey information text for human users;

Data stream id, to differentiate multiple data streams on one topic; and

Next/previous stream ids, to convey ordered collections.

9. The method, as in claim 8, wherein Market Data System includes at least one of any of the following:

market data middleware, real-time datafeed, direct exchange feed, order management system, complex event processing system.

10. The method. as in claim 8. wherein Market Data System is RMDS (Reuter'"'"'s Market Data System).