No More Hops:

Towards a linearly scalable application infrastructure.

Owen Taylor

Blog:

http://www.jroller.com/owentaylor

About me. . .

• ORBs

• Containers

• Frustration

• “The Final Frontier”

Technical Target: Linear Scalability

• Process increasing volume of information

– Scale out to get more processing power when volume increases

• Shorter time– Mostly through parallelizing of

transactions

• Lower cost– Pooling low commodity resources

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

4

Database-Based Architectures: scaling bottlenecks

Data – I/O overhead, Contention

Messaging – Complex workflows increase latencies

Processing – CPU, ParallelizationSilo approach,

each tier has its own

clustering model, lots of moving parts

6

Services can be Java, C++, .Net

Content-Based Routing

Typical SOA model based on ESB

Most ESB solutions do not address stateful services and

often use a centralized database to share state

between services

Pinpoint ‘That method call...’ [what about the app?]

Presentation Logic

Business Logic

Integration Logic

Data Tier

Messaging Tier

Client Tier

If we just add a caching layer to the system...

TPC: Transparent Partitioning & Colocation

• The next wave of applications will scale in this manner– Because Gartner says so

• Many already scale one or two tiers in this way– Partitioned Databases with Triggers

– Content-Based Routing though Messaging with coupled consumers

– All-in one web applications using caching (IMDG)

• Space-Based Architecture offers an implementation of TPC using Spaces– GigaSpaces enables this architecture for .NET, C++, and Java

Space-Based Architecture is an Implementation of TPC

• Utilizing a single logical/virtual resource to share: – Data

– Logic

– Events

• Services: – Interact with each other through the space

– Can be co-located with data/events for faster results

– Are deployed and managed in an adaptive and fail-safe way

} Objects!

Data Provisioning

Event Propagation

Logic Processing

Parallel Processing: Divide and Scale out

Request FeedProxy

Request

Request

Request

Proxy

Proxy

Proxy

Write

Write

Write

Service1

Service2

Service3

Partitioned Spaces

Request: Zoom-in

update stocks where …

Proxy

Virtual Table

Colocation: Dramatically Reduce Latency

Request FeedProxy

Request

Requests

Request

Proxy

Write

Write

Write

Partitioned Spaces

Request: Zoom-in

Proxy

Virtual Table

update stocks where …

Client Registration

Offer Driver

Execution Engine

Write

Notify

Register

Matching Engine

Update

Average Latency ~14 milliseconds

(+ ~2 milliseconds for backup)

Example: Algorithmic Trading

Reduced Latency Due To Colocation

Offer Driver

Execution Engine

Write

Notify

Matching Engine

Average Latency ~600 microseconds

(+ ~2 milliseconds for backup)

Client Registration

Register

Update

Write [TradingStrategy]

RTDtopic

GSC 1

Embedded Space

Processing Unit 1

StockConverter

Spring Bean

GSC 2

Embedded Space

Processing Unit 2

GSC 3

Embedded Space

Processing Unit 3

One Logical Space

(Partitioned)

GSC 4

SpaceProxy

Processing Unit 4

MarketFeed

Spring Bean

[Demo] Excel With a Grid Backbone:

StockConverter

Spring Bean

StockConverter

Spring Bean

15

Nuts and Bolts: 4 Verbs

Write TakeRead Write Notify

Write + Read = IMDG

Write + Notify = Messaging

Write + Take = Parallel Processing

Take

Write

Read

Take

Notify

16

Services can be Java, C++, .Net

Content-Based Routing

Shared state to enable stateful services

SBA = Real-time SOA for Stateful Applications

17

Space Bus

ValidationService

Service Bean

MatchingService

Service Bean

Take Write Notify

Declarative Spring-SBA - Making Scalability Even Simpler

Space Bus

ValidationService

Service Bean

MatchingService

Service Bean

Take Write Notify

Take/Notify Write Take/Notify WritePolling Event

ContainerNotify Event

ContainerPolling Event

ContainerNotify Event

Container

DeclarativeAbstraction

18

Reaching Scalability with Space Based SOA

Write

TakeRead

Write

Notify

Order Processing Demo: Logical Workflow

Write new Orders (Feed)Client

Accounting

BrokenOrderCleaner

Logistics

Take

Orders(new)

Write

Orders

(approved)

Take Orders

(approved)

Write

Orders

(shipped)

Take Orders

(shipped,

unshipped,

unapproved)

Write new Orders (once cleaned)

OrderSystem

Linearly Scalable OrderProcessing: Deploy Once:

GSC 1

SpaceProxy

Processing Unit 1

orderfeed

Spring Bean

GSC 2

EmbeddedSpace

Processing Unit 2

ordersystem

Spring Bean

GSC 1

Embedded Space

Processing Unit 1

ordersystem

Spring Bean

GSC 2

Embedded Space

Processing Unit 2

ordersystem

Spring Bean

GSC 3

Embedded Space

Processing Unit 3

ordersystemSpring Bean

One Logical Space

(Partitioned)

GSC 4

SpaceProxy

Processing Unit 4

orderfeed

Spring Bean

Linearly Scalable OrderProcessing: Deploy Again:

The throughput of the application grows linearly as the number of ordersystem deployments increase.

22

Building SBA Application – How it works..

• Step 1:

– Implement POJO domain model

• Step 2:

– Implement the POJO Services

• Step 3:

– Wire the services through spring

• Step 4:

– Packaging

– Deploy to Grid (Scale-Out)

Register

23

Come To The “Let’s Code” BOF!!!

• November 8th 2007 @7:15 PM in “City Room”

• Everyone bring a laptop

• Download GigaSpacesXAP6.0.1

– http://www.gigaspaces.com/os_downloads.html

• Install Eclipse 3.3 Europa [ or Intellij ]

• Go to my blog and download: “projectcreator.jar” (it is a zip in hiding)

– http://www.jroller.com/resources/o/owentaylor/project-creator.jar

25

So, Why use a Declarative SBA?

• Simple!

– Building a fully fledged distributed application becomes just a matter of wiring

simple local beans

• It’s all declarative through annotation or XML

• Non intrusiveness through abstraction

– High level abstraction provides higher degree of flexibility to plug-in different

solutions from different topologies, technologies and standards without

compromising on the least common denominator

• Extremely Extensible

– Very easy to extend the model and the underlying implementation without

changing the application

• Reduced learning curve – It’s just Spring

– If you already know Spring – you are ready to begin

• Fits natively to the existing Spring model

• Utilizes common practices such as annotation, IoC etc.

26

Questions Please?Thank You!

http://www.jroller.com/owentaylor