Massachusetts CJIS-XML Architecture: A Service-Oriented Approach for Delivering CJIS Content as GJXDM-Based XML

1. Massachusetts CJIS-XML Architecture:A Service-Oriented Architecture for Delivering CJIS Content as GJXDM-Based XMLPresented By: - The Commonwealth of Massachusetts (Executive Office of Public Safety and the Criminal History System Board) - xFact, Inc.Global Justice XML Data Model Users ConferenceJune 9th, 2005 | Atlanta, Georgia

2. Agenda and Introductions • Objective of this presentation • Describe how Massachusetts is using an SOA, Web Services, XML and the GJXDM to deliver CJIS content to agencies and users • Provide details about the architecture and implementation of the Massachusetts “CJIS-XML” project • Offer “real world” examples of how Massachusetts is leveraging the GJXDM, as well as lessons learned during the implementation and roll-out of the project • Speaker introductions • James F Slater III • CIO, Massachusetts Executive Office of Public Safety (EOPS) • Curt Wood • Deputy Director, Massachusetts Criminal History Systems Board (CHSB) • Amit Banerji & Greg Phoenix • xFact, Inc.

3. Massachusetts Executive Office of Public Safety (EOPS) and Criminal History Systems Board (CHSB) • Commonwealth's joint ICJIS vision: • Share critical information electronically at key points throughout the justice enterprise – the right information, to the right people, at the right time, and in the right format. • Key ICJIS business & technical drivers: • Improve quality, consistency, accessibility, and reliability of information • Promote more effective decision making • Streamline business processes to save costs, time, and resources • Enable the sharing of information “anywhere, at any time” • Support a diverse, open standards technology environment • Help compile metrics for evaluating system effectiveness • Provide flexible designs that can adapt to changing needs • Continuous progress in business and technology enable new ways to address the ICJIS mission and vision • Federal and State information sharing initiatives (OJP, GJXDM, Global, etc.) • Open standards and technologies (Web Services, XML, SOAP, etc.)

4. Massachusetts Movements Towards GJXDM and SOA using Web Services, SOAP, and XML • Commonwealth is working to evaluate and further develop an ICJIS vision • Initially created the “Mass. Justice XML” data dictionary, based on GJXDM 2.0 • Implemented a pilot SOA to provide “XML-ized” CJIS content to vendors of mobile systems (via Web Services) • CHSB was able to serve as a more flexible provider of pure CJIS content • Vendors were quickly able to provide value-added services using the SOA • Vendors competed on the basis of their value-added service using content from CJIS, and users ultimately received better services • Birth of CJIS-XML • The success of the pilot SOA led to an increased demand to provide more CJIS content via Web Services and XML • EOPS/CHSB developed a formal business and technical strategy to implement the beginnings of a production SOA using XML, GJXDM 3.0, Web Services, and SOAP • The release of GJXDM 3.0 required updates to portions of the “Mass. Justice XML” data dictionary

5. CJIS XML Architecture: Overall Description and Architecture • CJIS-XML is the implementation of a basic SOA to exchange CJIS data as GJXDM-based XML documents via Web Services • Key goals of the CJIS-XML architecture • Simple to use and develop against • Standardized and open methods for development, implementation, and integration • Expandable to integrate new functionality (CJIS transactions or data exchanges) • Conform to GJXDM 3.0 • No Web Services bloat or API complexity • Synchronous and asynchronous methods of access • Available to a diverse range of technology platforms (Java, .Net, C++, etc.) • CJIS-XML architecture today • Single Web Service acts as the only public interface • Approximately 35 CJIS transactions are available, along with a handful of agency-to-agency CJIS data exchanges (CHSB, Parole, DOC) • Individual GJXDM-based schemas for each implemented transaction or exchange • Standardized method for adding new “modules” (currently written in Java) to accommodate additional CJIS functionality • Both query and update transactions have the same semantic interface

6. CJIS XML Architecture: Core Characteristics • Centralized Web Service (WS) that manages requests and responses within the SOA • CJIS-XML WS accepts and returns well-formed XML request and response documents • The CJIS-XML Service Handler layer interprets requests and passes them to individual processing modules to perform transaction-specific business logic • New processing modules can be readily integrated into CJIS-XML to leverage the underlying SOAP/XML infrastructure and delivery framework

7. CJIS XML Architecture: Input Transaction Processing • All CJIS-XML transaction requests invoke the CJIS-XML WS • Transaction names and parameters are embedded in the XML request/response document • CJIS-XML loads/executes the appropriate processing module for the transaction • Each type of CJIS transaction has its own processing module CJIS-XML Request Process

8. Each processing module generates a well-formed XML response Requestors (web service clients) then retrieve (or receive) responses from the CJIS-XML WS CJIS XML Architecture: Output Transaction Processing CJIS-XML Response Process

9. CJIS XML Architecture: XML Request Transaction Description • Request transaction has header and body element • Header contains meta data about the transaction • Header information is the same for all transactions • Body contains the data that is exchanged • Body will be different for each transaction

10. CJIS XML Architecture: XML Response Transaction Description • Response transaction has header and body element • Header contains meta data about the transaction • Header information is the same for all transactions • Body contains the data that is exchanged • Body is different for each transaction

11. Example of the CJIS-XML Request and Response Process (Asynchronous) • CJIS-XML requests and responses are made using well-formed XML via SOAP over HTTP • In the asynchronous request/response model: • The CJIS-XML Web Service receives requests from clients • CJIS-XML clients must retrieve responses to their own requests • A complete transaction is made up of multiple steps: • Query request • Return message • Retrieval request • Query Response

12. How MA CJIS XML is Being Used Today • Integration with Massachusetts CJIS web-based applications • Web apps readily obtain GJXDM-based CJIS information (via web services) for display in record check, firearms, booking, inmate processing, and motor vehicle applications • Utilized by “Mobile Data Vendors” who provide vehicle-based and/or PDA CJIS applications to state and local law enforcement agencies • Agency-to-agency CJIS data exchanges • MA CHSB and MA Parole exchange Parolee and Victims data • MA CHSB and MA DOC exchange Offender release data • Other agencies in development (Courts, Sex Offender Registry Board)

13. MA CJIS XML and GJXDM Benefits Observed • Timely and efficient CJIS information sharing; enhanced public safety • Information that was “always there” now more effectively available • Real world results: crimes solved, offenders located, etc. • Use of open- and standards-based technologies easily accommodated a diverse technology environment and range of agencies/users • A common set of standards and single point of entry/access helps to maintain CJIS data integrity and controlled access to CJIS data • OJP GJXDM and “Global” concepts promote standardized inter- and intra-agency data exchanges and a more easily managed effort to share data • A single, well-specified API and set of XML schemas fostered an easy and rapid development cycle by programmers using the environment • Open standards and/or API stimulates competition among participating vendors to help the State gain the best value for services and products

14. Lessons Learned and Future Plans • Lessons learned: • Keep things simple and agile • Have an active governance structure and change management process in place • Understand how to effectively navigate the GJXDM and create schema subsets • Have a mechanism to handle schema and data dictionary updates in a graceful manner • A widespread understanding of metadata (and how to use it) is still being absorbed by vendors, agencies, and developers using XML • XML is sometimes advertised as an easy and flexible way to integrate systems, but in real life it seemed a bit more challenging than all the ad’s and bullet points suggest! • Future plans: • Completion of an ICJIS Strategic Implementation Plan to guide future efforts • Potential participation and integration with the XML RAP Sheet, NLETS XML transactions, and the CANDLE project • Continue to track and evaluate technologies such as RDF, OWL, and Registries

15. Question and Answer Session • Your questions, comments, and feedback are greatly appreciated • Thank you for attending!