litl_phil wrote: While it's nice that Google and Acer share the vision of cloud-based computing, it's also worth noting that we at litl already have a webbook on the market (available at litl.com) that runs our own cloud-based OS.
Unlike Chrome, litlOS is focused on creating a new and better web experience for the home, so we don't have the usual browser interface, we have our own innovative UI. In conjunction with easel mode (litl's inverted-V position) and our growing cohort of litl channels (special apps t...
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!
About Yakov Fain Yakov Fain is a Managing Director of Farata Systems, consulting, training and product company. He has authored several Java books, dozens of technical articles. SYS-CON Books released his latest co-authored book , Rich Internet Applications with Adobe Flex and Java: Secrets of the Masters in Spring 2007. Sun Microsystems has nominated and awarded Yakov with the title Java Champion. He leads the Princeton Java Users Group. He is an Adobe Certified Flex Instructor. Currently Yakov works on the book for O'Reilly "Enterprise Application Development with Flex". He twits at twitter.com/yfain.
>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
#6
Ted Hruzd commented on 3 Apr 2005
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
#5
sleepingbear commented on 22 Nov 2004
<"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.
#4
Vlad commented on 17 Nov 2004
Hi, Yakov:
Unfortunately, not ALL Financial Companies welcome "James Gosling Look-n-Feel".
Nice article.
#3
df commented on 17 Nov 2004
>> 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
#2
GeekInTheCity commented on 16 Nov 2004
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...
#1
Andrey Postoyanets commented on 16 Nov 2004
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.
Yakov Fain wrote: >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...
Ted Hruzd wrote: 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...
sleepingbear wrote: <"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.
df wrote: >> 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 wrote: 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 wrote: 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.
Oracle seems to have divided the open source ranks over the MySQL delay it’s having closing its acquisition of Sun. Eben Moglin, the GPL’s most ardent defender and delineator, the lawyer who has worked hand in glove for years with the Free Software Foundation’s founder Richard Stallman...
Cloud computing is a game changer. The cloud is disrupting traditional software and hardware business models by disrupting how IT service gets delivered. Entrepreneurial opportunities abound as this classic disruptive technology begins to proliferate, so it is no surprise that SYS-CON'...
The irony is that Oracle has advanced MySQL, lost money in the process, and helped its competitors - all at the same time. When Oracle buys Sun and controls MySQL the gift (other than to Microsoft SQL Server) keeps on giving as the existential threat to RDBs is managed by Redwood Shore...
WSO2, the open source SOA company, today announced the launch of the WSO2 Cloud Platform. Available today, the new WSO2 Cloud Platform features a family of WSO2 Cloud Virtual Machines; WSO2 Cloud Connectors for enabling fast, secure cloud services; and the multi-tenant WSO2 Governance-...
Now, the open source Mozilla Thunderbird client software can be used with Open-Xchange collaboration software. The "Community OXtender for Thunderbird" software connector gives users full access to appointments and contacts stored in the Open-Xchange Server and enables them to use Thun...
Morph Labs, a leading provider of enterprise cloud computing technology, today announced an introductory trial of the Morph CloudServer, an open, standards-based server IT organizations can use to rapidly model and evaluate their cloud implementations. A miniature "Cloud Environment in...
.gif)
Oracle seems to have divided the open source ranks over the MySQL delay it’s having closing its acquisition of Sun. Eben Moglin, the GPL’s most ardent defender and delineator, the lawyer who has worked hand in glove for years with the Free Software Foundation’s founder Richard Stallman...
Cloud computing is a game changer. The cloud is disrupting traditional software and hardware business models by disrupting how IT service gets delivered. Entrepreneurial opportunities abound as this classic disruptive technology begins to proliferate, so it is no surprise that SYS-CON'...
The irony is that Oracle has advanced MySQL, lost money in the process, and helped its competitors - all at the same time. When Oracle buys Sun and controls MySQL the gift (other than to Microsoft SQL Server) keeps on giving as the existential threat to RDBs is managed by Redwood Shore...
WSO2, the open source SOA company, today announced the launch of the WSO2 Cloud Platform. Available today, the new WSO2 Cloud Platform features a family of WSO2 Cloud Virtual Machines; WSO2 Cloud Connectors for enabling fast, secure cloud services; and the multi-tenant WSO2 Governance-...
Now, the open source Mozilla Thunderbird client software can be used with Open-Xchange collaboration software. The "Community OXtender for Thunderbird" software connector gives users full access to appointments and contacts stored in the Open-Xchange Server and enables them to use Thun...
Morph Labs, a leading provider of enterprise cloud computing technology, today announced an introductory trial of the Morph CloudServer, an open, standards-based server IT organizations can use to rapidly model and evaluate their cloud implementations. A miniature "Cloud Environment in...
