Overview

Data Management in Financial Services is a critical area that often requires IT managers to make trade-offs while ensuring that business operations run smoothly. The competing forces are: (1) time to market; (2) quality and (3) cost. These translate to technology decisions which are often miscalculated and cause additional issues in future. The most common mistake is entrusting all product and service needs to a single vendor. Not only does this prove to be expensive as a result of vendor lock-in, it also results in proprietary solutions that are difficult to integrate with systems deployed by clients and partners. Another common dilemma is the build vs. buy decision. Building solutions in-house results in more control and flexibility but often comes at the cost of longer project cycles potentially resulting in missed business opportunities. Frequent re-architecting arising from technology incompatibilities – such as moving from legacy to open systems – or coping with industry and regulatory changes adds further strain to resources and budgets.

Volante Technologies has researched these technical and business issues and come up with a product suite that seeks to reduce these stresses and strains. Volante provides out-of-the-box support for various functional components, making it easier to assemble integration solutions. Volante provides a modeling environment which can be used to rapidly build solutions that don’t need hand-coding. These “models” can be converted to implementations using code generators. Volante also provides the ability to deploy these implementations on various infrastructure platforms. This promotes reusability of existing environments as well as interoperability between systems. By separating the solutions space (via models) from infrastructure components, Volante ensures that the technology stack implementing the business solutions does not dictate or constrain the business requirements of the solution.

With its legacy of providing robust business systems for Financial Services, IBM has, over time, become the leader in this space. However, many firms have moved to other technologies and in an integration drive to provide seamless connectivity between various applications, went about acquiring proprietary and expensive infrastructure from other vendors in this space. Unfortunately this often called for migrating applications away from the mainframe, or to accept legacy limitations such as batch environments, COBOL message formats, etc. Volante’s solutions eliminate these trade-offs by providing the ability to run solutions for application integration on mainframe environments, just as they would run on other platforms.

About the Benchmark Engagement

One of the key requirements for application integration is the ability to provide real time connectivity to the platforms on which applications run. Several Volante customers deploy Volante solutions on a technology stack that includes IBM systems and software. The objective of the benchmark was to demonstrate that platform independence and model-based solution development does not result in reduced performance.

With this objective, Volante, as an IBM business partner, worked with the IBM System z Benchmark Center in Poughkeepsie, NY. Volante modeled the benchmark application after its customer’s use case. The two teams worked jointly to set up specific goals and success criteria for the benchmark:

· Provide Volante’s clients with performance statistics related to running Volante-based solutions on IBM System z mainframes.

· Study the performance characteristics of executing a varying number of threads for performing message transformations.

· Study the performance impact of running the benchmark in an EJB environment vs. running it as a plain Java application.

· Understand the bottlenecks to achieving maximum performance – the success criteria here was to show that there are no impediments to using all available CPs.

Benchmark Application

The application involved processing fixed-width message records and mapping them to SWIFT MT535 (Statement of Holdings). This is a frequently seen use-case since the Statement of Holdings aggregates information across multiple positions held by an account. The MT535 message is an ISO 15022 message – a complex message format with multiple levels of nested sections, qualifiers, options, etc. (see www.iso15022.org for details of this message). The input records were created by an application running on System z and were read from a batch file. Processing involved identifying boundaries of multi-record accounts, parsing, validating and transforming them into MT535 messages and validating the MT535 by applying the SWIFT defined Network Validation Rules. To isolate the processing phase from the I/O phase, the benchmark application read the entire input file into memory and processed the same data in several iterations across multiple threads.

Volante code generators can generate plain Java code or EJB code. In this benchmark we generated both and ran the benchmark in two modes: (1) as a Java application and (2) as an EJB application deployed on WebSphere Application Server.

System z Hardware

The hardware configuration for the benchmark environment included:

· Model type: System z9^TM

· Number of systems: 1

· Number of processors: 4

· Number of Logical Partitions (LPARs^TM) : 1

· Memory: 4 Gig Central Storage

· Storage type: IBM DS8000^TM

System z Software

The software configuration for the benchmark environment included:

· OS (LPAR): zOS V1R8

· Middleware: IBM WebSphere Application Server Version 6.1.0

· Volante Software: Release 3.2

Test Configurations

The benchmark was run in two different modes: (1) Java mode and (2) EJB mode. In each mode, the tests were run under 3 different CP configurations: 1, 2 and 4 CPs. Within each test, the number of threads was varied from 1 thread to a maximum of 12 threads. However, in some configurations the tests were run for less than 12 threads as there was no increase in throughput (see results below).

Results

Results of the benchmark tests were gathered from the application log files. We monitored CP utilization during the runs and found that they were over 95%. The following graphs illustrate the results of the tests performed:

1) Plain Java Mode

The highest throughput achieved was 5716 messages/sec. The fundamental observation was that the application was CP bound. A single thread was able to saturate the CP, regardless of the number of CPs (1, 2 or 4). As a result we observed very good scaling as we increased the thread count up to the number of CPs. Beyond that, the throughput was flat – no increase, only very slight decrease as would be expected.

The lowest latency obtained was 0.51 milliseconds. The chart above shows that the latency is optimal when the number of threads is less than or equal to the number of CPs. After that latency increases because multiple threads are competing for CP resources.

2) EJB Mode

The highest throughput achieved was 4188 messages/sec. This is lower than the results for plain Java, as would be expected because of the overhead of the EJB server. However, the scaling pattern was similar to plain Java – i.e. close to linear increase in throughput up to the number of CPs, after which it levels off.

The lowest latency seen was 0.68 milliseconds. The results above show that the latency pattern is similar to the plain Java mode – latency is optimal when a single thread is running on each CP, and with additional threads the latency increases.

Conclusions

We were able to process more than 5000 messages per second and saw latencies as low as 0.5 milliseconds. These numbers do depend on the structural and processing complexity of messages processed.

· CP Utilization and Scalability

In both plain Java and EJB modes, the application scaled almost linearly as the number of CPs was increased. This shows that the threads are running independently with very little synchronization overhead. Since each thread was fully CP bound, there was no increase in throughput in adding additional threads per CP (more than 1). There was no significant decrease in throughput either. However, latency was affected if additional threads were added to each CP.

· EJB Overhead

Running the application in EJB mode resulted in some loss of performance as expected due to application server overheads. Throughput was 22-27% lower than in the plain Java mode, while latency was 23-28% higher.

This application benchmark – which represented a real-world use case with some modifications as stated above (see “Benchmark Application”) – demonstrates that integration solutions can be run on a z/OS mainframe on a WebSphere infrastructure. Complex solutions based on Volante’s model-based approach are easy to develop, yet do not sacrifice on performance, as is evident from the results seen above.

Volante has also demonstrated that connectivity solutions with support for open standards can be deployed on mainframes. IBM systems running z/OS are used by organizations that do not want to compromise on reliability and performance. Strong support for open standards in z/OS makes it easy to integrate financial applications running on these systems into existing IT environments.

Contact Information:

For more information on this benchmark, the results or general product information on Volante products, please contact info@volantetech.com or call (212) 905-6231.

For general product information on IBM z/OS, IBM WebSphere or other IBM products, please call:

1-877-426-3774.

© 2007 Volante Technologies. All rights reserved. “Volante Technologies”, the Volante logo and Volante’s product names are trademarks of Volante Technologies. References to other companies and their products use trademarks owned by the respective companies and are for reference purpose only.

Trademarks:

The following are trademarks of the International Business Machines Corporation in the United States and/or other countries.

z/OS*

System z

zSeries*

IBM*

IBM logo*

*Registered trademarks of IBM Corporation