Disaster Management e-Gov Initiative

Program A Deceptively Simple Approach

to an Emergency Data Exchange LanguageDistribution Element (EDXL-DE)

Based Web Service

Connectivity Week Presentation June 11, 2009

Gary A. Ham

Disaster Management Program CapabilitiesDM Framework

DM-Framework• User Facing Interface • Available to Responders and Emergency managers• An “integration station” for applications that may need

to be concurrently accessed on the desk top• Defines ways by which applications can be “plugged

in”• Users can create a computing and communication

device that meets their individual requirements• Interacts with other systems via DM-OPEN

Disaster Management Program CapabilitiesDM-OPEN

DM-OPEN • Application Facing Middleware as a free Government Service - Federal infrastructure• Operational non-proprietary interoperability backbone • A vendor neutral Web services platform open to all - Acts as a “level playing field” • Allows disparate third-party applications, systems, networks and devices to share

information in a non-proprietary, open based standards format. • Connects Emergency Systems to Each Other• Uses Emergency Messaging Standards

– EDXL-DE and CAP– NIEM IEPDs

Federal Infrastructure

DM-OPEN: A Totally Non-proprietary Solution

• DM-OPEN is actually open. – Enables interoperability between differing networks – API’s are publicly available– DM-OPEN is government infrastructure– No vendor controls DM-OPEN, nor does any vendor control access– Prototype development and production activity is not restricted by license, non-

disclosure agreement, or any other form of intellectual property control• Supports the delivery of real-time data and situational awareness to public emergency

responders in the field, at operation centers, and across all levels of response management

• Serves as test bed to facilitate the development of open non-proprietary standard to support interoperable information sharing for the emergency responder community

A network of networks

Allows disparate networks to connect to each other

Benefits: DM-OPEN

• Reduced cost of development: – One interface is usable by other DM-OPEN partners– Cost of connectivity is dramatically reduced– A system only has to write to one interface per ICS function instead of one for each connecting

system per ICS function– Example: WebEOC, Previstar, E-Team, MyStateUSA and the DMIS Tools (and others) have all built

a Common Alerting Protocol (CAP) exchange capability through DM-OPEN.• This amounts to 10 possible pathways for CAP Alerts between systems• There are 15 possible connection paths for the cost of 6 interfaces• The benefit increases

• Reduced system rigidity:– Loosely coupled systems

using standard messaging– Easy to update an

application in one area without affecting the others, making maintenance easier, and improvement more fluid and less traumatic in terms of installation and training costs

DM-OPEN Interoperability is Available Today

• DM-OPEN is Federal infrastructure• Operational today – In production• Available at no cost to end users• Uses common XML data standards • Application, system, and tool agnostic.

It’s not a “we will have it soon.”

It is a fully funded program that can be leveraged to help solve information sharing and interoperability issues.

CAP In Production – 4 Different Products – Same Data

DM-OPEN: Improvement Pending

• Our current interfaces are RPC-encoded SOAP

– This is fine in a function-oriented, other-than-Microsoft environment

– It is out of date in a Web 2.0 SOA environment

– It is costly to maintain as new EDXL (and other) standards come into Play

• The new Goals:

– A truly data-driven interface that relies on the content of the request document to define the actions of the server and what is returned in response

– Make EDXL-DE the centerpiece for the interface (CAP1.1 and NWEM are maintained, but every thing else will be DE Driven)

– A single request response pattern for all activity.

DM-OPEN: A Concept of Operations for the DE

• One DE interface for all content types

• One connection to build even as the number of data standards increase

• “Data driven” retrieval – as opposed to process driven

• “Data driven” interest registration

• Access to values allowed in known ValueList URN Structures

• A low-cost solution to participation in a network of networks

Leveraging the Distribution ElementTo Meet Multiple Information Sharing Requirements

• DE serves two primary purposes

– Allows an organization to wrap and characterize important pieces of information into a single easy-to-distribute XML "package” for sharing

– Allows an organization to "address" the package in flexible ways to support intelligent routing including specification of recipients by role, geographic area, or keywords

• Organizations can use standardized lists of roles or keywords, or their own for additional flexibility and tailoring.

DM-Open as a Virtual “Post Office”

EDXL DE• Facilitates discriminatory

access Metadata• Role-based permissions• geo-location

COGs are ‘mailboxes’

DM-OPEN is a backbone message distribution server maintained by DHS that acts as a Virtual post office.

DM-OPEN: Excerpts from Design Documentation

HazCollect Service

InteroperatingEnd-User and

Alerting/MessagingSystems

ResponseMessage

RequestMessage

PostMessage

ACK

OWSM

Call-Back-Client

BPEL

Receive Input

Transform-In

DM-OPENServices

Invoke Service

Transform-Out

OracleInternet

Directory(OID)

OWSMPolicy Manager

& MonitorGateway/Agents

Databases: OPEN Web-Services, OID, SOA Meta-Data Repository, Oracle Service Registry

OracleServiceRegistry

BusinessActivity

Monitor (BAM)

DiskArraysSAN

NWS HazCollect

SOAP over HTTPS

SOAP overHTTPS

Web-ServicesCAP 1.1

EDXL-DENWEM

COG Admininstration

MessagingAlerts

Emergency MessagesNIEM IEPD

Oracle RAC

ResponseMessage

NWEM-Post& RequestMessages

DM-OPEN SOA Platform

Oracle Application Server(J2EE, WS-*, Event Services,

Business Rules)

• All complexity is hidden

• Used Oracle Identity Management, BPEL, Oracle Web Service Manager, and the Oracle Service Registry behind the scenes

• Uses two operations (WSDL Port Types) for all transactions:

• postOp()

• getRequestOp()

Drawing Courtesy IBM’s EADIS Design Team for DM-OPEN

DM-OPEN: Scope at IOC

The two use cases cover the entire scope of the actions that the using system is able to perform.

The Post and Request/Receive use cases contain several sub-use cases with detailed data manipulation actions

Post and Request/Receive are common message transaction services

Post and Request/Receive use cases form the base for the specific message service use cases

Drawing Courtesy IBM’s EADIS Design Team for DM-OPEN

DM-Framework & DM-OPEN Support Incident Coordination & Management

• Information needs to be managed and shared:– Within a Single organization– Laterally between multiple ‘peer’

organizations– Along the Chain of Command– Vertically– Externally– To the public

Facilitation and information exchange,but NOT command and control !!!

Contact Information

• For Information on DM-OPEN -http://www.disasterhelp.gov/disastermanagement/open/index.shtm

• To request DM-OPEN Access - http://fema.eyestreet.com/dmis/administratorUpdate.do?action=Init&type=Interop

• For Frequently Asked Questions - http://www.disasterhelp.gov/disastermanagement/open/faqs.shtm

• DM-OPEN Support:

– For developer assistance with implementation questions, please email OPEN@eyestreet.com.