Watch on-demand here: http://ecast.opensystemsmedia.com/339 Distributed systems work by sending information between otherwise independent applications. Traditionally, that communication is done by passing messages between the various nodes. This "message-centric" approach takes many forms, from simple direct transmissions to more complex message queue and transactional systems. All have a common premise: the unit of information exchange is the message itself. The infrastructure's role is to ensure that messages get to their intended recipients. Recently, another paradigm is becoming popular. In this approach, the distributed infrastructure takes more responsibility; it offers to the distributed system a single version of "truth." The fundamental unit of communication is a data-object value; the infrastructure has done its job not when a message is delivered, but when all nodes have the correct understanding of that value. Because the focus is on the data itself, this is termed "data-centric" infrastructure. While both types of middleware serve to connect distributed systems, the approaches are quite different. And the single most important decision you make when designing your distributed system – whether to go with the message-centric or data-centric approach – will result in different system capabilities, strengths, and weaknesses. In this webinar, we will examine both, discuss the differences and clarify which application use cases are best served by data- and message-centric designs.

1. Your systems. Working as one.
The Single
Most Important Decision in
Designing Your Distributed System
Stan Schneider, Ph.D.
CEO

2. Distributed Systems

3. Driver: Scale
• More things producing
and consuming data
• Greater volume of data
• System of systems
integration
System of
systems

4. Distributed Infrastructure Functions
• Communicate between concurrent apps
• Share and manage state
• Discover participants and data
• Add & delete participants
• Enforce rules of proper operation
• Deal with & recover from errors
• And on and on and on…

5. Communications Paradigms
What do applications exchange?

6. Message Centric Approach
• Traditional middleware exchanges messages
• Infrastructure is unaware of the content
• Developers write applications that send messages
between participants
Popular standards: JMS API; AMQP wire spec

7. Data Centric Approach
• Data-centric middleware maintains state
• Infrastructure manages the content
• Developers write applications that read and update a
virtual global data space
Source
Power Phase
(Key)
WPT1 37.4 122.0 -12.20
WPT2 10.7 74.0 -12.23
WPTN 50.2 150.07 -11.98
Persistence Recording
Service Service
Popular standards: DDS API, wire spec

8. Middleware Evolution
Point-to-Point Client/Server Publish/Subscribe Data-Centric
Pub/Sub Messaging
Brokered
ESB
Daemon
Data-Centric
Publish/Subscribe (DCPS)

9. A Simple Distributed Thermometer
• Message-centric
“verbs”
– Individual messages:
Alarm “set sensor B3 to 27”
Monitor – Application processed
• Data-centric “nouns”
– Update space: B3->
27
Process • Late joiner?
Control – Message: send
everything again
– Data: Just read last
value
Boiler B3 Temp
Quality
Logging

10. Sharing and Managing State
Who manages truth?

11. Managing State
• Message centric • Data centric
– Infrastructure doesn’t – Infrastructure knows
know state schemas, behavior
– MW controls message – MW controls data
behavior. Delivers all behavior. Can deliver
indistinguishable messages based on their
message equally content and properties.
– Applications manage – Infrastructure
state disseminates and
manages state

12. What is truth?
• Data-centric architecture is responsible for
managing “truth”
– How reliable is the information?
– How old is it?
– How many past versions are saved?
– What delivery guarantees are there?
– What happens if a producer fails?
• Called “Quality of Service” by DDS

13. What’s the Temperature?
• Message centric
– Messages
Alarm
Monitor
readings, changes, anything
– Deliver all message equally
Process – Application determines
Control
truth
Boiler B3 Temp Quality
• Data centric
Logging – Knows temp is a float
– Pick and choose who to
deliver it to
– MW delivers truth

14. Coupling
Set B3 to 27 B3
• Verb-based: applications • Noun-based: applications
interact with each other interact with data model

15. Database Analogy
• Files: “message” centric
– Application defined structure
– Simpler
– No common tools, consistency
• Database: data centric
– Key value: source of consistent truth
– Known schema
– CRUD interface
• Data-centric middleware is data-centric
infrastructure for moving data

16. State & Scaling…an Example

17. State & Scaling
Data State: Color denote uniqueness
Node/Service
Interface: Colors denote uniqueness

18. Application Centric Development
• Scales O(n2) only if
– each System invokes the Specified Interface of the System
that it wishes to communicate with and no application
state
– n is the number of interfaces

19. Application Centric Development
• Scales O(n3)
– Each system must understand the interaction
patterns and the remote data state….
– n is the number of data states

20. Application Centric Development
• O(n3) Scaling
– ~8 times more
complex

21. Message Centric Development
• Delegate syntactic
interoperability
– Scales O(n2)
– State is still in Apps

22. Data-Centric Development
• Delegate state to middleware
– Enables interoperability
– Scales O(n)
– State synced with middleware

23. Data-Centric Development
• Delegate state to middleware
– Enables interoperability
– Scales O(n)
– State synced with middleware
– Can move state into the middleware
and infrastructure
– Data-Centric Pub/Sub

24. Example: Data-Centric ‘Track’
• Middleware knows what a “track” is
• Each is an identified object; CRUD interface
• System maintains the track list
Dispose New Update New
Subscribe
Publish
“ID:UA23” “ID:DL87” “ID:UA23” “ID:UA23”
65.4 56.7 45.6
X 32.1 89.0 78.9

25. The Single Most Important Decision?
Will the apps manage truth &
The infrastructure exchange messages?
Or
Will the infrastructure manage truth &
The apps exchange state?

26. What to Consider?
Design Factors

27. Not Black & White
Data Centric
Message Centric

28. How Important is Controlled State?
• Unmanaged state leads quickly to inconsistency
• Data centric pros
– Multiple consumers access consistent state
– Clear data exchange rules
– Failover, tools, selective delivery natural; simpler
applications
• Data centric cons
– Agree on a shared data model (!)
– Upfront data model, property design
– Less design flexibility in applications

29. How Challenging is Integration?
• With data-centric, all apps
can examine, match, and
deliver the right data
• Components learn schema
and thus interoperate
• Enables generic
tools, reusable
applications, selective
delivery, and structured
designs

30. Distributing Work or Information?
• Message-centric best when distributing “things” and
“processing” them.
– Very mature message-centric techniques
– Transactional behavior
– Information is naturally centralized
– Load balancing that doles out single messages across many
servers
• Data-centric systems excel at scalable information
distribution
– Efficient fanout
– Selective control of bandwidth & delivery
– Tight latency or real-time delivery constraints
– Easier discovery, late-joiner updates
– Integrating many different functions
7/31/2012 30

31. What’s the Project Lifecycle?
• Messaging simpler connecting point A to point B
– Fielded in a few months
– Limited to a small number of cooperating applications
– Developed by a cohesive team
– Short lifetime
• Data-centric systems build lasting architecture
– Upfront data model, interface design
– Less familiar concepts
– Can add applications, scale, and evolve
– Distributed teams, complex system integration, and
long-term viability justify initial investment

32. How to Choose?

33. Clarify requirements & factors
• Develop requirements
– Map out data content and exchange
– Consider scenarios that expose coupling
– Analyze performance and scaling
– Plan for evolution
• Consider key factors
– Controlled state
– Integration
– Work or information
– Lifecycle

34. Choose the best fit
• Data centric and message centric are both
proven technologies
• Both can solve many (any?) problem
• Choose the approach that reduces
coupling, delivers performance, and supports
your long-term architecture

35. Download
Connext
Free Trial
NOW
www.rti.com/downloads

36. Your Systems.
Working as OneSM