Massachusetts CJIS-XML Architecture Page 1 Copyright © 2006, xFact, Inc. Prepared by xFact, Inc. Commonwealth of Massachusetts Massachusetts GJXDM Implementation

Massachusetts CJIS-XML Architecture

Page 1

Copyright © 2006, xFact, Inc.Prepared by xFact, Inc.

Commonwealth of MassachusettsMassachusetts GJXDM

Implementation Case Study

Presented By:- The Commonwealth of Massachusetts

(Executive Office of Public Safety and the

Criminal History System Board)

- xFact, Inc.

Innovations In Justice:Information Sharing Strategies and Best PracticesBJA Regional Information Sharing Conference

Nov 28-30, 2006 | San Diego, CA


Page 2


Commonwealth of Massachusetts

Agenda

• Massachusetts CJIS XML Background – Business Goals– Technology Goals– Transformation Goals

• Massachusetts CJIS XML Architecture– Service Oriented Architecture (SOA)– Overall Description of Architecture

• Massachusetts CJIS XML Implementation– History– Current Status

• Lesson Learned• Update on Massachusetts ICJIS • Question and Answer


Page 3



Massachusetts CJIS XML Background: Business Goals

• Business Goals– Improve quality, consistency, accessibility, and reliability of information– Enable 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– Avoid Screen Scraping– Use Standard Based Content Delivery – Provide Images – Photographs– Provide a Platform Neutral Interface

Lesson Learned: It was realized very early that if Business Goals/Architecture was to succeed, then System Architecture has to be simple and scalable. The key to success is improvisation without sacrificing standards. Mobile requirements forced EOPS/CHSB to focus on a standards based future ICJIS that will not only meet the requirements of mobile vendors, but also serve the needs of the rest of the Commonwealth of Massachusetts. Numerous earlier CJIS planning efforts undertaken in 1990’s yielded only partial success.


Page 4



Massachusetts CJIS XML Background: Technology Goals

• Technology Goals– Create a Systems Architecture to meet the goals of Business Architecture

• System Architecture attributes– Simple service based interface

– Vendor/Technology neutral

– System Design using the architecture should follow a black box model

– Users should program to interfaces and not worry about implementation

– Transport protocol should be TCP/IP based

– System Architecture should be amenable to simple design patterns

Lessons Learned: Learn to walk before learning to run. Keep the technology framework simple. Avoid vendor specific enhancements to standards and do not concede control to software publishers. Remember you have to maintain it some day.


Page 5



Massachusetts CJIS XML: Background

• 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 support other agencies in their implementation efforts.

– Prepare to retool and retrain your technology and data center staff to provide ongoing user support

Lessons Learned: Capability vs. Usability (need to expand)


Page 6



Service Oriented Architecture in Massachusetts

• SOA Defined– The concept of a SOA is one where independent and/or disparate systems are

presented in a federated (central) manner. A SOA helps to provide a centralized view by providing standardized access to systems, as well as a framework for linking systems on demand

– 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


Page 7



Service Oriented Architecture in Massachusetts cont.

SOA’s have been around for a while, and have had limited success being implemented due to a lack of ubiquitous technology. Previous attempts to realize the promise of a SOA by technologies such as CORBA and COM/DCOM were very cumbersome and expensive to implement, creating barriers to the success of a SOA.

Web Services, XML and Service-Oriented ArchitectureConceptually, 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


Page 8



Service Oriented Architecture in Massachusetts cont.

Advantages of using web services are as follows (but 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


Page 9



– 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 Movements Towards GJXDM and SOA using Web Services, SOAP, and XML


Page 10



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


Page 11



CJIS XML Architecture: Core Characteristics

CHSB Web App& Web Service

Runtime Environment(CJIS-XML)

ServiceRequestors

ServiceProviders

InformationProducers

CJIS Workstation Police Cruiser Police Handheld SOAP ServerSOAP Client

CJIS Mainframe

CJISProcessingModule (1)



“N” Number ofModules

CJIS RelationalDatbases

External CJISDatabases or

Systems

CJIS-XML Service Handler

HTTP(S) orXML SOAP

over HTTP(S)

XML

Native DataAccess

• 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


Page 12



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

Web ServicesRuntime

Environment

CJIS-XMLWeb Service


TransactionProcessingModule (1)


TransactionProcessing

Module (N...)

CJIS-XMLTransaction Requests

(1...N)

CJIS-XML Request Process


Page 13



CJIS XML Architecture: Output Transaction Processing

• 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 Response Process

Web ServicesRuntime

Environment




TransactionProcessing

Module (N...)

CJIS-XMLTransaction Requests

(1...N)

CJIS-XMLWeb Service


Page 14



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


Page 15



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

Query Request

Return

Query Response

RetrieveClient CJIS-XML

Web Service


Page 16



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

– Other agencies in development (Courts, Sex Offender Registry Board)


Page 17



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


Page 18



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!

– Avoid pull architecture


Page 19



Massachusetts Integrated Criminal Justice System (ICJIS)

• Governor’ Executive Order 465• ICJ Planning Council

– Membership– Subcommittee– Project Management Office ICJIS Strategic Implementation Plan

• ICJIS Strategic Implementation Plan Project Completed in April 2006• SWISS (Statewide Information Sharing System)


Page 20



SWISS Initiative

Enhance public safety by making incident information available to authorized state and local law enforcement officers and crime analysts

Promote homeland security by providing the intelligence community access to information that will facilitate their ability to anticipate, detect, preempt and deter terrorism and other local and national threats

Aid future inter-state and Federal information sharing initiatives by implementing a standardized repository of Commonwealth incidents

Support the development of policies, strategies, and solutions to address regional and statewide crime trends

SWISS: Public Safety’s Information Warehouse The Statewide Information Sharing System (SWISS) Project, a joint effort by the Massachusetts Executive Office of Public Safety (EOPS) and the Massachusetts Regional Homeland Security Councils, is an effort to improve the exchange of critical incident information amongst state and local law enforcement and homeland security agencies. SWISS will electronically exchange, store, and facilitate the analysis of incident report data maintained by public safety and law enforcement data agencies throughout the Commonwealth.

S W I S S Statewide Information Sharing System

BENEFITS Promote seamless, timely incident

information sharing across the various local, regional, and state criminal justice partners

Support customized local, regional, and statewide views of incident information for the Commonwealth Fusion Center and other participating agencies

Protect the privacy, ownership, and security of incident data, including victim information and evidentiary information

Utilize national data exchange standards in implementing the sharing of Commonwealth incident data, such as GJXDM/NIEM

C O MMO N W E A LT H O F MA SSAC H U SE T T S

OBJECTIVES


Page 21



SWISS

INFORMATION FLOW

Public Safety

Crime & Intelligence Analysts

Submit incident reports using ASCII or GJXDM based XML

Mandatory use of Web Services

Conduct regional investigations Track community crime trends

Conduct threat analysis Track homeland security incidents

Track statewide crime trends Support policy decision-making Support inter-state investigations

State and Local Law Enforcement

SWISSIncidents

State and Local Law EnforcementState and Local

Law Enforcement

S W I S S Statewide Information Sharing System

C O MMO N W E A LT H O F MA SSAC H U SE T T S


Page 22



Question and Answer Session

• Your questions, comments, and feedback are greatly appreciated

• Thank you for attending!

James F Slater III

MA EOPS

[email protected]

Curt Wood

MA CHSB

[email protected]

Greg Phoenix

xFact, Inc.

617.834.5041

[email protected]

Barry J. LaCroix

MA CHSB

[email protected]

Amit Banerji

xFact, Inc.

978.821.3214

[email protected]

Documents

Massachusetts CJIS-XML Architecture Page 1 Copyright © 2006, xFact, Inc. Prepared by xFact, Inc. Commonwealth of Massachusetts Massachusetts GJXDM Implementation