Suggestions for connecting .NET WPF GUI with Java SE Server aoo
Posted
by
Sam Goldberg
on Programmers
See other posts from Programmers
or by Sam Goldberg
Published on 2012-10-29T16:13:36Z
Indexed on
2012/10/29
17:21 UTC
Read the original article
Hit count: 346
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.)
© Programmers or respective owner