Rich Feeds for RESCUEAn Integration Story

Barry Demchak and Ingolf KrügerCalifornia Institute for Telecommunications and Information Technology (Calit2)

May 7, 2008

Roadmap

• Introduction to RESCUE and Rich Feeds

• Rich Feeds Objectives

• Unconventional and emergent data feeds

• SOA-based Systems of Systems Integration

• Rich Services applied to rapid integration

• Rich Feeds at Calit2/UCSD

RESCUE Project

• Calit2 at UC San Diego

• Gather, maintain, leverage, present emergency information

• Serve emergency response networks and general public

• Save lives and infrastructure, return to normalcy

Rich Feeds for RESCUE

• Captures, preserves, integrates, and exposes

• Unconventional and emergent data feeds

• Real time or archivally

• Serve emergency response networks and general public

Rich Feeds Objectives and Challenges

• Acquisition of data feeds from (disinterested) producers⇒ Heterogeneous data sources⇒ Possibly uncooperative producers

• Distribution of data feeds to arbitrary consumers (agencies or public) for domain integration, historical analysis, ???

⇒ Data must be purveyed as received⇒ Multiple data access paths

• Data feed intermediaries can add new feeds, determine who can add data, who can consume data, …

⇒ Policy driven authorizations⇒ Authentication of all users⇒ Policy definition infrastructure

• Long term archiving⇒ Database with schemas

• Access by external systems

Research Feeds

Calit2 Traffic Incidents Calit2 Tracked Assets

User View

• Today’s Data Feeds– Traffic– Trackable Objects– UCSD Police Cameras– CalIT2 Cameras

• Today’s Visualizations– Google Maps– Google Earth (soon)

Preview

• Integration Architecture and Methodology

• Visualizations

• Operating in the Real World

Our View: Systems of Systems Integration

• Bottom up• Unintrusive to producer

• Quick• Ripe for Services and SOA

Services and SOA

• Manageability• Scalability• Dependability• Testability

Network Implementation

Single Server, Multiple Processes

Single Application, Linked Modules

Logical Deployment

• Malleability• Interoperability• Composition• Incremental

development

Patterns

Composite Pattern – Hierarchy (Vertical Integration)

Interceptor Pattern

Service 1

Service 1.2Service 1.1 Service 1.3

Service 1.3.1 Service 1.3.2

Service 2

Service 2.2Service 2.1

Interceptor Service

Message Pattern – Loose Coupling (Horizontal Integration)

Rich Services Architectural Pattern

From tightly to l o o s e l y coupled systems

a hierarchically decomposed structure supporting“horizontal” and “vertical” service integration

Rich Feeds Logical Architecture

• Scales to support large numbers of users• Storage that scales

• Processing and DB intensive data analysis• Integration with GIS systems and databases• Appropriate visualization methods

Authorization Monitor

Authentication Monitor

Integration System

ODBC Adapter

Database

Logging System

Service / Data

Connector

Visualizer Client

Consumer Adapter

Consumer Systems

Service / Data

Connector

Producer

Adapter

Experiment

Server

Producer Systems

System of Systems

Deployment Architecture

• Scales to support large numbers of users• Storage that scales

• Processing and DB intensive data analysis• Integration with GIS systems and databases• Appropriate visualization methods

Rich Feeds Web Visualization

• UC San Diego Active Shooter Drill– October 2007– Demonstrated Gizmo moving with embedded camera image

• San Diego Firestorms – October 2007

– Demonstrated addition of Calit2 Webcams (2 hours)

• San Diego Metropolitan Medical Strike Team Drill – January 2008– Demonstrated policy exclusion of UCSD Police Webcams

Demonstrate Showing All Feeds

(Click on map)

Demonstrate Animation

(Click on map)

Rich Services Development Process

Rich Services to the RESCUE

“To boldly go where

no service has gone before”.

• an extension of the service notion, based on an architectural pattern• Dynamic adaptation

– new services can be introduced at runtime

– no need to change or adapt the implementation of existing services

• Manage the complexity of a system-of-systems – decomposing into primary and crosscutting concerns– providing flexible encapsulation for these concerns

– generating a model that can easily be leveraged into a deployment

• Workflow management– Service choreography at the infrastructure or application level

Roadmap

• Introduction to RESCUE and Rich Feeds

• Rich Feeds Objectives

• Unconventional and emergent data feeds

• SOA-based Systems of Systems Integration

• Rich Services applied to rapid integration

• Rich Feeds at Calit2/UCSD

Credits

• Funding– NSF RESCUE (#03311690)

– NSF Responsphere (#0403433)

– NSF ASOSA: Automotive Service-Oriented Software and Systems Engineering (#CCF0702791)

– California Institute for Telecommunications and Information Technology (Calit2)

• Pictures– Barry Demchak (2008 MMST Drill at Coors Amphitheater)

– San Diego County Firestorms After Action Report 2007 (http://www.sdcounty.ca.gov/oes/ready/docs/2007_SanDiego_Fire_AAR_Main_Document_FINAL.pdf)

– MMST Exercise @ UCSD (http://mmstexercise.calit2.net/)

– Wikipedia (http://en.wikipedia.org/wiki/Composite_pattern,

Backup Slides

• Go back …

Logical Architecture

Logical Architecture w/Policy

Policy System

RESCUE

ODBC Adapter

Dat

a F

eed

P

rod

ucer

Au

then

ticat

ion

S/D Connector

Vis

ualiz

ato

in

To

ol

Au

then

ticat

ion

S/D Connector

Dat

aba

se

Ob

ligat

ion

Pro

cess

ing

S/D Connector

Request + Identity Certificate (X.509 or SAML)Request + Obligations

(Identity � Attributes) x Policy = [Decision, Obligations]

Logging System

PERMIS Organization

PERMIS Sequencing

Subject PEPUser Subject PDPCredential Issue Svc

Attribute Authority *

Target PEPIdentity SOA

Target PEPMaster Target

PDPTarget PDP *

Certificate Authority

Obligation Svc

Execute(action, target, identity)

Valiidate(identity)

Exportable Attribute List

GetAttributeList(target)

GetCredentials(attributeList, identity)

SignCredential(attribute)

SignedCredential

Execute(action, target, identity, credentialList)

CredentialList

AttributeList

Subject

Target

Valiidate(identity)

Credential Issue Svc

Attribute Authority *

Valiidate(credentialList)

GetCredentialis(attributeList, identity)SignCredential

(attribute)SignedCredential

CredentialListValidation, ValidatedAttributeList

Integrate(attributeList, subjectEnvironment)

DecideAccess(attributeList)

Credential Validation Svc

DecideAccess(attributeList)

Decision, Obligations

PerformObligations(action, target, obligationList)

Target

ResultExecute(result)

Integrate(decisions, obligations)

Result

Valiidate(credemtial)Result

Integrate(validatedAattributeList, targetEnvironment)

Decision, Obligations