| By Yakov Fain |
Article Rating: |
|
| November 15, 2004 12:00 AM EST |
Reads: |
36,635 |
Front office financial applications that place and execute orders are different from many others, since real-time trading systems must be blazingly fast and reliable. A few seconds delay may cost a financial brokerage company millions of dollars and potential penalties.
If, back in the '90s, you'd suggested using Java for processing split-second stock market orders, most of the New York programmers would just simply say: "faggedaboudid." If you want to have some fun, read old articles on using Java for Wall Street applications. Here are some statements made a long time ago in 1997:
- Java is strong on the front end, but we do not foresee it being used for very large number-crunching applications.
- Java is fine only for very thin clients.
A couple of years ago I was participating in the design and development of a multitier and multiplatform equities trading system that was built around Java Messaging and Enterprise JavaBeans (both session and entity beans). This real-time system has successfully replaced a legacy C++ application, has been deployed in production, and worked happily ever after. Not only was it more stable than the legacy system, but it was a lot more scalable. Multithreaded listeners retrieve orders from one or more message queues and send them to a cluster of J2EE application servers. Need more processing power? Just add another application server to the cluster, add more queues, and purchase additional communication lines with the stock exchange. No code changes required.
This Fall I attended the conference "High Performance Technology on Wall Street" and if I had to describe this event in only one word, I'd use the word "grid." If I was allowed to add a second word, this would be "blades," and the third one would be "Java."
Software vendors have casually talked about using various Java technologies in high-speed real-time applications. Most of the vendors were either presenting software or hardware for grid computing. Blade servers are also becoming popular. Blades have nothing to do with shaving. Just imagine a metal cabinet with multiple narrow slots. Each slot hosts a blade server, which is a board with two or four processors, memory, and a local hard drive. All blades share high-speed I/O switches for communication with the rest of the world. Grid servers and agents are the software that supports such parallel computing.
Speakers presented colorful diagrams with hundreds of parallel jobs running on a grid; if one of the servers fails, the job gets redirected to another blade. Nice! But let's look at this technology from a practical point of view. Proprietary computation-centric, financial analytic software can be more or less easily divided into a set of parallel Java jobs. But how about running a hundred parallel application servers? This is also possible...if you have the budget to purchase hundreds of licenses for production, contingency, and QA environments. Most likely, these hundreds of servers will need to access either some data warehouse or a transactional database. If your system can't move the data fast enough between your application servers and the database, I/O may become a bottleneck of such a system. It's like driving a Ferrari on local streets.
I like this powerful technology and encourage you to present it as an option to your users. Can you process terabytes of data? Yes! Can you double the throughput? Sure! Technology is available...as long as you guys can afford it.
Another interesting topic was using XML for real-time systems. We already got used to application servers, database servers, Web servers, directory servers, intelligent business servers...please welcome: XML Server Farm. These agricultural machines are responsible for parallel XML parsing. If a system needs to send an order to a stock exchange to buy a hundred shares of SUN, we try to minimize the number of bytes that have to be processed, and "SUN,100" looks more attractive than "<Symbol>SUN</Symbol><Quantity>100</Quantity>". Who knows, maybe a couple of years from now the "slow XML" will be as funny as a "slow Java" is today.
Java feels at home in middle and back office applications that calculate risk and perform financial modeling utilizing functions for nonlinear optimization, statistical analysis, time-series analysis, and others. Some applications analyze trades that have already happened. As the brokerage industry introduces more and more regulations, financial giants are being fined heavily for cutting corners and breaking the rules. Applications that can process enormous amounts of data and weed out violations receive prime funding. Even though these Java applications may not need to process orders in real time, they also need a lot of power to sift the terabytes of data through various rule engines. These business intelligence servers use such in-memory gadgets as embedded Java databases, asynchronous nonpersistent queues, data caching, and parallel processing. Have I mentioned grids and blades yet?
Some heavy-duty Java gurus try to stay away from business applications, believing that the real fun coding is in companies that develop compilers, browsers, search engines, application servers, and the like. Trust me, these IT guys on Wall Street are not counting crows either. What's even more important for real geeks, you can work for a solid financial company and have as many earrings as you'd like, a long ponytail, grow a beard, and wear T-shirts and jeans. Wall Street welcomes the James Gosling look and feel!
Subscribe to JAVA Developer's Journal Email News Alerts
Subscribe via RSS
