As my first post i thought i’d write on what i am working on nowadays. Few months ago i accepted a work to write a QuickFix integration solution since Borsa Istanbul was having a transition to quickfix.
Even though i never had worked with QuickFix i thought i’d give it a try. I am writing this hoping that my experiances will help someone since there are not much resources on QuickFix/J.
Here are the layers of application that i’ve created:
GUI - Where the interaction happens
Initiator - Where the initiation happens. Not To be mixed with a socket initiator.
Application - Extends quickfix.Application
Outbound - This part takes care of sending messages
Inbound - Recieves and proccesses the messages
I am going to skip the GUI part since it does not have anything to do with quickfix itself.
This layer gets active when user click to connect _button from GUI and approves the connection settings. A new QuickFixInitiator gets started and this initiator basicaly creates whatever needed to create a proper _QuickFixApplication.
This is how the initiation phase looks like for me. First the SessionSettings gets created with a method called createSettingsInputStream() which passes all the settings configurations as an InputStream.
After creating SessionSettings a MessageStoreFactory gets created. This is where QuickFix will store the messages you recieve. LogFactory gets created right after that. Mine is a SLF4JFactory which i use with LOG4J which is must say can look a bit complicated at start but provides huge benefits. Maybe i’ll prepare tutorial on how to integrate SLF4J with LOG4J. Rest of the code is all straight forward. This pretty much sums up this layer.
This layer is where all the magic happens. QuickFix will send and recieve all the messages from this class what you’ll do with them is upto you.
Right after you extend bfix.QuickFixApplication you’ll get you @Override methods. The most important of these methods is fromApp. All the messages you reiceve will end-up here. How we’ll handle will be explained in Inbound layer.
This is how the constructor looks like. In my case multicast messages were getting delivered via UDP port different from Quickfix itself so i had to listen for multicasts on UDP and proccess them just like a normal fix message. So feel free to ignore the multicast part. The object executor is an instance of ExecutorService to handle multiple Threads. At the end of the block you can see executor starting a new Runnable instance of OrderSupplier this is the Outbound layer which we will be talking about next. Rest of the class is overriden method stubs. As you may have noticed earlier i have same boolean values which i pass from initiator to application, these values notices the application if the user wants to “reset password” or “reset message sequence number” while sending a login request. If you want to do the same notify the application in a similar manner and then add this fields to your login message in toAdmin method. This method is a checkpoint where your outbound messages out of a settled session will drop by. Here how it looks like:
Here is fromApp :
Here the messages we recieve will be cracked by a CustomMessageCracker which will be thoroughly explained in Inbound part.
Outbound is the part which takes of message sending as the name suggests. There are few elements in this part. The first one is the OrderSupplier which collects the orders from database and puts them in a LinkedList.
As you can see this runnable here fills a queue ready to be send so that the code which sends messages don’t have to wait for a new database transaction everytime it sends a message which would burden the system greatly. The obscure area here is fetchRequest where a database transaction happens and the data gets decoded to a fix message.
After getting the messages in a queue we have the OrderSender class which sends them according to message per second throttling.
Here you can see the throttling mechanism. After sending the message code starts a new thread of the runnable class OrderRecorder which writes the sent message to database and with that it pretty much sums up the outbound layer.
You may remember the a CustomMessageCracker initiated in QuickFixApplication constructor. This class extends quickfix.MessageCracker and handles all the messages that come to fromApp method in QuickFixApplication.
After this step every method handles it’s own message and does whatever it has to do.
This pretty much sums the Quickfix/J integration that i worked on. Remember that this is only the outline and there are much more to it then these chunks of code. Feel free contact me on topic and i’d be more then happy to help.