client-server architecture questions

[antoine]

Hello,

I'm planning the migration of a stock trading application from PC based
to client/server architecture. let me explain:

currently the app. running on a PC connects to:
- a Market Data feed server (receives the feed as text and parses it)
- an Order sending engine (sends orders and receives messages, as text)

the app runs in java, the feed server and order sending engine are
third-party.

so basically, all happens on the PC:
- reception & emission of messages (data & orders)
- computation of prices and other financial data
- order sending algorithm computation
- display of data (moving fast !) and all GUI (buttons, configuration
panels, etc...)

we have several users, each running one instance (each connecting both
to feed & order engine).

I'd like to migrate to a more efficient architecture where I'd separate
graphics & GUI from computation work. The idea would be to have a
single Java server running on one dedicated machine and taking care of
all computations, order sending algorithms, etc, with several clients
connected to it, which would then only be "terminals" to display market
data and send commands to the server via GUI. The idea is to offload
the GUI work from the server and improve performances.

only the server would be connected to the market feed and order engine.

I'm wandering which technology I should use to have clients and server
communicate with each other in the most efficient way. The tasks to be
implemented would be:
- server sends info to update market data on client's GUI (basically
values in a JTable)
- client modify server parameters through its GUI
- client triggers order sending on the server

I'm thinking about two options:
- using RMI: server invoques methods on the clients, clients invoque
methods on the server
- implementing a simple text message protocol

I'd like to get guru's advice on what would be pros & cons of each
method, and what other technique I could use.

ultimately, the idea would be to have clients and server in different
places (countries), so bandwidth might be an issue. of course
reliability is fundamental...
Thanks for giving me your advice !!

Antoine

 

[Robert kebernet Cooper]

Hmm... I tend to try and opt for SOAP over RMI for tier to tier
messaging now. No reason you couldn't use that for all your business
actions.

With regards to streaming price information, though, I suspect you
would want something a little more seamless.

My inclination would still be to just use and XML output streaming-HTTP
of data off the server, deserialize in small packages then update beans
to your JTable. It's not as elegant a solution as RMI EventHandlers, I
suppose. JMS is the more obvious option in the API stack, but I imagine
that becomes a question of performance vs clients, etc. I have had good
luck with high-volume message delivery with both JORAM and SwiftMQ (2m+
messages/hour on a mid-range server), but I don't know how much data
you are really talking about and I have never really tracked the
latency vs throughput there. It might be worth prototyping.

I will say this. Building your own protocol, however simple, is always
at the very bottom of my list of things to try. I spent time in a shop
like that, and it made me want to scream.