The Demonstration Results and Charts
To run the demo, you need the quote update application, the trading engine (both real-time and non-real-time versions), and the JavaFX-based chart application (download them all here
). A standard Java EE JMS provider is required to transport the quote data; I used the one that comes with Sun's Java EE 5 application server. To configure it, create a JMS topic destination with the name jms/QuoteUpdates
To see the difference between the non-real-time and the real-time versions of the OrderManager, run the chart application. This JavaFX application uses JFreeChart (open-source).
(Note: Many thanks to Jim Clarke at Sun for his work on the JavaFX version of the charting application.)
Figure 5 shows the output from the non-real-time version of the trading engine. Notice the many missed trades, the loss of money, the variation of time in the time-critical loop (indicating interruptions), and the GC events (shaded vertical bars). Overall, this represents lost money to the simulated financial institution.
The output from the real-time version is quite different (see Figure 6). Notice that it has no missed trades and no loss of money. The period for the time-critical loop is constant (indicating no interruptions), and while GC events still occurred (shaded vertical bars), they didn't impact critical processing.
Running the Demonstration Application
Running the demo requires multiple steps, and it may take some work to get it running the first time. First, download and install an evaluation copy of Java RTS version 2. Note that you must install it on a PC running Solaris 10 (x86/x64 or SPARC processor). If you must, you can install it on Solaris 10 on VMware or some other virtual server software, but you most likely won't get the real-time behavior.
Next, ensure that your JMS provider is configured and running (it should have the jms/QuoteUpdates topic defined). Since the trade notifications are sent out as JMX MBean notifications to the chart component, it's best to run it with an application server as your JMS provider.
Next, run the chart application via the following command (with the IP address of the server running your application server where indicated):
java -jar dist/RTfx.jar com.sun.oss.trader.fx.Main -- -host <app server IP address>
(Note that you can run the chart application from any machineit doesn't have to be on the Solaris 10 box with the trading engine.)
Next, start the trading engine (non-real-time or real-time version) from within NetBeans on Solaris. You can develop Java RTS applications within NetBeans or Eclipse on any platform, but Sun provides a NetBeans plug-in specifically for debugging Java RTS applications on Solaris. You can also execute it from the command line with the following commands:
Finally, to start the flow of quote updates, change the directory for the Quote Publisher application and execute the following command (with the JAR files for your JMS provider in the classpath):
java –jar dist/QuotePublisher.jar
Shortly after you start the applications in that order, you should see trade data update on the graph. Typically, for the non-real-time version, you will see garbage collection events coincide with losses (missed market ticks) as the trades are graphed. The graph will dip down into the negative region, and the line will turn red to indicate this. For the real-time version, the trades will form a straight line, as no market ticks are lost.
Most importantly, you should notice that even with the real-time version garbage collection still occurs. However, it doesn't interrupt the time-critical trading code, and Java RTS ensures that no real-time thread periods are missed.
How Hard Was That?
This sample application should prove that developing real-time applications in Java is relatively easy. In fact, the overall amount of code changes required to real-time enable the trading engine was minimal.
As with any real-time application, however, more effort may be required when you design your own real-time Java application because you need to ensure important events are handled with the proper priority. Still, you should be able to continue writing Java code mostly as you do today; it's the job of Java RTS to maintain real-time behavior.