What Patterns/Technologies have people used to pass Trading Data between between the service layer and GUI later?
To explain a bit more….Assume you a building a Basket Trading application for 20+ users. This application must be able to view the basket and its related market data in realtime and also edit the basket and market orders in realtime.
The GUI will also need to display the PandL for the whole basket.
What patterns/technologies would you use to ensure that the GUI is kept up to date and that coomands are processed by the server layer efficiently?
I have seen many different approaches to this problem, but I’m interested to see what others have done or are planning to do.
Some more specific questions are:
1) How thin/thick do you make the client?
2) What kind of IPC technology is utilised?
3) Do you have dedicated GUI ‘server’ processes?
4) How to you deal with data sets that are too big to store on the Client
Its an open question, so hopefully this will provoke some discussion!
We (the company I am working for) used Microsoft CAB once. But good/old MVC will always do. Use a good pub/sub server with throttling capabilities, it is pointless to show all (e.g.) 1000 updates per second when the human eye can handle just 24 frames per sec. Subscribe only to the relevant topics. Message processing, calculations and drawing must be handled by different threads, ideally on separate CPU cores. If charting is essential and is very intensive, use a product that knows how to use GPU (and make GPU part of the hardware requirements). GUI side storage must be used only for performance reasons (like a cache), e.g. once unsubscribed from the topic – clean the relevant storage, this also means that if GUI crashes it must be possible to completely restore the state from the server. Never subscribe to the same topic multiple times, fake it like a “smart ptr with reference counting”. Never (or at least try not to) keep amended (by the user) values in the GUI once sent to the server (there is a risk they will not rich the server or the relevant server side component (UDP), or they will be superseded by the values from another user), amended values should come from the server (as a confirmation, if everything is fine and with no concurrency). All these, obviously, mean that point 4 is a tough question. Split the volume (if possible) so that part of it can be stored on GUI, and again treat this as a cache or implement something that will tell to the GUI when to update the content (e.g. user preferences/portfolio vs. standing data). Also, if you know the volume, use memory mapped files
NOTE I now post my TRADING ALERTS into my personal FACEBOOK ACCOUNT and TWITTER. Don't worry as I don't post stupid cat videos or what I eat!