Scalable applications & service architecture via parallelization & caching.

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