6.5 million software developers and still going strong

Java Developer Magazine

Subscribe to Java Developer Magazine: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Java Developer Magazine: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Java Developer Authors: Stackify Blog, Pat Romanski, Hollis Tibbetts, Andreas Grabner, Sumith Kumar Puri

Related Topics: Java EE Journal, Java Developer Magazine

J2EE Journal: Article

Grids, Blades, and Java - Wall Street's Top Technologies

Java on Wall Street

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!

More Stories By Yakov Fain

Yakov Fain is a Java Champion and a co-founder of the IT consultancy Farata Systems and the product company SuranceBay. He wrote a thousand blogs (http://yakovfain.com) and several books about software development. Yakov authored and co-authored such books as "Angular 2 Development with TypeScript", "Java 24-Hour Trainer", and "Enterprise Web Development". His Twitter tag is @yfain

Comments (7) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Yakov Fain 04/03/05 08:13:44 AM EDT

>Which ECN is the fastest for high volume transactions (say over 2000/sec) ?

I do not have the exact numbers, but Island Electronic Communication Network is probably one of the best ECNs (they claim more than 10000 messages per second). What's more important that they have scalable architecture built on thousands of servers.

>So, is Java preferred to C for executing trades ?
I do not want to open this can of worms again J Here's a short answer: If you'll benchmarks C and Java language elements, C is faster. But in Java you can build a schalable application using multithreading, messaging, app servers that will beat C hands down. You can say that you can do the same using C, but it'll cost you many times more than in Java.

>Can Java 1.42 handle this or is Java 1.5 the solution ?
We did it using Java 1.3 and Java 1.5 would make it faster without changing even one line of code. Just start your servers using Java 5.0 JVM.

>Unix and C have issues with memory maps and persistance to disk. Unix Shared memory may be faster. Java has the infamous JVM and Garbage collections, but if properly tuned and with multiple Matching Engines, thus multiple JVMs, can Java be faster than C ?

Java has its issues, but again, properly designed J2EE applications can be blazing fast

>How about the Java based Berkeley DB (from SleepyCat Software) that
resides in the JVM ? Is such a solution Java's answer to Unix Shared memory for speed ?

We used a small J2EE vendor that added so called pinned-to-cache feature that would allow keep entity beans in memory minimizing the number of database requests. For example, if you need to find an OrderBean, it may be found in memory. I'm sure Berkley DB may have its advantages over persisted DBMS, but I'd also consider using non-persistent messages that are stored in memory.

Regards,
Yakov

Ted Hruzd 04/03/05 07:21:06 AM EDT

Yakov:

I like your Nov 2004 JDJ article regarding "Java on Wall Street", especially a summary regarding how Java applications for brokerage trading can scale.
How about the Matching Engine side - to quickly receive, store, match buy/sell orders, and ultimately trade orders ? I hear that Instinet uses a Java Matching Engine (maybe multiple ones ... to scale), and that ArcaX runs Matching Engines with Solaris / C, and that Nasdaq SuperMonTage is an HP ( Tandem NonStop ) multiple Server solution. Nasdaq purchased Brut recently.
Brut is a Solaris shop but I am unsure whether its Matching Engine is C or Java. Which ECN is the fastest for high volume transactions (say over 2000/sec) ?

So, is Java preferred to C for executing trades ? Can Java 1.42 handle this or is Java 1.5 the solution ? Unix and C have issues with memory maps and persistance to disk. Unix Shared memory may be faster. Java has the infamous JVM and Garbage collections, but if properly tuned and with multiple Matching Engines, thus multiple JVMs, can Java be faster than C ?
How about the Java based Berkeley DB (from SleepyCat Software) that resides in the JVM ? Is such a solution Java's answer to Unix Shared memory for speed ?

I enjoy reading all of your articles and would greatly apprecaite your perspective. I have been a Java Programmer, then Performance Engineer over the past 10 years.

regards,

Ted Hruzd

sleepingbear 11/22/04 06:15:57 PM EST

<"slow XML" will be as funny as a "slow Java" is today.> -- back when everything was a lot slower, electronic data interchange standards groups went to a lot of effort to minimize bytes transferred and interpreted. "SUN,100" can be compressed a lot more. But it is not self-defining nor human readable then -- one of the motivators for XML. OTOH, not many people I know actually read or write XML much.

Vlad 11/17/04 10:16:45 PM EST

Hi, Yakov:

Unfortunately, not ALL Financial Companies welcome "James Gosling Look-n-Feel".

Nice article.

df 11/17/04 05:53:35 AM EST

>> the C/C++ will always run faster than Java kind..

for last 1-2 years it is not true anymore

you can find lot of benchmarks, where the speed is similiar or even little bit faster for JAVA

e.g. C++ segmentation of the heap memory can be a performance problem, which is solved by the JAVA GC

GeekInTheCity 11/16/04 11:04:06 AM EST

I was a sceptic... the C/C++ will always run faster than Java kind... the requirements kept coming in so fast that I didn't have time to write it in C++ and now our Order Management System is 100% Java...

Andrey Postoyanets 11/16/04 12:08:14 AM EST

Awesome article! Thanks Yakov!
It's always sad to hear that "Java is slow/not applicable for real-time apps" from people who tried Java 3-5 years ago and it did not work out for them; Yakov is referring to the trading system application that was developed during the same time! Java itself has become more mature since then and many products (profilers, optimizers, test tools etc.) were developed/enhanced. All of this helps to meet performance objectives and ensure hardware scalability versus software rewrite, if proper system architecture solutions are applied. You just have to keep your knowledge up-to-date and love the work you do.