Implementing Service Oriented Architecture With NIEM Our Approach. Corrections Technology Conference May 2008

Transcription

1 Implementing Service Oriented Architecture With NIEM Our Approach Corrections Technology Conference May

2 Agenda What is the National Information Exchange Model (NIEM)? What is Service Oriented Architecture (SOA)? Our approach to using NIEM in a SOA for the Integrated Justice Portal at New York Considerations while building NIEM IEPDs Use of NIEM in Corrections Technology Q&A 2

3 3 What is NIEM? Compiled from National Information Exchange Model (NIEM) is a Framework for Nationwide Information Exchange It is a partnership of the U.S. Department of Justice and the U.S. Department of Homeland Security It is designed to develop, disseminate, and support enterprise-wide information exchange standards and processes that can enable jurisdictions to effectively share critical information in emergency situations The vision for NIEM is to be the standard of choice for Inter-governmental information exchange, thereby: Enhancing the quality of governmental decision making by enabling accurate, timely, complete, and relevant information to decision makers across the broad spectrum of NIEM Communities Of Interest Achieving greater efficiency, effectiveness, and return on investment (ROI) in operations by accelerating information exchange design and development Reducing risk in development efforts for practitioners and industry by having common exchange standards, tools, processes, and methodologies Improving public safety and homeland security by breaking down stovepipes enabling real-time, secure, enterprise- wide information sharing

4 NIEM Key Concepts Compiled from Data Components are the basic business data elements that represent real-world objects and concepts for example, information about people, places, material things, and events. NIEM Core is a set of Data components within an information exchange that are universally shared and understood among all (or almost all) domains (e.g., person, address, and organization). Domains refer to business enterprises broadly reflecting the agencies, units of government, operational functions, services, and information systems which are organized or affiliated to meet common objectives. NIEM currently has 7 domains. Information Exchange Package represents a set of data that is actually transmitted between agencies for a specific business purpose (e.g., initiating a charging document by the local prosecutor). IEPD is the necessary documentation required to complete the IEP and includes XML Schema that use or extend NIEM, supporting artifacts such as use cases, ERDs, catalog of artifacts, metadata for indexing, search, versioning etc. NIEM Core and Domains Relating IEPDs to IEP 4

5 What are SOA and Business Services? Service-Oriented Architecture Not a technology, but an architecture whose goal is to achieve loose coupling and high cohesion Concept rather than an actual standard Comprises of frameworks, policies, methodologies, and standards to define and maintain enterprise business services Encapsulates business functions into a collection of services which are easily aggregated to provide unified views and standard presentation Business service A service is the composition of software interactions that provide meaningful value to the business A service represents business functionality, not user interface functionality A service can be utilized across the enterprise and/or among business partners A service can be short lived, long running, synchronous, asynchronous, conversational or batch. There are two grains of business services: Coarse and Fine Coarse Grain Services External Partner Integration Fewer in Typical SOA implementations Perform a business transaction e.g. Stolen Vehicle Entry Wrap around and orchestrate fine grain services Have Security, Parsing, Validation, Routing, Logging logic etc. Internal Integration Fine Grain Services More in Typical SOA Implementations Perform an atomic action e.g. Stolen Vehicle Entry into the State Police Database Reused across multiple coarse grain services Striking a balance between fine-grained and coarsegrained services helps ensure fit of the service to the business or technical need.

6 Deloitte NYSPIN Replacement Project Integrated Justice Portal (IJP) 6

7 IJP Key Requirements NYSPIN is the state switch that is being replaced with the new IJP. NY IJP is envisioned as a one stop shopping platform for all Law Enforcement related information required. Listed below are some of the key metrics and requirements from the current system, that will be met with the new IJP. 351 NYPSIN supported business transactions to be replaced with 117 business services, 8 hot file validation services, 2 training certification services, 15 admin and common services, 46 user interfaces 7 criminal justice/public safety related information sources Support 20,000 internal and 30,000 external users 250 forms to support 12 database domains to convert 423M message annually/1.16 M messages per day. Peak hours are 1100 to 1900 On average 13 messages per second 52 messages per second during peak time Seamless integration of information from multiple in-state and out-of-state agencies 7

8 IJP SOA Roadmap Step 1 Communicate Business Benefits Step 2 Construct Roadmap Step 3 Build SOA Supporting Infrastructure Step 4 Expose Business Functions as Services Step 5 Create Portal Views and Automate Processes Step 6 Manage & Monitor Portal and Web Services 8

9 IJP SOA Roadmap 1. Select SOA Standards & Tools 2. Establish SOA Infrastructure 3. Pilot SOA 4. Develop Services and Connectors 5. Develop Channel Applications 6. Deploy SOA and Monitor Enterprise Architecture Resource planning Define Principles Focus on scalability Define and build environments Establish processes Validate architecture Start small Proceed by domain Focus on data model Abstract integration points Focus on user needs Business process focus Repeatable processes Define areas of responsibility 9

10 10 IJP Application Architecture

11 11 IJP Component Architecture

12 IJP Choosing the right orchestration Coarse grain services support a business transaction e.g. Stolen Vehicle Entry Coarse grain services orchestrate fine grain services Fine grain services perform one agency specific CRUD action e.g. Stolen Vehicle Entry to NCIC

13 IJP a service orchestration example In the new SOA enabled system, troopers will only operate through one standardized user interface. The business service serving the user interface will perform all related tasks and communications via ESB.

14 IJP NIEM IEPD process Create a domain model for the system Create the subset schema for the system Create a master list of all the domains and their properties across all business services in the system. If time is a factor, model at least the major domains and update the list when new elements are added. A person object should have the same properties across request and response and across all services. This avoids class conflicts when tools like XML beans are used to convert xml schema into java classes. Subset schema is generated using NIEM subset schema generation tool. Namespaces used: c, u, j etc. Create the extension and wrapper schemas for the system Create the request or response document schema for the specific exchange Assemble Message Schema An ERD is created for the exchange to show relationships between the objects. Specific elements are imported in this schema from the extension and subset schema. Standard wrapper schemas are created for exception, routing, notification. Namespaces used: nysdoc, nysext,nyscommon, c, u, j etc. Elements required by the IEPD and not available in the Subset schema are added to the extension schema. Domain model spreadsheet is update iteratively if new elements are discovered Namespaces used: nysext, c, u, j etc. Package the header, payload, document, exception schema into the message schema. Package artifacts like use cases, ERD. Namespaces used: nyscommon, nysdoc, nysext, c, u, j,etc. 14 A systems processing oriented approach utilizing object oriented design concepts (as opposed to a payload centric approach) was used. NIEM was extended to introduce data components and properties that facilitate systems processing.

15 IJP NIEM-SOA architecture key features A business process implemented through a series of XML transformations All services accept NIEM 1.0 XML as request and return the same as response Each service has a request and response IEPD NIEM parsing XML libraries accelerate development Schema validations are not performed for better performance Validations are performed programmatically by validation services Larger NIEM code lists are extracted into a code table database for easier maintenance Constraints involving enumerations are applied in the NIEM Schema and also checked programmatically NIEM XML is accepted by a service as an XML Object. Hence, WSDLs don t show schema constraints e.g. mandatory or optional elements A coarse grain service accepts a NIEM XML request, transforms it into a NIEM XML fine grain request through XSL and, in a few cases, programmatically. This minimizes code changes if an agency adds or removes elements to either a request or a response. This also allows for ability to expose fine grain services as coarse services due to business needs and new partnerships. Object based fine grain services were considered and this approach was found more flexible. This reduces errors when the user of the services independently validates their instance against a request schema. This is mitigated using user friendly documentation and sample XML instances. 15

16 Things to consider when implementing NIEM Achieve consistency in object definition across multiple IEPDs serving multiple services in a System Consistency also means changes to an object in one IEPD should be propagated to all IEPDs that use that object Caution in applying constraints if a constraint is applied to a child element than all parent elements need to be extended Add elements to indicate to the service what action to perform Standardize definition of Routing, Exception Handling wrappers, No Record Found indicator objects Be aware of high cost associated with changing versions of NIEM The driver for change should be business needs and not newer versions. The Architect should define a standard canonical across the agency. NIEM can t enforce single definition of an object across multiple services. A person entity may have different properties in different IEPDS. For example a Parole inquiry request may need person first name, last name and DOB, whereas the response may return many more elements such as height, sex code, weight, statute, supervising official etc. When inconsistent objects are converted to java beans using tools such as XML beans, conflicts occur. It is the Architect s responsibility to achieve consistency across IEPDs. We added an object called BusinessOptions to all our request schemas. Our services read this object and decide what action to perform on the request e.g. inquire on vehicle using VIN only. NIEM focuses on what the information exchange payload should contain and not on what should a system do with the payload. For example, NIEM can t enforce how exceptions are handled. The Architect needs to standardize the wrapper schemas. 16

17 Our approach to standardizing IEPDs Approach is compliant with and supplementary to the NIEM IEPD process: Define common business objects like person or vehicle Apply Lowest common denominator of constraints Extract code lists into a database If possible, retain enumerations in the schema itself Each service has a request and response IEPD. Reuse IEPDs for similar requests or responses Introduce extended elements for systems processing e.g. BusinessOptions, NoRecordIndicator, LegacyText Standardize wrapper schemas. This is key for proper service interaction. NIEM prescribed IEPD IEPD with standard definition of wrapper schemas: Message.xsd Header.xsd Payload.xsd Exception.xsd Notification.xsd 17 Relating IEPDs to IEP

18 NIEM Exchanges in Corrections Technology MA DOC Release Exchange Exchange to send inmate release information from MA DOC to CHSB utilizing GJXDM standards Agencies Involved: Massachusetts Department of Correction and Massachusetts Criminal History Systems Board MA DOC MA Parole Exchanges Completed the specifications and domain modeling for several exchanges including Parole Eligibility Hearing, Hearing Disposition, Home and Work Plan, Warrant Information, and Inmate Admission Information Agencies Involved: Massachusetts Department of Correction and Massachusetts Parole Board NYC DOC Inmate Status Notification Inmate status notification pushes the information to a web service which utilizes NIEM exchange standards New York City Department of Correction with New York City Data-share and intended for consumption by multiple users NYC DOC Inmate Information Exchange Inmate information can be fetched by multiple users from a Web Service. The exchange utilizes NIEM standards Agencies Involved: New York City Department of Correction with New York City Data-share and intended for consumption by multiple users

19 Discussion: use of NIEM in Corrections Technology Example: Corrections Transfer Document Used when subject is transferred from jurisdiction of one state correctional facility to another Here are the exchanges involving this document from the Justice Information Exchange Model (JIEM): , Corrections informs state probation and parole that subject is being transferred from out-of-state , Corrections informs state repository that subject is being transferred from out-of-state , Corrections informs victim services that subject is being transferred from out-of-state What information will this document contain? Person Information, Court Information, Justice Information, Parole Information What is the value of standardizing this document using NIEM? Seamless information exchange between Corrections and Other Agencies using NIEM Easier processing within a Corrections System document can be assembled from standard data provided from other services such us Person information, Case information from Courts, Charge Code from DCJS Which NIEM domains can be used? Common for Person Information, Justice for Charge Codes, Applicable Laws etc. 19

20 20 Questions

21 About Deloitte Deloitte refers to one or more of Deloitte Touche Tohmatsu, a Swiss Verein, its member firms and their respective subsidiaries and affiliates. Deloitte Touche Tohmatsu is an organization of member firms around the world devoted to excellence in providing professional services and advice, focused on client service through a global strategy executed locally in nearly 140 countries. With access to the deep intellectual capital of approximately 135,000 people worldwide, Deloitte delivers services in four professional areas, audit, tax, consulting and financial advisory services, and serves more than 80 percent of the world s largest companies, as well as large national enterprises, public institutions, locally important clients, and successful, fast-growing global growth companies. Services are not provided by the Deloitte Touche Tohmatsu Verein and, for regulatory and other reasons, certain member firms do not provide services in all four professional areas. As a Swiss Verein (association), neither Deloitte Touche Tohmatsu nor any of its member firms has any liability for each other s acts or omissions. Each of the member firms is a separate and independent legal entity operating under the names Deloitte, Deloitte & Touche, Deloitte Touche Tohmatsu or other related names. In the United States, Deloitte & Touche USA LLP is the U.S. member firm of Deloitte Touche Tohmatsu and services are provided by the subsidiaries of Deloitte & Touche USA LLP (Deloitte & Touche LLP, Deloitte Consulting LLP, Deloitte Financial Advisory Services LLP, Deloitte Tax LLP, and their subsidiaries), and not by Deloitte & Touche USA LLP. The subsidiaries of the U.S. member firm are among the nation s leading professional services firms, providing audit, tax, consulting, and financial advisory services through nearly 40,000 people in more than 90 cities. Known as employers of choice for innovative human resources programs, they are dedicated to helping their clients and their people excel. For more information, please visit the U.S. member firm s Web site at Copyright 2007 Deloitte Development LLC. All rights reserved. 21