BACKGROUND
We are building a Java (SE) trading application which will be monitoring market data and sending trade messages based on the market data, and also on user defined configuration parameters.
We are planning to provide the user with a thin client, built in .NET (WPF) for managing the parameters, controlling the server behavior, and viewing the current state of the trading. The client doesn't need real-time updates; it will instead update the view once every few seconds (or whatever interval is configured by the user).
The client has about 6 different operations it needs to perform with the server, for example:
- CRUD with configuration parameters
- query subset of the data
- receive updates of current positions from server
It is possible that most of the different operations (except for receiving data) are just different flavors of managing the configuration parameters, but it's too early in our analysis for us to be sure.
To connect the client with the server, we have been considering using:
- SOAP Web Service
- RESTful service
- building a custom TCP/IP based API (text or xml) (least preferred – but we use this approach with other applications we have)
As best as I understand, pros and cons of the different web service flavors are:
SOAP
pro: totally automated in .NET (and Java), modifying server side interface require no code changes in communication layer, just running refresh on Web Service reference to regenerate the classes.
con: more overhead in the communication layer sending more text, etc. We're not using J2EE container so maybe doesn't work so well with J2SE
REST
pro: lighter weight, less data. Has good .NET and Java support. (I don't have any real experience with this, so don't know what other benefits it has.)
con: client will not be automatically aware if there are any new operations or properties added (?), so communication layer needs to be updated by developer if server interface changes.
con: (both approaches) Server cannot really push updates to the client at regular intervals (?) (However, we won't mind if client polls the server to get updates.)
QUESTION
What are your opinions on the above options or suggestions for other ways to connect the 2 parts? (Ideally, we don't want to put much work into the communication layer, because it's not the significant part of the application so the more off-the-shelf and automated the better.)
Best Answer
To give a different choice, try a non-connected but bi-directional protocol such as a message queue (of which my preference would be ZeroMQ) where you can push changes to the client, and if the client happens to be disconnected, it'll get them when it next connects, and you can push updates to all connected clients very easily. (there are plenty of topology scenarios you can support with a message-passing architecture).
You will care if you have a lot of clients all polling the server for updates, so if you're looking to have several clients, its best to think of this from the start.