Open Source Trade Model

Open Source Trade Model M 917 536 3378 maksim_kozyarchuk@yahoo.com

Overview Over the past couple of month, I’ve written several articles that discuss Trade Model, Domain Model and Data Entry. Many of those ideas are now checked in as code on GitHub in the following projects. NCT-portal -- Front end that demonstrates the type of functionality that can be expected from a Trade Model.  It contains front end JavaScript that leverages Booktstrap and Python based backend that runs on Flask.  It is designed to be deployed on Elastic Beanstalk web server tier. NCT-workers  -- Contains business logic and domain model for entering and representing trades.  It’s built in python and is designed to be deployed on Elastic Beanstalk worker tier. These projects are made available under GPL 2 license The Goal    Over the past 15+ years, I’ve had an opportunity to contribute to code around trading, portfolio management and accounting systems.  Most of the systems I’ve worked with were able to support multiple asset classes side-by-side and enable multiple user groups, including traders, middle office and accountants working off a single copy of the data.  Combination of cross asset and cross functional capability of an asset management systems is the ZEN of Trading Systems.  It’s the Holy Grail that allows high data quality as well as simple and consistent usability. This in turn allows better transparency of data and accuracy of reporting.    However, it is my experience that vast majority of trading, portfolio management and accounting systems are not cross asset and have highly specialized domain/data models requiring lots and lots of customized “data feeds and compares” between them. This project has two goals: Demonstrate trade model capable of supporting cross asset portfolio enabling single data store behind multiple asset management applications. Develop a set of tools and APIs for loading the data in and extracting the data out of the system Commitment Quantity:  Code for this project will be developed test first and will be monitored by a continuous integration system.  Currently unit tests are running on Travis-CI (https://travis-ci.org/kozyarchuk/NCT-workers and https://travis-ci.org/kozyarchuk/NCT-portal) Simple:  Solutions developed in this project will favor simplicity and API consistency over product specific market conventions Functional::  Solutions developed in this project will be deployable and runnable via an API.  This project is currently designed to be deployed to AWS Elastic Beanstalk. Roadmap There is a significant backlog of functionality that needs to be developed. This backlog is currently maintained in my notes but will be moved to a work management system at some point in time.  The following are some of the key functional goals for the near term. Trade File Management process capable of importing trade executions from several broker platforms Extensions to Trade Model to support functionality discussed here Positions, P&L and Cash Balances Time Series and Daily Mark to Market P&L, Risk and Position reporting Trade Fills, Trade Allocations and commission calculations Call to Action Developing an effective Trade Model is a large undertaking, but if done well it can have a profound impact on the technology landscape within the asset management world.  If you are interested in learning how you can contribute.  Please send me a note at maksim_kozyarchuk@yahoo.com

Implementing SOA on AWS

Implementing SOA on AWS by  Maksim Kozyarchuk maksim_kozyarchuk@yahoo.com

History of SOA and SOA in the Cloud    It is a common design pattern to offload processing of business tasks away from the user interface.  This design pattern is at the core of many modern applications and has many benefits including: Improved responsiveness of user interfaces( web, mobile or desktop) Decoupling of presentation and business logic layers, allowing specialization and improving code reuse Ability to effectively scale applications and gracefully handle bursts in user activity    A number of technologies has been developed to support this design pattern under the name of Service Oriented Architectures. The first and most prominent was Java’s J2EE and ESB stacks.  Within the Python ecosystem, Celery with (RabitMQ or Redis) as transport has is a fairly robust and popular implementation of this design pattern.   Technologies such as VMWare and Docker make it possible to run SOA implementation on the cloud with little architectural change.   However, current generation of cloud computing solutions led by AWS include SOA toolkit as part of their managed offering and it’s worth looking at how they may compare to self managed SOA deployments.   In this article, I will walk through setup of Elastic Beanstalk Worker Tier environment and discuss how to used it as the backbone of the Service Oriented Architecture in the Cloud. Components of EB Worker Tier Elastic Beanstalk’s Worker Tier builds on top of Elastic Beanstalk model for deployment, load balancing, scaling and health monitoring.   It adds a daemon process that runs within each EB instance.  That daemon process pulls requests off a preconfigured SQS queue and sends them as HTTP POST request to a local URL.  This simple add-on to the EB stack effectively allows an SOA platform that supports: Rolling upgrades of the underlying software enables A/B testing and zero downtime Automatic scaling and load balancing of the workers Configurable health monitoring of the application Use of HTTP as invocation method makes the platform largely technology agnostic Furthermore, EB Worker Tier also supports dead letter queue allowing for troubleshooting and replay of failed messages. Recent addition of scheduling capabilities into the EB Worker Tier, adds a powerful capability of adding seamless automation of simple repetitive tasks without any additional infrastructure. Implementing EB Worker Tier Implementation of Elastic Beanstalk’s Worker Tier is straightforward and is well documented here.  The only component that was not clearly documented were needed permissions.  To get the right permissions, I ended up adding AmazonSQSFullAccess  and CloudWatchFullAccess policies to the   aws-elasticbeanstalk-ec2-role role used to run my Worker Tier components.     Final thoughts   Cloud service providers have done a great job to accommodate existing SOA platforms in the cloud.  However, when considering a move to the cloud, it is worthwhile to look at new technologies that cloud providers bring.  They will likely help you solve many of the long functionality gaps within your SOA platform.  Another exciting technology emerging in the AWS stack in Lambda which further abstracts the SOA platform.  However Lambda is still fairly new and limiting, supporting only Node.js based deployment.