E N D
Massachusetts CJIS XML: A GJXDM Implementation Case StudyPresented By: - The Commonwealth of Massachusetts (Executive Office of Public Safety and the Criminal History System Board) - xFact, Inc.SEARCH 2006 Symposium on Justice and Public Safety Information SharingMarch 15, 2006 | Washington, DC
Agenda • Massachusetts CJIS XML Background • Business Goals • Transformation Goals • Massachusetts CJIS XML Architecture • Service Oriented Architecture (SOA) • Overall Description of Architecture • Massachusetts CJIS XML Implementation • History • Current Status • Demonstration • Lessons Learned • Update on Massachusetts ICJIS • Questions and Answers
Massachusetts CJIS XML Background: Business Goals • Business Goals: • Migrate from mainframe based to web-based systems • Expand information sharing • Provide standards-based data exchanges • Provide new device independent content (i.e., driver license photos, mugshots) Lesson Learned:Be able to improvise without sacrificing standards Numerous earlier CJIS planning efforts yielded only partial success. The key is being able to improvise without sacrificing standards. Mobile requirements forced EOPS/CHSB to focus on developing a standards based interface that will not only meet the requirements of mobile vendors, but also serve the needs of the Commonwealth of Massachusetts. In 2003, EOPS created a Mass Justice XML data dictionary based on the GJXDM funded by various grants.
Massachusetts CJIS XML Background: Transformation Goals • Transformation Goals: • Support user community by creating effective implementation documentation • Conduct implementer training – help them understand SOA • Select a vendor to help to train and implement early implementations • Vendor help was needed to transition technical staff from mainframe based computing to non-mainframe computing • Vendor was selected to create a SOA bus based on GJXDM • Prepare to retool and retrain your technology and data center staff to provide ongoing user support • Prepare to support other agencies in their implementation efforts. Lessons Learned: Keep it Simple!
Massachusetts CJIS XML Architecture:Service Oriented Architecture in Massachusetts • Service Oriented Architecture (SOA) Defined: • Centralized View: In SOA, independent and/or disparate systems are presented in as a unified system. A SOA helps to provide a centralized view by providing standardized access to systems as well as a framework for linking systems on demand. • Component Based:A SOA is component-based architecture. A component is characterized as a self-contained and well-defined item (i.e., service) that provides a specific function or group of related functions. Each component communicates with other components by using the interfaces (rules for interaction) exposed by each individual component. • The concept of a SOA is based on the following key principles: • Services are meaningful and have simple to use interfaces that define how to interact with and/or use the service • Services are self-contained and do not depend on the context or state of other services • Services may be combined with one or more services to coordinate activities or functionality • Services provide a well-defined task or function, and when asked to perform that function guarantee the execution of it • The details of how a service is implemented is not exposed to developers or systems; services are like black boxes that are only known to accept a desired request and produce an expected result • Services should be language and operating system independent
Massachusetts CJIS XML Architecture:Service Oriented Architecture in Massachusetts Cont. • Web Services: A SOA needs a software bus or connection technology on which the components/services can exchange information. Web Services combine the use of Internet- and XML-based technologies to provide such a bus, allowing services to be accessed using standards-based protocols. • Essential technologies of web services are: • Core Internet Technologies: • Network-based standards such as Internet Protocol (IP), the Domain Name System (DNS), and the HyperText Transfer Protocol (HTTP) • Extensible Markup Language (XML) • Provides a standardized set of markup rules for creating structured documents • XML documents are defined and described using XML schemas to enforce document structure and rules • Simple Object Access Protocol (SOAP) • SOAP is a XML-based protocol for exchanging information (XML messages) in a decentralized environment • Web Services Description Language (WSDL) • A standard XML-based format to define how to access a service, and what operations the service performs • Universal Description, Discovery and Integration (UDDI) • Provides a central directory mechanism for looking up web services
Massachusetts CJIS XML Architecture: Service Oriented Architecture in Massachusetts Cont. • Web Services Advantages: Advantages of using web services include (but are not limited to): • Facilitates the implementation of a SOA • Provides peer-to-peer communication as opposed to strictly client and server communication • Enables interoperability between heterogeneous systems and or platforms • Allows straightforward communication at various computing levels: • Local system-to-system • Enterprise system-to-system • Systems and applications • Web browsers applications • Hand held applications • Mobile data terminal applications • Provides a framework for allowing CHSB to enable XML-based data exchanges with legacy (CJIS mainframe) systems
Massachusetts CJIS XML Architecture: Massachusetts Movements Towards GJXDM and SOA using Web Services, SOAP, and XML • 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
Massachusetts 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
Massachusetts 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
Massachusetts 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
Each processing module generates a well-formed XML response Requestors (web service clients) then retrieve (or receive) responses from the CJIS-XML WS Massachusetts CJIS XML Architecture: Output Transaction Processing CJIS-XML Response Process
Massachusetts 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
Massachusetts CJIS XML Architecture: 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
Massachusetts CJIS XML Implementation: How Massachusetts 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
Massachusetts CJIS XML Implementation: 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
Massachusetts CJIS XML Implementation: CJIS XML Demonstration • Demonstration
Lessons Learned • 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!
Massachusetts Integrated Criminal Justice System (ICJIS) • Governor’s Executive Order 465 • ICJ Planning Council • Membership • Subcommittee • Project Management Office ICJIS Strategic Implementation Plan • ICJIS Strategic Implementation Plan Project
Question and Answer Session • Your questions, comments, and feedback are greatly appreciated • Thank you for attending!