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.
A parameter you need to consider which you don’t mention the deployment environment.
1) Is this a private application running running behind a fenced network or a web application exposed on a public network?
2) Is this going to be deployed on public or private cloud?
3) What platforms are you running and supporting; Window and/or iOS and/o rLinux)?
I like GWT as a technology for web based clients and have used it successfully for several web-service based applications. It provides great scalability client-> presentation->sevice tier abstractions and allows you to develop in a single language (java; compiling it to highly optimized platform dependent java script on the client.), which makes the code base easier to maintain.
Also pay attention to evolution of your code. Not all trading GUIs need be extremely efficient because almost always, throttling makes sense (assuming the server is processing the bulk of the logic). In that case, an efficient but iterative protocol like google protobufs can work.
- Assuming you are using java platform, i think a java web start client should be a good choice IMHO, i think pure web/ajax clients are cannot keep up with fast data exchange and rich interaction with users (eg: realtime charts)
2. I think a message oriented architecture should be ok in this case; depending on your needs you could either use message broker (for example qpid) for everything or messages ( which are obviously asyncronous) for data push and web services for basket and order editing (syncronous); data inside messages/web services should be serialized with some serializing protocol; again if you use only java, you cuold pass transparently persistent objects from db-layer to gui and the other way round quite simply, for example using Hibernate (ORM/DB persistence), Spring (general purpose framework), Gilead (syncs persistent object between client and server) and Xstream (serializing libraries). If you are multi-platform, you could use protobuf but need some extra manual-step to make object “travel” across layers.
3. I think the server should not contain any GUI logic, but exposes a reasonable series on services (accessible via messages or web-service)
4. Service layer should have methods that return paginated data.—
We use FrozenMountian’s WebSync product to instantly communicate between client/server (and client/client). It is hosted in IIS and has been great. I don’t work for them, just really like their product. They have a free version to try out.
• Thanks for the comments so far – great stuff
Just to scope the requirements a bit – this will be an ‘internal’ application – i.e. no external clients.
There is no limit on platform types or use of clouds, languages etc
– although I’d be interested to see if cloud computing is applicable to a high frequency application such as this!
It depends on the performance requirements (e.g. latency). For instance Amazon Queue (http://aws.amazon.com/sqs/) has a latency of 1-10s (https://forums.aws.amazon.com/thread.jspa?threadID=58114). Clearly no acceptable if requirements say (e.g.) 0.5s
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!