NIEM and SOA for Mission Critical System Information Sharing Environment August 2011

advertisement
NIEM and SOA for Mission Critical System
Office of the Program Manager
Information Sharing Environment
August 2011
www.ise.gov
Agenda
• National Information Exchange Model (NIEM) – What is it?
• NIEM and SOA at New York State Police
• Why is this relevant at a Healthcare Conference?
This is Not a Healthcare Case Study, but We
Share Similar Problems and Potentially
NIEM Might Offer a Solution….
NIEM – What is it?
• An XML-based voluntary consensus standard with a pre-harmonized
vocabulary to enable information sharing
• Designed to develop, disseminate and support cross-enterprise
information exchange
• Enable mission partners to effectively share critical information in
emergency situations, as well as support the day-to-day operational
information sharing requirements
• Managed by the DoJ, DHS, HHS, the Global Justice Information
Sharing Initiative
The NIEM Framework
NIEM connects communities of people, and provides a foundation for
seamless information exchange between federal, state, local, and
tribal agencies.
Community
Technical
Framework
Support
Framework
Formal Governance
Processes
Data Model
Tools for Development
and Discovery
Online Repositories
XML Design Rules
Established Training
Program
Mission-Oriented
Domains
Development
Methodology
Implementation
Support
Self-Managing
Domain Stewards
Predefined
Deliverables (IEPD)
Help Desk &
Knowledge Center
NIEM – Historic Perspective
• 2000 – GJXDD - Global Justice XML Data Dictionary
• 2003 – GJXDM – Global Justice XML Data Model
• 2005 – NIEM program is established
• 2006 – NIEM 1.0 is released
• 2011 – Current version is 2.1
• 2013 – Anticipated release of NIEM 3.0
NIEM Model Architecture
NIEM Core consists
of data elements that
are commonly
understood across
domains
NIEM Domains
include mission
specific data that is
managed through
independent
stewards
Future Domains
are added to NIEM as
necessary based on
an established need
What is an IEPD?
An Information Exchange Package Documentation (IEPD)
is a collection of artifacts that describe the construction
and content of an information exchange
A. Developed to provide the business, functional, and technical
details of the information exchange through predefined artifacts
B. Created with a core set of artifacts in a prescribed format and
organizational structure to allow for consistency
C. Designed to be shared and reused in the development of new
information exchanges through publication in IEPD repositories
The IEPD Lifecycle
Scenario
Planning
Analyze
Requirements
Map & Model
The IEPD
Lifecycle
Build &
Validate
Assemble &
Document
Publish &
Implement
Plan the project, establish the process, and
identify information exchange business
requirements
Selected information exchange is further
elaborated to understand and document the
business context and data requirements
Associate local objects with types and elements
in NIEM. This process is called mapping an
exchange content model to NIEM
Create a set of exchange-specific NIEM
conformant XML schemas that implement the
data model created for the exchange
Prepare and package all related files for this
IEPD into a single self‐contained, selfdocumented, portable archive file
Publish IEPD for search, discovery, and reuse
Scope of IEPDs
IEPDs contain design specifications for an information exchange
but may not include supplementary information such as
implementation decisions
IEPDs do
Include the XML schemas that
define the XML message structure
Contain standardized artifacts that
document an information exchange
Have a defined development
methodology (IEPD Lifecycle)
Ease the documentation process
for reuse
IEPDs do not
Specify how exchange data is
physically transferred between
entities
Describe an interface or Interface
Control Document (ICD)
Specify any technical information
outside of the message structure
Future UML Profile for NIEM
• Standardized model representing NIEM packages
• Build upon the scope of the existing profile to include support for MPD
development
• Support “model-driven” MPD development
• The profile will reflect NIEM architectural concepts and restrictions as set
forth in the NIEM Naming and Design Rules (NDR) v1.3 and Model Package
Description Specification (i.e. we don’t want to accommodate all of XML
schema, only what is allowed by the NDR)
• End Goal: A developer (using supporting tools) should be able to generate
an equivalent conformant MPD from any UML model that applies the
envisioned UML profile properly. Conversely, a developer should be able to
create an equivalent profiled UML model from a conformant MPD.
New York Statewide Police Information Network (NYSPIN)
NIEM and SOA at New York State Police
Case Study
Scenario….
We have all seen someone getting pulled over by a cop, right?
Here's what happens –
• The officer gathers the driver’s license/registration information
• Driver and passengers stay in the car for what feels like an eternity
• Officer often comes back after a few minutes, and
– Lets the driver off with a warning, or
– Gives the driver a ticket, or
– Gives the driver a ticket and asks him/her to appear in court, or
– Just arrests the driver (and maybe the passengers)
Here’s what really happens….
• The officer has some combination of the following information:
Vehicle plates and registration
Driver’s license
• The officer checks the driver/vehicle information against:
DMV systems for driver and registration information
Repositories (hot files) for stolen property (vehicles, boats,
snowmobiles, guns, etc.) to see if the vehicle is stolen
Criminal history and other repositories for Wanted, Missing and
unidentified persons, Parole, orders of protection, etc. to see if the
driver is wanted
Other repositories for Lo Jack, sex-offender registries, gang related
activities, etc.
• The officer makes an informed decision
What is NYSPIN?
• Each state has one messaging solution --the “SWITCH”
◦ Allows all law enforcement users to connect to remote distributed systems for DMV,
Criminal History, Stolen Property, Warrants, etc.
◦ Critical system for crime prevention, law enforcement, and officer safety
◦ Very high transaction volumes
• New York SWITCH is NYSPIN (New York Statewide Police Information
Network)
◦ 1100 Enforcer terminals directly connect to this system
◦ About 107 Metro user connections to CAD, RMS, Mobile systems, etc.
◦ About 50,000 users (direct and indirect)
◦ About 1.5 Million messages per day
• Legacy switch used COBOL on a UNISYS mainframe environment,
proprietary protocols and interface definition
NY Long-term Justice
Information Sharing Vision
“Provide ‘one-
stop
information
shopping
platform’ for all
law
enforcement,
justice and
correction
entities and
users”
Integrated Justice Community:
Stakeholders and Partners
In-State Agencies
•
•
•
Law Enforcement/Criminal Justice Agencies:
– Division of State Police
– Division of Criminal Justice Services
– Local Police Departments
– Sheriffs Departments
– Administrative Office of the Courts
Corrections Agencies:
– State Prisons
– Sheriffs Department of Corrections
– Probation
– Parole
Other Agencies
– Division of Homeland Security and
Emergency Services
– Department of Motor Vehicles
– Division of Tax and Finance
Out-of-State Agencies
•
•
Federal Bureau of Investigation:
– National Crime Information Center
(NCIC) for Hotfiles
The International Justice and Public
Safety Network (NLETS):
– 49 State DMV Records
– 49 State Rap Sheets
– 49 State Criminal History
– Lo Jack
– National Weather Service
– Immigration Services
– Canadian Police Information Center
(CPIC)
– Interpol
Challenges Faced
• Mission critical system -- stringent requirements around accuracy,
performance and high availability
◦ Desire to roll-out the new solution with minimal disruption of services
• Coordination among multiple in-state and National agencies
• Multiple point-to-point connections
• No standard business vocabulary
• Manual (paper-based) processes
• Islands of data often with no unified view of information
• Changes were expensive and time consuming
• Proprietary and legacy protocols and formats
◦ Limited support for the existing legacy infrastructure
Solution – Integrated Justice Portal
Highlights
• 100% compliance with NYSP
architectural requirements for
open hardware and software
standards; minimal vendor
dependency
• SOA solution with end-to-end
NIEM conformance
• 85 course-grain & 140 fine-grain
services support all functionality
• Transition Strategy supported
terminal devices during migration
to Portal-based UI and web
services-based Metro interfaces
• Not a COTS package -- integrated
solution using commercial COTS
• Supports 20,000 internal and
30,000 external users
NYDHS
Local Law
Enforcements
Homeland
Security
Probation
State Prison
UNYRIC
Probation and
Correctional
Alternatives
Parole
Regional Intelligence
Center
NYC
DOS
Attorney
General
NYC Department of
Sanitation
NY Attorney
General
Public Safety
CCH and Warrants
Tax and
Finance
Tax and Finance
Courts
Integrated Justice Portal
NY Courts
Portal based user interface
SOA Business Services
Messaging Hub
Web Services and MQ based interfaces
Other Civil
Agencies
NY Division of
Motor Vehicles
Civil Agencies
Upgraded
Interfaces
Legacy
Interfaces
NYSPIN scope
• 1.6 million messages per day - On
average 13 messages per second,
52 messages per second during
peak time
NY Sheriffs
IJP – Application Architecture
Enforcer
2K
Browser
Metros
(to Be)
Metros
(Legacy)
Via Transitional Adapter
- Non NIEM Compliant
Asynchronous
Web Service
Enterprise Java Beans (Stateless Session Beans)
Business Services (One per business domain)
Business
Service
Layer
Fine Grain Business Services (Reused across coarse grain)
Service Agency Abstraction Layer
Integration
Services
Layer
Transformation
Routing,
Enrichment
XML
Data Abstraction Layer
JMS (Asynchronous)
WebSphere Business Integration Message Broker
Integration Bus ( MQ/JMS/WebServices )
Service
Agency / Data
Layer
Connector
DMV
Connector
Connector
Connector
DTF
NCIC
NLETS
Notification
Aggregation
Correlation
Log, Audit, Exception
IBM WebSphere Application Server
Transitional Java Wrapper
(Message Driven Beans)
Au, Az
IBM Websphere
Portal
Synchronous
Business
Service
Interface
Layer
Synchronous NIEM
Compliant Web
Services
Transitional Websphere
Integration message Broker
Data Validation, Security (Az)
Presentation
Layer /
Transitional
Common Services Scope
Channels and
Business
Applications
Client Layer
ODS
CCH,
Hotfiles
19
Portlet
Client Business
Interface
Portlet
Portal Container
Portal Framework
Reusable Services
Framework
Router
Enforcer and Transitional Adapter
Service Agency
Adapter
Transformation
Service Agency Access
Business Services
(Coarse Grain + Fine Grain)
Enterprise Java Beans
(Stateless Session Bean)
TA Message
Driven Bean
Transitional
Broker
Transitional
Gateway
Enforcer
Web Service
Metro
IJP – Component Architecture
Metro
Websphere Application Server
Websphere Business
Integrator
Legend
NIEM XML
Remote Queue
Local Queue
Plain Old Java Objects
WBI Components
WAS Components
External Resource
20
IJP – Service Orchestration
◦ Coarse grain services – support entire business transaction
• e.g., Stolen Vehicle Entry
◦ Service orchestrates multiple fine grain services
IVR
Applicati
on
Business
Partner
NCIC
DMV
Agenc
yX
Browser
IVR
Applicati
on
Business
Partner
Each
interaction from
CG to FG is an
XSL
transformation
Business
Services Orchestr
LOB`
ation
Channel
Enabling
Services
State
Police
LOB Systems
Business
Services Orchestr
LOB`
ation
Business Services
Orchestrat
LOB`
ion
LOB Systems
Browser
Channels
Business
Partner
Channel
Enabling
Services
Applicati
on
Orchestrated Services
State
Police
NCIC
DNV
Agenc
yX
LOB Systems
IVR
Channels
Browser
Intermediary Services
Channel Enabling
Services
Channels
Basic Services
State
Police
NCIC
DMV
Agenc
yX
21
IJP Lessons Learned
• Establish end vision, create a roadmap that will get you there
• Roadmap periodically adjusted for changing requirements, delays,
emerging technologies, etc
• Identify key stakeholders, their dependencies, and inter-dependencies
early on
• Establish, implement, and enforce a robust Governance structure
• Establish a robust transition strategy – minimal disruption of service
• Recognize the importance of training and change management: the
new system would only be successful if the people using it embrace
the new technology
Federal CIO council report released recently showcasing NIEM and its rapid adoption
within Federal, State, Local, Tribal and International mission partners http://www.cio.gov/documents/3.12.1-NIEM-Assessment%20Report_Final_Master.pdf
This report highlights an unprecedented opportunity for substantial gains in increasing
standardized connections and shared services for cross-boundary information
exchange. It challenges the status quo of silos and presents a path forward to a
strategy for significant gains for the overall NIEM community.
“We’ll be on our way to computerizing all of America’s medical records, which
won’t just eliminate inefficiencies, save billions of dollars and create tens of
thousands of jobs – but will save lives by reducing deadly medical errors.”
– President Barack Obama, February 4, 2009
23
Healthcare Information Exchange
• Emerging Health Information Exchanges (HIE) are developing
the capacity to share patient clinical information among
healthcare providers across care settings. This requires:
• Standard, Repeatable and Flexible means for defining message
structure
• Secure mechanisms to ensure that the right information is shared with
the right user
• Address security and privacy policy related issues
• Deal with compliance issues
• Collaborate with multiple partners
• Federated information sharing, identity and authorization management
• Cloud based operations
Sounds familiar. We are also facing similar issues, and looking to
collaborate with other domains to jointly address these issue….
Questions?
WWW.ISE.GOV
25
Download