This document discusses how telecommunications and web services are adopting horizontal scaling and parallel architectures to handle enormous growth. It describes how event-driven applications are well-suited for parallelism and how middleware like tuple spaces, message queues, and publish/subscribe systems provide coordination and scalability. Finally, it argues that horizontal scalability requires parallel designs from the start and that simple middleware models with distributed caching can effectively support both communication and data management needs.

1. Ultra-scalable Architectures for
Telecommunications and Web 2.0
Services
Mauricio Arango
Bernd Kaponig
Sun Microsystems
October 27, 2009

2. Web 2.0 Impact on Communications
Applications
• Information-sharing, social media services such
as Facebook, Twitter – experiencing fast &
enormous growth
• Growth handled via horizontal scaling vs.
vertical scaling – no forklift upgrades – agile
and lower-cost
• Involves handling parallelism challenge in
telecommunications service software
2

3. Impact of New Communications
Applications - cont.
• Telecom service providers launching Web 2.0-
like services
– Nokia Ovi
– Vodafone 360
• Expansion of services based on telecom
network advantages - event-driven
– Location-based
– M2M
– Metered realtime billing
– SLA management
3

4. Parallel Application Architecture
Model (server side)
● Parallelize – breakup
into pieces
– Application
– Data
● Requires middleware
– Coordination
(communication)
– Data management
4

5. Price of Horizontal Scaling
• Requires software that can be distributed and has high degree
of parallelism -
– Applications broken into components
– Components run in parallel in a distributed processing infrastructure
Monolithic application Parallel application
5

6. Good News – Event-driven apps
have high parallelism
• Web and • Data stream-driven
telecommunications • Event-based coordination
applications are event- pattern
driven
– User-generated events
– Monitoring and sensing
events
– Network events
6

7. Other Parallel Application Design
Patterns
Worker 1
• Master-worker Master Worker 2
Worker N
• Pipeline Phase
Stage 1 Stage 2 Stage N
1
Phase
Stage 1
• Hybrid 1 Stage 2 Stage N
Master Phase
St
1 Stage 2 Stage N
Phase
Stage 1
1 Stage 2 Stage N
7

8. Communications Middleware
• Coordination – interaction required when an
application is split into multiple components
Direct communication Indirect communication
• Request-response, Notification • A node only needs to know about the
• intermediate entity
Tightly coupled – every node needs to
know about other nodes' address and • Space decoupling
functions – non-scalable complexity for • Time decoupling
developer
• Three mechanisms
• Poor at handling node failures
– Tuple Space
– Message Queue
– Publish/Subscribe 8

9. Tuple Space
• Invented by David Gelernter in early 80s • Space & time decoupling across
• Simple functionality – via four operations components
– out()- deposits tuple • Shared associative object (tuple)
– in()- removes matching tuple store
– read() - reads matching tuple • Inherent load-balancing
– notify() - registers for notification • Event processing framework
on matching tuple • Natural fit with business
processes
Component 2 Component 3
Component 1
Component 4
in( ) out( )
out( ) read( )
read( )
Tuple Space 9

10. Message Queue
• Intermediate entity: set of queues
• Communicating components only need to know queue names
• Basic functions:
– sendMsg(queueName, message)
– getMsg(queueName)
• Can be mapped as a subset of Tuple Space using:
– out(queueName, message) for sendMsg
– in(queueName) for getMsg
Component 1
Component 2
sendMsg(queue-1, )
getMsg(queue-1)
sendMsg(queue-2, )
Message queue 1
Component 3
getMsg(queue-2)
Message queue 2
10

11. Publish/Subscribe
• Intermediate entity: broker
• Basic functions:
– subscribe(template)
– publish(message)
• Can be mapped as a subset of Tuple Space
using:
– out(tuple) for publish()
– notify(template) for subscribe()
11

12. Surge of Indirect Messaging
Middleware
● Blitz (JavaSpaces)
● Gigaspaces
● Rinda
● Gruple
● Semispace
● Open source JMS
– Sun Open Message Queue
– Apache ActiveMQ
● Amazon Simple Message Queue Service
● Rabbit MQ – based AMQP standard
● Gearman
● XMPP Pub/Sub
● Pubsubhubbub 12

13. Data Management Middleware
• Scaling via parallelization and
caching
• Parallelization
– Replication – read-most data
– Partitioning/sharding – write &
read
• Distributed caching
– Shares scaling techniques with
communications middleware
– Use of Distributed Hash Tables
(DHT)
13

14. Use Case – Twitter-like, many-to-
many Messaging System
• Process new message
– out(message_list_update, follower,
message_publisher, message_content)
• Update message list
– in(message_list_update, ?r, ?t)
– Put(new message)
• Retrieve message list
– get(messages)
14

15. Conclusions
• Horizontal scalability requires parallel application
architectures from day one
• Parallelization involves simple communications
middleware models & simple APIs
– Tuple Space simplest & superset model
• Distributed caching – scalable foundation for both
communications and data management middleware
• Parallel application architectures key in
telecommunications evolution
15

16. Additional information
● Paper (includes references):
http://blogs.sun.com/arango/resource/ICIN-09-Ultra
● Blog: http://blogs.sun.com/arango/
16