|
Thin client vs client/server architecture
I work with developing an application that allows users to connect to a specific stock exchange and trade stocks. The application is a normal Windows which connects to the exchange through a proprietary C API. The user have to login to get a session going. The application receives a lot of information continuously with market data. The user can send and manipulate orders.
The application is old, like 10 years and ported from some other OS and originally written in C. The code is not very well layered and non object-oriented. It is ported to MFC and Visual C++ but very messy and nowadays impossible to maintain. We have lots of bugs which require constant bug fixes and frequent unpopular product updates.
We will therefore start over and develop a similar application from scratch. My customer, the stock exchange, has requested (among other) the following features:
1. Possible to upgrade application while still running the application or without having to logout and loose the session if it's possible, depending on type of upgrade.
2. The application should have the look and feel of a normal Windows application so a web browser solution is not acceptable.
3. Have high performance and should be able to receive large amount of market data without freezing or starting to act sluggish.
4. Store user settings globally, that is whatever PC you use to login with, your application settings should be used automatically, even you never used that PC before.
So what kind of architecture is most suitable for us?
Requirement 1 suggests putting most of the functionality on a server, so upgrades can be done without bothering users? However, how do you upgrade a running server without kicking out users? Using several servers and upgrade them one by one and run different versions of the software? Or use fat clients and upgrade the clients by some mechanism like the automatic Windows update? Have anyone besides Microsoft implemented that?
Using a thin client, that is a dumb client, will lead to that more data needs to be sent than using a smart client. A smart client will be able to process data and compute information by it self, while a dumb client needs everything sent to it. For example, the smart client can gather statistics from individual trades and order, but the dumb client needs everything computed and sent for it. This will affect the performance, since usually API calls are costly and requires a lot of overhead so it is better to compute it locally.
Has anyone ever developed a thin client that works as a normal Windows application, but is generic and pretty much just displays stuff received from a server and sends back user actions for server processing?
User settings should be stored globally. The exchange’s API does not handle user settings for client applications so we can’t use that option? This means that we need some sort of server, at least a simple XML database server.
I’m afraid that the thin client will not be good enough, that users will not be able to configure it and use it as a normal Windows application and that will feel slow. My fear could also be from the fact I never done anything else than fat Windows clients before. What architecture would you guys suggest and has these problems been tackled before?
Mellowman
Thursday, December 4, 2003
It sounds like the people defining the specifications are a bit jaded with respect to the old application and its need for constant patches. You should ask them if the requirement for hot upgrades is absolutely necessary or if it is a byproduct of the volume of upgrades associated with the old system. I suspect it is the latter, in which case they don't really need hot upgrades, they just want less downtime.
It does sound like you're going to have a relatively thin client, we actually just implemented one here. The windows are all defined but the data displayed is all driven from the database. The only reason we have to patch the front end is to enable new features, change the screen layouts, or tweak the queries.
All the drop down menus and definitions of required fields and user settings are stored on the database. So a large number of changes can be made without anyone experiencing downtime.
Now for the caveat, we're running VPNs over DSL from remote sites to our data center and we're still experiencing some lag. There's a lot of data being tossed around. Our lag runs no greater than 10 seconds, but your traders might not be willing to tolerate that. I would mention that to the people defining the specs. It is a tradeoff. We made it and we're happy with it, but your situation is different. Best of luck.
Lou
Thursday, December 4, 2003
I've written a number of finance applications using a web browser for the client. These include several trading programs. I got around the "it's not fast like a Windows" app by using a variety of tricks, including using frames to split out processing, and using some IE specific items like the ModalDialog ability. Believe me, we have picky users, and they're good with what they've got. Updates are seamless, and most of the performance battle was fought on the servers (in particular communication between the database and web servers).
Code Monkey
Thursday, December 4, 2003
"1. Possible to upgrade application while still running the application or without having to logout and loose the session if it's possible, depending on type of upgrade."
If you refine this requirement so that it says (something like) "be able to upgrade the program so that new sessions use the new version without having to have users log out", it's fairly easy.
Write a very thin program that runs another program (the real one). When upgrading, have the thin program point to the new version.
I don't think there is any *simple* way of updating the executable code dynamically for an already-running program. (You might be able to do something hairy with dynamically binding DLLs).
njkayaker
Thursday, December 4, 2003
How about using the MS HTML control inside your application? That way you get to make it look more or less like a standard Windows app, but it's really a web app.
Maybe that's cheating, but it seems to me the simplest solution.
Steve Barbour
Thursday, December 4, 2003
"1. Possible to upgrade application while still running the application or without having to logout and loose the session if it's possible, depending on type of upgrade."
This reminds me of the story of the FAA's failed new air traffic control system (read about it in this book: http://www.amazon.com/exec/obidos/tg/detail/-/013673443X/qid=1070570594/sr=1-13/ref=sr_1_13/103-7540567-1687852?v=glance&s=books ).
If I understand what you're talking about and it's what they were trying to do, then it's essentially impossible. Also, it's basically pointless: if you really want to do this, then have 2 servers, and when you're ready to upgrade one of them, have it stop accepting new connections. Then, after a suitable amount of time has passed (a minute, an hour, a day, you decide), kick off any users still logged on, and proceed with the upgrade. They can just use the other server. Then, bring the upgraded system on-line, and repeat with the other server.
Exception guy
Thursday, December 4, 2003
Hi,
It sounds like you might be replacing something that I worked on 7 or 8 years ago :)
With current technologies I would suggest and traditional c/s application. Using VS.Net and a nice feature, you can have updates to your app be automatically deployed when the user starts the application.
Conversely if you don't feel like going the VS.Net route and want to stick with VB or Delphi or even C++ for the UI, I would suggest reading up on the Windows Installer technology. With it you can have an update be automatically applied to a client box with little to no intervention.
HTH,
Kevin
Kevin Moore
Thursday, December 4, 2003
"1. Possible to upgrade application while still running the application or without having to logout and loose the session if it's possible, depending on type of upgrade."
So I guess Windows is out.
Doh!
Thursday, December 4, 2003
Speaking of which, if someone knows of a good article on the strategies available to perform live updates, either on a fat client or on the servers, I'm interested. I think this has been discussed here before, but "live update" returns waaaaay too many links :-)
As usual, you should take a look at ActiveX controls embedded in web pages. I'm not sure how reliable that would be in an intensive-use context like trading, but you can always build a simple prototype in VB and run intensive tests to see how steady this solution is.
Frederic Faure
Friday, December 5, 2003
There *are* systems that allow live upgrades while a program is running, but you have to use languages like LISP or Smalltalk to get that capability.
The href-exe option in .NET is a really good one. The idea is you click on a link, and the exe is downloaded from the web site to the client. The exe runs on the client, but is sandboxed so you don't have the security concerns you usually would in this scenario.
The nice thing is that to deploy an upgrade, you just push a new copy of the client app to the web server and the client will automatically put it down the next time they run. This isn't really hot upgrades, but it's pretty close.
Chris Tavares
Friday, December 5, 2003
 Recent Topics
Fog Creek Home
|
