Webcast (sorry, audio not included) on system integration design patterns from July of 2010 pertaining mostly (but not exclusively) to Data-Distribution Service (DDS) technology.
9. Subsystem 2
P P
PP P
Subsystem 1
P P
PP P
Schematic of a Composed System
Subsystems may have different network environments
Integration may have different network environment
than subsystems themselves
Data may need to be transformed / cleansed as it
moves among subsystems
Routing / gateway services will adapt data types /
formats / protocols
LAN LAN
WAN
Router/G
ateway
Router/G
ateway
Isolation
Additional
Governance
11. Same data model?
Same network env.?
Same lifecycle?
Behavior unaffected?
Understandable?
Apples and Oranges
P P
PP P
Subsystem 1 + Subsystem 2
P P
PP P
Subsystem 2
P P
PP P
Subsystem 1
P P
PP P
Router/
Gateway
Router/
Gateway
TRL 9:
Actual system proven through successful mission operations. Actual application of the technology in its final form and under mission conditions, such as those encountered in operational test and evaluation (OT&E). Examples include using the system under operational mission conditions.
When I say “large” in this presentation, I’m primarily talking about complexity. I’m not talking primarily about a unified simple design that happens to have lots of participants in it.
Same principles apply to defense systems, financial systems, power systems, industrial automation, etc.
Care about lots of the same things as any system designers — functionality, performance, … — but care about certain things much more.
Isolation relates to governance: making sure integration doesn’t violate SLAs
This will eventually be a talk about DDS, but we’ll get to that later
Integrating two subsystems with different data spaces is not the same as joining them into one data space.
You will be tempted to just mush things together. (Just connect the network cable; it’s easy, right?) Beware that temptation.
Are the different subsystems using the same structural and behavioral data model?
Are the network environments the same?
Do they evolve together?
Suppose the answers are both Yes.
Will they continue to be the same over time as the composed system evolves?
Will the system behave the same when all the data is going to twice as many consumers?
Can one team of people understand the design and operation of a now-much-more-complex single subsystem?
Same principles apply in every industry
Same principles apply in every industry
Same principles apply in every industry
Same principles apply in every industry
2 problem areas brought up before that we haven’t discussed yet.
These will be bridge to technology-specific discussion in 2nd half.
From the beginning, the data stream is associated with the schema of the data that will be propagated on that stream. Your applications already have some expectations; if you express those to a data-centric infrastructure, it can help you. For example, you can use this schema to automatically transform data into other formats. (This is how the Routing Service and Web Integration Service work.) The infrastructure can also dissect your data to filter on content (for example “give me updates where x > 5”).
“Key” means “this field establishes the identity of a unique object.” Like the key in a relational database table. In DDS, can be any number of fields of any type(s).
New track you’ve never seen before. Notice that since type is already known, only need to send field values, not field names or types.
Update to a track you’ve already seen
Another new track – notice that the key is different
A track you’ve seen before has gone away
Test results from lab of hundreds of multi-core Linux machines connected by gigabit Ethernet