jin cach customer requirements report v26.doc

Online Business Systems One World Trade Center

121 SW Salmon St. Portland, Oregon 97204

Washington Justice Information Network

Criminal and Case History Query Project

Customer Requirements Report

December 17, 2004

Version 25 (Draft)

Washington JIN CACH Customer Requirements Report

Document History

Version Date Author Comments

24 16Dec2004 Murray Laatsch Draft submitted to JIN Project Director for approval and consideration by the JIN Steering Committee.

25 17Dec2004 Andy Ross Applied JIN Program Director feedback and re-submitted for approval and consideration by the JIN Steering Committee.

ii


Table of Contents

1 INTRODUCTION........................................................................................................................................ 1

1.1 DOCUMENT PURPOSE............................................................................................................................... 11.2 RELATED ARTIFACTS............................................................................................................................... 11.3 DISTRIBUTION......................................................................................................................................... 1

2 EXECUTIVE SUMMARY........................................................................................................................... 2

3 BACKGROUND........................................................................................................................................... 4

4 METHODOLOGY....................................................................................................................................... 5

5 BUSINESS NEEDS ANALYSIS................................................................................................................... 6

5.1 BUSINESS SCOPE...................................................................................................................................... 65.2 BUSINESS GOALS AND OBJECTIVES..........................................................................................................95.3 BUSINESS REQUIREMENTS...................................................................................................................... 145.4 CRITICAL SUCCESS FACTORS.................................................................................................................. 155.5 RISK...................................................................................................................................................... 165.6 CONSTRAINTS........................................................................................................................................ 17

6 USER REQUIREMENTS.......................................................................................................................... 18

7 FUNCTIONAL REQUIREMENTS...........................................................................................................20

8 NON-FUNCTIONAL REQUIREMENTS.................................................................................................24

9 TECHNICAL REQUIREMENTS.............................................................................................................. 33

APPENDIX A – REQUIREMENTS ASSESSMENT INTERVIEWS..............................................................34

APPENDIX B – DOCUMENTATION REVIEW.............................................................................................35

APPENDIX C – LEGAL AND PROCEDURAL REQUIREMENTS ASSESSMENT.....................................37

Appendix D – Issues............................................................................................................................................ 41

iii


1 INTRODUCTION

1.1 DOCUMENT PURPOSE

The primary purpose of this document is to identify, elicit and ratify the requirements of the JIN Criminal History Query Project. Several acronyms are used throughout this document and are briefly explained here:

JIN – Justice Information Network. The overall Washington State Program for integrated justice.

JINDEX – The JIN Data Exchange. This includes the integration broker, the technical infrastructure for implementation, and the Center of Excellence for future development projects.

CACH - Case and Criminal History. While this project was initially named Criminal History Query, stakeholder feedback has indicated the important distinction between case and criminal history information. As such, CHQ is relabeled CACH.

The initial set of JIN Requirements has been vetted through stakeholder interviews. The key findings from these interviews are captured and this document will confirm the initial understanding of the project in preparation for technical requirements and Design sessions / interviews.

In addition to the review of the related documents, interviews and walkthroughs were conducted to increase the understanding of project team members with respect to the existing system and project needs. The information gleaned has been captured in this document. This document and its included work products are intended to form the initial input into the JAD Sessions that follow to gather and refine technical requirements.

1.2 RELATED ARTIFACTS

Artifact Description

Contract A04-PSC-007 Contract between State of Washington DIS and Online Business Systems dated 1Nov2004.

Statement of Work JIN SOW – Exhibit A within Contract A04-PSC-007. Defines detailed success criteria, deliverables and work expectations.

Online Proposal Online Business Systems technical proposal (Volume 1) to Washington DIS in response to RFP # A04-RFP-005. Contains the Overall Online approach being utilized on the project.

JIN CHQ Project Charter V12 Approved Project Charter.

1.3 DISTRIBUTION

Brian LeDuc State of Washington – JIN Program Director

Murray Laatsch Online Business Systems Ltd. –

Senior Solutions Architect / JIN CACH Project Manager

Andy Ross Online Business Systems Ltd. –

Technical Architect / JIN CACH Technical Team Lead

Dave Usery URL Integration Ltd. – Integrated Justice Domain Business Analyst

David Neufeld Online Business Systems Ltd. – Delivery Manager

Version 25 (Draft) Page 1


2 EXECUTIVE SUMMARY

The Customer Requirements report contains summarizations and conclusions of the information that has been acquired through the collaborative series of workshops and interviews with key project stakeholders and contributors to date. The requirements documented here are primarily non-technical in nature. They provide the ratified business requirements upon which the technical requirements and design will be derived.

A cursory examination of the proposed requirements initially seemed to reveal the need to simply increase the functionality already inherent within the Summary Offender Profile (SOP) application. That is, enhance this JIN application to permit queries by person demographics such as name, date of birth, etc. The results of this query would reveal a set or list of possible name matches and the associated person identifier. This identifier would then be selected, revealing criminal history information regarding that person only. The search would query both the Washington State Patrol (WSP) and the Administrative Office of the Courts (AOC) repositories, combining the results into a consolidated criminal history query.

The results of our detailed examination of the underlying business goals, user requirements, functional requirements and non-functional requirements tells a different story altogether. In fact, the requirements of the JIN stakeholders clearly express the need for a statewide standard framework and an architected set of services that are designed to support a wide variety of state based criminal justice Agencies. The solution would be application to application integration without a large focus on the User Interface but more focus on how individual agency solutions (JILS, Protrak) could be enhanced by calling standard services to augment local information instead of re-building interfaces with each agency – rebuilding what each other already has. The onus for this project will be on developing a single access method for such services and registering their availability and potential for reuse.

A maturing set of middleware standards have made such a solution practical and affordable. But more importantly, standards are drawing likeminded agencies together into ‘communities of interest’ such as JIN. All with the goal of leveraging these standards (Justice XML GJXDM, Web Services and Service Oriented Architecture methodologies) to promote the overall objective – Public Safety.

What are the requirements for a central state integrated justice web services registry? This document introduces the requirements from a business perspective. While the individual web services (Criminal History Queries introduced in the RFP) are part of the solution, the development of these web services is intended to provide examples of the types of services that can be registered. This framework, JINDEX (Justice Information Network Data Exchange) will provide developers with an easily accessible Center Of Excellence, containing ratified standards, example solutions, and most of all a central standards based registry upon which each agency can expose a single accepted invocation method for which they expect all other agencies to use in support of their local criminal justice efforts.

Within this document are sections that cover:

Methodology. The JIN Criminal History Project relies on a standard definition of the principals of Service Oriented Architecture (SOA). The Customer Requirements deliverable provides a brief overview of the principles of SOA and the methodology that has been adopted for the JIN CHQ project.

Business Needs Analysis – provides an evaluation of proposed requirements and the specification of business requirements discovered from the review of background documentation and stakeholder/steering committee interviews.

Context. This section contains a statement on the project’s business scope intended to define the boundaries of the project effort, define the business domain and introduce key concepts and terminology that will be used throughout the remainder of the project efforts.

The project’s business goals and objectives are represented as a collection of business requirements that have been determined from a number of inputs – including JIN technology and design principles from JIN office charters and documentation as well as proposed JIN requirements that have been discovered thru the collaborative series of workshops and interviews with key project stakeholders and contributors to date.



Building upon goals and objectives within scope, the business requirements are more distinctly defined. In general, business requirements restate the JIN vision and direction. Ratifying this set of business requirements permits the correlation and trace-ability of each requirement (user, functional and non-functional) back to a business reason.

The project’s critical success factors provide a list of the overriding factors and accomplishments necessary within the architecture to consider the effort a success. Importantly, in keeping with the distinction between the two facets of the project, the success factors have been similarly listed distinctly – one list presenting factors that relate to what is referred to now as JINDEX, the second listing those factors related to the JINDEX CACH (Case And Criminal History Services.

Finally within the context of the Business Needs Analysis, a number of project risks and constraints have been identified and documented.

User Requirements provide a concrete list of behaviors and functionality that users expect to see from the solution. The user requirements have been derived from stakeholder interviews and represent both the requirements of the integration framework (JINDEX) and the JINDEX CACH web services, as identified in the Business requirements.

Finally, the complete known list of functional, non-functional requirements as discovered during stakeholder interviews and existing documentation reviews are presented.



3 BACKGROUND

The justice process in Washington involves federal, state and local entities, including law enforcement officers, courts, prosecutors, and corrections. The stakeholders in this process employ a variety of mainframe and server-based applications. There are numerous policies, rules, and standards relating to these systems. The Justice Information Network (JIN) will be the means by which these constituents share information. The Integrated Justice Information Board (The Board) is the governance structure for JIN. The governor and the legislature have endorsed the JIN effort and its governing board is established by statute. The Board’s membership includes the Chief of the Washington State Patrol, the Attorney General, Administrator for the Courts, the Chief Information Officer, the Secretary of the Department of Corrections, Director of the Department of Licensing and various members of the local justice community, including sheriffs, police chiefs, prosecutors, judges and county clerks. Additional background is available on the JIN website at www.jin.wa.gov.

The mission of JIN is to improve public safety by providing criminal justice practitioners with complete, timely and accurate information, and to improve operating efficiency by facilitating the integration of disparate systems throughout the state.

Pursuant to statute (RCW §10.98.200), JIN has the following objectives:

Maximize standardization of data and communications technology;

Improve workflow within the criminal justice system;

Provide complete, accurate, and timely information to criminal justice agencies;

Maintain security and privacy rights respecting criminal justice information.

JIN will be the foundation for justice information sharing projects within the State enterprise and participating local government entities. Once implemented, JIN will give its participants the ability to exchange information and conduct transactions reliably, in real time, consistent with the individual operational requirements of the agencies. Generally, the JIN should support the following:

Manage movement of data among applications;

Support consolidated queries among applications;

Interact with existing technology, without the need to invest in major changes or upgrades to existing applications or infrastructure;

Provide a user interface for access to justice information;

Provide for data security and user authentication

The Board has engaged Online Business Systems to assist in developing and implementing a model for information sharing in the justice community and for the construction of a service that validates the model. The Board is seeking solutions based on an open, distributed standards and service-based architectures that improve the flow of information in a flexible and cost-effective manner.

The goal of the project is to assist the Board in answering the following questions (Part 1) and to build and deploy a consolidated query of justice information (part 2):

Part 1 What are the network security and performance requirements of the justice community?

How should justice information move physically and logically across the network?

Part 2

Design and deploy a standards and service-based query tool for public information that extracts information from the AOC and WSP data repositories to allow for identification of suspects and to provide consolidated history for known individuals.


http://www.jin.wa.gov/


4 METHODOLOGY

The JIN Criminal History Project relies on a standard definition of the principals of Service Oriented Architecture (SOA). Familiarity with the principals of SOA forms the methodology for the eventual solution. In fact, the evolution of this methodology has influenced Public and Criminal Justice Practitioner expectations that their needs for integrated justice can be achieved and will provide value.

As with most methodologies or approaches, the precise definition of SOA is impossible to pin down, however, Online has adopted a working definition for this project which is based on the materials of thought leaders in this field and Online’s internal methodology (ROAD Rapid Online Application Development).

SOA - The policies, practices, frameworks that enable application functionality to be provided and consumed as sets of services published at granularity relevant to the service consumer. Services can be invoked, published and discovered, and are abstracted away from the implementation using a single, standards-based form of interface.

SOA is as a style resulting from the use of particular policies, practices and frameworks that deliver services that conform to certain industry accepted norms. Examples include certain granularity, independence from the implementation platform or location, and standards compliance. What these definitions highlight is that any form of service can be exposed with a web services interface. However higher order qualities such as reusability and independence from implementation, will only be achieved by employing some science in a design and building process that is explicitly directed at incremental objectives beyond the basic interoperability enabled by use of web services.

The goal for a SOA is a worldwide mesh of collaborating services, which are published and available for invocation. Adopting SOA is essential to deliver the business agility and IT flexibility promised by web services. These benefits are delivered not by just viewing service architecture from a technology perspective and the adoption of web service protocols, but require the creation of a Service Oriented Environment that is based on the following key principals.

Service is the important concept. Web Services are the set of protocols by which Services can be published, discovered and used in a technology neutral, standard form. Properly architected and designed logic is still required, behind this web services façade.

SOA is not just an architecture of services seen from a technology perspective, but the policies, practices, and frameworks by which we ensure the right services are provided and consumed.

With SOA it is critical to implement solutions that ensure that there are at least two different and separate processes—for provider and consumer.

Rather than leaving developers to discover individual services and put them into context, the Service Registry is instead their starting point that guides them to a coherent set that has been assembled for their domain. The State of Washington Criminal Justice domain – JINDEX (Justice Information Network Data Exchange).

If the principles of service oriented architecture are complied with, the following benefits are achievable:

There is real synchronization between the business and IT implementation perspective . For many years, business people haven't really understood the IT architecture. With well designed services we can radically improve communications with the business, and indeed move beyond alignment and seriously consider convergence of business and IT processes.

A well formed service provides us with a unit of management that relates to business usage. Enforced separation of the service provision provides us with basis for understanding the life cycle costs of a service and how it is used in the business.

When the service is abstracted from the implementation it is possible to consider various alternative options for delivery and collaboration models. No one expects that, at any stage in the foreseeable future, core enterprise applications will be acquired purely by assembling services from multiple sources. However it is entirely realistic to assume that certain services will be acquired from external sources because it is more appropriate to acquire them. For example authentication services, a good example of third party commodity services that can deliver a superior service because of specialization, and the benefits of using a trusted external



agency to improve authentication.



5 BUSINESS NEEDS ANALYSIS

This section is part evaluation of proposed requirements and the specification of Business Requirements derived from the review of background documentation and Stakeholder/Steering Committee interviews. In addition, critical success factors, risks and constraints are identified. Prior to examining the proposed requirements, it seems prudent to introduce the context of the JIN Criminal History Query project though an examination of the Business Scope.

5.1 BUSINESS SCOPE

This section is intended to define the boundaries of the project effort, define the business domain and introduce key concepts and terminology that will be used throughout the remainder of the project efforts.

The background section of this document introduced the Stakeholders of JIN. The following diagram depicts a subset of these as Key Stakeholders in Unified Modeling Language (UML) ‘actor’ notation.

ud Context - JIN Stakeholders

King County (KC)

Justice Information Network (JIN) CHQ

Project

Yakima County (YC)

Adminstrativ e Office of the Courts (AOC)

Washington State Patrol (WSP)

Department of Information Systems

(DIS)

Key Stakeholder

Key Stakeholder

Key Stakeholder

Key StakeholderKey Stakeholder



In terms of a services oriented architecture, the JIN Stakeholders are can be viewed as both Service Providers and Service Consumers. The majority of these Stakeholders are State Criminal Justice Agencies, that make up the limited scope of service consumers for JIN. This is in contrast to the broad scope of Service Providers, which may include Local, County, State or Federal agencies. The following diagram depicts this service provider/consumer contrast.

ud Context - Actors

Criminal Justice Practitioners

JIN CHQ Project

JIN CHQ Project

King County (KC)Yakima County (YC)

Adminstrative Office of the Courts (AOC)

Washington State Patrol (WSP)

Serv ice Prov ider Serv ice Consumer

State Justice AgenciesCounty Justice Agencies

Criminal Justice Agencies

Federal Justice Agencies

Pierce CountyTacoma CountyOther Counties

Corrections Other State Justice Agencies

Other Government Agencies

Local Justice Agencies

Seattle Municipal CourtOther Local Justice

Agencies

Couty ClerksLaw Enforcement OfficersPublic DefendersProsecutorsJudges

The preceding diagram presents an important concept/requirement for JINDEX. That is, only Criminal Justice Agencies are Service Consumers. That is the mandate of JIN. This does not preclude Other Government Agencies from being Service Providers, in essence, developing services that are certified and Registered with JINDEX, making them available to this targeted set of Service Consumers.



The following diagram provides context for the Customer Requirements. Boundaries are drawn between JINDEX and the Service Providers that form the scope for the JINDEX CACH Services. This is not a long term vision context diagram. It represents the vision upon completion of the JIN CHQ Project, whereas, the longer term vision would include many more Service Providers and Service Consumers. They have been excluded for clarity and brevity and to reflect project scope.

ud Context

WSP

Yakima County King County

AOC

JINDEX

Serv ice Developer


Criminal Justice Practitioners

JINDEX Center Of Excellence (COE)

JINDEX Serv ice Registry

JINDEX Support Serv ices

«artifact»

Standards

«artifact»

Code Examples

«artifact»

Implementation Patterns

«artifact»

Contractual Guidelines / Forms«artifact»

Best Practices

«artifact»

Test Cases

«artifact»

XML Schemas

«artifact»

Certification / Governance Model

«artifact»

Service Contracts

«artifact»

Marketing and Education

JINDEX CACH Serv ices

«web service»

AOC Person ID by Case Person Detail Query

Web Service Director

Serv ice Prov ider

«web service»

AOC Case Detail by Person ID Query

JILSProtrack

JINDEX CACH Serv ices

«datastore»

AOC Case Repository «datastore»

WSP ACCESS Criminal History Repository

«web service»

WSP Person ID by File Person Detail Query

«web service»

WSP Charge Detail by Person ID Query

«web service»

Consolidated Person ID by Person Detail Query

«web service»

Consolidated Detail by Person ID Query

«common service»

Registration

«common service»

Logging and Audit

«common service»

Security

«common service»

Notification

«common service»

Message Validation

«common service»

Development

«common service»

Adminstration

«common service»

COE Prov isioning

«service request»«service request»

The notation used is not intended to imply a physical hosting arrangement nor a responsibility to deliver. This diagram is above all a reflection of needs. The needs for JINDEX are shown in UML package notation, representing groups of related high level functionality requirements. These groups include:



JINDEX Center Of Excellence, containing many artifacts or document repositories for primary use by Service Developers.

JINDEX Support Services – providing the development, administrative and governance models for JINDEX.

JINDEX Services Registry – providing the central web Services Director, receiving service requests from both Yakima and King County applications with the intent of directing the service calls to wherever the may reside. Providing location transparency for the Agency Applications.

The JINDEX CACH Services are packages contain the repository specific web services, with the Consolidated web services being assembled ‘on the fly’ within the JINDEX Service Registry.

Throughout this context diagram are nodes labeled (stereotyped) <<common services>>. This designation aligns with the principals of Service Oriented Architecture, stressing reuse of logging, error handling and other less ‘business aligned’ services than their outward facing cousins – the <<web services>>.

5.2 BUSINESS GOALS AND OBJECTIVES

In attempting to validate the JIN goals for technology, design principles and proposed requirements, we must examine them in comparison to the principals of Service Orientation. In defining and clarifying these principals, they become valuable in setting policies, benchmarks and so on. The majority of the technology principals / proposed requirements have been restated as Business Requirements or User Requirements, subsequent to stakeholder interviews and a validation effort involving the Steering Committee members. Where no obvious applicability could be found, or the goal requires clarification, an issue number is assigned. Each issue is explored in greater detail in the Issues section found in Appendix D.

Proposed Business Goal Description Project Applicability

JIN Technology Principles

Standards

JIN constituents should conform to national, state, and open industry standards wherever possible.

This principal has been incorporated into a Business Requirement BR7.


Interoperability

New applications should focus on interoperability with the JIN infrastructure and data sharing as part of the design process.



Shared Infrastructure

The JIN community will use shared infrastructure appropriately and leverage existing infrastructure to the fullest extent possible.



Security and Privacy

Disclosure of data is the responsibility of the owner of the data according to applicable laws. Applications, data and security are the responsibility of their respective owners.



Applications and Data Exchanges

Applications that need to exchange data via the JIN should be designed or enhanced to be compatible with the JIN infrastructure.

This principal has been incorporated into a Critical Success Factor CSF6.


Reusable Components

Applications should use common, reusable components, data and designs wherever possible.


JIN Design principles Exchanges will be event-driven and timely, and designed to optimize

This principal requires clarification and is explored in




Exchanges efficiency for publishers and subscribers. greater detail in Appendix D, Issue I01.

JIN Design Principles

Services

The Justice Information Network is a service provider.


JIN Design Principles

Security

Exchanges will be secure and will comply with all state and federal requirements.


Proposed JIN Requirements

Core Application

Allow applications to be integrated in a loosely coupled fashion.

This proposed requirement has been incorporated into a Business Requirement BR4.


Core Application

Support industry standard component models.



Core Application

Support open communications protocols. This proposed requirement is explored in greater detail in Appendix D, Issue I12.

Potential Technical Requirement.


Core Application

Implement integration with minimal impact and changes to existing applications.

This proposed requirement is explored in greater detail in Appendix D, Issue I01.


Core Application

Allow processing to continue if one or more connected applications are temporarily unavailable.

This proposed requirement has been incorporated into a User Requirement UR17.


Core Application

Make use of third party databases for the storage of business rules, routing information, metadata information, and schema definitions.




Core Application

Allow applications to register their services or their interest in a given event without disrupting the operation or configuration.



Core Application

Provide a secure and managed environment for integration exchanges.

The security aspect of this proposed requirement has been incorporated into Business Requirement BR6 with the managed environment aspect incorporated into Business Requirement BR4.


Core Application

Scale the solution as applications, transactions, and services are added.

This proposed requirement has been incorporated into a Non-Functional Requirement NFR14.


Communications

Facilitate guaranteed, bi-directional information exchange among disparate applications.

The bi-directional aspect of this proposed requirement has been incorporated into Business




Requirement BR1 with the guaranteed aspect explored in greater detail in Appendix D, Issue I01.


Communications

Fully functional transactional and data integrity infrastructure for the network



Communications

Employ a protocol that supports once only delivery of messages.




Communications

Message queues and the tools required for managing those queues.




Communications

Transform or manipulate the data before either transporting it to another application or presenting it to a user. Transformation capabilities must include both logical (e.g., field merges) and structural (e.g., format changes) transformations.




Communications

Define these transformations as business rules to be performed during any activity involving a specific data source.




Communications

Provide guarantee once-only message delivery.



Communications

Provide the ability to return receipts of message deliveries.


Potential Functional Requirement.


Communications

Allow for content-based message routing. This proposed requirement has been incorporated into a Business Requirement BR7.


Communications

Provide notification of message delivery failure, and maintain state to rollback and restore data in the event of failure.



Communications

Provide the ability to dynamically reconfigure message routing without impacting any services.

This proposed requirement is considered a Technical Requirement and is explored in greater detail in Appendix D, Issue I18.

Proposed JIN Requirements Provide the ability to log high-priority messages to persistent storage without

The priority aspect of this proposed requirement has been




Communications impacting performance incorporated into User Requirement U18 with the storage aspect explored in greater detail in Appendix D, Issue I10.


Communications

Provide the ability to restrict or control message delivery based on security-based access rights; Provide a security schema that can be based on individual messages, message groups, or message content.

The restrict or control aspect of this proposed requirement has been incorporated into Business Requirement BR6 with the security schema considered a Technical Requirement and is explored in greater detail in Appendix D, Issue I04.


Communications

Perform all message transport transparently among different hardware platforms, databases, and operating systems.



Data Management

Metadata management associated with the data, exchanges, transactions, and processes developed within and connected to the JIN.



Data Management

Data schema management and documentation to be used in transformations and exchanges, including the ability to manage an exchange schema using JusticeXML v3.0



Data Management

Relational database to capture information to support audit, reporting, and administration functions.



Connectivity

JIN should provide software connections among agency platforms, applications, and databases in a scalable, high-performance, non-intrusive manner.



Connectivity

Enable the organization to perform standard data exchanges, XML based communications, and file exchanges with other participants, regardless of the existing technology employed by either the transmitting or receiving systems.



Connectivity

Include the mechanisms for providing the required connectivity for all applications in the justice community. This may include off-the-shelf adapters to connect to the relevant technologies, or guidelines for creating such adapters.


Proposed JIN Requirements Include development tools that can support the aspects of integration

This proposed requirement is considered a Technical




Application and Interface Development Services

associated with developing web-based applications and user interfaces.

Requirement and is explored in greater detail in Appendix D, Issue I16.



Basic graphical UI development for presenting data consolidated from multiple sources.




Small-scale application development leveraging data and components from underlying systems.




Mission critical application development capabilities




5.3 BUSINESS REQUIREMENTS

This section lists the reasons that JIN needs the Criminal/Case History Query application and why it needs a service oriented integration framework. In general, business requirements restate the JIN vision and direction. Ratifying this set of business requirements permits the correlation and traceability of each requirement (user, functional and non-functional) back to a business reason.

ud Business Requirements

JIN


«BR3»Prov ide Criminal

Justice Integration Serv ices

«BR1»Exchange Criminal Justice Information

«BR2»Lev erage Existing State Infrastructure

«BR4»Central Statewide

Integration Framework

«BR6»Legislated Information Ownership

«BR9»Physical Network

Connectiv ity

«BR5»Lev erage Summary

Offender Profile Application

«BR7»Promote

Integration Standards Criminal Justice

Practitioners

«BR8»Public Safety



Each Business Requirement (BR##) identified is explored in greater detail in the following table. This list is presented as the findings from the Stakeholder Interviews and the background documentation review.

# Business Requirement

BR1

Exchange Criminal Justice Information.

BR2

Leverage Existing State Infrastructure.

BR3

Provide Criminal Justice Integration Services.

BR4

Central State Integration Framework.

This is the main premise of JINDEX, providing the Center Of Excellence, Support Services and the Services Registry.

BR5

Leverage Summary Offender Profile Application.

Both the application logic and the lessons learned from the development project.

BR6

Legislated Information Ownership.

Not a business requirement of JIN, but remains a requirement / responsibility of Criminal Justice Agencies.

BR7

Promote Integration Standards.

Advocacy within JIN stakeholders and state agencies – encouraging them to adopt pure service-oriented architecture as they migrate their applications to web-based platforms. Doing so will significantly reduce the costs and risks of integration.

BR8

Public Safety.

Not a business requirement of JIN, but remains a requirement / responsibility of Criminal Justice Practitioners.

BR9

Physical Network Connectivity.

Not a business requirement of JIN, but remains a requirement / responsibility of Criminal Justice Agencies.

5.4 CRITICAL SUCCESS FACTORS

The following is a list of specific overriding factors and accomplishments necessary within the architecture to consider the effort a success. Typically, these are very specific and constrained restatements of one or more of the business goals. This section presents considerations for Critical Success Factors (CSF##). The Requirements Baseline will define the quantitative techniques that will be used for measurement.

In keeping with the distinction between the 2 facets of the JIN CHQ Project as discovered during the requirements assessment activities, the Critical Success Factors have been separated into 2 tables. The first presents those factors that relate to what is being referred to as JINDEX. The second lists those factors related to the actual web services themselves. In order to make then recognizable and discernable, they are referred to as JINDEX CACH Services.

The numbering schema used to reference each Critical Success Factor (CSF) has evolved from the presentation at



the Steering Committee validation meeting. As such, the numbers are randomly distributed between the 2 tables. This is intentional.

J I N D E X

# Critical Success Factor

CSF2 Increased awareness of Criminal Justice service availability.

CSF5 Criminal Justice Agencies increase solution delivery effectiveness by leveraging SOA best-practices and examples.

CSF6 Criminal Justice Agencies design / deliver solutions and projects that use or consider JINDEX principals.

The following table outlines the Critical Success Factors related to the second aspect of this project, the query services themselves.

J I N D E X C A C H S e r v i c e s

# Critical Success Factor

CSF1 AOC Case and WSP Criminal History repository information consumable as a web service.

CSF3 King County users are delivered Integrated Justice information through web services interface.

CSF4 Yakima County users are delivered Integrated Justice information through web services interface.

5.5 RISK

This section outlines the Risks (R##) inherent or perceived with regards to the previously identified Business Requirements. The requirements Baseline deliverable will explore each risk in detail, including the outline of a plan for each item, declaring how much risk can be tolerated and the means to do so.

# Risk

R1

Evolving Web Services standards.

Some form of governance for the standards is required to be ratified by the state to facilitate service development against these standards.

R2

Criminal justice agency reliance on vendor delivered Solutions.

R3

Lack of broad Service Oriented Architecture education.

This includes lack of awareness of the benefits related to developing applications within an architected solution. Benefits are not short term, but are realized as the number of services increase.



# Risk

R4

Interpretations of security and ownership responsibilities.

R5

Proliferation of project documentation to assist solution developers.

The sheer volume of material that must be consulted in order to determine which standards to adhere to is overwhelming.

R6

Other Integrated Justice initiatives within the state define/adopt conflicting standards.

This risk is related to existing initiatives, like e-citations, that are either relying on the standards that JINDEX has yet to ratify or developing solutions without considering potential JINDEX services for reuse.

5.6 CONSTRAINTS

This section outlines the assumptions and Constraints (C##) that have been captured as a starting point. Each of these has been vetted with project stakeholders through the interview process. Constraints include those gleaned from an assessment of the Legal and Procedural requirements for information sharing, details of which is contained the Appendix C of this document.

Constrains are factors that place limitations or direction on the design of the eventual solution but are not necessarily related to any specific business goal or requirement.

# Constraint

C1

All JINDEX web services will adhere to common WS Standards, including the ratified WS-nn family of standards.

The standards adopted by JINDEX will be examined and defined during Design.

C2

JIN does not have the legislative responsibility of providing guaranteed delivery of messages between stakeholders.

This issue is explored in Issue # I01 in Appendix D.

C3

Service consumers are restricted to Criminal Justice Agencies.

This does not preclude the certification and registration of services by Other Government Agencies.

C4

All service requests and replies will use HTTPS transport.



6 USER REQUIREMENTS

User Requirements (UR##) give a concrete list of behaviors and functionality that users expect to see from the solution. The following user requirements have been derived from stakeholder interviews and represent both the requirements of the integration framework (JINDEX) and the CACH Case And Criminal History web services, identified in the business requirements.

J I N D E X

# User Requirement User

UR1 Allow access to service usage/access details to support ownership auditing. Service Owner

UR3 Receive examples, guidance and best practices for developing services destined for registering on JINDEX.

Service Developer / Tester

UR4 Permit users to register their intent to receive new services. Criminal Justice Practitioner

UR7 Notification of new service availability. Criminal Justice Agency

UR8 View service availability including current up/down status of underlying service components.


Criminal Justice Practitioner

UR9 Notification when errors occur. Solution Support

U10 Support the design, development, testing and deployment of web services solutions.


UR15

Standards & guidelines conformance. Service Developer / Tester

UR16

Maintain/view service contracts between Service Provider and Service Consumer.


Service Owner

UR18

Service developers will utilize the JINDEX web services as examples of suitable design / patterns implementation and implementation best practices.




J I N D E X C A C H S e r v i c e s

# User Requirement User

UR2 All services will be consumable through WS-nn and a generic Web User Interface.


UR5 Broker automated authorization according to the service owner requirements.

Criminal Justice Agency

UR6 Companion test services that support service solution development. Service Developer / Tester

UR11

WSP Criminal Justice “ACCESS switch” repository information available through an ‘ID of Possible Match Query’ Web Service.



UR12

AOC Case repository information available through an ‘ID of Possible Match Query’ Web Service



UR13

WSP Criminal Justice “ACCESS switch” repository information available through a ‘Consolidated Criminal History Query’ Web Service.



UR14

AOC Case repository information available through a ‘Consolidated Criminal History Query’ Web Service.



UR17

Allow processing to continue if one or more connected application is temporarily unavailable.


UR18

Utilize the CACH services as examples of suitable design / patterns implementation and implementation best practices.


UR19

WSP Criminal Justice “ACCESS switch” repository information and the AOC Case repository information available through a single combined ‘ID of Possible Match Query’ web service.



UR20

WSP Criminal Justice “ACCESS switch” repository information and the AOC Case repository information available through a single combined ‘Consolidated Criminal History Query’ Web Service.





7 FUNCTIONAL REQUIREMENTS

This section outlines the collective Functional Requirements (FR##) for the JINDEX CACH services and the associated JINDEX framework. These requirements show the intended behavior of the solution and define the application capabilities that are required to fulfill the User Requirements.

ud Functional Requirements

JINDEX Common Services

JINDEX Support Services

JINDEX Center Of Excellence

JINDEX CACH Services

JINDEX Service Registry

«FR10»Authenticate Serv ice User

«FR11»Authorize Serv ice

User

«FR38»Test Serv ice

«FR34»View Integration

Contract

«FR18»Validate Message

«FR28»View Serv ice API

«FR31»Certify Serv ice

«FR29»View Serv ice Certification

Requirements

«FR30»Apply for Serv ice

Certification

«FR16»Redirect Serv ice

Calls

«FR22»View Serv ice

Metrics

«FR24»Publish Standards

«FR25»View Standards

«FR20»View Audit Log

«FR19»Audit Serv ice Usage

«FR23»Resume/Suspend

Serv ice

«FR37»Dev elop Serv ice

«FR35»Contract

Expiration Notification

«FR21»View Serv ices

Av ailable

«FR32»Register New

Serv ice

«FR39»Host

Consolidated Serv ices

«FR36»Register Interest in Serv ice Type

«FR4»Notification of Serv ice Type Status Change

Query AOC Person ID by

Person Details

Query AOC Case Detail by Person

ID

«FR5»Query

Consolidated Person ID by

Person Details

Serv ice Dev eloper

JIN

Query Consolidated

Detail by Person ID

Query WSP Person ID by

Person Details

Query WSP File Detail by Person

ID

JILS (King County)

Protrack (Yakima County)

«FR26»Publish Code

Examples

«FR27»View Code Examples


«FR15»External

Authorization

«FR33»Add Integration

Contract

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

The preceding diagram presents a high level overview of JINDEX functional requirements, as a means of demonstrating the breadth of potential user interactions with JINDEX. This diagram is not intended to define the scope of this project, as this is documented elsewhere. As well, readers should not infer automated or machine-



based solutions for each node in the diagram, as many will likely be delivered manually. The complete set of Functional Requirements is presented in the following table.

J I N D E X

# Functional Requirement User Requirement Ref

FR1 WSP ACCESS data will be accessible through an ‘ID of Possible Match’ query. In this query, a subset of a person’s attributes is passed into ACCESS. ACCESS returns a list of persons who are possible matches based on the input.

UR11

FR2 WSP ACCESS data will be accessible through a ‘Criminal History’ query. In this query, an explicit person identifier is passed into ACCESS. ACCESS returns all criminal history data for that person.

UR13

FR3 AOC data will be accessible through an ‘ID of Possible Match’ query. In this query, a subset of a person’s attributes is passed into AOC. AOC returns a list of persons who are possible matches based on the input.

UR12

FR4 AOC data will be accessible through a ‘Case History’ query. In this query, an explicit person identifier is passed into AOC. AOC returns all case history data for that person.

UR14

FR5 A ‘Consolidated ID of Possible Match’ query will access both AOC and WSP systems. Given a single request to the consolidated query, the query will in turn redirect the request to both AOC and WSP systems.

UR19

FR6 A ‘Consolidated Case and Criminal History’ query will access both AOC and WSP systems. Given a single request to the consolidated query, the query will in turn redirect the request to both AOC and WSP systems.

UR20

FR7 All queries will be implemented as asynchronous request/reply web services.

UR2

FR8 JINDEX will implement reliable messaging, to include definable conversations (i.e. a CACH conversation can take different parameters from other, future conversations) and configurable parameters, including number of retries, time between retries, and escalation/notification procedures (e.g. email alerts)

UR17, UR9

FR9 All requests and replies will consist of a SOAP message with an embedded Justice XML document in the SOAP body

UR2

FR10 A common JINDEX authorization service will interface with existing Washington State security gateways, injecting security tokens in the SOAP header in accordance with information received from the gateway (e.g. a user sends a basic SOAP request with no security tokens in the header. The request goes through Fortress authenticated. JINDEX authorization service builds a WSS header to inject in the SOAP header of the original message. This example is illustrative only; design will be finalized during the design phase)

UR5

FR11 Standardized security tokens (e.g. username, ORI, GUID) in the SOAP header will enable external applications to perform necessary authorization, without needing to re-authenticate.

UR5

FR12 Translation to and from Justice XML and existing AOC interfaces will be done by the JINDEX integration framework. Existing interfaces may or may not include leveraging other applications that are currently interfacing with this system.



J I N D E X


FR13 Translation to and from Justice XML and existing WSP interfaces will be done by the JINDEX integration framework. Existing interfaces may or may not include leveraging other applications that are currently interfacing with this system.

FR14 As an asynchronous request/reply pattern, all requests must contain the URI to which replies should be posted.

FR15 Service providers will be responsible for providing services/logic that can be accessed by a JIN common authorization service, such that, JINDEX brokers the call for authorization.

FR16 Service calls from Agency applications will be redirected to a web service that fulfills the request embedded in the call. This is done in a location transparent fashion.

Service consumers will be responsible for developing application functionality that can handle multiple replies received asynchronously (e.g. a request from JILS will be redirected to both AOC and WSP. AOC and WSP will respond separately to JILS. JILS must be able to refresh query display results as they are received from AOC and WSP)

UR17

FR17 All requests and replies will conform to the WS-I Basic Profile, and potentially other WS-I profiles, as determined in the project design phase.

UR2, UR18

FR18 JINDEX will be capable of validating individual messages against relevant XSD schemas (although performance considerations may recommend or dictate that validation be performed at endpoints, rather than in the messaging framework)

FR19 All messages sent across JINDEX will be logged. Sender, receiver, date/time, and message type will be recorded at a minimum.

UR1

FR20 Users will be able to examine JINDEX logs both for debugging and audit purposes. Access rights to examine logs will be restricted. All users will be able to examine transactions where they were either the sender or the receiver. Only selected users will be able to examine complete logs.

UR1

FR21 Service status and availability will be visible to authorized users UR8

FR22 Service usage metrics will be visible to administrator users UR1

FR23 Criminal Justice Agencies / service producers (the owners of a particular service) will be able to both suspend and resume their services. Suspending a service takes it offline from the JINDEX, essentially insulating it from receiving any messages from the framework. Resuming a service brings it back online.

FR24 JINDEX users will be able to publish standards for service development in the Center of Excellence

UR3

FR25 Criminal Justice Agencies will be able to view standards for service development in the Center of Excellence

UR3

FR26 JINDEX users will be able to publish code examples for service development in the Center of Excellence

UR3

FR27 Criminal Justice Agencies will be able to view code examples for service UR3



J I N D E X


development in the Center of Excellence

FR28 Criminal Justice Agencies users will be able to view Service APIs for service development in the Center of Excellence

UR3

FR29 JINDEX users will be able to view Service Certification Requirements

FR30 Criminal Justice Agencies will be able to apply for certification of new services

FR31 JINDEX users will be able to certify new services

FR32 Once certified, service providers will be able to register their new services

FR33 Service providers will be able to add/publish integration contracts, defining specific requirements for use of their service(s) (e.g. WSP may require the ORI security token in their SOAP header, whereas AOC may not)

UR16

FR34 Service consumers will be able to view integration contracts for available services.

UR16

FR35 Service consumers will be able to receive notification on expiry of integration contracts.

UR16

FR36 Criminal Justice Agencies will be able to register their interest in new services.

UR7

FR37 Service developers will have a platform upon which new services can be developed

UR10

FR38 Service developers will have a platform upon which new services can be tested

UR10

FR39 Criminal Justice Agencies will be able to have consolidated services hosted by JINDEX support services



8 NON-FUNCTIONAL REQUIREMENTS

This section describes the Non-Functional Requirements (NFR##) captured during the stakeholder interviews and documentation review. While functional requirements describe the behaviors (functions or services) of the system that support user goals, tasks or activities, non-functional requirements describe the overall qualities of the application as a whole. Qualities are properties or characteristics of the system that its stakeholders care about and hence will affect their degree of satisfaction with the system.

Informally we can think of functional requirements capturing what the system must do, and the non-functional requirements as describing how well these functional requirements are satisfied—where “how well” is judged by some externally observable/measurable property of the system behavior, not its internal implementation. In other words, “how well” may be judged by the user in terms of some characteristic that the user values or is concerned about, such as:

• Usability (ease-of-use, learnability, memorability, efficiency, etc.)

• Configurability and supportability

• Correctness, reliability, availability

• Quality of service requirements such as performance (throughput, response time, transit delay, latency, etc.)

• Safety properties (so-called because they “prevent bad things from happening”), such as security and fault tolerance

• Operational scalability including support for additional users or sites, or higher transaction volumes

NFRs ensure fitness of the system for purpose, apart from the specific functions that the system is capable of. That is, they constrain how the functions may be implemented and provide the criteria for evaluating each technical option. Subsequent to this deliverable is the Requirements Baseline document, which will express each NFR in a measurable (testable) form. However, this can be difficult due to the nature of NFRs and they are often evaluated subjectively.

As options are considered throughout the project lifecycle, the evolving prioritized list of NFRs will be used to evaluate options, as part of the discussion and collaboration process and will be relied upon to justify the choice of one option over another, driving efficient and timely decision making. Several major design decisions will be made, based primarily on the weighted measurement of Non-Functional Requirements against each alterative. Included is the selection of Sonic ESB vs MS BizTalk.

The following list has been captured from the IEEE/ANSI830-1993, IEEE Recommended Practice for Software Requirements Specifications and tailored to fit the JIN CHQ Project. A final, prioritized list of NFRs will be presented in the Requirements Baseline deliverable of the project.

Here we have to be clear—not all services that JIN may provide need all of these characteristics; however it is important that if a service is to be used by multiple consumers, (as is typically the case when a SOA is required), the specification needs to be generalized, the service needs to be abstracted from the implementation, and developers of consumer applications shouldn't need to know about the underlying model and rules. The specification of obligations that client applications must meet needs to be formally defined and precise and the service must be offered at a relevant level of granularity that combines appropriate flexibility with ease of assembly into the business process.



Non-Functional Requirements - JINDEX

# Non-Functional Requirement

Project Applicability / Notes

NFR1 Performance

JINDEX messaging framework should be able to handle 15 transactions per second (average)

Stakeholder interview with Trever Esko from King County indicated some preliminary performance metrics. KC’s JILS application will likely be one of the first consumers of JIN web services. JILS’ UI application for criminal and case history must run within acceptable performance guidelines. It should take no more than 5-8 seconds total response time for a JILS inquiry. KC expects that county users will eventually be conducting 1200-1400 inquiries/day, most of which should be during normal business hours (= ~ 2.5 requests per minute).

Online anticipates a small client start to the project, with managed growth over time as service contracts with other agencies are established.

KC represents a large proportion of Washington’s population base and hence a relative proportion among Law Enforcement Agencies and JIN service consumers. In the 2000 census, KC represented 29% of the state population. The percentage is projected to be 26% in 2030.

(source http://www.wsdot.wa.gov/planning/wtp/datalibrary/population/countiespopgrowth.htm)

Planning for a 74% increase over JILS’ figures for CACH consumption seems prudent. Similarly, since CACH is expected to be just one of many web services in use across the JIN, a forty-fold increase in traffic as new services are brought online is advised. Each web service is assumed to follow an asynchronous request/reply paradigm (equally applicable to event-driven), putting 2 distinct messages through a messaging broker. JIN’s messaging backbone, therefore, should be able to handle at least 15 XML transactions per second.

(1400 tx / 8 hours / 3600 seconds / 26% population * 40 new web services * 2 messages per request/reply) = 15 transactions per second

This metric pertains strictly to the messaging framework and is irrespective of the endpoints applications. JINDEX cannot control the performance of applications such as ACCESS or AOC. The metric simply demonstrates the number of messages that the JINDEX should be able broker to the various endpoints.

NFR2 Performance

JINDEX should be able to throttle messages in accordance with the performance limitations of endpoint applications

JINDEX could potentially broker more messages to an endpoint application than the application could handle. In order to avoid overloading applications, JINDEX should be able to define throttling metrics by endpoint (e.g. application X receives a maximum of 2 requests per second, application Y receives a maximum of 3 requests per second, etc.) Messages in excess of throttling maximums would be held in a queue and forwarded to the endpoints at the next available interval.

NFR3 Usability

Web services must be easily discoverable by potential service consumers. JINDEX will document both short and

Usability takes on a new meaning within the context of machine-consumable web services. Simply put, there is no traditional user interface in this domain. Usability is, however, still very much applicable as a non-functional requirement for this and future web services-based projects.

Usability in the JIN domain should be considered from the perspective of


http://www.wsdot.wa.gov/planning/wtp/datalibrary/population/countiespopgrowth.htm

http://www.wsdot.wa.gov/planning/wtp/datalibrary/population/countiespopgrowth.htm





long term plans for statewide information devolution.

business users (who are potential service consumers) and system integrators.

Business users must be able to easily discover services available to them across the State. As service providers bring new services online, these services cannot remain hidden, to be discovered through happenstance and word of mouth. Rather, the implementation of a carefully and deliberately planned integration framework for the JIN must include both short and long term plans for information dissemination to potential service consumers. Eventually, UDDI may be the mechanism with which to address usability for business users.

(The Universal Description, Discovery and Integration (UDDI) specifications define a registry service for Web services and for other electronic and non-electronic services. A UDDI registry service is a Web service that manages information about service providers, service implementations, and service metadata. Service providers can use UDDI to advertise the services they offer. Service consumers can use UDDI to discover services that suit their requirements and to obtain the service metadata needed to consume those services. Source - http://www.uddi.org/)

In the short term, however, the cost of implementing UDDI services may not be offset by the benefit of large numbers of consumers able to dynamically discover web services. With this consideration, the non-functional requirement of easy discoverability may be accomplished through less elegant, although more pervasively available means, such as a JINDEX email newsletter, website publishing similar to grandcentral.com, etc. This will ultimately be decided by the JIN Board through the alternatives evaluation process.

Feedback from King and Yakima counties, as the initial consumers of Criminal and Case History Web Services, will be key in validating whether ‘easy discoverability’ has been achieved, regardless of the delivery mechanism.

NFR4 UsabilityWeb services must be self-describing for system integrators. JINDEX will provide documented guidelines for the usage of WSDL.

Web Services Description Language (WSDL) is commonly used among system integrators and is generally supported by commercial middleware products. If used properly, WSDL can speed the integration process and can eliminate much of the paper documentation that has historically accompanied the establishment of trading partner relationships. What WSDL provides is a machine-consumable template for endpoint integrators to use in tying their back-office systems and applications to a web service. WSDL can only achieve these goals, however, if certain guidelines are followed. For example, request and reply schemas must include appropriate levels of embedded annotation to clearly define the semantics of each data element, and the business context of the messages as a whole. URIs and ports for both production and test environments should be detailed, ideally within a single WSDL file (although separate files may be required). JINDEX will provide documented guidelines for systems integrators to follow in developing WSDL for future JINDEX


http://www.uddi.org/





services.

NFR5 Operational

JINDEX should allow for intuitive and service-based remote debugging and support.

In an integration framework involving multiple remote agencies accessing multiple statewide services, self-support capabilities become essential. DIS cannot be expected to field all support calls for JINDEX problems, unless additional resources are funded, which seems unlikely. Where a message has become ‘lost’ or a service unresponsive, endpoint agencies must be able to access separate services to debug. This must be independent of the broker technology used to implement the framework. If the integration framework is implemented using either Biztalk or Sonic, remote agencies shall not be required to have the product installed in order to debug. A browser-based or a web-services based management console/querying capability should allow for users to query based on message type, date/time, and message originator/recipient (where the querying user must be either party to the transaction)

NFR6 Operational/Reliability/ Maintainability

JINDEX requires reliable messaging. This should be implemented based on an open, standards-based reliable messaging framework.

Reliable messaging reduces support requirements, as it typically involves elements such as automatic retries, configurable timeouts, and configurable escalation and notification mechanisms (e.g. ‘notify support via email if message could not be delivered after 5 attempts). Most middleware software technologies implement proprietary guaranteed or reliable messaging mechanisms. In a topology such as JIN, where multiple remote agencies may be using multiple middleware technologies, the requirement to use a standards-based reliable messaging framework becomes evident. Unfortunately, standards such as WS-Reliable Messaging are still emerging and have not yet received ratification. The design phase of this project will examine the pros and cons of implementing un-ratified standards.

NFR7 Reliability

JINDEX should achieve at least a 94% availability level.

Washington State’s justice community will, over time, come to rely on the JINDEX framework as more integrated justice services come online. System uptime will therefore be crucial to the community. Users will expect JINDEX to be available, similar to the way in which a dial tone is expected when lifting a telephone receiver. As the state’s dial tone for integrated services, JINDEX should achieve a high level of availability. The 94% availability metric is based on 23 hours per day, 6 days per week, and 20 hours of availability on the 7 th day (a scheduled weekly outage during off-peak hours, whether it is taken or not, will allow for regular system upgrades and deployment of new services). Depending on service level agreements achieved with the JINDEX hosting agency (likely DIS), greater levels of availability may be realized. System availability can easily be measured by examining server logs over a trial period of several weeks for any downtime.

NFR8 Reliability

JINDEX should be fault tolerant. Queued messages should be recoverable across server bounces.

In a latent, asynchronous messaging framework, recoverability from system downtime is essential. Servers go down for a number of reasons, and the JINDEX must not lose messages as a result.

NFR9 Operational/Usability

JINDEX should allow for When a new JIN service comes online, it may be immediately useful across the state. Many agencies, however, will not have achieved a state






service consumption by users with varying technological maturities.

of technological maturity requisite in order to consume the web service programmatically. Building SOAP XML messages and being able to consume like responses is a goal that may be several years away for numerous justice agencies’ IT departments. Alternatives must exist for these consumers to take advantage of JIN services without the use of XML messaging and middleware. As part of the JINDEX Center of Excellence concept, guidelines and examples will be written for new service development that include, for example, recommended practices on alternative delivery mechanisms using pervasive technology (e.g. implementing a web-form interface to an XML web service). The Case and Criminal History Query web services will provide the initial template. Although these will both be SOAP/XML based services, a UI will be implemented for demonstration not only of the end functionality, but also how service providers should plan implementations to encourage more widespread uptake by all service consumers.

NFR10 Operational/Safety

JINDEX should implement an open, standards-based framework for authentication and authorization.

A myriad of authentication and authorization paradigms are implemented across the state. Network-level security, single-point authentication gateways, and application security all have legitimate origins and will continue to co-exist as long as different agencies are mandated with different security requirements (i.e. forever). Fundamental to a service-based architecture is enabling efficient authentication and authorization in this type of varied topology. ‘Efficient’, in this context, generally means not having to login with the same credentials multiple times in order to gain access to the desired services.

Emerging standards such as WS-Security are trying to address these issues. Credentials are tokenized in a standard form and passed within SOAP headers such that gateways, endpoints and applications can re-use credentials. As with WS-Reliable Messaging, lack of ratification remains an issue. Options will be examined in detail during the project design phase.

As an example, JINDEX may provide a single service to interface with existing state security gateways such as Fortress and Transact Washington. JINDEX security services could build the SOAP WSS header based on information received from the gateway. The WSS header, including security tokens such as username, ORI, etc. would be passed to endpoint applications such as ACCESS. These would then determine if the ‘upstream’ authentication and authorization mechanisms were sufficient. If not, the endpoint applications could choose to re-validate credentials.

NFR11 Resource/Acceptance/ Documentation

Consolidated, concise JINDEX framework documentation will be published as a project artifact

Systems integrators, end users, and maintenance personnel will have a steep learning curve with the many new technologies used in the JIN framework. As part of the Center of Excellence concept, Online Business Systems will provide documentation and examples for developers to develop their own web services for future integrated justice projects. Artifacts should include appropriate primer documentation on standards (e.g. SOAP, WSS (if used), WS Reliable Messaging (if used)), guidelines (e.g. how to write your WSDL), technologies used in implementation (asynchronous messaging, Sonic/Biztalk), and samples/examples. Artifacts will be non-proprietary, free from IP encumbrances, and will be






available for use by Washington State constituents on future projects. This approach, combined with a concerted internal marketing effort, offers the best chance at success for end-user (statewide) acceptance of JINDEX. By making the technology open, well documented, and accessible to all, uptake of JINDEX and development of additional integrated justice services should be the result.

NFR12 Portability

Integration technology selected for implementation of the JINDEX should allow for endpoint integration without the use of remote agents, or by using a different integration technology

By nature of implementing JINDEX using open web services standards, solutions will be inherently portable and interoperable with any other systems that support these standards (all significant middleware vendors and most application servers now support web services). Sonic and Biztalk are the two technology platforms to be evaluated by the state. One of the evaluation criteria will be how well these products can architecturally support remote endpoint integration without the deployment of an agent. Occasionally, however, adapters will need to be developed in order to interface with endpoint applications. This NFR would give preference to the technology that could be easily deployed and hosted on existing, low-cost, or open-source infrastructure. In other words, can Biztalk adapters be hosted on Windows servers independently from Biztalk? Can Sonic adapters be hosted on Java application servers independently from Sonic?

NFR13 Portability

CACH services should be compatible with the appropriate WS-Interoperability (WS-I) profile

WS-I promotes interoperability across platforms, operating systems, and programming languages. Following WS-I profiles ensures, for example, that a Biztalk Web Service can communicate with a Sonic Web Service.

NFR14 Performance

CACH should be able to handle 0.4 transactions per second

(1400 TX / 8 hours / 3600 seconds / 26% population * 2 messages per request/reply) = 0.4 transactions per second

NFR15 Usability

CACH services must have published WSDL that is consumable by King and Yakima counties

WSDL provides the usability aspect for service developers. It presents an easily understandable view of the functionality expectations, connection details and message formats.

NFR16 Resource

JINDEX Center of Excellence shall publish recommended skillsets for systems developers, architects, and maintenance personnel. Additionally, the aforementioned guidelines and examples for web service development should be usable as training guides

Future integrated justice projects are likely to be implemented by a mixture of IT resources internal to Criminal Justice Agencies, as well as external vendors. Guidelines for recommended skillsets will assist in resource planning, internal training initiatives, and vendor solicitation.






for skilled developers with little previous exposure to web services.

NFR17 Reusable

All JINDEX core services and CACH services shall be developed using a Service Oriented Architecture (SOA) methodology. SOA methodology guidelines shall be documented and published in for the Center of Excellence.

A fundamental tenet of SOA, and indeed services in general, is the intent to reuse functionality. Reuse has traditionally been problematic, especially in heterogeneous communities (such as the multitude of Criminal Justice Practitioners and Agencies across an entire state). Web Services and SOA, however, provide both the framework and the technical means to finally make reuse both feasible and practical. Remote agencies can dynamically discover a service someone else is offering through UDDI. They can develop interfaces to this service with minimal interaction and effort through the self-describing, machine-consumable WSDL. The technologies use standards supported by all major vendors, thus the traditional separation of developer communities into ‘camps’ is eliminated. A number of principles must still be followed, however, and these will form a significant part of the Center of Excellence artifacts in the implementation phase of this project.

NFR18 Safety/Reliability

JINDEX will provide guidelines for the future provisioning of Quality of Service (QOS) levels within the messaging framework.

The nature of criminal justice dictates that some tasks must be given more urgency than others. The officer in the field requires data in a more timely fashion than a typical office clerical inquiry. It stands to reason, therefore, that JINDEX should be able to delineate separate message precedences and accordingly prioritize delivery. While QOS provisioning is out of scope for implementation of CACH services, Online Business Systems will research any emerging standards in this domain and will include recommendations/guidelines for the Center of Excellence on how QOS might be achieved in the future.

NFR19 Safety

JINDEX will maintain data integrity and confidentiality. JINDEX will provide mechanisms which could facilitate logging and audit.

Criminal Justice information is, by nature, sensitive and must be protected. Numerous manual and automated access controls, logging, and audit procedures are already in place across Washington State. The implementation of JINDEX must not compromise any of these principals, rather it should enhance and facilitate more efficient security processes.

XML messages transmitted in plain text over a network could be ‘snooped’, thereby compromising confidentiality and injecting threats to integrity. All JINDEX services, therefore, should be implemented using HTTPS.

Agencies will continue to retain ownership of the information in their custody, and hence will manage authorization rights and protecting misuse of information. JINDEX will facilitate authentication and authorization, as previously described in this section.

The statement “JINDEX will provide mechanisms which could facilitate logging and audit” is deliberately left somewhat open. The JINDEX framework will definitely allow for full logging of who messages were sent from and to, the types of messages, the dates and times sent, and the contents of messages. This type of detailed logging allows for detailed and even automated auditing, but it also confers immense memory requirements. Even with a modest 5 KB XML message, the performance planning metrics outlined in NFR1 above would mean the monthly






accumulation of more than 64 Gigabytes of log data.

(1400 tx / 26% population * 40 new web services * 2 messages per request/reply * 30 days * 5000 bytes)

Omitting the message payload from the logs can reduce this metric by an order of magnitude, but the memory requirements are still significant. It is therefore recommended that JINDEX logs follow a paradigm such as a 6 month ‘sliding window’, such that log entries older than 6 months are continually archived. JINDEX logs would primarily be for debugging purposes, with limited time-bound auditability. These parameters will be configurable by the JINDEX hosting agency (e.g. DIS) and the option to log more or less, and for what time period will need to be negotiated among stakeholders.



9 TECHNICAL REQUIREMENTS

Prior to the precise definition of technical or architectural requirements, the bulk of customer related requirements must be examined, discussed and ratified. The Requirements Baseline deliverable will examine the specific architectural requirements, identifying the needs for:

Data Model - Present a high-level data model which captures the business process view of the data and data relationships.

Data Integrity - Identify requirements for maintaining data correctness: fixes, tolerances, redundancies, built-in checks.

Data Characteristics - Describe data types, volumes, volatility, unusual access requirements

Data Distribution - Identify location and geography requirements, along with replication, translation, READ-ONLY requirements associated with the distribution.

Data Synchronization - Describe time-value, latency tolerance replication demands of all data synchronizations.

Critical Dependencies and Interfaces - Identify dependencies in terms of timing and information flow as well as critical interfaces to legacy systems.

Application Deployment Requirements - Identify the chronological order of deployment as well as the location of each deployment and its platform needs.

Application Performance Requirements - Identify required throughputs, response times, and transaction volumes for peak and non-peak periods.

Expected Service Levels - Detail the "up time" requirements for each application: global availability versus local availability; reliability and maintainability needs.

Application Development Environment - Identify methodologies and tools to be used in the application development.

Infrastructure Deployment - Define geographic constraints on the technology: location, stability, accessibility, performance for hardware, software, and network components.

Expected Service Levels - Detail the "up time" requirements for all portions of the infrastructure incorporating mean time between failure (MTBF) constraints.

Support Roles - Describe new roles and responsibilities needed in the support organizations and in the consumer organizations. Include training requirements.

Support Coverage - Identify staffing levels and coverage schemes needed to support each major function including skill sets required.

Expected Service Levels - Determine expected problem resolution time frames and identify acceptable time frames for each major architecture component.

Once the Technical Requirements are identified, they will be mapped back to each Customer Requirement (Business Requirements, User Requirements, Functional Requirements, Non-functional Requirements, Critical Success Factors, Constraints, and Risks). Traceability mapping identified technical requirements that do not map back to business requirements (requirement creep or vision, depending on your point of view) and business requirements, CSFs, risks, or constraints that are not reflected in technical requirements.



APPENDIX A – REQUIREMENTS ASSESSMENT INTERVIEWS

This section provides the key observations from each of the stakeholder interviews. Stakeholder interviews were conducted and interview notes captured and reviewed by each stakeholder individually prior to drawing conclusions / requirements from the content. This process has proven beneficial to the project in establishing a collaborative environment in which to ratify user requirements amongst the diverse stakeholder group. In addition, questions and clarification from the background documentation review were explored during the interviews, leading to additional material to review and identifying areas that would require further analysis and follow-up.

The complete interview notes are not provided here, instead, key observations are summarized in order to provide context for the actual customer requirements, captured thought this document.

# Key Observations

1 Web Services standards adoption!

2 Not a User Interface, but an application-to-application environment using web services to connect state systems and regional systems.

3 Conform to agency audit and logging requirements. Individual user access and reasons for access must be logged depending on particular Service Contract is established.

4 DIS would be a logical agency to host the shared CACH application.

5 Both individual services and consolidated services are required, allowing each Agency to choose to consume whichever service best fits within their existing or planned applications.

6 QOS and Priority options should be available for JIN offered services. While this is outside the scope of the JIN Project, consideration must be given to establishing a priority of service fulfillment based on role.

7 Counties will play a key role in the building of test cases and the acceptance testing of the application.

8 Build the application with extensibility in mind.

9 What is developed is the physical manifestation of the design principals and not just another point-to-point solution.

10 Separate the Framework from the Query Services, ensuring adequate effort is spent on other facets of the project. Do not assume the framework will be a legacy of a pure Query Service implementation effort.



APPENDIX B – DOCUMENTATION REVIEW

This section presents a summary of the DIS, AOC, WSP, King County, Yakima County and JIN background documentation that was reviewed in support of the assessment of the current operational environment, as well as the legal and procedural requirements for information sharing and in the preparation of the customer requirements details. The following artifacts were reviewed during the requirements assessment phase and in the preparation of this deliverable.

# Artifact Notes

1 Summary Offender Profile Design Document

Two user guide type reference documents, as well as the operator's guide.

2 Equarius POC Final report

Not the results or lessons learned – contains more of a presentation of the POC solution.

3 SOP Review County review of the pilot rollout of SOP

4 POC Evaluation documentation – graduate students

University of Washington SOP Evaluation

5 King County Law, Safety and Justice Integration planning documents

Strategic Information Plan and Technical Architecture

6 SOP Data Element by Source System

List of the data elements by source. Less useful without the mapping logic in the source code.

7 SOP Phase II Requirements

SOW from Templar for spending the additional 50K in services on something that adds value to CACH and SOP Phase 2

8 AOC Security Discussions

Email thread from AOC that discusses security, including INFRASTRUCTURE DEPARTMENT POLICY 7.14.1: Cryptographic Key Management

9 WSP Security Discussions

Document available on the web. access.wsp.wa.gov

10 WSP ACCESS Manual Contains security procedures, user guides and specs for command access (Query/response) to the WSP ACCESS switch.

11 JIN Proof of Concept Evaluation criteria for JIN Technical POC

12 JIN Feasibility Study March 1997 by ECG Consultants

13 JIN Strategic Plan Reviewed.

14 JIN Technical Architecture Report dated June 2002

Contains DESIGN DECISIONS that should be validated. Can serve as a good starting point for interview discussions.

15 2002 Implementation Recommendations

Reviewed.

16 JIN Common Architecture Data Dictionary

Referenced by the answers to RFP respondent questions during RFP process.

Created by JIEM tool I believe. Process flows and data standards. Must confirm the usability of this material.



# Artifact Notes

17 DIS IT portfolios Reviewed.

18 AOC IT portfolios JIS Migration Plan is the state of IT at AOC as of 2001 and the second document is a current picture ‘working’ document. Understanding both permits a balanced view on priority shifts, plan deviances, etc.

Contains courts consensus building for their projects and how this is accomplished.

19 WSP IT portfolios http://sww.wa.gov/dis/mostd/WSPportfolio/default.htm

20 Yakima County Technical Services Law & Justice System Integration planning documents

Not yet received.

21 SOP source code Proprietary connection/query logic for WSP/AOC adapters.

22 JIN Board meeting minutes

Reviewed.

23 DIS Security Policies Reviewed during DIS Design Review.

24 JIN Common Architecture Data Dictionary

Referenced by the answers to RFP respondent questions during RFP process

25 DIS Design Review Materials

Obtained during DIS collaboration. Network Diagram and DIS review checklist.



APPENDIX C – LEGAL AND PROCEDURAL REQUIREMENTS ASSESSMENT

Review of Policies, Authorizing Legislation

JIN Authorizing Legislation

Chapter 10.98 of the Revised Code of Washington (RCW) defines the requirements for collecting and transmitting criminal justice information for the purpose of reporting criminal histories. A key component of this section – the Criminal Justice Information Act – was the creation of the Washington Integrated Justice Information Board in 2003. The authorizing language defines the goal of the Board is to “develop and maintain, in a cost-effective manner, a statewide network of criminal justice information that enables sharing and integrated delivery of justice information maintained in the state's independent information systems.”1

Specifically, the statute requires the promotion of standards for justice-related information systems and information sharing to reduce redundant data entry and promote timely access of information while at the same time adhering to State law governing information security and citizen privacy rights2.

The Board is a stand-alone body (it is not housed under another agency or the Office of the Governor) and is governed by its authorizing legislation and the by-laws it has created. Chapter §10.98 prescribes the composition of the Board as well as its authority to meet and appoint new members. The Integrated Justice Information Board has many responsibilities with regard to the implementation of justice information sharing, including: coordinating and facilitating the governance, implementation, operation, maintenance, and enhancement of sharing and integrated delivery of complete, accurate, and timely justice information; encouraging the creation of interfaces between justice agencies; establishing and implementing uniform data standards and protocols; and adopting strategic and tactical plans for to implement, maintain and enhance integrated justice efforts statewide. The statute clearly states that the responsibilities of the Board will in no way supercede those of the Department of Information Systems (DIS) or the authority of the involved court, state, or local agencies to maintain control over their own data.3

Regarding funding for justice information sharing, the Integrated Justice Information Board has responsibility to provide the Office of Financial Management with budgetary and policy review of state agency plans affecting the justice information network. They also have the authority to pursue, develop, and coordinate grants and other funding opportunities for state and local justice information projects that will expand or enhance the sharing and integrated delivery of statewide justice information and to recommend to the governor, the supreme court, and the legislature those legislative changes and appropriations needed to implement, maintain, and enhance a statewide justice information network and to assure the availability of complete, accurate, and timely justice information. However, there is no authorized appropriation included in § RCW 10.98 for Board activities or justice integration projects.

The Justice Information Network (JIN) program office is charged with implementing the vision and priorities set forth by the Integrated Justice Information Board. According to its Strategic Plan, JIN was created in 2003, around the time of the Board’s creation. Five of the Board’s largest participating agencies – the Administrative Office of the Courts, the Department of Information Systems, the Department of Corrections, the Washington State Police, and the Department of Law – agreed to fund the creation of the JIN program office at DIS to support the Integrated Justice Information Board’s governance structure4.

1 § RCW 10.98.2002 § RCW 10.98.2103 § RCW 10.98.2204 Justice Information Network Strategic Plan 2005-2007, Executive Summary, page 1.



Privacy and Security Policy in Washington

In 2000, Governor Gary Locke created Executive Order 00-03, which outlines state policy with regard to personal information about individuals that is collected and maintained by public sector agencies. The Executive Order calls for state agencies to minimize the collection, retention, and release of personal information by the state. It also prohibits the unauthorized sale of citizens’ personal information by state government and provides citizens with the opportunity to know what personal information about them the state holds, and to review and correct that information.5

Also in 2000, the DIS promulgated its Information Security Policy, which promotes an enterprise-wide view of information security, and encourages agencies that use information systems to support critical State business functions develop, implement, maintain, and test security processes, procedures, and practices to protect and safeguard voice, video, and computer data computing and telecommunications facilities -- including telephones, hardware, software, and personnel -- against security breaches. 6 The security policy provides general guidelines but leaves the implementation of these guidelines to the individual agencies.

SWOT Analysis

In many respects, the legislation and policies around integrated justice in Washington are proactive and provide strategic vision to justice agencies looking to implement interfaces to support justice information sharing. This vision – set by the Integrated Justice Information Board – has been translated to tangible, tactical goals and objectives by the JIN program office. These goals are supported by the DIS vision and infrastructure, which have helped provide guidance on such matters as security, privacy, and compliance with the statewide architecture and accepted technology and information sharing standards.

As the State of Washington moves from planning for integrated justice to actual implementation, there may be other issues that need to be addressed through statute, administrative procedure, or a memorandum of understanding among the Integrated Justice Information Board’s members. At the highest level, these issues concern funding/staffing, state/local issues, and maintenance/support-related issues. Each one of these will be addressed in turn below.

Funding/Staffing

While the legislative language authorizing the Integrated Justice Information Board allows it to seek grants and other funding requests to support justice information sharing, it does not authorize a specific funding level to support the justice information sharing project or the program management function of JIN, which is currently housed at DIS.

Currently, JIN is a one-person shop, with hopes of bringing on a few more staff members to help support the Board’s vision. However, since these individuals are DIS employees (whose positions are contributed to from other Board agencies), there needs to be some manner in which the Integrated Justice Information somehow exercises its role as the real authority over JIN while DIS is simply a place to administratively house the program.

To sustain an integrated justice effort, it is clear that funding for program management as well as system maintenance issues (see below) must be included as a component of the effort.

State/Local Issues

The legislative language authorizing the Integrated Justice Information Board only addresses interaction between state and local agencies in a few spots; namely, with the appointment of a county clerk, a county council member, a local police representative, a sheriff, a prosecutor, and a local-level appointee named by the Association of Washington Cities.

Garnering local level involvement in justice information sharing is incredibly difficult, given the number of disparate systems used among local law enforcement agencies alone. However, improving information sharing at the local level is key to ensuring quality data for state-level information sharing.

Currently, addressing local level integration projects in a proactive manner seems outside of the scope of the JIN

5 Executive Order 00-03: Public Records Privacy Protections, State of Washington, April 2000.6 Information Technology Security Policy, Washington State Department of Information Services, page 5.



initiative and the overall priorities. The role of local agencies in JIN and state-level integration will likely need to be addressed at some point.

Implementation/Operation Maintenance/Support

In several places in the Integrated Justice Information Board’s authorizing language, issues around system maintenance and support are addressed. For example, in § RCW 10.98.230 (c), the statute requires the Board to “coordinate and facilitate the governance, implementation, operation, maintenance, and enhancement of sharing and integrated delivery of complete, accurate, and timely justice information.” While the Board’s vision, documented in the JIN strategic plan, outlines broad goals and objectives as well as the governance for statewide justice information sharing, it is unclear at this point how JIN and the Board’s partner agencies will manage implementation, operation, and maintenance-related issues.

A question exists as to the exact role JIN will play in the implementation and operation of an integrated system. A well defined JIN architecture that the state and local agencies will be encouraged to follow is apparently a mandate. What has not yet been defined is what role JIN will play in implementing and operating the architecture. Very specific user requirements are emerging, such as guaranteed receipt and recover, which imply a strong central operation. Other requirements seem suggest a loosely coupled, non-intrusive architecture relying on open standards and understood services which each agency may expose and consume. Will JIN enforce and guarantee the requirements, build the architecture up to the door of local servers, assist beyond the door to the adapter level, or will JIN simply address architecture and policy issues. The options are not exclusive but the role will dictate governance and funding issues in the future. For JIN to guarantee that user requirements are met greatly increases the resource requirements for JIN as well as the ability to manage policy set by the Board.

An example of the need for further clarity around system maintenance and support is around adherence to State-level information security policies. The DIS security policy requires that agencies using information technology undertake several specific tasks, such as establishing its secure state business applications within the Washington State Digital Government framework, which requires that all parties interact with agencies through a common security architecture and authentication process. The policy also requires staff training on information security policies. At this point, it is unclear how the Board will implement such policies: currently, JIN is too small an office to coordinate that effort on behalf of participating agencies.

These maintenance, implementation, and support issues may be easily addressed in the current Board/JIN Program Office infrastructure by clarifying these responsibilities, identifying means to support them (through JIN or Board participating agencies) and formally establishing them through memoranda of understanding or other officially recognized documented agreements.



In summary, the following SWOT (strengths/weaknesses/opportunities/threats) analysis describes the strengths and some potential weaknesses of the legal and procedural environment for justice information sharing in Washington State:

Strengths

*Clear governance structure and role definition for state-level justice information sharing.

*Well-document and accepted strategic vision and plan for statewide information sharing

Weaknesses

*No funding authorization for program office or justice integration projects in existing statute

*Lack of clarity about roles and responsibilities for maintenance and support issues

Opportunities

*Early success of JIN could encourage continued support from key agencies to fund/expand the JIN Program Office

*Pilot projects could help build support among other key stakeholders for justice information sharing, which could bring more support for staff, funding projects, etc.

Threats

*Reliance for funding based on soliciting outside grants and individual appropriations. As such, future funding is subject to shifting conditions and priorities.

*Unclear how local agencies will participate in justice information sharing efforts.

JIN Program Office Recommendations

In summary, we have the following recommendations regarding the role of the JIN Program Office:

Define the user requirements JIN intends to satisfy beyond architecture;

Begin planning for information system support and maintenance and formalize those roles, responsibilities, and how they will be supported financially;

Utilize the Board in an active way politically to measure JIN’s ability to meet the user community’s expectations if they go beyond architecture standards and message routing.

Formalize (whether through a memorandum of understanding or legislative change) the JIN Program Office and adequate funding for its support and operations;

Begin planning for how to work with local justice agencies to support integrated justice systems.



APPENDIX D – ISSUES

The following items have been compiled during stakeholder interview and in the preparation and identification of the Customer requirements. These items will help set the agenda for the TAG (Technical Advisory Group) meetings in January and have been listed here to serve as a starting point for topics of discussion. Discussion of these issues may result in the establishment of new assumptions and constraints, requirements or open issues. There is no particular ordering to these issues, which have been roughly grouped by functional areas.

Issues that are left blank represent issues that are still being explored and that might yet impact the requirements. This impact will be reflected in the Requirements Baseline deliverable – which establishes the baseline for the design alternatives selection and solution design.

# Issue

I01 Guaranteed Delivery.

What is the specific Customer Requirement driving the need for a Technical Requirement covering guaranteed delivery of messages?

Guaranteed transactional (part of process orchestration) messaging solutions will likely require Agencies to host transaction software (adapter) for the servers at their location, forming a tightly-coupled, fault tolerant communication protocols which are in general proprietary to the integration software.

This requirement could be negated if JIN was limited to hosting SOAP query only transactions. This would limit the patterns necessary to be supported in the ‘Center of Excellence’ as well.

I02 SOP Version 1 tight coupling.

There is an impression that SOP exposed the AOC database structures and this contributes to the view that SOP was proprietary and was based on a tightly coupled protocol. This is perceived to contribute to a high fragility and unsustainable cost of ownership. Minor database changes must be insulated from affecting all those that rely on this information.

The initial assumption for the adapter to AOC was SQL/ODBC, however, screen scraping is being advised. Screen scraping is the least effective means of integrating application for numerous reasons. The ‘exposure’ issue must be resolved or the adapter will involve a screen scraping Technology requirement.

You can solve this by facading each partner's database(s) with web services. However, even for read-only applications (and definitely for transactional applications), it is dangerous to bypass the business logic encoded in applications.

E-Trip is considering utilizing this form of integration adapter since their requirements call for process orchestration with services brokering application logic as opposed to the initial scope of JIN CHQ project as a Request/Reply message pattern.

I03 Multiple application/data stores within the AOC Repository.

Initial assumption for this query/response type web services was to access a single repository via SQL/ODBC/JDBC. Multiple distinct applications have been discussed during the interviews: SCOMIS, DISCIS and JIS.

I04 Hybrid Security Model.

King County chose the Standard certs, through Transact Washington for user access to JILS. It was



# Issue

decided that this provided adequate authentication for law enforcement. They recommend the "Standard Roaming" since that does not tie the user to a specific PC and doesn't have a software footprint on the machine, making it easier to communicate as a requirement to multiple agencies. Costs run around $10.00 per year.

I05 Leveraging SOP.

1Dec received first set of sample source code artifacts from templar, being used to access suitability before purchase. Expectation from the beginning of this project was that the Query Agents contain the mapping logic to satisfy the functional requirements.

I06 Base solution on Justice XML.

Intermediate business format will present web services as easily consumable by other agency applications. Methods of leveraging Justice XML must permit explicit sub-schema creation without reference to the Master namespace. This centralized reference model does not fit the deployment in a location transparent deployment model whereas parsing and validation will require excessive network traffic unless the schema makes explicit definition of elements as opposed to referencing a central XML namespace.

I07 UDDI Automated Registry functionality vs. Manual.

While web services, SOAP and WSDL have achieved a great deal of global traction, UDDI is somewhat of a late comer. Case studies, vendor implementations, and documentation are available, but somewhat limited. As such, UDDI usage patterns may change significantly in the coming years. A great deal of effort can be spent on implementing UDDI for this project, to the benefit of only the more technologically advanced stakeholders in the state. The recommended approach may be to pilot UDDI with King and Yakima counties, but not to invest cycles in development of statewide enterprise level UDDI hosting and support.

I08 Emerging WS-xx standards.

Several project requirements mention the use of standards to accomplish specific business tasks, predominantly to ensure interoperability between heterogeneous systems. Unfortunately, within several domains such as reliability, security, and orchestration, standards are still in developmental phases and have yet to be ratified. Implementing a solution based on un-ratified standards injects a risk that there is a delta between the state of the standards at the point in time when the project goes live, and the standards’ ‘final’ state. It is generally felt, however, that this is the lesser of evils, when the alternatives include implementing vendor-specific or even project-specific mechanisms for achieving the business objectives.

I09 Design or Enhancement to agency applications that need to be compatible with JIN.

All parties have an inherent assumption that existing applications will not need to be enhanced or re-engineered in order to be integrated. Placing a web-services façade in front of existing applications essentially hides their specific implementations and insulates them from the need to change. An adapter will need to be created for each application, whether this adapter uses existing APIs, method calls, SQL commands, etc. Adapter development, however, occasionally confers remote agent hosting requirements. If, for example, a Biztalk adapter making SQL calls into the AOC repository were developed, this adapter would need to be hosted somewhere. The specific architectures of Biztalk and Sonic for adapter development, and their potential to be hosted on low-cost, lightweight, and/or open source platforms, is discussed in NFR 12.

I10 Third Party Database.

Includes security schema.

I11 Fully Functional Solution.

Not a requirement.



# Issue

I12 Support Open Protocols.

Both integration technologies being considered for JINDEX, Sonic and Biztalk, include support for SOAP, XML, and HTTPS. Support for emerging protocols, such as WSS, WS-Reliable Messaging will not be beyond beta implementation.

I13 Message Queue.

I14 User Interface.

Multiple interfaces already.

I15 Development Environment.

I16 Development Tools.

I17 Off the Shelf Adapters.

Both integration technologies being considered for JINDEX, Sonic and Biztalk, have available off the shelf adapters for major technologies, ERPs, and databases.

I18 Transformation Capabilities.

Both integration technologies being considered for JINDEX, Sonic and Biztalk, include inherent transformation capabilities.

I19 Leveraging LESA Functionality

A relatively late development in the requirements gathering phase indicates a great deal of potential to leverage code developed by LESA that interfaces with ACCESS. Similar to SOP, advantages of leveraging an existing codeset include decreased project risk and fewer overall interfaces into ACCESS (and hence components to maintain and support). Even more beneficial to the state than leveraging SOP, LESA’s code is not proprietary to a vendor. Unfortunately, the LESA avenue was not discovered until early December 2004, and hence requires further time for detailed analysis.


jin cach customer requirements report v26.doc

Documents