High Transaction Systems

8/3/2019 High Transaction Systems

1/14

CONFIDENTIAL

Produced by: Andreas GeppertDate: June 6, 2008 Slide 1

High-volume Transaction Processing onthe Java Application Platform at CreditSuisse

July 3, 2008Andreas GeppertPlatform Architecture, Technical Infrastructure ServicesCredit Suisse

[email protected]


2/14

Produced by: Andreas GeppertDate: July 3, 2008 Slide 2

Outline

Credit Suisse IT Facts and Figures

Application Platforms

Transaction Processing on the Java Application Platform


3/14


Credit Suisse Standard Banking IT Platform Facts &Figures

number of applications (mostly homegrown) ~ 1'000 Number of databases ~ 43'000 IMS transactions / day 24 m System availability 99.8%

Changes / month ~ 2'200 Batch jobs / day ~ 77'000 domestic payment transactions 250 m

(92% processed completely automatically)

how do you manage applications and application & technologylandscape ?


4/14


Application PlatformsDefinition

Frees developers from infrastructure and operation concerns

Focuses on efficient processes and lean operation

Developing an AP is substantially more expensive than custom/special

engineering. Therefore an adequate number of applications sharing the platform

are necessary to amortize the effort

Layer in technical architecture closing the gap between runtime

platforms/standardized technical components and applications

An AP is designed and supported as a whole (allows optimizations not possible ona per component basis, e.g. availability, BCP)

Application platform (AP): Set of integrated technical components andprocesses for the development and operation of similar applications


5/14


Why Invest In Platforms?Technical Drivers

Pricedesign/build/test once, operate and automatecentrally, amortize across many applications

Qualityshared tested components, common monitoring &stability measures (including bug fixes/patches)

Riskpre-defined infra security, IT-DR, accountabilityestablished and enforced for platform

Capability

defined operational characteristics, performance

and capacity

Pricedesign/build/test once, operate and automatecentrally, amortize across many applications

Qualityshared tested components, common monitoring &stability measures (including bug fixes/patches)

Riskpre-defined infra security, IT-DR, accountabilityestablished and enforced for platform

Capabilitydefined operational characteristics, performance

and capacity

From custom building platform: Integrated and tested components in runtime stack

Fixed component versions per platform release

Defined and largely automated processes for ordering,provisioning, configuration management, softwaredistribution, change management, performance & capacitymanagement, monitoring, IT DR, auditing, etc.

Platform management for platform as a whole:

requirements management, release management, life cyclemanagement, technology strategy & architecture, end toend service, pricing, business case, KPIs, etc.

Application Specific Work Graphical User Interface (GUI)

Business Logic

Database Schemas Configuration

Infrastructure Design / Implementation

Runtime Stack

HW, OS, Middleware, Network

Systems Management/Operation, Security,

Development Tools, etc.


6/14


What is a Platform?

Platform Types

Runtime Platform (RTP)

generic

Hosting Platform (CHP, DHP, etc.)added services like capacity mgt

(virtualization) for OS build, DB build,etc.

Application Platform (AP)

added services specialized for areas ofsimilar applications

Text

Text

Text

Text

Text

Text

Managed,high-qualityTechnical

Components

Automated,integrated

Tool-chain

Hosting onShared HWResources

Architecture,Guidelines &

Documentation

A set of integrated technical components and processes for the

development and operation of applications


7/14


Current Application Platforms

Transaction

Processing

/ Batch

XBS

WS80

....

Java

Dispo

ADAC

....

Data

Warehouse

LBM

Cr-MIS

....

Enterprise

Resource

Planning

GLI

HR4U

....

Hosting

Light

E-Atlas

....

Integration

Infrastructure

(Managed Interfacesfor Services, Events,Bulk-Data, Workflow)intra-AP

cross-AP

*) restricted access only

*)

...

?


8/14


Current and Future Transaction Processing

currently, the vast part of transaction processing is done on theTP/B platform, using the IMS transaction monitor, DB2 and MQ on

z/OS

transaction programs are implemented in PL/1 (~ 12 m lines ofcode)

PL/1 skills become ever more scarce Credit Suisse decided to invest in PL/1 (e.g., development) andalso investigate other strategic options

Java and hence the Java Application Platform (JAP) as thestraightforward language of choice


9/14


Java Transaction Processing Challenges

several references show that high-volume transaction processingcan be done in Java, but ...

is it feasible in Credit Suisse (in terms of maturity of operations andcharacteristics of applications) ?

is it feasible on JAP, using off-the-shelf components and

commodity hardware? can transactional properties be guaranteed? many use cases require distributed transactions involving more than one

resource manager (e.g., a database system and a queuing system)

can requirements be met? processing of up to 80 payment orders per second

processing of more than 100 securities transactions per second


10/14


Proof of Concept System Architecture

SAN

WLS Cluster

t3s/Corba/Web Services

JDBC/SSL

DB inst. DB inst. DB inst.Data Guard

or PPRC

MQ

MQ

SubsystemWLS WLS

Sun T2K, JAP 4.1 Sun T2K, JAP 4.1

RAC/SFRAC or DB2 Datasharing

Oracle: Sun T2KDB2: Mainframe



Database DB LogWLS Trx Log


11/14


Java Transaction Processing Feasibility

feasibility of transaction processing on JAP has been proven three prototype applications: processing of one type of payment messages

up to 700 messages per second could be processed, using 2PC

parts of securities order processing

150 trx/s including queues, 700 trx/s without queues artificial benchmark (Dell DVDstore)

600 trx/s with slight tuning, 1000 trx/s with some tuning (using 1PC)

confidence in reliability of 2PC (using special tests); efficiency of2PC not an issue

first experiences (and resulting guidelines) in database tuning


12/14


Java Transaction Processing: Next Steps

given the successful proof of concept, JAP will be extended toaccommodate also transaction processing

a pilot application is being implemented (and will be brought into

production)

infrastructure will be set up, configured, and integrated (reference) architectures and design guidelines will be defined

open questions will be addressed


13/14


Java Transaction Processing: Open Issues

application development guidelines and standardized infrastructure e.g., which API to use (JDBC, SQLJ, JPA)

how to guarantee transaction properties in the presence of remoteservice calls, in particular atomicity

cannot be part of the transaction

service execution cannot be rolled back design patterns based on prebookings

"disentangling" databases, e.g., along application subdomainboundaries

operations, in particular monitoring database tuning, parallelization, and horizontal scalability


14/14


QUESTIONS?

Documents

High Transaction Systems