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.)
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.
2
I’ve done two relevant (for this question) projects. The first uses SOAP, a Java server and a .NET-Client. The second uses REST, but both, client and server, are written in Java.
Your pros and cons seem all valid to me. I personally like REST-style messages more. The main-reason for this is, that it’s very lightweight (in action and development), what you already pointed out. The changes in the message-layer have to be done by hand, but in my projects that hasn’t been a big deal.
In Addition, when you consider to allow usage of your Webservice from other clients, REST might be the better choice, because I never had problems in any language I used with REST, with SOAP it has always been, let’s s exhausting.
But if you feel like there’ll be lot of changes, you might give it another weight. So according to this article, you can get SOAP working without J2EE.
Hope that helps.
1
I compared REST + JSON for interchanging data between .NET client and Java server against traditional SOAP client/server approach. In all both cases, the Java server app is running as a standalone process, and not inside J2EE container.
For .NET client, I tested RestSharp to send the REST requests and handle responses. I found RestSharp to be elegant, easy, and light-weight solution. On the Java server side, I tested Restlet, which was also fairly easy to set up, and also tested Gson for serializing and deserializing objects. After a bunch of fumbling around with Restlet, I was able to test serializing .NET objects to JSON and receiving with Java server. (I found Restlet’s documentation and object model to be confusing, especially in comparison with RestSharp. This is also why I ended up using Gson for serializing/deserializing).
The significant disadvantage I found (but not the only one), is that the Gson deserialization is case-sensitive (as I imagine probably most if not all the Json libraries are), and there was a mismatch between the casing on the .NET side and the Java side. (As an aside, I think whoever decided that variable/property names should be case-sensitive introduced a lot of unnecessary complexity into interoperability. It would be a lot better if all text matching was case-insensitive by default, but globally configurable turn on case-sensitivity. I think that would be far more useful.)
I then compared this with SOAP WS, using VS 2010 to generate the proxy classes, and jSoapServer to run on the Java side. It was up and running with a bunch of operations in minutes (only 1 minor glitch to get prototypes to work).
I have to say that, for simplicity with this tool set (VS 2010 and Eclipse) and set of components (.NET WPF and Java), the SOAP Web Service wins hands down. It is so much easier to manage the coupling between server and client with the WSDL and .NET web service client generation, than it was with JSON (and REST). While I can see the huge benefits of JSON + REST for Ajax and web apps (where you don’t have the SOAP framework easily built in), for a rapid development mode, SOAP was the way to go in this case.
UPDATE
Someone on StackOverflow pointed me to a Gson setting to specify the field naming policy. This resolved the problem between differences between the client and server casing of names. However, it still seems that SOAP offers faster development of new methods and updates to objects between GUI and server (though I may revise opinion in future).
UPDATE
In the end, I selected Apache CXF, which is working awesomely well. Setting up the service in Java was a breeze, and Visual Studio generated all the service classes and web service client without any hitches. Any changes to server interface are very easily propagated to the GUI by having VS update the Service Reference. This turned out to be the appropriate RAD solution for us, given our toolset.