Timpani User Guide
Jetty is a lightweight, open-source web server and servlet container. Among its many features is implementation of WebSocket protocol, as well as standard HTTP. In the Timpani project, HTTP is used to serve a static web page, while business messages are transmitted by WebSocket.
The Jetty libraries needed to build the application are retrieved by Maven automatically. However, Jetty also supporting resources and documentation,and it needs to be configured. Download Jetty, which is part of the Eclipse project, from Jetty Downloads
Unlike relational databases, MongoDB is a document database. Each document contains all of the properties of a business entity. The normal encoding is BSON, which is equivalent to JSON, but is optimized for performance. Queries consist of BSON documents also. They are used as the criteria for matching documents in the database. Those that match are returned as a result set.
MongoDB API is designed for asynchronous operation. This supports pipelining of events.
The project build retrieves the MongoDB client driver library automatically. The server cluster needs to be installed. For development, MongoDB may be run in stand-alone configuration. Executables are available from Downloads MongoDB
To build the executable, invoke Maven with the command mvn install. The product of the build is a WAR file for deployment.
Jetty configuration should be stored in Jetty base directory as described in Managing Jetty Base and Jetty Home.
The WAR file from the Timpani build must be deployed to the webapps subdirectory. This project does not demonstrate automated deployment (possible future enhancement).
In the start.ini file, add this setting if not already present:
# Websocket enabled
--module=websocket
The only MongoDB setting currently implemented is the host or hosts of the MongoDB cluster. For development purposes, the setting defaults to localhost. This needs enhancement to make it more generic.
See MongoDB documentation for details. At minimum, the --dbpath parameter must be supplied to tell the system where to physically store the database.
In order to fulfill queries, the database must first be populated with security definitions. The application provides a sample bulk loader in class org.fixtrading.timpani.securitydef.datastore.loader.TagValueSourceBulkLoader. It parses a file of security definitions in tag=value encoding and loads them into MongoDB. A free source of security definitions is available on CME's FTP site. With some alterations perhaps, this loader should work for other markets that provide reference data in FIX.
Jetty will find the WAR file in its configuration and start the Timpani servlet. The servlet contains a MongoDB client driver to communicate with the datastore.
By default, the static HTML page is located at root level on port 8080, but this configuration can easily be changed.
Remember that unlike static web pages, websockets are connection oriented. So the first thing to do is connect to the servlet by pressing the Connect button. The client-side code connects back to the servlet via an HTTP request for upgrade to WebSocket protocol. If all goes well, Jetty accepts the request and issues a response with status code 101 Switching Protocols. When the client receives that response, it changes status to Connected, and it disables the Connect button. Now the session is ready for queries.
The dropdown lists all the supported criteria for searching for security definitions:
- Symbol
- Security Type
- CFI Code
- Product
- Security Group
- Trading Session ID
- Market ID
- Market Segment ID
- Security Exchange
- All Securities
Enter the key value to search for. For example, if you selected "CFI Code" as the search criterion, enter a code to match.
Press the Request button. All matching security definitions will be displayed. If none match, a result is returned with the value SecurityRequestResult.NoInstrumentsFound. If an error occurs like datastore unavailable, the result will contain SecurityRequestResult.InstrumentDataTemporarilyUnavailable.