Blogger Code Formatting

Before I start posting code, I thought I'd outline how to display formatted code in blogger.  The following links were helpful in setting up code formatting in blogger:

• http://alexgorbatchev.com/SyntaxHighlighter/
• The syntax high lighting css and js files
• http://www.redheap.com/2013/01/syntaxhighlighter-at-blogger.html
• The instructions that I followed.  I tried many approaches, but this was the only one that worked for me.
• http://accessify.com/tools-and-wizards/developer-tools/quick-escape/default.php
• The tool that I use to escape special characters before adding to a blog entry
• http://cdnjs.com/libraries/SyntaxHighlighter/
• The CDN location where the libraries are loaded from

The "brushes" and themes available are located here:

• Brushes: http://alexgorbatchev.com/SyntaxHighlighter/manual/brushes/
• Themes:  http://alexgorbatchev.com/SyntaxHighlighter/manual/themes/

I also included the style additions outlined in the blog post below. I included the additions after the "link href" sections that included the css files for SyntaxHighLighter.

• CSS: http://vichargrave.com/wordpress-syntaxhighlighter-3-x-tweaks/

    <script src='http://alexgorbatchev.com/pub/sh/current/scripts/shCore.js' type='text/javascript'></script>
    <script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushJava.js' type='text/javascript'></script>
    <script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushXml.js' type='text/javascript'></script>
    <script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushSql.js' type='text/javascript'></script>
    <script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushBash.js' type='text/javascript'></script>
    <script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushCss.js' type='text/javascript'></script>
    <script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushJScript.js' type='text/javascript'></script>
    <script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushPlain.js' type='text/javascript'></script>
    <script type='text/javascript'>
        SyntaxHighlighter.config.bloggerMode = true;
        SyntaxHighlighter.defaults['auto-links'] = false;
        SyntaxHighlighter.defaults['tab-size'] = 2;
        SyntaxHighlighter.defaults['toolbar'] = false;
        SyntaxHighlighter.all();
    </script>

    <link href="http://alexgorbatchev.com/pub/sh/current/styles/shCore.css" rel="stylesheet" type="text/css"></link>
    <link href="http://alexgorbatchev.com/pub/sh/current/styles/shThemeDefault.css" rel="stylesheet" type="text/css"></link>
    <style>
        .syntaxhighlighter .line.alt2 {
        background-color: #f2f2f2 !important;
        }
        .syntaxhighlighter {
        background-color: white !important;
        border: 1px solid #DADAD9 !important;
        margin-bottom: 20px !important;
        }
        .syntaxhighlighter .line.highlighted.alt1, .syntaxhighlighter .line.highlighted.alt2 {
        background-color: #D4DDF8 !important;
        }
    </style>
    
    </head>

Other Trading System Functionality

At server start up, core services will be started:

• Servlet Container (Tomcat)
• Confirm JMS provider is active (ActiveMQ)
• User Service
• Account Service
• Strategy Service (scan database for strategies to load)
• Securities Service
• Position Service
• Order Service
• Transaction Service
• Metrics Service
• Risk Service
• Communications Service
• Authentication Service (authentication and authorization)
• Audit Service
• Run every XX minutes.  Compare order quantity with transaction quantity and alert if different.
• Will need to be run on start up to determine if there are issues.
• At regular intervals, account quantity should be reconciled with transaction quantities.

                                                                                                                  

Starting of strategies will follow this general flow:

1. Scan the strategy_run table for strategies with their load set to true.
2. Does a position exist in the position table?  
1. Iterate through the the position table corresponding to this run id, and sum the quantities for each security/option in the position_details table.  Do all quantities = 0 -->
1. yes - then will activate in the create-new-trade state
2. no - then will activate in the managing-trade state.  Is trade complete -->
1. yes - manage complete trade
2. no - determine what components need to be built and continue building trade - send alert - trade incomplete

                                                                                                                  

The StrategyService sends orders to the OrderService, and the OrderService receives fills and order status from broker.  These orders are associated with a strategy_run_id and a position_id, which can be resolved to an account, userid, and strategy.

When a fill occurs, an entry is created in the transaction table by the TransactionService.  A fill alert is sent via JMS to the StrategyService.  The StrategyService will call the PositionService to update the position_details table.  The StrategyService will also update it's positions map from the db by requesting an updated list of positions from the PositionService.  In backtest mode, an order is converted to a transaction automatically.

Order status alerts are sent by the OrderService to the StrategyService.  A strategy may act on an order status update by cancelling or replacing orders.

The trade_summary table is update at trade closure.  The trade_details_by_day table is updated daily.  These updates are handled by the MetricsService.

                                                                                                                  

Many of the tables will have CRUD functionality provided by a browser based UI:

• users
• user_details
• user_email
• user_phone
• user_address
• account
• strategy
• strategy_settings
• strategy_run
• account_strategy_run

                                                                                                                  

Additionally, the browser based UI will provide the following functionality:

• Account Overview
•     Can view orders associated with the account
•     Can view fills associated with the account
•     Can view transactions associated with the account
•     Can view all securities in the account
•     Can view the current cash balance in the account

• System Overview
•     Positions and/or transactions by strategy type or name
•     Positions and/or transactions by security
•     Positions and or transactions by account, then strategy, etc

                                                                                                                  

Next steps:

• Technology POC: Twitter Bootstrap and Thymeleaf with Spring MVC
• Technology POC: Spring Security with Spring MVC
• Code DAOs for Hibernate and Spring JDBC
• Code Spring Services
• Code CRUD pages for the tables in the ERM diagrams
• Refactor the Strategy Engine to use the above

                                                                                                                  

Future blog post will be on the topics above as well as Tomcat, ActiveMQ, MySQL, Maven, and Eclipse.  I may include some trading posts as well.

Data Model Details

The tables in the model include the user tables that are populated when a new user is created in the system.  A user name is created by the UserService during the user registration phase.

• users
• user_details
• user_email
• user_phone
• user_address

After a user is created, an account is registered for that user by the AccountService.  This table is a place holder at this point and will be refactored when connections to a broker are built.  This table should be adequate during the first stages of system development.  An account can be either regt or pm margined, and either funded or paper/simulation.

• account

As strategies are developed, the strategy and strategy_settings tables are populated.  An entry in the strategy_run is associated with a specific set of settings, a specific account, and specific date range.  Multiple runs, can use the same set of strategy settings.  The allocation amount from an account to a specific run is set in the account_strategy_run table.  The allocation amount cannot be greater than the sum of the margin required by the strategy versus the account cash available.  All of these updates are handled by the StrategyService.

• strategy
• strategy_settings
• strategy_run
• account_strategy_run

A position is a set of options strikes, for example an iron condor, for specific expiration month.  A new position (PositionService) and security_option(s) (SecuritiesService) are created by the StrategyService just prior to the first order being sent by the StrategyService.  An order value object is created and sent via JMS to the OrderService.  The OrderService creates an entry in the order table and sends the order to the broker connector via JMS.  The OrderService monitors the status of orders and will update/cancel orders.  Order status alerts are sent by the OrderService to the StrategyService. 

• position
• security_option
• order - composed of options_security entities, and may result in multiple fills/transactions

The OrderService will match fills to orders and will send fills via JMS to the TransactionService.  The TransactionService will update the fill and transaction tables.  The TransactionService will send a fill alert via JMS to the StrategyService .  The StrategyService will then call the PositionService to update the position_details table.

• fill - composed of options_security entities
• transaction - composed of options_security entities, and associated with an order and position
• position_details - composed of transaction entities

The MetricsService will update the trade_summary and trade_details_by_day tables, as well as query these tables for data to display in charts.

• trade_summary
• trade_details_by_day

The next post will contain some ideas about other functionality required by the system.