Extreme Transaction Processing

The GigaSpaces vision for the XTP Market

에릭골드

영업이사

아시아태평양

Eric GoldSenior DirectorAsia Pacific Sales

XTP: Extreme Transaction Processing

• XTP Applications are characterized by:– Exceptionally demanding requirements for

• Performance

• Scalability

• Availability

• Manageability

• And overall Dependability

Business Drivers push for Escalating Transactional Workload

“Extreme” On Line Transaction Processing Will Grow Dramatically

A review of current technology: Tier-based Architectures

Business Logic

Data

A review of current technology: Tier-based Architectures

Business Logic

WebLogicJMS

WebLogicJMS

WebLogicJMS

Data

A review of current technology: Tier-based Architectures

Business Logic Messaging

A review of current technology: Tier-based Architectures (clusters & clusters & clusters & clusters & clusters)

WebLogicJMS

WebLogicJMS

WebLogicJMS

Data Cache

Business Logic Messaging Database

XA Transaction Monitor

WebLogicJMS

WebLogicJMS

WebLogicJMS

Data Cache

Business Logic Messaging Database

A review of current technology: Tier-based Architectures …And don’t forget the XA Transaction Monitor!!

A review of current technology: Tier-based Architectures

XA Transaction Monitor

WebLogicJMS

WebLogicJMS

WebLogicJMS

Data Cache

Business Logic Messaging Database

A review of current technology: Tier-based Architectures

XA Transaction Monitor

WebLogicJMS

WebLogicJMS

WebLogicJMS

Data Cache

Business Logic Messaging Database

A review of current technology: Tier-based Architectures

XA Transaction Monitor

WebLogicJMS

WebLogicJMS

WebLogicJMS

Data Cache

Business Logic Messaging Database

Complicated• 3 to 4 different technologies – difficult to administer• A cluster for each tier• Managing transactions is difficult• Testing is complex• Hard to find people who are experts in ALL the technologies

A review of current technology: Tier-based Architectures

XA Transaction Monitor

WebLogicJMS

WebLogicJMS

WebLogicJMS

Data Cache

Business Logic Messaging Database

A review of current technology: Tier-based Architectures

XA Transaction Monitor

WebLogicJMS

WebLogicJMS

WebLogicJMS

Data Cache

Business Logic Messaging Database

Slow!• The network is the bottleneck!• You can tune each tier, but the end-to-end transaction timeis only as fast as the slowest point.If the cache is fast, but the network is slow, the transaction will be slow!

A review of current technology: Tier-based Architectures

XA Transaction Monitor

WebLogicJMS

WebLogicJMS

WebLogicJMS

Data Cache

Business Logic Messaging Database

A review of current technology: Tier-based Architectures

XA Transaction Monitor

WebLogicJMS

WebLogicJMS

WebLogicJMS

Data Cache

Business Logic Messaging Database

Scaling is difficult (and expensive!)• Where to add more servers? • More business logic (app servers)?• More messaging servers?• More caching servers?• More database servers?• How do you scale up??

A review of current technology: Tier-based Architectures

XA Transaction Monitor

WebLogicJMS

WebLogicJMS

WebLogicJMS

Data Cache

Business Logic Messaging Database

A review of current technology: Tier-based Architectures

XA Transaction Monitor

WebLogicJMS

WebLogicJMS

WebLogicJMS

Data Cache

Business Logic Messaging Database

Reliability is expensive and difficult to implement• Redundancy needs to be built into each tier• That means you need to buy a lot of extra servers to befully redundant• Message traffic increases as you add redundancy, so performance is affected

Why do complicated distributed architectures like this exist?

XA Transaction Monitor

WebLogicJMS

WebLogicJMS

WebLogicJMS

Data Cache

Business Logic Messaging Database

Why do complicated tier-based architectures like this exist?

XA Transaction Monitor

WebLogicJMS

WebLogicJMS

WebLogicJMS

Data Cache

Business Logic Messaging Database

We have tier-based architectures because there is not a single machine powerful enough to achieve all the IT goals

We need a dream machine!

• Extreme transaction processing requirements are creating demand for a dream machine. We need:– Simplicity

– Low latency

– Scalability

– Reliability

The dream machine

The dream machine: Consolidate business logic, messaging, and data cache together

XA Transaction Monitor

WebLogicJMS

WebLogicJMS

WebLogicJMS

Data Cache

Business Logic Messaging Database

–Simplicity: build & deploy applications using one unified technology–Low latency: all transactions/calculations performed at “in-memory” speed. No network latency.–Scalability: infinite throughput capacity, and only one cluster–Reliability: no downtime, instant recovery

The dream machine

Pure SIMPLICITY…and SPEED!

In our dream machine, business logic, messaging, anddata storage are all developed in one unified technologyanda transaction runs completely in memory!

No network latency!

The dream machine!

Our dream machine also has infinite scalability, and it never crashes!

The dream machine…with shared memory!

In our dream machine,data and state can be shared between transactions!

The dream machine

The dream machine exists!

“…new-style application server products will compete against J2EE vendors and Microsoft for the high-end OLTP and the mass- market business application platform projects, gaining at least 20 percent share of the total market.” Source Gartner

The Gartner view: “dream machines” will be implemented in software, as “new-style” app servers

The next generation won’t require such complexity

XA Transaction Monitor

WebLogicJMS

WebLogicJMS

WebLogicJMS

Data Cache

Business Logic Messaging Database

The next generation won’t require such complexity• Physical tiers will be consolidated

into virtual tiers, we call these consolidation units “processing units”

• Each processing unit has all the messaging, business logic, and data it needs for a transaction co- located in memory on one CPU

• Multiple processing units can run in parallel in a grid environment Total TPS =

X*N

X TPS

X TPS

X TPS

X TPS

Processing Unit 1

Processing Unit 2

Processing Unit 3

Processing Unit N

Incoming Transactions

The Ideal Scenario - “Write Once Scale Anywhere”

The next generation won’t require such complexity

Total TPS = X*N

X TPS

X TPS

X TPS

X TPS

Processing Unit 1

Processing Unit 2

Processing Unit 3

Processing Unit N

Incoming Transactions

The Ideal Scenario - “Write Once Scale Anywhere”

• You will be able to write the application once, as if it runs on one machine, and then scale the application to run on an infinite number of machines

• Write Once, Scale Anywhere

The dream machine… will be implemented with software, not hardware

Total TPS = X*N

X TPS

X TPS

X TPS

X TPS

Processing Unit 1

Processing Unit 2

Processing Unit 3

Processing Unit N

Incoming Transactions

The Ideal Scenario - “Write Once Scale Anywhere”

SharedMemorySpace

The dream machine won’t be one big machine…it will be one logical machine distributed on many small machines (i.e. processing units) in a grid…

The collection of small machines will comprise one large shared memory space

Tier-based architectures will gradually be replaced by these next-generation space-based architectures

GigaSpaces XAP is the dream machine!

Total TPS = X*N

X TPS

X TPS

X TPS

X TPS

Processing Unit 1

Processing Unit 2

Processing Unit 3

Processing Unit N

Incoming Transactions

The Ideal Scenario - “Write Once Scale Anywhere”

SharedMemorySpace

GigaSpaces has virtualized & consolidated the essential functions required for Extreme Transaction Processing

• Application server, messaging infrastructure and data cache now all run as a single cluster of processes

• Transactions can now run completely in memory

• Transactions can be scaled across an infinite number of machines in a grid computing environment

Thank you very much.