170 likes | 282 Views
NEER-IPT All Hazards Alert & Warning (AHAW) Capability Pattern. Releasable to International NCOIC-NEER AHAW-20091014. The Goal: Part One.
E N D
NEER-IPT All Hazards Alert & Warning (AHAW) Capability Pattern Releasable to International NCOIC-NEER AHAW-20091014
The Goal: Part One • From Abstract: “The goal of the All Hazards Alert & Warning (AHAW) pattern is to provide a practical, pragmatic methodology for efficient & timely generation, authentication or confirmation & distribution of emergency alerts & warnings …” • Takeaway for At-Risk, At-Large Public Audience: • Right Information to • Right People at • Right Time • Best Emergency Response REQUIRES Best Start • Emergency Management Lifecycle Starts with Planning & Preparation, BUT • AHAW Forms First Public Perception • Success of NCOIC NEER-IPT AHAW = Speed + Invisibility • SHOULD Take Least Possible Time for Alert/Warning Message Delivery • Process SHOULD NOT be Noticed
The Goal: Part Two • From Abstract: “This pattern seeks to automate the human to machine, machine to machine & machine to human interchange during emergency communications as effectively as possible given the limitations of heterogeneous ICT systems & systems of systems.” • Takeaway for NCOIC Audience: • AHAW MUST Achieve Communication Clarity so • Automation Speeds Human Decision Making in Emergencies • Net-Centric Services Framework Provides SOA Ecosystem • NEER-IPT Core Services Can Provide Building Blocks (Note: Presentation doesn’t follow the specified flow of the Pattern Outline.)
The Problem • Problem Statement: Policies & Governance Across Organizational Boundaries: Who is Authorized to Issue Alerts & Warnings? • Local, State, National, Tribal & International Jurisdictions • Different Legal Mandates & Jurisdictional Polices Apply in Different Situations • NCOIC NEER-IPT AHAW Pattern MUST Work with Any & All Solutions • Jurisdictional Independence added to Platform & Vendor Independence • Use of Intermediate, Domain-Specific Standards can Accomplish this Objective • Many Jurisdictions Adopting Open-Standards Based Solution Requirements
The Solution: Methodology • AHAW Based on Open Standards • Organization for the Advance of Structured Information Standards (OASIS) Common Alerting Protocol v1.1 • OASIS Emergency Data Exchange Language Distribution Element (EDXL-DE) v1.0 • OASIS Reference Model for Service Oriented Architecture v1.0 • Others from Object Management Group (OMG), The Open Group (TOG), International Organization for Standardization (ISO) • AHAW uses most Net-Centric Services Framework Principles • Execution Platform Independence • Dyanmic Configuration • Explicit Service Scope • Autonomicity • Reuse • Net Centric Data
CAP Standard • CAP Provides a Standard Message Format for Alerts & Warnings Common Alerting Protocol v1.2 Source: OASIS Standard Common Alerting Protocal v1.2(approval pending as of 24 August 2009)
EDXL-DE Standard • EDXL-DE Provides Standard Distribution for Emergency Messages EDXL-DE v1.0 Document Object Model (Source: OASIS Standard Emergency Data Exchange Language Distribution Element EDXL-DE)
The Solution: Methodology • AHAW Pattern Identifies Key Participants – Actors • Subject Matter Experts (Bring Expertise from Field to Designing Standards & Services • Standards Developers Develop Open St&ards for use in Services • Service Providers Create & Deliver Services Based on Standards • Service Consumers Use Services • Policy Makers Specify Policies for Governance of Services, Nertworks & Systems • Senders Issue CAP Alerts Packaged as EDXL-DE Payloads • Recipients Consume CAP Alerts Packaged as EDXL-DE Payloads • Certification Authorities Certify Conformance with Standards & Issue Identity Management Certificates or
The Solution: Methodology • AHAW Based on Net-Centric Principles • Explicitness: Implemented in Service Description • Symmetry: Implemented in Identification of Alert Senders & Recipients • Dynamism: Implemented in the use of SOA Registry-Repositories for Visibility & Discovery • Globalism: Implemented in the Service Description for Specification of Policies, Action Model & Process Model • Ubiquitous Access: Implemented in the use of SOA Registry-Repositories for Visibility & Discovery • Entity Identity Primacy: Implemented in the use of Certification Authorities for Identity Management • Explicit Relationship: Implemented through Service Description in Policy Description & Service level Agreements • Scale independence: Implemented in use of Platform & Scale Independent Open Standards • Pragmatism: Implemented in the Identification of choreography & Orchestration Contraints for the Integration of Discrete Services
Pre-Condition:SOA Principle: Visibility • Visibility is the relationship between service consumers & providers that is satisfied when they are able to interact with each other. Preconditions to visibility are awareness, willingness & reachability. The initiator in a service interaction MUST be aware of the other parties, the participants MUST be predisposed to interaction, & the participants MUST be able to interact Source: OASIS SOA-RM: Concepts around Visibility(OASIS Ref Model for SOAs)
Pre-Condition:SOA Registry-Repositories • SOA Registry-Repositories (SOA-RRs) Provide Visibility Robust EDXL-DE-Capable Network of Networks using SPORs (Source: NCOIC)
Pre-Condition:NEER-IPT Core Services • NEER-IPT Core Services & Cloud Computing • Agency Locator • Identity Management • Digital Rights Management • Cloud Computing Storefront is a type of SOA Registry-Repository (Source: NCOIC)
Pre-Condition:Service Description • Service Description from SOA-RR is Key to Accessing, Understanding & Invocation of Services Service Description (Source: Reference Architecture Foundation for SOA v1.0)
Pre-Condition:Policies & Contracts • Policies & Contracts, including Service Level Agreements (SLAs) MUST be Referenced Model for Policies & Contracts related to Service Participants (Source: Reference Architecture Foundation for SOA v1.0)
Behavior:How AHAW Works • NC Pattern Term: Behavior • The Behavior of the EDXL-DE packaged & distributed CAP alert message using NEER-IPT Core Services is straightforward: • it is verfied by the authorized issuing governmental jurisdiction; &, • it is released into a distribution network such as the DHS DM-OPEN system where it is available to all qualified polling entities. • At Present: Pull Only; Push in Development • EDXL-DE Adoption Actively Promoted by DHS, but AHAW Requires DE • AHAW is First NEER-IPT Pattern Modeling Behavior of Net-Centric Services • Emergency Management Message Payloads • Alerts • Reports • Requests • Responses
The Goal: Revisited • From Abstract: “The goal of the All Hazards Alert & Warning (AHAW) pattern is to provide a practical, pragmatic methodology for efficient & timely generation, authentication or confirmation & distribution of emergency alerts & warnings …” • Takeaway for At-Risk, At-Large Public Audience: • Right Information to • Right People at • Right Time • Best Emergency Response REQUIRES Best Start • Emergency Management Lifecycle Starts with Planning & Preparation, BUT • AHAW Forms First Public Perception • Success of NCOIC NEER-IPT AHAW = Speed + Invisibility • SHOULD Take Least Possible Time for Alert/Warning Message Delivery • Process SHOULD NOT be Noticed
NEER Contacts • Please direct all inquiries regarding the NCOIC Net-Enabled Emergency Response initiative to: • Stephen GrossNEER IPT Chair+1.202.879.5678stgross@deloitte.com • Please copy: • Paul Mangione,Senior Technical Staff +1.253.839.3395paul.mangione@ncoic.org