High-Performance Interoperable Architecture for Information Dominance

Gordon A. Hunt – RTI Webinar

Chief Engineer, RTI • UCS WG Sub-Committee Chair • Commander USN-R

Agenda

• High Performance– It really is about time…

• Interoperable Architecture– What is Interoperability– Architecture foundations

• [for] Information Dominance– Putting it all together– Right time – right data – right place

So, a little about Performance.

Measure the right thingfor the right reason.

Performance

• What can we measure?– Message rates– Numbers of messages– Size of messages– Time to process messages– Number of clients, number of servers– Throughput of a broker/server

• Do the measurements matter?– Consider that “Messages” are about something.– What I really care about, is how long it takes to know that

something.

Performance is often Defined by…

Point-to-point, sockets, RPC, RMIConcerned with an applications individual throughput/latencyBottleneck at the slowest applicationLittle correlation between bus/fabric speeds and system performance

Centralized, DB, ESBsMeasure the aggregate performanceReplication rates, transaction ratesNumber of supported clientsGenerally not measure client

performance

Decentralized, Data CentricMeasures data as presented to the applicationMeasures data update rates (1-1, 1-many, etc.)Measures time to get the consistent state

BrokerESB

DBMS

Performance Does Matter

• Impacts Scale– How big is the System-of Systems going to be?– Physically can’t send all the data everywhere.– Can’t revisit existing application when adding new capability.

• Impacts flexibility of Implementation– Not arbitrarily constrained to messages rates/sizes.– Capability and distribution can be added.

• However, the following is required– Applications need to manage their performance requirements– Applications need to manage their behavior explicitly

Application Behavior Concerns

• What data is valid– Do I have the current value(s), from everyone

• How much of the data do I need– Reliably, only get me date that changes by a little bit– Send me data no faster than this rate

• What happens if– I expected an update to data at …, what do you do.– I want an acknowledgement, wait for this long, for this many

• I’m too busy– Old data that I am just getting around to looking at– Are the updates I’m about to send even valid anymore?

Managed Performance for Information Dominance

Integration Bus for Information Dominance

Operational Systems / Tactical Systems

DATA-IN_MOTION

Information Technology (IT)Command & Control (C2)

DATA-AT-REST

ApplicationQuality of Service

(Desired Behaviors,..)

ApplicationQuality of Service

(Desired Behaviors,..)

An Integration Capability that

• Supports Integration of applications and delivery of consistent behaviors when– Environment is ADHOC– Performance concerns are mixed– Scale is unknown– Technologies are mixed

• Enables Information Dominance via– Architectural approach that supports a rigorous yet

flexible integration methodology that is interoperable across data form/function boundaries

Interoperable Architecture

How Do We ‘Do’ Interoperability?

What does the Architecture look like?

Current Approaches

• Protocol Definitions & Standards– Tell me the messages

• Open Architecture Mandates– Interoperability on Commonality

• Service Oriented Architecture – Stateless services

Is Current Practice Working

• Recent studies have shown a growth in interoperability policy issuance in DoD– Thousands of pages of directives, instructions, and mandates– Numerous standards and architecture bodies in the DoD

• No Correlation between Increased Interoperability and Standards– Standards are necessary, but not sufficient for interoperability

• Conventional means of developing platform, unit command, and theater architectures are complex, manpower intensive, and time consuming.– Achieving Interoperability increases complexity– Complexity of systems-of-systems not understood or well managed – Can’t make complexity go away, just move where it is

Pause: What are we Trying to Achieve?

DriverInterchangeability To put each of (two things) in the place of the other, or to be used in place of

each other.

Integratability To form, coordinate, or blend into a functioning or unified whole. To incorporate into a larger, functioning or unified whole.

Replaceability One thing or person taking the place of another especially as a substitute or successor.

Extensibility The ability to add new components, subsystems, and capabilities to a system.

Interoperability The ability of systems, units, or forces to provide services to and accept services from other systems, units, or forces, and to use the services so exchanged to enable them to operate effectively together.

Open Architecture Requires Interoperability at a Higher Level Than Key Interfaces.

Levels of Interoperability -- Technical --

System BehaviorCommunication protocol for exchanging

data. Bits & Bytes

are exchanged in

an unambiguous

manner.

Non-Functional NeedInterchangeability,

Integrateability, Replaceability,

Extensibility,

and Meaningful

InteroperabilityTechnical

Levels of Interoperability-- Syntactic --

System BehaviorCommon structure or data format defined for exchanging information.

This format

must be unambiguously defined.

Non-Functional NeedInterchangeability,

Integrateability, Replaceability,

Extensibility,

And Meaningful

Interoperability

Syntactic

Technical

Levels of Interoperability-- Semantic --

System BehaviorMeaning of data

is exchanged

via common

information

model.

The meaningof information is shared and unambiguously defined.

Non-Functional NeedInterchangeability,

Integrateability, Replaceability,

Extensibility,

And Meaningful

Interoperability

Semantic

Syntactic

Technical

What’s the Difference?

• Semantic definition captures concepts of– Structure (Content)– Relationships (Context) – Time (Behaviors)

• This makes the state of the system and the application’s data– Explicit– Directly Observable– Manageable

• Everything has state…

Why is this hard?

Consider a measure of complexity on application development approaches.

How to Architect Systems to Achieve Interoperability

1. Application Centric: Building Interoperable Apps– Application manages Technical, Syntactic, and Semantic Interoperability

2. Message Centric: Building Interoperable Messaging Systems– Delegates Syntactic Interoperability to Messaging Middleware– Application manages Semantic Interoperability

3. Data Centric: Building Truly Data Centric Systems– Delegates Semantic Interoperability to Middleware– Open Architecture Requires a Data Centric Approach.

19

20

Application Centric Development

• Scales O(n) only if– fully known, distributed, and homogeneous

knowledge of interfaces and state

Node/Service

Interface: Colors denote uniqueness

Data State: Color denote uniqueness

21

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

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

22

23

Application Centric Development

• Small systems aren’t the problem, and they give a false sense of hope. – This is ~3.5 time more ‘complex’ than 2 nodes

24

Application Centric Development

• O(n3) Scaling – ~8 times more

complex

25

Message Centric Development

• Delegate syntacticinteroperability– Scales O(n2)– State is still in Apps

Data-Centric Development

• Delegate to middlewareSyntactic and Semantic Interoperability– Scales O(n)– State synced with middleware

– State IN the middlewareand infrastructure

– Data-Centric Pub/Sub

26

An Interoperable Architecture

HAS a Data-Centric bus and is Semantically Defined.

What is State?

• Things have attributes and characteristics

– The meeting will run 1:00–2:00 in the conference room.

– My friend’s phone number is 555-1234 and he’s currently grooming his cat.

– The car is blue and is traveling north from Sunnyvale at 65 mph.

– The UAS is performing this mission, with these goals and resources.

…whether they exist in the real world, in the computer, or both

…whether or not we observe or acknowledge them

“State” (“data”) is a snapshot of these attributes and characteristics.

Best Practice: operate on state, not dialogs about state.

Data-Centric is Explicit Understanding of State

Weather Service- Stateless Service- Provides current weather

only when asked

Weather ‘Client’- Asks for a Weather Report- Get the current prediction

State- The fact that I asked, - Where, at a certain time- ‘Somebody’ has to keep it current…

Example: Data-Centric FlightPlan

Publish

Subscribe

New

45.6

78.9

“AA123”Update

56.7

89.0

“AA123”New

65.4

32.1

“DL987”Dispose

“AA123”

X

Start with a Semantic understanding of FlightPlans

Content is understood – can represent data efficiently

Context is understood, know what’s what….

Example: Data-Centric FlightPlan

• Once infrastructure understands objects, can attach behavior (QoS) contracts to them

• Data-in-motion behavior includes time perspective• “Keep only the latest value” or “I need updates at this

rate” make no sense unless per-object– Flight AA123 updates shouldn’t overwrite DL987,

even if AA123 is updated more frequently– Update rate for one track shouldn’t change just because another

track appeared

Publish

Subscribe

Quality of Service

Deadline

Time-Based Filter

HistoryFlightPlanFlightPlanFlightPlanFlightPlan

[for] Information Dominance

Making it Happen, Steps you can take…

32

Challenges for Information Dominance

• Consistent Application Performance– Regardless of Scale– Numbers of nodes, amount of data, data rates…

• Dynamic systems’ topology– No system always on, nodes come and go– Capabilities derived from rapid integration

• Disparate Technologies– Different deployment concerns– Different interaction patterns and behaviors

• Data-in-Motion and Data-at-Rest– Making at all actionable at the right place & time

Data-Centric Infrastructure Supports Information Dominance

Integration Bus for Information Dominance

Operational Systems / Tactical Systems

DATA-IN_MOTION

Information Technology (IT)Command & Control (C2)

DATA-AT-REST

ApplicationQuality of Service

(Time, Performance,..)

ApplicationQuality of Service

(Time, Performance,..)

RTI Connext :Edge-to-Enterprise Real-Time SOA

Facilitates cross-organizational integration:• Well-defined and discoverable information models;• Standard data-centric operations• Standard wire interoperability protocol• Mediation: integrate with any interface, expose via any interface

Connext Integrator

Operational Systems Information Technology (IT)

Connext Micro

Connext DDS

Connext Messaging

RTI Connext™: A Data-Centric Infrastructure

RTI DataBus™

ConnextMicro

Pub/Sub API

Small Device Apps

ConnextDDS

Pub/Sub API

DDS Apps

ConnextMessaging

Messaging API

General-Purpose Real-Time Apps

ConnextIntegrator

Adapters

Discrete OT & IT Apps/Systems

Administration

Monitoring

Logging

Recording

Replay

Federation

Transformation

PersistenceVisualization

Common Tools and Infrastructure Services

Summary

• Information Dominance is enabled by– Access to the right information – Managed expectations with regards to performance

• Access to the right information is facilitated by– The right architecture and description of data– Content, Context, and Behavior

• Leveraging the data is facilitated by – Having that data presented to the application in the

right form and function– Decoupling the applications view from the

infrastructures management of the state

Where is State

Point-to-point, sockets, RPC, RMIState is in the applicationsEach application maintains its view

Centralized, DB, ESBsState is in the DatabaseManaged interactions with state

Decentralized, Data CentricState is in the busStateless clients/servicesState has explicit properties to manage its behavior

BrokerESB

DBMS

DownloadConnextFree TrialNOW

www.rti.com/downloads