Final Report Master Thesis MAS-06-01.04 - BFHstatic.sws.bfh.ch/download/MAS-06-01-04-doc.pdfMaster Thesis SWX Off Order Book Trading Final Report Abstract The Off Order Book Trading

Master Thesis

SWX Off Order Book Trading

Final Report

Abstract The Off Order Book Trading system is a SOA oriented Java EE 5 based multi-tier application that supports the quote request, quote and offer list quotation models.

Key Words Java EE 5, SOA, BPEL

Student Ralf Battenfeld, 041 790 73 43

Class MAS-06

Master-Thesis No MAS-06-01.04.DMT

Supervising Tutor Rico Piantoni, 058 854 27 90

Supervising Tutor Hans Burkhard, 058 854 27 36

Expert Dr. Stephan Fischli

Master Thesis 17/12/08


Table of Contents

1. Introduction.......................................................................................................................................3

1.1 Purpose & Scope....................................................................................................................31.2 Changes since last Version....................................................................................................31.3 Definitions & Abbreviations.....................................................................................................31.4 References..............................................................................................................................41.5 Outstanding Issues.................................................................................................................5

2. Management Summary....................................................................................................................6

2.1 Business Perspective..............................................................................................................62.2 Technology Perspective.........................................................................................................6

3. Analysis.............................................................................................................................................8

4. Design...............................................................................................................................................9

4.1 Hardware View........................................................................................................................94.2 Runtime View........................................................................................................................10

4.2.1 Overview of EJB Mode............................................................................................114.2.2 Overview of BPEL Mode.........................................................................................124.2.3 Overview of JMS Mode...........................................................................................13

4.3 Logical View .........................................................................................................................144.3.1 Application Details...................................................................................................144.3.2 BPEL Processing Details........................................................................................194.3.3 BPEL Process Guidelines.......................................................................................22

4.4 Data View..............................................................................................................................234.4.1 FIX DB Schema.......................................................................................................234.4.2 Flat Quote Table......................................................................................................234.4.3 Data Store Size.......................................................................................................24

5. Performance Tests.........................................................................................................................25

5.1 Synchronous Communication...............................................................................................255.1.1 Concurrently Generated Load................................................................................255.1.2 Sequential versus Concurrent Processing..............................................................265.1.3 Batch Size Performance Impact using Web Services and RMI (IIOP)...................275.1.4 Transaction Atomicity and Durability Test...............................................................285.1.5 BPEL Test...............................................................................................................295.1.6 Asynchronous Test..................................................................................................30

6. Reflection........................................................................................................................................31

7. Appendix.........................................................................................................................................33

7.1 Using POJOs and Dependency Injection.............................................................................337.2 Migration to JBoss................................................................................................................337.3 Running Unit Tests...............................................................................................................34

2/34



1. Introduction

1.1 Purpose & Scope

This document describes the design of the Off Order Book Trading application. The application allows us to test several communication protocols as well as several internal processing paradigms. In the real world, all these different communication protocols and internal processing options are redundant. However, this Masters thesis explores the performance impacts of all these different processing methods, because the outcome may provide important input for a future project that has been scheduled for a later date.

It is important to note that some of the performance tests were executed on two different application servers. It is not the goal of this Masters thesis to assess the performance of the two application servers. Therefore, the performance differential between these two application servers is of little importance. The purpose of our migration tests was only to verify the portability of the application.

The report focuses on the application. External client programs are not described in this document.

1.2 Changes since last Version

Date Description

28.10.2008 First Draft

01.12.2008 Completely rewritten; all chapters have been reorganized.

15.12.2008 Final Version.

1.3 Definitions & Abbreviations

Term Definition

OOB Abbreviation for Off Order Book

EJB Mode Run mode using JAVA EE 5 APIs only

BPEL Mode Run mode using BPEL processes to orchestrate composed EJB services

JPA The Java Persistence API, sometimes referred to as JPA, is a Java programming language framework that allows developers to manage relational data in Java Platform, Standard Edition and Java Platform, Enterprise Edition applications.

JDBC Java Database Connectivity (JDBC) is an API for the Java programming language that defines how a client may access a database. It provides methods for querying and updating data in a database. JDBC is oriented towards relational databases.

FIX The Financial Information eXchange ("FIX") Protocol is a series of messaging specifications for the electronic communication of trade-related messages.

Fast InfoSet Fast Infoset specifies a standardized binary encoding for the XML Information Set. https://fi.dev.java.net/

BPEL WS-BPEL (or BPEL for short) is a language for specifying business process behavior based on web services.

Contra Firm The broker or other firm on the contra side of the trade.

CUG The Closed User Group business model allows groups of participants to trade on a virtual exchange.

EJB EJB is a managed, server-side component architecture for modular construction of enterprise applications.

Entering Firm The broker who has recorded or reported an execution. This field is

3/34

https://fi.dev.java.net/

http://www.w3.org/TR/xml-infoset/

http://www.w3.org/TR/xml-infoset/

http://www.fixprotocol.org/specifications/

http://en.wikipedia.org/wiki/Relational_database_management_system

http://en.wikipedia.org/wiki/Database

http://en.wikipedia.org/wiki/Java_(programming_language)


http://en.wikipedia.org/wiki/Application_programming_interface

http://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition

http://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition

http://en.wikipedia.org/wiki/Java_Platform,_Standard_Edition





particularly useful when the trade is entered into a trade recording system by a broker who is not a party to the trade, as it allows any inquiries or problems to be directed to the appropriate source.

ESB Enterprise Service Bus is an abstraction layer on top of an enterprise messaging system and is used to loosely couple computer software systems in a service-oriented architecture.

Java EE 5 Java Enterprise Edition 5 platform

Market Maker Market makers must maintain continuous two-sided quotes (bid and ask) within a predefined spread. A market is created when the designated market maker quotes bids and offers over a period of time. Market makers ensure that there is a buyer for every sell order and a seller for every buy order at any time.

Price Taker Price takers can make a buy or sell decision, and the output is assumed not to affect the price.

QPS Quotes Per Second defines how many quote messages can be handled by the application. It can also be used to express quote requests per second or offer lists per second.

Quotematch The SWX high-performance system for trading in securitized derivatives.

Respondent A ”respondent” may be one of the following:

• a broker/dealer

• an inter-dealer broker (or broker’s broker)

• an electronic service

• bid or offer prices provided by one or more market makers

• bid or offer prices provided by an inter-dealer broker

• matching system with limit orders entered by customers (dealers or institutions)

• an issuer

SOA Service Oriented Architecture is a computer systems architectural style for creating and using business processes, packaged as services.

Strict Limit (No Price Improvement)

A limit order that must be traded at the exact limit price specified without any price improvement. Requires OrdType=Limit.

Suspended The order is not eligible for trading. This usually happens as the result of a verbal or otherwise out-of-band request to suspend the order, or because the order was submitted or modified via a cancel/replace request, with ExecInst=Suspended.

SWXess The new SWX trading platform.

SWX The SWX Swiss Exchange is a central link in the value chain of the Swiss financial marketplace. It organizes, operates and regulates key aspects of Switzerland's capital market.

VMware ESX VMware ESX from VMware, Inc. presents a completely virtualized set of hardware to the guest operating system.

1.4 References

Reference & Document Title Applicable Reference and Version

Implementing SOA Implementing Service-Oriented Architectures (SOA) with the Java EE 5 SDK

SOA in Practice SOA in Practice, The Art of Distributed System Design, Nicolai M. Josuttis, O'Reilly, August 2007

DSI Requirements Specification for Data Synchronization Interface (DSI)

EJB FAQ https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html#StandaloneRemoteEJB

JavaBeans 3.0 Enterprise JavaBeans 3.0, Bill Burke & Richard Monson-Haefel, O'Reilly, Fifth Edition, May 2006

4/34

https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html#StandaloneRemoteEJB

https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html#StandaloneRemoteEJB



Pro EJB 3 Pro EJB 3, Java Persistence API, Mike Keith and Merrick Schincariol, APRESS 2006

Unofficial JAXB Guide https://jaxb.dev.java.net/guide/

Java EE 5 Architekturen Java EE 5 Architekturen, Patterns und Idiome, Adam Bien, Entwickler.Press, 2007.

wp-timesten70-appsrv Configuring Oracle TimesTen 7.0 for Application Servers and Object-Relational Mapping Frameworks

TimeTen Operations Guide Oracle TimesTen In-Memory Database Operations Guide

TimesTen Best Practices http://www.oracle.com/technology/products/timesten/pdf/wp/tt70_good_practices.pdf

MAS-06-01.04.SoftwareReqSpec SWX Off Order Book Trading Software Requirements Specification

1.5 Outstanding Issues

5/34



2. Management SummaryThis chapter summarizes the findings of this project. It aims not to give advice at the product level, but instead to discuss the architecture and the APIs involved.

The requirement specification [MAS-06-01.04.SoftwareReqSpec] defines the following business objectives and success criteria:

VS-SC-1: The system is able to support up to 10 market makers. Each market maker can create up to 30 QPS.

VS-SC-2: The system is able to support 100 price takers. Each price taker can receive quotes from every market maker

VS-SC-3: The system is configurable to run in two modes:

1. Using the full SOA stack: BPEL services, ESB, web services, EJB

2. Using EJB only, but with a similar design approach (SOA)

VS-SC-4: The system is able to support filters in order to block requests sent by other participants. Filters are maintained by the participants. The design of the filters shall be maintainable and applicable for new business requirements.

VS-SC-5: A report documenting the following topics:

1. Pro/Contra using the full SOA stack

2. Pro/ Contra using EJB only

3. Performance statistics for both run modes, separated according to quote request, quote and offer list

4. Performance statistics shall be measured on 2 different Java EE 5 application servers.

5. The effort required for introducing new business models (implementation effort versus configuration effort)

2.1 Business Perspective

From the business perspective, all defined requirements have been fully implemented. The system is able to process up to ten times more QPS than required. The filters are maintainable and extensible. One of the questions this report should answer is whether BPEL is an applicable technology from the business point of view. There are two questions to be answered: (1) Is BPEL a flexible approach for introducing new business models? (2) How easy is BPEL development? More precisely, can business people with no development experience create BPEL processes?

The first question cannot be answered unambiguously. BPEL cannot implement complex business logic, as it depends heavily on the underlying services and external partner links. A BPEL process acts more like a controller that orchestrates other services. If the services themselves provide the new business model, then the question can be answered in the affirmative, otherwise the answer will be negative.

The second question should also be answered in the negative. Programming BPEL solely with a drag-and-drop graphical interface is possible only in very trivial circumstances.

2.2 Technology Perspective

From the technology viewpoint, the system incorporates multiple APIs, thus allowing us to assess their advantages and disadvantages.

Java EE 5 turned out to be a powerful, reliable and scalable platform. There is a learning curve associated with the APIs, but the benefits of using Java EE 5 are tremendous, as it consolidates best practices collected over many years. It would definitely be a good decision to develop future applications for this platform.

6/34



It is not recommended to use BPEL for this project. This application does not suit BPEL, mainly because no external partner link exists. There is significant overhead to communicate over the NMR when all underlying services (EJBs) reside in the same EJB module. This is why the measured QPS rates are very low. Even though the Quote BPEL process almost fulfills the required QPS, it is not competitive with the QPS rate achieved using Java EE 5.

The application can communicate either synchronously by using Web Services or asynchronously by using Java Messaging Services (JMS). Both variants have their own advantages.

Web Services turned out to be a viable alternative to RMI. Web Services are at least as fast as RMI, platform-independent and very easy to use.

Contrary to expectations, JMS provides speedy asynchronous communication. Using JMS allows a looser coupling, greater flexibility and better transaction control. JMS also fits better into the exchange framework. In production, there will not be a constant QPS rate for the application. Instead, the rate will have peaks and troughs. Using JMS fits perfectly into this picture. When a higher load has to be processed, then the message queues and the latency will grow. Clients are not blocked on receiving FIX messages from the members; they are still able to send JMS messages.

Whether using Web Services or JMS, batching is the key for high-performance computing. It is strongly recommended that clients communicating with the application be capable of batching FIX messages. It is recommended to use a batch size in the range from 50 to 100 FIX messages. A batch size higher than 100 FIX messages causes a higher latency than the required 50 milliseconds.

Both, the throughput and the latency are heavily pending on the database durable commit mode. The delayed durable commit mode provides incredible speed and a latency in the required time range but requires to replicate the database. The guaranteed durable commit mode syncs every commit to the disk and is therefore 100% recoverable but decreases the throughput and increases the latency heavily. However, [TimesTen Best Practices] describes several options to optimize the performance and robustness. It is very likely that following these options will provide better results.

The migration to JBoss was ultimately a simple task. It was more time-consuming to learn JBoss than to migrate to the application itself. The few differences between Glassfish and JBoss could be eliminated by rewriting the EJB deployment descriptor.

The application server was able to process 4500 QPS in both communications variants. However, the measured CPU utilization suggests that a practical QPS rate of 3000 QPS is the upper limit of the application.

7/34



3. AnalysisThe analysis is covered in detail in the requirements specification [MAS-06-01.04.SoftwareReqSpec] and is not included in this documents.

8/34



4. Design

4.1 Hardware View

The following physical components1 are used for this project:

1. A workstation hosting the application server and the database2. Three VMWare hosted workstations for generating load remotely3. A Gigabit Ethernet LAN

The following table describe the details of the physical components:

Physical Component Details

Application Server Model: HP Compaq dc7800 Small Form Factor PC

Processor: Intel® Core™2 Duo E7300 (2,66 GHz)

Operating System: Solaris 5.10 x86 64-bit

Memory: 8 GB DDR2 DRAM

Harddisk Speed: 7.200 revolutions per minute

Harddisk Controller: SATA 3,0 Gb/s

Network Card: Intel® 82567LM Gigabit

VMWare hosted Client Processor: 2 virtual i386 processors (2.3 GHz)

Operating System: Solaris 5.10 x86

Memory: 8 GB

1Components like routers and gateways are ignored

9/34



4.2 Runtime View

The application can operate in several different ways. From the client’s perspective, the application provides synchronous interfaces using Web Services or RMI (IIOP) or an asynchronous interface using Message Queues, as shown in the following diagram:

Clients can communicate with the application using one of the following interfaces:• Synchronously

• A Web Service processes FIX messages purely with JAVA EE 5 APIs [EJB Mode].• A Web Service processes FIX messages by using BPEL processes [BPEL Mode].• Using the RMI protocol by looking up EJB references remotely.

• Asynchronously• The application allows clients to send or receive JMS messages.

Internally, the application can process incoming FIX messages either sequentially or concurrently. Finally, the application is able to persist FIX messages in three ways. FIX messages other than Quotes are always persisted using JPA and the FIX DB schema. Quotes can be persisted by using either JPA (FIX DB schema or the Flat Quotes table), or JDBC (Flat Quotes table).

The reference data loader tools communicates directly with the database by using JPA and resource local transactions.

All these different ways of processing FIX messages are explained in the following sections. As an overview, the table below summarizes all possible run mode combinations. The blue-colored run modes are covered by the performance tests:

Asynchronously (JMS) Synchronously (Web Services)

JMS Mode EJB Mode BPEL Mode

Sequentially Concurrently Sequentially Concurrently Sequentially Concurrently

JPA JDBC JPA JDBC JPA JDBC JPA JDBC JPA JDBC JPA JDBC

FIX DB Schema

Flat Quote

Table

FIX DB Schema

Flat Quote

Table

FIX DB Schema

Flat Quote

Table

FIX DB Schema

Flat Quote

Table

FIX DB Schema

Flat Quote

Table

FIX DB Schema

Flat Quote

Table

FIX DB Schema

Flat Quote

Table

FIX DB Schema

Flat Quote

Table

FIX DB Schema

Flat Quote

Table

FIX DB Schema

Flat Quo

te Tabl

e

FIX DB Schema

Flat Quote

Table

FIX DB Schema

Flat Quote

Table

10/34



4.2.1 Overview of EJB ModeThis section describes the steps performed when the application receives FIX messages over the EntryBean Web Service. All components described operate in the same EJB module. The purpose of this design is to compare sequential versus concurrent processing. In addition, three different persistence options are implemented.

The basic steps of an application running in EJB Mode are as follows:

1. The Load Generator sends 1-n FIX message within a single Web Service operation.2. Based on a configurable flag, the EntryBean processes incoming messages either sequentially

by calling the ProcessBean, or concurrently by splitting the received messages into a configurable number of JMS messages that are subsequently sent to the ProcessMDBean.

3. In concurrent mode, the ProcessMDBean extracts the Quote messages from the received JMS message and delegates the processing of each Quote message to the ProcessBean.

4. The ProcessBean processes each quote in a new transaction. Each quote will be validated and filtered. If the validation and filtering does not throw a business exception, the message will be persisted using either JPA (QuoteEntityFacade or EncQuoteFacade) or JDBC (PersisterBean).

11/34



4.2.2 Overview of BPEL ModeThis section describes the steps performed when the application receives FIX messages over the EntryBPEL Web Service. The components are grouped into two EJB modules and a BPEL module.

The basic steps of an application running in BPEL Mode are as follows:

1. The Load Generator sends 1-n FIX messages within a single Web Service operation. This time, the Web Service is defined in a separate EJB module.

2. Each supported FIX message will be handled by a separate BPEL process. All BPEL processes pass the incoming FIX message over the JBI Normalized Message Router [Implementing SOA] to the ProcessBean for further processing.

3. The ProcessBean process the FIX messages in the same way as described for EJB Mode.

12/34



4.2.3 Overview of JMS ModeThis section describes the steps performed when the application receives FIX messages asynchronously. All described components run in the same EJB module.

The basic steps of an application running in JMS Mode are as follows:

1. The LoadGenAsync tool splitts 1-n FIX messages into a configurable number of JMS messages and sends these JMS messages to the AsyncQueue.

2. Each JMS message will be individually processed by the AsyncProcessMDB. The bean simply delegates the processing of the extracted FIX messages to the EntryBean. The returned results are then packed into a new JMS message sent to the AsyncReplyQueue.

3. The LoadGenAsync tool receives the JMS messages via the AsyncReplyQueue.

The LoadGenAsync tool serves two run modes. The first mode produces JMS messages whereas the second consumes JMS messages. This allows us to produce and consume JMS messages on the same or on different workstations.

Because of the asynchronous behavior, the JMS messages have to be fully recoverable. This means:

• All JMS messages have to be sent with the delivery mode set to DeliveryMode.PERSISTENT.

• Each JMS session has to be created with the transaction flag set to true, e.g., connection.createSession(true, 0).

13/34



4.3 Logical View

4.3.1 Application Details

BootstrappingWhen the application server is starting up, the BootstrapServlet is automatically called by the application server. This behavior is triggered by the <load-on-startup> flag in the WEB deployment descriptor. The servlet calls the BootstrapBean.init() method remotely to start several initialization steps.

Data CachingThere are several tables that hold reference data. These data do not change during a business day. For performance reasons, these tables are loaded into separate singletons during the bootstrap procedure.There also exist cached data which have to be refreshed from time to time. The bootstrap procedure starts the CacheTimerBean which refreshes these caches on a configurable interval2. Note that on a clustered configuration, the caches are loaded on every application instance.

Transaction Boundaries and Exception HandlingThis section describes transaction handling in detail. Every critical task must be performed by the ProcessBean. The ProcessBean handles every call in a new transaction as shown in the following figure:

The BusinessRejectException and derived exceptions represent business exceptions. If the ProcessBean catches a BusinessRejectException, the bean rolls back the transaction by throwing a BusinessRollbackException.

[Pro EJB 3] describes how to recover from optimistic lock exceptions. Following these guide-lines, the ChangeCollisionException is thrown in order to roll back the transaction and to inform the EntryBean that the last operation has to be repeated once.

2 In addition, two entity listeners are configured to update the Filtermessage and the CUG cache immediately.

14/34



Finally, a system exception or runtime exception will be caught by the EntryBean. If this happens, the EntryBean throws a service exception to inform the client that an unexpected error has occurred. Such errors can be either resource exceptions, such as running out of storage space in the database, or bugs in the code. In both situations, the administrators and developers will have to investigate the problem.

RecoveryFor this project, the recovery procedure is trivial. It is the responsibility of the client to handle recovery situations correctly. If the application crashes before returning the results, the client has no information about the state of the last operation and will just resend the last message with the same content. For messages that have already been processed, the application will return a BusinessMsgReject with the reason code of ID_IS_NOT_UNIQUE.

Processing Quotes ConcurrentlyConcurrency in Java EE 5 is only possible using Message Queues and Message Driven Beans (MDB). The EntryBean can be configured to process Quote messages concurrently. The bean implements a pattern called “Synchronous Integration Service (SIS)”, also known as “In-Out Queue” [Java EE 5 Architekturen].

The implementation is unique to our use case and therefore requires some explanation. First of all, the “In-Queue” is preconfigured and injected by the EJB container. The “Out-Queue” is created as a temporary queue when the bean is instantiated. When multiple clients are connected at the same time, for each connection a corresponding EntryBean instance exists, and therefore a corresponding temporary “Out-Queue” also exists. This guarantees that clients will always receive the right response messages3.

In order to minimize the JMS processing impact, the following specific features are implemented:1. The EntryBean splits the FIX messages into a configurable number of JMS MapMessages. Each

MapMessage includes multiple FIX messages.2. Each FIX message is represented as an XML string, marshalled/unmarshalled by the

JAXBContext handler. 3. The delivery mode of each JMS message is non-persistent4. All JMS sessions are non-

transactional.

The EntryBean and MDBs can only communicate with each other via JMS messages. It must be possible to inform the EntryBean when something special happens on the MDB side. A simple protocol between the EntryBean and the MDBs is in place to meet this requirement:

MapMessage structure sent by the EntryBean :

Property Name Type Description

MsgCount int Number of FIX messages included

MsgStartFrom int The starting value from which the FIX messages can be extracted

msgId=%d String The FIX message as an XML string

MapMessage structure sent by the ProcessMDBean:

Property Name Type Description

MsgCount int Number of result messages included

MsgStartFrom int The starting value from which the FIX messages can be extracted

msgId=%d String The result of processing. Possible values are:

1. “FILTERED_OUT”

3 It is possible to use one configured “Out-Queue”, but this has the disadvantage of using Message Selectors to route the response message to the correct client.4 For the Glassfish server, the ConnectionFactory must be set to “No Transaction”. This can be configured on the administration page under “Resources/JMS Resources/Connection Factories”

15/34



2. “UNCHANGED”

3. “SYSTEM_EXCEPTION”

4. The modified but valid FIX message as an XML string

Using JAXBContextThe application regularly uses the JAXBContext to marshal and unmarshal FIX messages. The class JAXBContextHandler wraps the JAXBContext behind a singleton. Chapter 8.1 in [Unofficial JAXBGuide] explains that the JAXBContext class is thread safe, but the marshaller and unmarshaller classes are not. Therefore, every session bean that uses marshaling or unmarshaling will have to create instances of the marshaler and unmarshaler. The primary reason why marshaling and unmarshaling are used is to include multiple FIX messages in one JMS MapMessage. MapMessage allows us only to include primitive data types as objects, whereas the JMS ObjectMessage allows us to transport only one FIX message. Interestingly, tests showed that marshaling and unmarshaling are more than twice as fast as serialization and deserialization. This could explain why Web Services are faster than RMI [5.1.3].

When to Use EJBs[JavaBeans 3.0] describes situations where EJBs are strong and should be used. In addition to the suggested list, the following questions are alsotaken into account:

1. Is the feature relevant to the business model?2. Are references to other EJBs required?3. Is the feature a potential candidate for use as a BPEL Partnerlink?

Based on these guide lines, the following session beans have been implemented:

Name Type Local Interface

Remote Interface

Web Service

Description

BootstrapBean Stateless Session

● Initializes the internal caches as well as the internal timers. Implements a remote interface so that the Bootstrap servlet is able to call this bean.

CacheTimerBean Stateless Session

● Internal timer that refreshes the caches at a configurable interval.

EntryBean Stateless Session

● ● ● The entry service for clients to communicate over the exposed web service. In addition, a remote interface allows them to communicate over RMI (IIOP).

FilterBean Stateless Session

● Is responsible for filtering the PartyBlocks. The bean also handles the closed user group filtering.

IntervalExpiryBean Stateless Session

● Internal timer that checks periodically for expired Quote messages.

MatchingBean Stateless Session

● Responsible for all matching related tasks.

PersisterBean Stateless Session

● Persists Quote messages either into the FIX DB schema or into the Flat Quote Table.

ProcessBean Stateless Session

● ● The central location where all incoming FIX messages are processed.

ValidateBean Stateless Session

●Validates every incoming FIX message. It is absolutely mandatory that this validation is the very first action. All subsequently called beans expect a validated message and do not perform any further validation checks.

AsyncProcessMDBean Message Driven

Called for every JMS message sent to the AsyncQueue. Delegates the processing of the extracted FIX messages

16/34



to the EntryBean. The results are then sent to the AsyncReplyQueue.

ValidateMDBean Message Driven

Called for every JMS message sent to the Validate queue. Processes the extracted FIX messages by delegating the FIX messages to the ProcessBean. Subsequently sends the results to the defined reply destination.

Details of the filtering implementationBefore going into the details of the filtering process, it is worthwhile to offer a short introduction regarding business requirements. In general, the participants set filters that can block request messages directly on the server side. From the application’s point of view, this consists of filtering the PartyBlock component. Each addressed participant (contra firm) has its own entry in the PartyBlock list. That means that, for every addressed participant, all filters defined by this participant have to be read and applied. If all filters have been successfully passed, the PartyBlock entry stays in the FIX message, otherwise the entry is removed from the list.

Participants must be able to assign filters as appropriate for their internal organizational structure. For example, suppose that a bank has three different departments: department “A” trades US shares, department “B” trades derivatives and department “C” trades bonds.

Filters set by department “A” should only influence department “A” and not departments “B” or “C”, and vice versa.

In order to fulfill this requirement, filter conditions are split into two condition types:1. Apply Conditions : These filter conditions define the circumstances under which the Message

Conditions have to be applied.2. Message Conditions : these filter conditions define the actual filter conditions a FIX message has

to meet before the FIX message is sent to the participant.

With the apply conditions, the departments are able to define their own filters not affecting the other departments.

The filter business requirement is probably the most complicated feature implemented in this application. Here we will describe the changes that would be necessary to extend the filter with additional features. When a new filter field has to be processed, few changes are visible to the clients. Just add a new enumeration in the enum class FilterFieldEnum. Every enumeration represents a specific FIX field and a specific data type.

On the server side, each filter ends by comparing two values, mostly in the context of two simple data types. The verb “comparing” points to our use of the Comparable interface. The signature of the AbstractFieldProcessor shows that the Comparable interface is incorporated generically. Every deriving filter class must specify a data type that implements this interface:

public abstract class AbstractFieldProcessor<T, U extends Comparable> implements IProcessFilter<T>

As already described, most of the data types to be compared are simple Java data types. No special steps are necessary. The only exception is filtering of Credit Rating fields. The Credit Rating is a data type represented by its own Entity class, CreditRatingBase. In order to filter Credit Ratings, the entity implements the Comparable interface.

17/34



Tuning of the ApplicationAn important aspect for high performance computing is to find the optimal application server configuration. Glassfish allows to monitor internal resources nicely and gives a lot of information. Besides these statistics, it is useful to collect own statistics.

To analyse the runtime behaviour of processing JMS messages, four time measuring points are implemented:

The first measuring point logs the time before the JMS message was successfully sent to the AsyncQueue. The second measuring point logs the time when the AsyncProcessMDB receives the JMS message. The third measuring point logs the time right before sending the result to the AsyncReplyQueue and finally, the fourth measuring point logs the time when the asynchronous load generator has received the JMS message. Analyzing these measure points allows to profile a end-to-end scenario.

18/34



4.3.2 BPEL Processing Details

OverviewBPEL processes are implemented in the simplest possible way. All BPEL processes delegate the FIX message processing to the ProcessService partner link, which is a WSDL generated from the Web Service representing the ProcessBean. In fact, the BPEL processes are pure routers between the BPELEntry EJB module and the ProcessBean. Each BPEL process can also be considered an orchestrating process – it serves as the counterpart in scope of the EntryBean, which acts as the controller for the other EJBs.

Every BPEL process must have a Partner link from which the BPEL process receives something. These partner links are created manually for each BPEL process. In most of the cases, the partner link is a copy of the ProcessService with a different namespace. In order to send FIX messages to the various BPEL processes from the outside world, the BPELEntry EJB module exposes a Web Service and consumes all of these partner links internally as a Web Service Client. FIX messages received over the Web Service are simply forwarded to the associated BPEL process via the implemented Web Service Client.

The following figure is an example of a BPEL process. The Quote Request BPEL process receives a new Quote Request message and delegates the FIX message to the ProcessService partner link. The response is returned to the caller:

Figure Quote Request BPEL Process

19/34



Quote ProcessingAll FIX messages are processed as previously described, except for Quote messages. Instead of receiving one FIX message, as the other BPEL processes do, the Quote BPEL process receives a list of Quote messages. In order to process all of these Quote messages, the BPEL process loops through the list and collects the results for each processed Quote message.

Figure Quote BPEL Process

The main reason for this different implementation is to obtain performance results for a more advanced BPEL process than is possible with other BPEL implementations.

20/34



Composite ApplicationThe Composite Application project is used to create a service assembly that can be deployed to the Java Business Integration (JBI) server. A Composite Application project can:

• Assemble an application that uses multiple project types (BPEL, XSLT, IEP, or SQL). • Configure external/edge access protocols (SOAP, JMS, SMTP, and others). • Build JBI deployment packages. • Deploy the application image to the target JBI server. • Monitor the status of JBI server components and applications.

The following diagram shows the service assemblies for the OOB-Deploy-casa composite application:

Figure OOB-Deploy-casa Service Assemblies

21/34



4.3.3 BPEL Process Guidelines

The following steps summarize the BPEL creation process:1. Create a new BPEL project module.

2. In the application EJB module, create a new Web Service based on an existing session bean.

3. Right-click on the newly-created Web Service and select the option “Generate and Copy WSDL”. Place the WSDL file into the BPEL project.

4. In the BPEL project, create a new BPEL process.

5. If not visible, double-click on the new BPEL process icon. Drag the generated WSDL to the right side of the BPEL design editor.

6. Create a new WSDL file, importing the XML schemas generated by step 3.

7. Define the same operations as defined in the WSDL file created in step 3.

8. Drag the new WSDL file to the left side of the BPEL design editor.

9. Implement all required BPEL actions using the palette. At a minimum, this requires a “Receive” action, an “Invoke” action, an “assign” action to assign the received variable with the invoke variable and a 'reply' action to pass back the result of the BPEL process.

10. In order to communicate with the BPEL process from outside, it is necessary to create a new EJB project module.

11. Create the Web Service Client code by pointing to the WSDL file created in step 6.

12. Create a new stateless session bean and program the Web Service Client call.

13. Create a new Web Service based on the newly created session bean. This is the Web Service that clients can use to send messages to the BPEL process.

14. Create a composite application module. Drag the BPEL module and the two EJB modules inside the casa design editor and then perform the “clean and build” option. This should generate a picture similar to the previous one.

15. Finally, deploy the composite application module.

22/34



4.4 Data View

4.4.1 FIX DB SchemaThe following Database schema is an exact representation of the FIXML 4.4 schema provided by [FIX]. In a first step, this XML schema is converted into Java classes using JAXB. Thereafter, a small subset of the generated Java classes are turned into JPA entities representing database tables.

A FIX message contains many fields and components5. To reduce the complexity, only the required components are annotated as JPA entities. As shown in the figure above, the FIX Quote message has a One-to-Many relations to the FIX PartyBlock component and a One-to-One relation to the FIX Instrument component. The other FIX components FinancialDetails, Stipulations, UndInstrmtGrp, OrderQtyData and LegQuotGrp are not enabled as JPA entities.

Some of the tables are cached internally to reduce the number of database access events. The application checks the message integrity and consequently no relations to these cached tables need be defined.

A special table is the Business_Reject_Message table. Every thrown Business Exception results in a Business_Reject_Message being returned to the sender. Each of these messages describes the details of why the incoming FIX message was rejected.

4.4.2 Flat Quote TableSince the application checks the message integrity itself, a valid alternative to the FIX-oriented DB schema is to use a flat table. To reduce the effort of maintaining two DB tables for all JPA entities, the flat table approach is only implemented for Quote messages. The EncQuote entity that represents the flat table can be considered as a Data Transfer Object (DTO) between the application and the database.

5 In the FIX world, a component is a set of fields, repeatedly used in other FIX messages

23/34



The structure of the entity is:

Field Type Description

COMPOUNDID String Primary Key in the form: “<QID>-<FIRMID>”

STATUS String Status of the Quote message. Possible enumeration values are:

OPEN, EXECUTED, EXPIRED, EXPIRED_NOTIFICATED

ORDTYPE String Defines order type. “Z” defines auction matching

VERSION Integer Version of the Quote message. Used for detecting optimistic lock failures

VALIDUNTILTM Date Expiration time of the Quote message

ENCTXT LOB6 The original Quote message represented as an XML string

4.4.3 Data Store SizeTimesTen manages data store space using two separate memory partitions within a single contiguous memory space. One partition contains permanent data and the other contains temporary data. In general, the available shared memory segment must be large enough to hold the data store. The [TimeTenOperations Guide] contains detailed instructions for how to specify the data store.

To estimate the size of the data store, TimesTen provides the ttSize utility. Based on the current records in a specific table, the utility can estimate the required space for the expected number of rows. If the expected QPS rate is 300, then the following calculation defines the size of the data store:

Total records within a business day: 300 Quotes per second × 3600 seconds × 8 hours = 8640000 Quotes. For 8640000 records, the utility calculates:

ttSize -tbl devbfr.ENCQUOTE -rows 8640000 OffOB_DEV_DSN

Rows = 8640000

Total in-line row bytes = 861339571

Out-of-line columns: Column COMPOUNDID total 483840000 avg size 18 Column STATUS total 345600000 avg size 7 Column ORDTYPE total 276480000 avg size 1 Column ENCTXT total 4285440000 avg size 459 Total out-of-line column bytes = 5391360000

Indexes: T-tree index DEVBFR.ENCQUOTE adds 175545425 bytes Total index bytes = 175545425

Total = 6428244996

As reported by the ttSize tool, the shared memory segment must be able to hold a data store size of ~6.3 GB for 8640000 records. It is not specified for how many days a Quote is tradable. In production, the On Order Book trading model restricts the lifetime of a Quote to the entering day, i.e., the closing procedure will expire all entered Quotes. A dangerous situation can occur if the data store size is exceeded. TimesTen will send out a SMTP trap when the remaining data store size falls below a configurable limit. It is strongly recommended to incorporate the SNMP traps into the internal monitoring framework.

6 The field must be annotated as a LOB otherwise the database will not be able to store XML strings

24/34



5. Performance Tests

5.1 Synchronous Communication

5.1.1 Concurrently Generated LoadThe purpose of this test is to determine the scaling behavior when multiple clients are concurrently generating load.

The test settings are:• Client count: 1, 2, 3 remote clients running in parallel• Client-Server communication: Web Services• JPA Provider: Oracle Toplink• Database: Oracle TimesTen 7 (Logging=1, DurableCommits=0)• Application is running on: Glassfish• Run mode is: EJB-Mode, sequentially processing, using JDBC, Flat Quote Table• Addressed Participant Count: 1• Batch Size: 1, 20, 100, 200• Generated QPS: 200, 400, 800, 1200, 1600, 2000

The following diagram summarizes the results when three clients are generating load concurrently. The x-axis legend, for example, 400-1, can be interpreted as 400 QPS generated by a batch size of 1.

The measured results are:

The conclusions of the test are:

1. Technical Batching has a major impact when a high QPS rate is required. With a batch size of one message, a remote client can generate up to 300 QPS. However, a batch size of 100 or more messages allows it to generate up to 1500 QPS. This limit is constrained by the client and not by the server.

2. The application is able to process a maximum of 4500 QPS. Analyzing the measured CPU utilization indicates that the application can handle 3000 QPS in a healthy state. A CPU utilization above 60% is acceptable only for short periods.

25/34

200-1400-1

800-11200-1

200-20400-20

800-201200-20

200-100400-100

800-1001200-100

1600-100200-200

400-200800-200

1200-2001600-200

2000-200

0

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

0

10

20

30

40

50

60

70

80

90

100

Client vduobmzs01 Client vduobmzs02 Client vduobmzs05 % CPU Server

Mea

sure

d Q

PS

Test Run 200-1 400-1 800-1 1200-1 200-20 400-20 800-20 1200-20 200-100 400-100 800-100 1200-100 1600-100 200-200 400-200 800-200 1200-200 1600-200 2000-200

Client vduobmzs01 199 200 190 200 200 390 795 980 200 400 800 1090 1500 200 400 790 1120 1400 1500

Client vduobmzs02 200 360 400 350 200 400 795 1100 200 400 800 1200 1450 200 400 800 1180 1500 1390

Client vduobmzs05 198 360 350 350 200 400 790 1000 200 400 790 1160 1450 200 400 800 1150 1500 1400

% CPU Server 33.6 40.9 40.5 38.9 13.5 26 59 59.8 12.5 23.2 39.9 64.4 74.8 12.1 22.8 44.2 67.8 69.3 81.5



More information about the impact of different batch sizes is provided in section [5.1.3].

5.1.2 Sequential versus Concurrent ProcessingThe purpose of this test is to compare sequential processing against concurrent processing, as well as to compare JPA with JDBC persisting.

The test settings are:

• Client count: one client running locally on the server• Client-Server communication: Web Services• JPA Provider: Oracle Toplink (Glassfish) / Hibernate (JBoss7)• Database: Oracle TimesTen 7 (Logging=1, DurableCommits=0)• Run mode is: EJB-Mode• Database access: JPA or JDBC• Database schema: FIX DB Schema or Flat Quote Table• Generated QPS: as high as possible• Batch Size: 200

The following chart shows the results for sequential and for concurrent processing of Quotes, separated out for JBoss and Glassfish:


Based on the results, we draw the following conclusions:

1. The SIS pattern [Java EE 5 Architekturen], implemented to process FIX messages concurrently, does not perform better than sequentially processing of the FIX messages. Sequentially processing is simpler and requires fewer CPU resources.

2. Direct database access using JDBC improves the performance by about 20% for the Flat Quote Table approach.

3. Using JPA to persist Quotes into the Fix DB schema is about 3 times slower than persisting into the Flat Quote Table.

The results produced by Glassfish and JBoss are show that Glassfish performs significantly better for the same test8. It is remarkable that a JBoss Web Service operation requires about 25% more time than the same Web Service operation in Glassfish. A possible reason could be that whenever possible, Glassfish

7 Standard JBoss configuration are used.8 Always persisting into the Flat Quote Table

26/34

Seq-JPA-FixDBSeq-JPA-FlatTable

Seq-JDBC-FlatTableConc-JPA-FixDB

Conc-JPA-FlatTableConc-JDBC-FlatTable

0

500

1000

1500

2000

2500

Glassfish Jboss

QP

S

Seq-JPA-FixDB Seq-JPA-FlatTable Seq-JDBC-FlatTable Conc-JPA-FixDB Conc-JPA-FlatTable Conc-JDBC-FlatTable

Glassfish 490 1790 2220 640 1700 2010

Jboss 1000 1640 1100 1640



uses the [Fast InfoSet] standard as the binary encoding format for the XML Information Set. This aims to provide more efficient serialization than the text-based XML format.

It is difficult to compare two Java EE 5 application servers. The results presented above should be interpreted with caution, especially in the case where JBoss ran with the default configuration. It is also important to point out that JBoss and Glassfish use different JPA providers. JBoss uses Hibernate, whereas Glassfish uses Toplink.

5.1.3 Batch Size Performance Impact using Web Services and RMI (IIOP)

The purpose of this test is to document the performance impact by varying the batch size. The tests are executed by using Web Services as well as by using RMI as the communication protocol.

The test settings are:

• Client count: one client running remotely• Client-Server communication: Web Services or RMI• JPA Provider: Oracle Toplink• Database: Oracle TimesTen 7 (Logging=1, DurableCommits=0)• Run mode is: EJB-Mode• Database access: JDBC• Database schema: Flat Quote Table• Generated QPS: as high as possible• Batch Size: 1, 5, 10, 20, 50, 100


27/34

1 5 10 20 50 100

0

10

20

30

40

50

60

70

80

90

0

10

20

30

40

50

60

70

80

90

100

Web Service Total RMI Total Web Service InRMI In Web Service Ratio RMI Ratio

Batch Size

Tim

e [m

s]

Batch Size 1 5 10 20 50 100

Web Service Total 3.79 5.1 8.01 12.91 27.67 51.96

RMI Total 3.79 7.24 11.59 18.76 41.18 80.59

Web Service In 0.75 1.74 3.29 6.3 15.56 30.36

RMI In 0.72 1.64 3.11 5.73 13.79 26.87

Web Service Ratio 80.21 65.88 58.93 51.2 43.77 41.57

RMI Ratio 81 77.35 73.17 69.46 66.51 66.66



The results clearly demonstrate that batching has an enormous performance impact. In addition, the results indicate that Web Services transport FIX messages more efficiently than RMI. Note that Web Service Total and RMI Total are the measured total process times, whereas Web Service In and RMI In are the measured application process times. The difference is the communication protocol overhead. Contrary to general opinion, our results suggest that Web Services are faster than RMI (IIOP).

5.1.4 Transaction Atomicity and Durability TestThe purpose of this test is to document the performance impact by varying the DurableCommits flag. TimesTen allows to choose different transaction atomicity and durability options [TimeTen OperationsGuide]:

• Guaranteed atomicity and durability (Logging=1, DurableCommits=1)• Guarantees atomicity and delayed durability (Logging=1, DurabilityCommits=0)• No guaranteed atomicity, no guaranteed durability (Logging=0, DurabilityCommits=0)

The first options writes every committed transaction to the disk. In case of a system fail over the database is able to recover all committed transactions. The second options guarantees atomicity but not the durability. Committed transactions are written to the disk on a configurable interval. To ensure no data loss in the event of a single point of failure, the database offers the 2-SAFE Replication option [TimesTenBest Practices].

The test settings are:• Client count: 1, 2, 3 remote clients running in parallel• Client-Server communication: Web Services• JPA Provider: Oracle Toplink• Database: Oracle TimesTen 7 (Logging=1, DurableCommits=0/1)• Application is running on: Glassfish• Run mode is: EJB-Mode, sequentially processing, using JDBC, Flat Quote Table• Addressed Participant Count: 1• Batch Size: 200• Generated QPS: 2000


28/34

Seq/DC=0Seq/DC=1

Conc/DC=0Conc/DC=1

0

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

0

50

100

150

200

250

300

350

QPS Client 1 QPS Client 2 QPS Client 3CPU % Disk % Latency [ms]

Run Modes

Ma

x.

QP

S

Seq/DC=0 Seq/DC=1 Conc/DC=0 Conc/DC=1

QPS Client 1 1470 588 1246 748

QPS Client 2 1475 589 1318 746

QPS Client 3 1527 585 1291 749

CPU % 69 75 58 33

Disk % 5 70 5 44

Latency [ms] 116.33 324.33 144 249.33



The results document that using DurableCommits=1 has an enormous performance impact. For the sequential mode the highest achievable QPS rate is decreased by 61%. For the concurrent mode, the highest achievable QPS rate is decreased by 49%. A purpose that the concurrent mode performs better using DurableCommits=1 is explained in [TimeTen Operations Guide]:

The performance cost of durable commits can be mitigated if many threads are running at the same time, due to an effect called "group commit." Under group commit, a single disk write commits a group of concurrent transactions durably. Group commit does not improve the response time of any given commit operation, as each durable commit must wait for a disk write to complete, but it can significantly improve the throughput of a series of concurrent transactions.

5.1.5 BPEL TestThe purpose of this test is to identify the highest possible QPS rate when Quote messages are processed by the Quote BPEL process.

The test settings are:• Client count: 1 remote client• Client-Server communication: Web Services• JPA Provider: Oracle Toplink• Database: Oracle TimesTen 7• Application is running on: Glassfish• Run mode is: BPEL-Mode, sequentially processing, using JDBC, Flat Quote Table• Addressed Participant Count: 1• Batch Size: 1, 5, 10 20, 100• Generated QPS: 600


The results indicate that the highest QPS rate is achievable with a batch size of 20 FIX messages. However, the highest measured QPS of about 275 is much lower than the QPS rate achievable in the context of the other run modes.

29/34

1 5 10 20 50 100

0

200

400

600

800

1000

QPS

Batch Size

QP

S

Batch Size 1 5 10 20 50 100QPS 110 230 250 280 275 250



5.1.6 Asynchronous TestThe purpose of this test is to measure the latency when Quote messages are processed asynchronously given different QPS rates.

The test settings are:• Client Count: Two remote clients. One client is producing and the other is consuming • Client-Server communication: JMS• JPA Provider: Oracle Toplink• Database: Oracle TimesTen 7 (Logging=1, DurableCommits=0/1)• Application is running on: Glassfish• Application mode is: EJB-Mode, sequentially processing, using JDBC, Flat Quote table• Generated QPS: 100, 500, 1000, 1500, 2000, 2500, 3000, 3500• Batch Size: 50 FIX Quote messages

• Addressed Participants: 1


The chart above shows the measured results. It shows the latency in milliseconds and the QPS rate the consumer was able to receive. Using DurableCommits=0, the latency remains constantly around 50 milliseconds. Using DurableCommits=1, the latency remains constantly around 200 milliseconds but a QPS rate of 2500 and above increases the latency and causes growing message queues.

Similarly, batching has a major performance impact on Web Services. Including only one FIX message in a JMS message limits the upper QPS rate to 230. On the other hand, including 100 or more FIX messages in a JMS message allows us to generate more than 3000 QPS.

30/34

1 2 3 4 5 6 7 8

0

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

0

200

400

600

800

1000

1200

1400

1600

1800

2000

QPS Intendend Average QPS DC=0 Average QPS DC=1 Latency [ms] DC=0 Latency [ms] DC=1

Test Run

QP

S

Test Run QPS Intendend Average QPS DC=0 Average QPS DC=1 Latency [ms] DC=0 Latency [ms] DC=1

1 100 99 100 94.6 178

2 500 492 476 75 142

3 1000 896 938 113 166

4 1500 1396 1322 70 246

5 2000 1852 1875 47 215

6 2500 2272 1880 78 8594

7 3000 2607 1181 48 69490

8 3500 2755 1282 44 50407



6. ReflectionThis Masters thesis was a perfect complement to my coursework. The theme allowed me to work deeply with technologies that I wished to master. It was the right project at the right time. Below are some thoughts and reflections I had during the project.

Project DefinitionThe first notable point is that I began by making the project too complicated. I spent a lot of time creating a dedicated wiki. The wiki was only ever used in the first week. The same is true for my project management approach. For a one-person project, a full fledged project management is simply too much overhead. A simple Excel sheet would have adequately met my needs. My conclusion is that before starting a Masters thesis, it is worthwhile to identify the important goals, to focus on these goals and to sideline all extraneous tasks.

Development EnvironmentThe implementation time can be divided into phases. More than half of my time was spent working on my personal laptop. Even though the laptop features a fast dual-core CPU with 3 GB of memory, I ran into a lot of issues. The development tools have very significant memory requirements, to such an extent that I had to reboot my laptop at least five times a day because of memory problems. Even worse, I encountered several inexplicable problems. Periodically, it was necessarily to reinstall my application server from scratch due to corruption. After four months, I was able to switch over to a workstation provided by my company. The situation changed immediately. Not only was the workstation at least twice as fast as my laptop computer, but it also featured 8 GB of installed memory. The problems I had previously encountered did not reappear.

I used NetBeans/Glassfish for development purposes. Aside from the memory problem, caused by the combination of all the installed tools, NetBeans and Glassfish together provide a suitable development environment that I found of great value. In contrast to other tools, NetBeans/Glassfish does not require additional tools or plug-ins. Even SOA and BPEL are fully integrated.

Theory and PracticeI realized that theory and practice are not the same. I remember that I was not sure how to use POJOs. In particular, I had to investigate when POJOs should or should not have access to EJB instances. I ultimately chose to use the CachedServiceLocator pattern. To look up EJB references individually by POJO seemed too complicated, since this is only reasonable when the EJB references are configured in the EJB deployment descriptor. I instead chose to use annotations and then to pass the EJB references to the POJOs using a CachedServiceLocator instance.

Source Code QualityAlthough I tried to refactor the source code whenever necessary, there are still parts of the code that I am not happy with. In my personal experience, this is normal. Source code quality is in inherent competition with completion time. For example, I am not satisfied with how I implemented the session bean façades for entities. Too many of these session beans were implemented.

Using Web ServicesIn general, it is easy to work with Web Services. I found it helpful to use the Java API for XML-Services (JAX-WS), which greatly simplifies Web Service development. NetBeans supports this API, so that server side as well as client side Web Service source code can be created automatically without having to modify the source code manually.

Using BPELBPEL and related APIs were not part of the coursework, so using BPEL was a special challenge for me. I must confess that I have only scratched the surface of the SOA/BPEL technologies. During the project, I

31/34



developed a growing dislike for BPEL. I realised that BPEL programming requires a different set of developer skills than does Java. BPEL requires additional specialized knowledge that is more related to XML XLT than to Java. One conclusion I can definitely draw is that BPEL programming cannot be performed by graphical drag-and-drop. It is unfortunate but true that I still do not understand all the WSDL definitions. Personally, I do not think that SOA/BPEL is appropriate for production-level software.

Using JMSThe asynchronous approach was introduced very late in the project. A colleague at my company suggested this as an alternative to Web Services. I am glad to have followed this suggestion. I am impressed with the potential of JMS, which I had not previously appreciated.

Using JDBCDuring the project I encountered a lot of database lock timeout exceptions. These problems are not solved yet. However, very late in the project I found a possible reason why under heavy load the database is throwing lock timeout exceptions. It seems that Glassfish does not return a JDBC connection back to the connection pool properly. Using JDBC I had to close each JDBC connection received by calling getConnection() explicitly.

Remote Lookup ChallengesTo complete the performance tests, it was necessary to implement a communication variant using RMI (IIOP) to process FIX messages synchronously.

I encountered major problems when implementing remote lookups. Remote lookups are not portable; every application server performs this operation differently. Even for the well documented Glassfish application server, I was not able to lookup remote EJB and message queues. I tried almost everything I found on the internet, but nothing worked. Finally, I tried out the proposed method specified in the standard. The Java EE 5 standard defines the application client as the only portable means for clients to communicate with the server. I am not sure why, but application clients have not been discussed in my coursework. None of the books I have cover this kind of Java EE module. The only documentation I found was the official Java EE 5 tutorial from Sun. In this tutorial, every client program is an application client module. Using an application client module, I was able to remotely lookup EJB references and message queues, but not without some difficulty. Everything works inside NetBeans, but running the application client outside NetBeans failed, probably due to a bug in NetBeans. The manifest file did not include the class path setting. After correcting this setting manually, the application operated as expected. Personally, I think my coursework should have discussed application clients as an alternative to remote lookups, mainly because application clients are part of the Java EE 5 specification.

Personal ConclusionsI reached my desired objectives. Nevertheless, there are some areas which still are mysterious to me. An example is the entity manager in JPA. To complete my education, I plan to work through two Sun Java EE 5 certificates.

Finally, I would like to thank to all the people involved with my project. Thanks go especially to Dr. Stephan Fischli, Mr. Rico Piantoni, Mr. Hans Burkhard and Mr. Christian Bach for their assistance.

32/34



7. Appendix

7.1 Using POJOs and Dependency Injection

Injecting dependencies into a session bean does not require a lot of effort. The EJB container does this automatically. More investigation is required regarding when POJOs (Plain Old Java Objects) should have access to EJB references. For the Glassfish application server, the following rule is implemented:

Local EJB access is only portable from within the same application, so the POJO class must be called from a component running within the same application as the target Local EJB. Injection is not supported for POJO classes, so the POJO needs to look up the local EJB reference within the private namespace (java:comp/env) of the component within whose scope it is executing.[EJB FAQ]

In other words, if the POJO wants to lookup a local EJB reference, the local EJB dependency must be defined within that EJB component. For this project, all EJB references required by POJOs are passed from the EJB component to the POJOs via the CachingServiceLocator class. All POJOs extract EJB references from this class. This is a simple and portable way to pass EJB references to the POJOs. The EJB component initializes the CachingServiceLocator instance with the @PostConstruct annotated method.

7.2 Migration to JBoss

Unlike the specification in [MAS-06-01.04.SoftwareReqSpec] the secondary application server used for running additional performance tests runs JBoss rather than the Oracle 11g application server. This is because of new internal policies.

The following are my experiences with deploying the application to the JBoss server. It was necessary:

• To configure the same Oracle TimesTen database. [wp-timesten70-appsrv]

• To configure the validation queue in a separate XML file in the deployment directory.

• To rewrite the ejb-jar.xml deployment descriptor in order to overrule the annotations set primarily for Glassfish.

• To change the source code. Not everything could be overruled overrule in the deployment descriptor files. Two code changes were necessarily:

• Hibernate does not accept two separate One-To-Many relations with Fetchtype.EAGER in the same Entity class. (@OneToMany(cascade = CascadeType.ALL, fetch=FetchType.EAGER)).

• The global JNDI names are constructed differently. The caches that perform a remote EJB lookup have to be adjusted to reflect the JBoss global JNDI names.9

To reduce the migration effort, the BPEL processes were not migrated to JBoss.

9 Recently, I discovered the @RemoteBinding annotation which should solve this issue

33/34



7.3 Running Unit Tests

About 200 end-to-end unit tests were implemented. To execute these tests on the command line, the following steps had to be performed:

1. Change the current directory to the directory where the OOB-LoadGen-java project is installed.Example: cd /export/home/devbfr/develop/final/OOB-LoadGen-java

2. Set the JAVA_HOME environment variable Example: setenv JAVA_HOME /usr/jdk/latest

3. Execute the ant scriptExample: /export/home/devbfr/netbeans-6.1/java2/ant/bin/ant

Step 3 executes the build.xml defined by NetBeans. The script first compiles all dependencies and then executes the unit tests. Note that some of the unit tests require an empty database.

Below is an example of a test run:-do-test-run:

[junit] Testsuite: com.swx.offob.client.webservice.CUGTest

[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 5.069 sec

[junit]

[junit] Testsuite: com.swx.offob.client.webservice.ExecReportTest


[junit]

[junit] Testsuite: com.swx.offob.client.webservice.FilterTest


[junit]

[junit] Testsuite: com.swx.offob.client.webservice.OfferListTest


[junit]

[junit] Testsuite: com.swx.offob.client.webservice.QuoteRequestTest


[junit]

[junit] Testsuite: com.swx.offob.client.webservice.QuoteResponseTest


[junit]

[junit] Testsuite: com.swx.offob.client.webservice.QuoteTest


[junit]

These tests are the absolute minimum that a project can implement. Many more unit tests are required if the project is to be turned into a production effort.

34/34

Documents

Final Report Master Thesis MAS-06-01.04 - BFHstatic.sws.bfh.ch/download/MAS-06-01-04-doc.pdfMaster Thesis SWX Off Order Book Trading Final Report Abstract The Off Order Book Trading