JIN Design

Document Sample
JIN Design Powered By Docstoc
					      Washington Justice Information Network
            Case and Criminal History (CACH)
                          Design Document

This document is supplied solely for historical background. The contents of the
document describe the original design for all aspects of the application. It is not
limited to just AOC, but contains information regarding specifications for the DIS
and WSP aspects of the application. It has not been updated since its inception.
It is not to be used for specification development without first consulting the
AOC PCH & CACH project manager.




                                                         Online Business Systems
                                                          One World Trade Center
                                                               121 SW Salmon St.
                                                          Portland, Oregon 97204
                                Washington JIN JINDEX Design Document




Document History
  Version          Date             Author                             Comments

1.0         March 6, 2005       Andy Ross        Document Creation
1.1         April 12, 2005      Bradley Falk     Initial Release
                   th
1.2         May 12 , 2005       Bradley Falk     Updates based on community feedback:
                                                         Clarified security and authentication for
                                                          services and networks on the JINDEX
                                                         Changed Requirement TR30
                                                         Added SQL Server storage details
                                                         Added a response-delay setting to the SOAP
                                                          envelope for orchestration processes (DF62,
                                                          DF63)
1.3         May 30th, 2005      Bradley Falk     Formally removed the PCN requirement (TR7) from
                                                 the design (DF54)
1.4         June 15, 2005       Bradley Falk     Clarified PCH Search Criteria
1.5         July 11, 2005       Bradley Falk             Added AFIS ID to the PCH Request data
                                                          dictionary
                                                         Relabeled DW query information to
                                                          supplement PCH queries, not CACH queries
                                                          since we are after License numbers
                                                         ACCESS parsers were restructured in
                                                          Appendix A to match the record types being
                                                          returned by the various queries. Thus, parsing
                                                          is done by record type, not query type. The
                                                          structure of the XML Documents being
                                                          returned does not change, but additional data
                                                          is more readily available.
                                                         AOC requires the WS-Secrity Password
                                                          element to be included with the
                                                          UsernameToken
                                                         Added Fault Code Dictionary to Web Services
                                                          Client Usage
1.6         August 5th          Bradley Falk             Updated sample response messages to ensure
                                                          namespace correctness
                                                         Revises the WSP Design to reflect the
                                                          customization capabilities for future queries
1.7         December 20, 2006   Steven Scott             Added Arrest Date to WSP Cach Response.
                                                         Split Charge Name cell in to two cells.
                                                         Changed Charge Name to Charge Offense
                                                          Code ID.



                                                ii
                 Washington JIN JINDEX Design Document

Version   Date       Author                            Comments

                                         Changed Charge Name to Charge Offense
                                          Level Text.
                                         Corrected Charge Offense Code ID node path.
                                         Changed the text Revised Code of Washington
                                          (RCW) to Charge Offence Code ID.
                                         Changed text Disposition Text to Charge
                                          Disposition Description Text.
                                         Changed text Disposition Text to Charge
                                          Disposition Condition.
                                         Removed Charge Date and associated
                                          information (i.e. ChargeFilingDate) from Data
                                          Dictionary - Cach Response/WSP Criminal
                                          Info because data only relates to AOC
                                          responses.
                                         Removed Other Identification Number from
                                          the Data Dictionary (PCH/CACH Requests)
                                          because it is not searchable, and it should be
                                          correctly referenced as an MNU indentifier in
                                          a WSP/ACCESS response.
                                         Changed Other Identification Number in Data
                                          Dictionary (PCH Requests) to Misc.
                                          Identifying Number (MNU).
                                         Changed Arresting Agency Name to
                                          Contributing Agency Name.
                                         Removed Originating Agency and associated
                                          GJXMD data identifiers from Criminal
                                          History Records.




                                iii
                                                       Washington JIN JINDEX Design Document

Table of Contents


INTRODUCTION ............................................................................................................................................1
   DOCUMENT PURPOSE ......................................................................................................................................1
   RELATED ARTIFACTS ......................................................................................................................................1
   DISTRIBUTION .................................................................................................................................................1
JINDEX SOLUTION ARCHITECTURE ......................................................................................................3
   JINDEX OVERVIEW .......................................................................................................................................3
   JINDEX CACH QUERIES ...............................................................................................................................4
     Data Source Providers ...............................................................................................................................4
     Web Services ..............................................................................................................................................5
     GJXDM Schemas .......................................................................................................................................5
     Logical Messaging Workflow .....................................................................................................................6
JINDEX BIZTALK SERVER .........................................................................................................................8
   JINDEX SERVER CONFIGURATION .................................................................................................................8
     Deployment ................................................................................................................................................8
     SQL Server 2000 High-Availability ...........................................................................................................9
     BizTalk 2004 High-Availability ..................................................................................................................9
     Databases & Storage................................................................................................................................ 10
     Pipeline ....................................................................................................................................................10
     Security.....................................................................................................................................................11
     Access Control Lists .................................................................................................................................11
   SERVICES ......................................................................................................................................................12
     Auditing ....................................................................................................................................................12
     Logging ....................................................................................................................................................13
     Monitoring ...............................................................................................................................................14
     Notifications .............................................................................................................................................15
   WEB SERVICES ORCHESTRATION ..................................................................................................................15
     Message Correlation ................................................................................................................................ 18
JUSTICE XML...............................................................................................................................................22
   APPLICATION MODELS ..................................................................................................................................22
     PCH Request ............................................................................................................................................22
   DATA DICTIONARY .......................................................................................................................................25
   SAMPLE MESSAGES .......................................................................................................................................31
   SOAP HEADERS ...........................................................................................................................................38
     WS-Security ..............................................................................................................................................39
     WS-Addressing .........................................................................................................................................39
     WS-Coordination......................................................................................................................................40
     WS-I ..........................................................................................................................................................41
AOC ADAPTER.............................................................................................................................................43
   GENERAL DESCRIPTION ................................................................................................................................ 43
   SOLUTION ARCHITECTURE ............................................................................................................................43
   DIAGRAMS ....................................................................................................................................................45
     Architecture ..............................................................................................................................................45
     Sequence / Orchestration .........................................................................................................................45
   CLASS DIAGRAM ...........................................................................................................................................47
     WS-Address ..............................................................................................................................................48
     WS-Security ..............................................................................................................................................48



                                                                                      iv
                                                       Washington JIN JINDEX Design Document

   COORDINATING DETAILS ............................................................................................................................... 49
     Logging ....................................................................................................................................................49
   FAULTS .........................................................................................................................................................50
WSP ACCESS SWITCH ADAPTER ...........................................................................................................51
   GENERAL DESCRIPTION ................................................................................................................................ 51
   SUMMARY OFFENDER PROFILE INTEGRATION ............................................................................................... 52
     Overview ..................................................................................................................................................52
     Security.....................................................................................................................................................52
     Logging ....................................................................................................................................................54
   CLASS DIAGRAM ...........................................................................................................................................55
   FAULTS .........................................................................................................................................................55
   SERIALIZATION ..............................................................................................................................................56
   DEPLOYMENT................................................................................................................................................57
   ACCESS QUERY TRANSFORMATIONS ..........................................................................................................57
CRIMINAL HISTORY TEST CLIENT ......................................................................................................59
   POSSIBLE CRIMINAL HISTORY QUERY...........................................................................................................59
   POSSIBLE CRIMINAL HISTORY RESULTS ........................................................................................................60
   CASE AND CRIMINAL HISTORY DETAIL .........................................................................................................62
     Case History Results ................................................................................................................................ 62
     Criminal History Results ..........................................................................................................................63
     Protection Orders.....................................................................................................................................64
     Warrants ...................................................................................................................................................64
   ARCHITECTURE .............................................................................................................................................65
     Topology...................................................................................................................................................66
     Servlet Sequence Diagram .......................................................................................................................67
     Web Service Sequence Diagram...............................................................................................................68
     Class Diagram .........................................................................................................................................69
   DEPLOYMENT................................................................................................................................................69
WEB SERVICE CLIENTS ...........................................................................................................................71
   GENERAL DESCRIPTION ................................................................................................................................ 71
   WEB SERVICE META-DATA ..........................................................................................................................71
   FAULTS .........................................................................................................................................................73
   FAULT CODE DATA DICTIONARY ..................................................................................................................73
SECURITY .....................................................................................................................................................75
   CERTIFICATES ...............................................................................................................................................76
     Transact Washington................................................................................................................................ 76
     JIN Responsibility ....................................................................................................................................77
APPENDIX A – ACCESS PARSER MAPPINGS .......................................................................................78
   POSSIBLE CRIMINAL HISTORY RECORDS .......................................................................................................78
     NCIC Protection Order Record ...............................................................................................................78
     NCIC Wanted Person Record ...................................................................................................................79
     WACIC Protection Order Record ............................................................................................................81
     WACIC Warrant .......................................................................................................................................82
     WACIC Possible Criminal History Record ..............................................................................................84
     DOL Record .............................................................................................................................................85
     NCIC Interstate Criminal History Record ................................................................................................ 86
   CRIMINAL HISTORY RECORDS .......................................................................................................................88
     Washington State Criminal History Record .............................................................................................89
     NCIC Protection Order Record ...............................................................................................................93



                                                                                      v
                                                    Washington JIN JINDEX Design Document

      NCIC Wanted Person Record ...................................................................................................................95
      WACIC Protection Order Record ............................................................................................................96
      WACIC Warrant .......................................................................................................................................99
      WACIC Possible Criminal History Record ............................................................................................100
APPENDIX B – WS-I BASIC PROFILE REQUIREMENTS .................................................................103

APPENDIX C – CACH SCHEMA .............................................................................................................116
   CACH SCHEMA ..........................................................................................................................................116
APPENDIX D – DESIGN FEATURE TRACEABILITY .........................................................................117

APPENDIX E – GLOSSARY OF TERMS ................................................................................................ 123




                                                                                 vi
                                      Washington JIN CACH Queries Design

INTRODUCTION


DOCUMENT PURPOSE

      This document expands upon the JINDEX and CACH requirements outlined in the approved Customer
      Requirements Report and Requirements Baseline, and options identified in the Alternatives Document.
      Follow-up stakeholder interviews and Technical Advisory Group (TAG) meetings have clarified
      delivery expectations for the integration framework and the specific web service queries. This
      document outlines the design for CACH web services, from the standpoint of the JINDEX hub
      BizTalk server, adapters for the Administrative office of the Courts (AOC) and Washington State
      Patrol (WSP), and the consuming agencies, King and Yakima counties. While requirements documents
      focused on the “what”, this Design Document will focus on the “how”. Readers are assumed to have an
      understanding of the technologies involved, as well as the ratified decisions made for the JIN CACH
      project in conjunction with the JIN Technical Advisory Group (TAG).
      Technical Requirements have been migrated from the Requirements document in their entirety to this
      document forming the Traceability section. All technical requirements are traceable to Design Features
      in this document. The requirements in this document supercedes the previous documents. If the
      original requirement is no longer required or required clarification, this is noted with additional
      comments.

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 used on the
                                              project.
JINDEX CACH Project Charter V12               Approved Project Charter.
JINDEX CACH Customer Requirements             Approved Customer Requirements Report.
Report V29
JINDEX CACH Requirements Baseline V11         Approved Requirements Baseline Document.
JINDEX CACH Alternatives Document V4          Approved Alternatives Document.

DISTRIBUTION

Brian LeDuc                  State of Washington – JIN Program Director
David Neufeld                Online Business Systems Ltd. – Delivery Manager
Bradley Falk                 Online Business Systems Ltd. – Solutions Architect



Version 1.6Error! Bookmark not defined.                                                                        Page 1
                                   Washington JIN CACH Queries Design




Version 1.6Error! Bookmark not defined.                                 Page 2
                                      Washington JIN CACH Queries Design

JINDEX SOLUTION ARCHITECTURE


JINDEX OVERVIEW



      The JINDEX is a message broker cluster centrally located at the Department if Information Services
      (DIS) and it is the mechanism that facilitates and simplifies communication between agencies using
      web services. It is the middleware used by the State of Washington providing the messaging
      infrastructure connecting all state level, justice applications.




      In the initial implementation, JINDEX serves as the information broker for the various counties,
      including, but not limited to King County and Yakima County. These counties will be able to issue
      requests for Possible Criminal History and the Case and Criminal History information, known as the
      PCH and CACH Query Services.
      These Query Services interface with two data repositories: the Administrative Office of the Courts
      (AOC) and the Washington State Patrol (WSP). Each query will be implemented using web services
      and they will be invoked in a server-to-server or application-to-application context. In other words,
      there will be no user interface component implemented for the county applications.
      The Possible Criminal History query (previously known as the ID by Possible Match Query) allows a
      Criminal Justice Practitioner to search for people with criminal histories based on a suspects
      characteristic or personal attributes. The Case and Criminal History provides detail on a suspect with
      data from Court and Criminal Record data sources. There are many sources of data, but the AOC and
      WSP agencies act as data source providers and any request for data is delegated to these agencies.
      An example of a web service consumer includes Yakima County, which has developed an application
      called “ProTrack” for its user community. When a Yakima user wishes to access PCH or CACH data,
      the ProTrack server would initiate an HTTP/S Web Services request to the JINDEX servers. The
      JINDEX servers would then split the initial request, forwarding two separate requests to the AOC and
      WSP. While each HTTP/S request will involve a synchronous response identifying successful receipt
      of a request, the actual query response, within the business context, will be posted to the query
      originator asynchronously.


Version 1.6Error! Bookmark not defined.                                                                        Page 3
                                        Washington JIN CACH Queries Design

JINDEX CACH QUERIES


Data Source Providers
        The Administrative Office of the Courts and the Washington State Patrol are presently the two
        supporting agencies of the CACH Queries. Each agency has a variety of systems that act as sources of
        data.
Query                       Agency      Data                   Source System
                                        Requirements

Possible Criminal           AOC         Criminal History       Case Management System
History
Possible Criminal           WSP         Criminal History       ACCESS – QWH Query
History
Possible Criminal           WSP         Drivers License        ACCESS – DW Query
History
Case & Criminal History     AOC         Criminal History       Case Management System
Case & Criminal History     AOC         Case History           Case Management System
Case & Criminal History     WSP         Criminal History       ACCESS – QR Query
Case & Criminal History     WSP         Protection Order       ACCESS – QWH Query
Case & Criminal History     WSP         Warrants               ACCESS – QWH Query
Case & Criminal History     WSP         Offender               ACCESS – QR Query


Query                       Agency                        Query                     Data Provider
PCHRequest                  AOC                           PCHRequest                JIS or AOC
PCHRequest                  WSP                           QWH                       NCIC
PCHRequest                  WSP                           QWH                       WWCIC
PCHRequest                  WSP                           DW                        DOL
CACHRequest                 AOC                           CACHRequest               JIS or AOC
CACHRequest                 WSP                           QR                        WWCIC
CACHRequest                 WSP                           QWH                       NCIC
CACHRequest                 WSP                           QWH                       WWCIC
CACHRequest                 WSP                           DW                        DOL




    #                                                     Design Feature
   DF1      The WSP Data Sources is abstracted with a query generator. This query service accepts incoming XML
            and can generated the ACCESS query that will be executed. This can be any query, but parsing the
            results is handled for the QWH, QR and DW queries.


Version 1.6Error! Bookmark not defined.                                                                        Page 4
                                        Washington JIN CACH Queries Design

   #                                                     Design Feature
  DF2      Possible Criminal History Query will generate a QWH Query for the WSP web services
  DF3      Case and Criminal History Query will generate QR, QWH, QR and DW queries against the WSP web
           services
  DF4      The AOC Data Sources is also abstracted with the web service. The web service is bound to data façade
           layers used internally at AOC. The façade used in this design accesses the Case Management System
  DF5      All network traffic will be over encrypted channels. VPN connectivity will be established between each
           client and server.
  DF6      SSL will be used for authentication. This is for HTTP/S web services



Web Services
       Web Services is effectively the collection of Internet enabled applications that exchange information
       without knowledge of the underlying technologies. It is anticipated that all or most applications that
       use the JINDEX will use web services to add functionality and increase information sharing.
       Messages are XML documents, wrapped with a SOAP envelope. SOAP is the de-facto web service
       standard for wrapping XML documents. It is important because most web service standards such as
       WS-Security and WS-Addressing require SOAP.
       The SOAP body is the XML document we are exchanging. The XML document is a sub set of the
       GJDXM 3.0.2 schemas to incorporate all the required data elements identified as requirements. The
       schema‟s have been provided to Online Business Systems and to the JIN project from a third-party.


   #                                                     Design Feature
  DF7      Web Services will be SOAP 1.2 based to facilitate the use of current and emerging web service
           standards.


GJXDM Schemas
       GJXDM is the Global Justice XML Data Mode and is currently at version 3.0.2. This collection of
       XML schemas was used to create the XML subsets used to invoke JINDEX web services. The feature
       of these schemas is that it validates against the GJDXM at a component level and includes the Warrant
       and Protection Order information.
       However, these schemas have the following limitations:
               This is not the rap sheet schema used which was developed by several states in the Justice
                Integration field
                    o    This limited the interoperability with those states as the current version of the
                         schemes must be transformed to the rap sheets for compatibility
                    o    The rap sheet is the easier approach since it already includes all the required data
                         elements with the exception of the Warrant and Protection Order information.
               The XML uses „.‟ A character in the element names that is known to cause issues with
                BizTalk artifacts
               The number of namespaces has increased and includes repeated references to the GJXDM

Version 1.6Error! Bookmark not defined.                                                                         Page 5
                                        Washington JIN CACH Queries Design

                namespace which can lead to future versioning conflicts
               It lacked the required cardinality for Subjects. Results were limited to a single Subject when
                many Subjects could be returned in a result
               Several required fields were absent including Booking information and several Person ID
                attributes and elements
       As a result, the current schemas have been further altered to include the required missing fields and
       altered the cardinality to allow multiple instances of the same data elements.
       Please refer to Appendix C for the schema subset artifacts including the data dictionary and
       component diagram.
   #                                                    Design Feature
  DF8      The SOAP message bodies will be modeled using the GJXDM 3.0.2 namespace.



Logical Messaging Workflow
       Each system (the AOC and WSP, with ACCESS acting as a façade for multiple separate state and
       national-level systems) responds asynchronously to the query, posting their results to the JINDEX
       BizTalk server. Within an orchestrated service with a defined time-to-live of 10 seconds, the JINDEX
       BizTalk server aggregates the multiple responses into a single, consolidated XML message, and posts
       this single message back to the originating agency.
       Multiple source systems are being queried and may have vastly different response times, systems may
       respond after the JINDEX orchestration has expired and the consolidated response has already been
       posted back to the query originator. In these cases, the latecomer response should still be forwarded
       back to the query originator, even though it will be in a separate message. The following sequence
       diagram illustrates this process:




Version 1.6Error! Bookmark not defined.                                                                          Page 6
                                       Washington JIN CACH Queries Design




       For all ACCESS queries, responses from the switch will be captured using the existing Summary
       Offender Profile application. Responses will be parsed and XML messages will be dispatched back to
       the JINDEX for consolidation.


   #                                                    Design Feature
  DF9      Messages are asynchronous to support the use of long running transactions and queries

  DF10     Messages that have responded after the aggregation are still to be forwarded on after
  DF11     The WSP web services wrap the SOP application for the interaction with the ACCESS switch. SOP is
           responsible for the TCP communication to the ACCESS switch
  DF12     The BizTalk service is responsible for aggregating the results from the various internal justice agencies
  DF13     JINDEX will dispatch web service requests to both the AOC and to the WSP web services
  DF14     The aggregation cycle will last 10 seconds. After that, messages will simply flow through




Version 1.6Error! Bookmark not defined.                                                                        Page 7
                                       Washington JIN CACH Queries Design

JINDEX BIZTALK SERVER


JINDEX SERVER CONFIGURATION


Deployment




       Representatives from Microsoft have indicated that this deployment will satisfy the following
       requirements:
               99.9% availability (NFR7)
               Automatic Failover (NFR8)
               Message Throughput (NFR14)
       It should be noted that the query services are estimated to generate 0.4 transactions per second by
       themselves, which this configuration should “easily” be able to handle. This configuration may not be
       able to handle 15 transactions per second (NFR1, based on 40 new web services), but should be able to
       accommodate growth over at least the 12-month period following implementation of the query services
       (if not longer). Both Microsoft and Online recommend JINDEX administrators monitor server
       performance (CPU usage and web services response time) by using Microsoft‟s Health and Activity
       Tracking (HAT) tool and track results over time such that the JIN Program Office can be made aware
       of when additional hardware resources should be added to the configuration.




   #                                                   Design Feature
  DF15     BizTalk brokers will exist in a load-balanced and high-availability (Active-Active) configuration


Version 1.6Error! Bookmark not defined.                                                                        Page 8
                                        Washington JIN CACH Queries Design

   #                                                     Design Feature
  DF16     SQL Servers (BizTalk Data Stores) will exist in a cluster configuration

  DF17     Achieve 99.9% availability

  DF18     Automatic failover

  DF19     Achieve message throughput rates that satisfy the expected 0.4 messages/second



SQL Server 2000 High-Availability
       BizTalk 2004 relies on SQL Server 2000 functionality for high availability because instances of
       BizTalk server maintain state and messages in the SQL Server databases. The receiving host persists
       messages to the data store for the orchestration services to pick up. Once the orchestration service has
       worked on the message it is persisted to the sending host. Finally, the sending host can transmit the
       message.
       The SQL Server cluster must be up and running before the BizTalk 2004 server instance can be
       installed in order for clustering to be functional.
       The two BizTalk server instances will use the same storage (i.e. SQL Server cluster), referred to as a
       SAN or Shared Area Network. All inbound and outbound messages will be persisted to the shared
       drive, such that if the active BizTalk server‟s hardware fails, the other BizTalk server can transition
       from passive to active with no loss of data. If an active server encounters an error or fails, the passive
       server assumes the primary active role. The database instance fails and restores connections to the new
       active instance.
       For additional information on installing and configuring the SQL Server 2000 cluster, please refer to
       the following for SQL Server 2000 Failover Clustering documentation.
       The SQL Server Cluster will house one BizTalk 2004 service, the Enterprise Single Sign-On or the
       Secret Master service. This is required to achieve high-availability on the BizTalk load-balanced
       deployment.

BizTalk 2004 High-Availability
                                                                               JINDEX BizTalk Servers will
                                                                               be deployed as an Active-Active
                                                                               using Microsoft Windows 2003
                                                                               Enterprise Server. BizTalk 2004
                                                                               will be deployed to each server
                                                                               instance, but the Windows
                                                                               server will not be clustered.
                                                                               Failover is achieved by having
                                                                               each BizTalk Host (a BizTalk
                                                                               host is an instance of either the
                                                                               Send, Receive or Process
                                                                               service) run on each server
                                                                               instance.
                                                                              BizTalk has a service called
                                                                              ESSO or the Enterprise Single
                                                                              Sign-On service. This service
       must be made fault-tolerance for BizTalk 2004 to be fault tolerance. This can be accomplished by
       installing this service on the SQL Server 2000 cluster, not on the BizTalk server instances. The SSO

Version 1.6Error! Bookmark not defined.                                                                             Page 9
                                       Washington JIN CACH Queries Design

      service is also known as the Master Secret service.
      This provides high availability in Orchestration scenarios as well as sending and receiving processes.
      The SQL Server instances on which BizTalk depends will be deployed as an Active-Passive cluster.
      IIS supports clustering and the Active-Passive configuration and requires careful consideration for
      achieving high-availability for HTTP and Web Services adapters. The HTTP receive adapter in
      BizTalk Server 2004 is an Internet Server API (ISAPI). When a client posts a message to the BizTalk
      server through the HTTP protocol, the message typically arrives at a specific URL on a BizTalk Server
      computer with Internet Information Services (IIS) installed. You create a host instance in BizTalk
      Server with a receive location that subscribes to this URL. BizTalk Server 2004 provides high
      availability for the HTTP receive adapter by letting you create multiple host instances of the same
      receive host. These host instances subscribe to a specific URL that can be a shared to distribute
      incoming messages across multiple receives hosts. These hosts function to serve the virtual IP address
      of the cluster, so that if one cluster member fails, others can still serve this IP address.
      Detailed instructions on configuring clustered and high-availability solutions for BizTalk can be found
      in the following link:
           Microsoft MSDN BizTalk High Availability

Databases & Storage
      To accommodate all transactional data and supporting information that will be persisted on the SQL
      Server‟s shared storage space, sufficient storage space must be available.
      There are two databases – the BizTalk data store and the application data store. The BizTalk instance
      must be large enough to persist 35,000 CACH and PCH messages. This is given the expectation that
      there will be a sustained message rate of 0.4 messages/second. Since message sizes are expected to be
      5k (5,120 bytes) on average, the table page (block) size should be 8KB. This results in 280,000KB of
      storage required – just for the messages. As this represents a very small data store, it would be optimal
      to create a larger data store to maintain search indexes and other SQL Server specific data, as well as
      other BizTalk 2004 related meta data. Larger database sizes improve performance as less effort is
      spent organizing and optimizing the store. The BizTalk database should have a physical size of
      512MB to have optimal performance and adequate room for all BizTalk state.
      The application database will be used to persist audit and test client information. This database will be
      larger as data will not be removed and there will be a high volume of data being inserted. The audit
      logs will not only be used for the PCH and CACH queries, it will be used for all future web services.
      Every web service invocation will result in two new rows in the logs – one for the incoming message
      and one for the outgoing message. It is anticipated that each row be no larger than 512 bytes, which
      would require 35KB per day for the audits or 15MB per year. An addition 5MB would be required per
      year for the indexes used to search the audits. Thus, there will be 20MB of audit data per interface per
      year. As it is anticipated that there will be 10 new interfaces added by 2006, there will be 200MB of
      audit data.

Pipeline
      BizTalk Server works mainly with the XML document format. A pipeline prepares a message for
      processing by the server after being received by an adapter or it prepares a message for sending after
      being processed by the server.
      Pipelines commonly perform:
           • Data normalization from various formats to XML
           • Data transformation from XML to various formats


Version 1.6Error! Bookmark not defined.                                                                           Page 10
                                        Washington JIN CACH Queries Design

           • Document decryption and encryption, as per the WS-Security specification
           • Document signing and digital signature verification, as per the WS-Security specification
        In the implementation of the CACH Queries, a receiving custom pipeline will be responsible for
        auditing the receipt of the incoming message and the validation of required elements. The entire
        message will not be validate against the application schemas given the size of the dependencies on the
        GXDM and the possessing memory and time required for the validation.
        The incoming messages SOAP Headers must be validated as well. The following is assumed to be
        relative to the SOAP header element found at SOAP:Envelope/SOAP:Header
XPath                                                                       Description
/wsse:Security/wsse:UsernameToken/@wsu:Id=”ORI”                             ID Attribute with the value ORI
/wsse:Security/wsse:UsernameToken/@wsu:Id=”ORI”/wsse:Username               The ORI Value
/wsa:MessageID                                                              Message Identifier
/wsa:ReplyTo                                                                ReplyTo
/wsa:To                                                                     Destination
/wsa:Action                                                                 Web service to be invoked
/wsa:RelatesTo                                                              Only required when this is a
                                                                            response


    #                                                   Design Feature
  DF20      The Date/Time, ORI, Message ID, Reply To, To Action and RelatesTo will all be audited



Security
    #                                                   Design Feature
  DF21      Sever X509 Certificates will be used to authenticate client connections.
             Client connections and message bodies will not be encrypted unless required by a future web service
            consumer. X509 is NOT to be implemented
  DF22      The JINDEX is responsible for procuring a server side certificate that will be used to authenticate all
            clients.


Access Control Lists
        In order to achieve adequate security for the JINDEX BizTalk environment, roles must be defined with
        commensurate Access Control Lists (ACL) and permissions. The following roles should be
        implemented in BizTalk:
        Role/ACL                         Description                                Permissions
JINDEX Administrators        DIS support personnel responsible      Use Health and Activity Monitoring Tool
                             for monitoring the health of           (HAT)
                             JINDEX-hosted services, as well as
                             debugging errors.
JINDEX Managers              JIN Program Director and other         Use HAT, but removed from

Version 1.6Error! Bookmark not defined.                                                                          Page 11
                                           Washington JIN CACH Queries Design

          Role/ACL                          Description                                Permissions
                               senior DIS personnel who may wish        HM_EVENT_WRITER and
                               to periodically run reports or           BAM_EVENT_WRITER SQL Server
                               monitor JINDEX activity and              roles in the Tracking database.
                               performance
Agency Administrators          Agency support personnel who will
                               liaise with JINDEX Administrators
                               to debug errors on behalf of their
                               agency user communities.



      #                                                    Design Feature
     DF23     Access Control lists will be used to limit administrative access to users on the BizTalk server,
              specifically to access the Event Log and HAT and BAM tools.



SERVICES


Auditing
          It is required that all incoming messages be audited and this will be performed by the receiving
          pipeline. For each message, the following fields are to be recorded:
Field                    Description
Date/Time                The date and time of the incoming message. The field must include the following:
                         Day, Month, Year, Hour (24), Minute, Second, Millisecond, Time zone
Service or Action        This specifies what web service is used for the processing of the message. For these
                         exchanges, it could be one of the following: pch-request, pch-response, cach-request or
                         cach-response or the wsa:Action value
From                     The agency code of the agency invoking the web service. Corresponds to the
                         wsa:ReplyTo SOAP header
ORI                      The originating identifier of the message submitter or the wss:UsernameToken value
To                       The destination address or wsa:To
MessageID                The message identifier or wsa:MessageID
          Auditing will be recorded on the BizTalk SQL Server, but under a new database. This database, while
          part of the same BizTalk SQL Server cluster is logically separated from the BizTalk instances,
          including the tracking database. This database is technically intended to support external applications,
          auditing being an external application to BizTalk:
                  New User/Password
                  New Schema
                  Single Table
          The table will contain the following columns:
Field                 Type                   Description


Version 1.6Error! Bookmark not defined.                                                                              Page 12
                                            Washington JIN CACH Queries Design

Field                    Type                  Description
AUDIT_ID                 IDENTITY (PK)         Primary Key
RECEIVED_TS              DATE/TIME             The time and date the message was received
SERVICE_NM               String(40)            The Service instance
FROM                     String(40)            The implementing service host
TO                       String(40)            The target web service
ORI                      String(10)            The Originating Agency Identifier
MessageID                String(128)           Unique Identifier for the Source system


      #                                                      Design Feature
  DF24        The JINDEX will provide basic centralized auditing records. This construct can be reused for future
              web service interfaces


Logging
          Logging is the process of providing application related information. This information can be used to
          view application processes for processing knowledge or for debugging error situations. Since most
                                                                                                               ar eneeded t see t ia c p.
                                                                                                                   Q ncom o and s
                                                                                                                      ui m e™
                                                                                                                       k
                                                                                                              TI FF( U cTi pr essed) h pi t ur e
                                                                                                                                     decom r essor


          processes will be expressed as orchestrations, logging should be invoked as an Expression Shape (                   )
          in the designer. From the expression, calls to the logger façade would log any of the following
          information:
Type                                   Description
ApplicationName                        The name of the process that describes the log context
Level                                  Severity code. Once of INFO, DEBUG, ERROR
Description                            The note to display
Error                                  Stack trace for error messages
LogName                                The log instance name. For example – CHQ
          It is recommended that the implementation use Log4net for all application logging. There are several
          advantages over Microsoft‟s Enterprise Instrumentation Framework (EIF), which is being replaced
          with the Enterprise Template Library. EIF is not intended for logging directly and because it involves
          remoting, it would degrade performance of an orchestration.
          Log4net is a well-known open-source tool that provides simple configuration based logging. It allows
          the system to change logging properties without modifying or interrupting orchestration processes. By
          default, the logger should use the System Event Log. This destination allows an administrator to use
          the Event Viewer system tool to view, sort and search the logs using a well-known tool that is easy to
          use.
          Use Log4Net – To abstract the logging to multiple sources without affecting runtime logging. Initial
          logging though should be to the Windows Event Log so it can be viewed with the Event Viewer. Using
          the logging framework, a custom assembly must be created to overcome the following limitations:
                           Assembly-attribute-driven configuration won‟t work because BizTalk 2004 does not
                            appear to support the addition of custom attributes for BizTalk assemblies. (And even
                            if it did, this method would pose issues for BizTalk environments.)

Version 1.6Error! Bookmark not defined.                                                                                          Page 13
                                          Washington JIN CACH Queries Design

                        Using the log4net configuration classes for configuration is problematic because there
                         is no clear point at which to make the call. (How does as an orchestration know if it is
                         “first” and should initialize. How does it know at any point in an orchestration whether
                         the BizTalk service has been recently recycled, losing the log4net
                         configuration) Moreover, there is not a good way to identify where the configuration
                         file should be located.
                        ILog-derived classes (log4net loggers) are not serializable “out-of-the-box”, making it
                         difficult to use them in an orchestration setting.
                        Log4net context-storage mechanisms are thread-relative, which isn‟t workable for
                         orchestrations, since orchestrations often a) dehydrate and then re-hydrate on a
                         different thread and b) make use of parallel branches. We‟d like to correctly associate
                         context such as the orchestration instance ID on a logger that is scoped to an
                         orchestration.
         See EIF vs Log4net for details and examples on creating the Logging façade for BizTalk.
         The Log4net also serves as a useful interface for invoking notifications. A new appender would be
         created that will be used to invoke SMTP or email notifications. The configuration file for this
         appender will be include with each orchestration service assembly. The following properties represent
         notification emails:
Property                              Description
To                                    <<List of Administrators>>
Subject                               Error Message
From                                  Process ID
Body                                  Brief Description, the incoming SOAP message and any error details


         Notifications must be distributed once and only once per error cycle. An error cycle starts with the first
         error and ends with the first recovery or successful iteration. The orchestrations must maintain a static
         variable or record in a database that ensures that emails are not repeatedly dispatched during an error
         cycle.


     #                                                     Design Feature
     DF25    Log4Net will be used for all logging and custom notifications

     DF26    Email will be used for error and critical error notifications

     DF27    Alerts will be sent once and only once per error cycle



Monitoring
         The Windows Management Instrumentation (WMI) is the low-level event manager. It is responsible
         for issuing windows events for various system level events such as connectivity issues, resource issues
         and fail over conditions.
         WMI will be used by the notification components to exposing critical events to the JINDEX
         administrators. The JINDEX administrators are not responsible for agency issues other than network
         level connectivity to and from the JINDEX. These systems are not to be monitored.


Version 1.6Error! Bookmark not defined.                                                                             Page 14
                                        Washington JIN CACH Queries Design



Notifications
       For the JINDEX, notifications and alerts are to be used interchangeably. Notifications are to be
       classified based on what services are being executed. For the CACH project, there are only two types,
       SYSTEM and CACH. System notifications are messages to be sent to the JINDEX administrators that
       alerts them of the possible events:
               Fail Over: A broker instance has failed
               Message Throttling: When the system cannot keep up with demand, the system will start
                throttling messages. This leads to slower processing and often represents scaling issues or
                system issues
               Memory Utilization: When the system starts running low on system resources, clients may be
                denied access.
               Disk Space
       System notifications are generated automatically by BizTalk and Windows 2003 Server. These classes
       of notifications are logged to the Event Log by default.
       CACH errors are problems that occur as part of a custom process – these exceptions must be escalated
       to the system administrator in a configurable manner. Customizable notifications are managed by the
       logging framework. This allows the administrator to manage logs and notifications at the same time ad
       control the conditions that create a notification.


   #                                                      Design Feature
  DF28     WMI will be used to a limited extent – only those events generated natively by BizTalk will be
           captured. They will be captured and viewable in the Windows Event Viewer by the BizTalk
           Administrative staff
  DF29     Notifications must be sent once and only once

  DF30     Failure to post to an end-point or send ports will result in a critical error condition. These will result in
           an alert to the JINDEX administrator. This will be implemented as part of the orchestration


       Custom notifications will use the Log4net framework as described in the Logging section.

WEB SERVICES ORCHESTRATION

       The web services orchestration process is responsible for splitting requests to various agencies and
       aggregating responses from the same agencies and forwarding the responses to the initial sender. To
       accomplish this task there are really three orchestrations that work together – asynchronously. It is
       preferred to have several smaller orchestrations as opposed to a single larger orchestration for the
       following reasons:
           1.   Breaking a large orchestration into several smaller ones utilizes memory more efficiently.
                While the large orchestration can be dehydrated – or removed from memory and its state
                persisted to the database until it is brought back, this process of hydration has a performance
                impact.
           2.   In terms of scalability – smaller orchestrations scale better. A smaller process to handle a
                transaction can be created and executed faster than a larger one.


Version 1.6Error! Bookmark not defined.                                                                            Page 15
                                       Washington JIN CACH Queries Design

          3.   Smaller processes are easier to debug. Using a custom application message store, versus
               solely relying on the BizTalk Message Inbox, developers have access to the full incoming
               XML message during the runtime process without incurring the overhead of the BizTalk
               Business Activity Monitoring and with full visibility of the message contents as opposed to
               the HAT (Health Activity Tracking) tool.
          4.   Finally, it is possible to make incremental alterations to the orchestrations without taking
               down the entire process. This allows the administrator to alter security policies to a single
               server instance without taking the instance down

Solution Components
      The Criminal History Queries are built as a series of asynchronous processes are can be grouped into
      the following orchestrations:
          1.   Dispatch incoming requests to the various Data Providing Agencies, such as the AOC and the
               WSP
          2.   Receive and Acknowledge response message from the web service consumers
          3.   Message correlation, aggregation and then dispatching the aggregate back to a ReplyTo web
               service
          4.   Purging of expired messages




Version 1.6Error! Bookmark not defined.                                                                        Page 16
                                       Washington JIN CACH Queries Design

Solution Sequence




Step     Description
    1.   An incoming message is received from an agencies application server. While a pch:PCHRequest
         message is represented, the sequence is the same for the cach:CACHRequest. Refer to the sample
         request messages in this document and any other sample request messages.
    2.   An incoming request message is validated, a log entry is created and then the message is persisted to
         the application message store
    3.   Valid request messages are forwarded to the external web service consumers – the agencies (AOC
         and WSP) that provide data in the form of a response message to the JINDEX
    4.   If at least one of the consuming web services acknowledges the request, an Acknowledgement
         message is returned back to the originating web service client. This is part of the same web service
         call that initiated this process. However, if all web service consumers Fault on the message or if the
         incoming message cannot be validated, a fault message is returned. Please review the Fault message
         handling sections
    5.   Once Requests have been made on the web service consumers, the JINDEX waits for the Response
         messages. The messages must also be validated, audited and logged, just as the incoming request

Version 1.6Error! Bookmark not defined.                                                                           Page 17
                                          Washington JIN CACH Queries Design

Step       Description
           message is. Once the message has been validated, it must be persisted to the application message
           store
    6.     Valid messages are to result in an Acknowledgment response, while invalid messages (validation
           failures) will result in Fault messages, just as in step 4
    7.     The final process is the aggregation of the response messages. In step 5 response messages were
           persisted to the application message store and here, the SQL adapter retrieves all new messages from
           the message store.
    8.     When the SQL Adapter is invoked, new messages that are to be dispatched to the originating agency
           are grouped and correlated. There will be a single message per agency, per unique message
           identifier containing all new response messages.
    9.     It is the responsibility of the agency to accept the response message or reject it with a fault
           messages. Accepted messages are to be marked as sent so they are not dispatched again.




   #                                                       Design Feature
  DF31       The PCH and CACH orchestration processes are responsible for splitting or delegating incoming
             requests to the AOC and WSP
  DF32       With the responses from AOC and WSP, the PCH and CACH orchestration processes are also
             responsible for aggregating a single response message
  DF33       Time-to-live values will be retrieved from the configuration file

  DF34       The number of retries will be retrieved from the configuration file



Message Correlation
         Queries and their responses will be separated from each other asynchronously and responses from
         multiple target systems will be received and aggregated. Thus, each party in the long-running
         transaction must implement orchestration, including persistent storage and tracking of message
         identifiers, which are unique by requesting agency.
         The WS-Addressing fields will be used to represent all Message Identifier fields, including the
         RelatesTo field that is used to correlate to the original message identifier
         For example, King and Yakima counties may each send message #12345, but message #56789 sent
         twice from the same agency would be treated as a duplicate or a resend. The following diagram
         illustrates message identifier and correlation components.




Version 1.6Error! Bookmark not defined.                                                                       Page 18
                                        Washington JIN CACH Queries Design




       Each party will be responsible for implementing message stores according to the integration
       technology used in-house. Terminology will likely vary across toolsets and server platforms, and this
       example is just used to illustrate the concepts.


   #                                                    Design Feature
  DF35     Messages received from the same source with the same Message ID are to be discarded. A fault
           message will be returned. Agencies are responsible for handling a fault message by alerting their users.
  DF36     A message that is split or delegated to new agencies will be assigned a new MessageID in the WS-
           Addressing field. Each agency will be assigned the same MessageID field
  DF37     When external agencies respond using an asynchronous web service such PCH Response or CACH
           Response, they must use the RelatesTo WS-Addressing field which is used by the BizTalk aggregation
           orchestration process to create a cumulative list. The RelatesID message ID will equal the initial
           MessageID bound to the message that invoked the PCH Request or CACH Request in the first place


       Responses from producer systems, posted asynchronously from the original requests, must contain
       correlation identifiers, which match the message identifiers from the original requests. The following
       diagram illustrates the response process and message correlation.



Version 1.6Error! Bookmark not defined.                                                                         Page 19
                                      Washington JIN CACH Queries Design




       <wsa:MessageID>  MessageID
       <wsa:RelatesTo>  CorrelationID
       <wsa:From>            Incoming Agency
       <wsa:ReplyTo>         Must be present in order to indicate to the producers where responses should
       be posted to.


   #                                                Design Feature
  DF38    Messages received from the various internal agencies are to be aggregated by the BizTalk
          implementation
  DF39    The WS-Addressing specification is used to handling the message identification and message
          correlation
  DF40    WS-Addressing will define the source of the message

  DF41    WS-Addressing will define where responses will be sent to (ReplyTo)



Valid Exchanges
From           To              Type             Action


Version 1.6Error! Bookmark not defined.                                                                  Page 20
                                     Washington JIN CACH Queries Design

From          To              Type            Action
King County   JINDEX          PCHRequest      PossibleCriminalHistory.wsdl/RequestPossibleCriminalHistory
Yakima        JINDEX          PCHRequest      PossibleCriminalHistory.wsdl/RequestPossibleCriminalHistory
County
JINDEX        Access          Query (PCH)     Access.wsdl/RequestPossibleCriminalHistory
JINDEX        AOC             PCHRequest      PossibleCriminalHistory.wsdl/RequestPossibleCriminalHistory
AOC           JINDEX          PCHResponse     PossibleCriminalHistory.wsdl/PossibleCriminalHistoryResponse
WSP           JINDEX          PCHResponse     PossibleCriminalHistory.wsdl/PossibleCriminalHistoryResponse
JINDEX        King County     PCHResponse     PossibleCriminalHistory.wsdl/PossibleCriminalHistoryResponse
JINDEX        Yakima County   PCHResponse     PossibleCriminalHistory.wsdl/PossibleCriminalHistoryResponse
King County   JINDEX          CACHRequest     CaseCriminalHistory.wsdl/RequestCaseAndCriminalHistory
Yakima        JINDEX          CACHRequest     CaseCriminalHistory.wsdl/RequestCaseAndCriminalHistory
County
JINDEX        Access          Query (CACH)    Access.wsdl/RequestCaseAndCriminalHistory
JINDEX        AOC             CACHRequest     CaseCriminalHistory.wsdl/RequestCaseAndCriminalHistory
AOC           JINDEX          CACHResponse    CaseCriminalHistory.wsdl/CaseAndCriminalHistoryResponse
WSP           JINDEX          CACHResponse    CaseCriminalHistory.wsdl/CaseAndCriminalHistoryResponse
JINDEX        King County     CACHResponse    CaseCriminalHistory.wsdl/CaseAndCriminalHistoryResponse
JINDEX        Yakima County   CACHResponse    CaseCriminalHistory.wsdl/CaseAndCriminalHistoryResponse




Version 1.6Error! Bookmark not defined.                                                                     Page 21
                                          Washington JIN CACH Queries Design

JUSTICE XML

        The business payloads of all requests and responses used in this project will consist of GJXDM
        schema subsets, developed in accordance with the schema subsetting rules identified by the Georgia
        Tech Research Institute (http://justicexml.gtri.gatech.edu/rules_for_schema_subsets.html). Four
        schema subsets have been developed according to the specific messages that must be transmitted.
        These are:



APPLICATION MODELS


PCH Request
        The Possible Criminal History Query will allow a Criminal Justice Practitioner to query on a Subject‟s
        characteristics and attributes, in order to determine if the person exists in existing Court and/or
        Criminal data repositories.
        Possible Criminal History queries will be executed to give the criminal justice practitioners the most
        flexibility in their searches. Thus, at a minimum, a user must enter one of the following fields:
                Last Name
                SSN
                FBI Number
                State ID (SID)
                AFIS Number
                Drivers License Number
        While the use of the identification numbers (such as SSN for example) are specific enough for CACH
        queries, they remain a requirement of the PCH queries since not all data provides can reliably or even
        uniquely identify a possible criminal history on those identifiers alone.
        Supplementing the minimum set of search parameters are the physical characteristics. These
        parameters are more specific and ensure better quality in the search results.
        All search criteria use 'soft' values. This gives the possible criminal history data requester flexibility.
        The following rules should be applied to new and future service implementations that provide data to
        the JINDEX, such as the AOC:
Field                      Description
Last Name                  It will be assumed that the last name specified is the first part of a last name. Also
                           the last name could also be an alias name. Thus, if a user uses 'smi' as a search
                           parameter, 'smith' is a possible match. 'smi' must be compared against the last name
                           and any of the alias fields. A last name must be distinguishable from the first name.
                           This prevents 'smi' from matching a first name as some data models have
                           denormalized name data
First Name                 It will be assumed that the first name specified is the first part of a name. Also the
                           first name could also be an alias name. Thus, if a user uses 'jo' as a search parameter,
                           'john' is a possible match. 'jo' must be compared against the first name and any of the
                           alias fields. A first name must be distinguishable from the last name


Version 1.6Error! Bookmark not defined.                                                                               Page 22
                                           Washington JIN CACH Queries Design

Field                       Description
Date of Birth               A date specified will be bracketed. This means that any date specified will be
                            compared to a range of dates +/- one year. For example, If a user uses Jan 1, 1970 as
                            a date, the queries should search for a DOB between Jan 1, 1969 and Jan 1, 1971
                            inclusive
Height                      When a height is specified, the result set should be flexible enough to be +/- 1 inch.
                            Thus, if 511 is specified (5' 11") then the search should include heights 510 through
                            600
Weight                      When a weight is specified, the result set should be flexible enough to be +/- 5
                            pounds. Thus is 170 is specified, then the search should include weights between
                            165 and 175 inclusive
         Of the required fields, the Last Name is non-specific (not unique, general) and that introduces the
         possibility of very large result sets. Even with more specific search criteria, it is still possible to have
         large result sets. By policy, results will be limited to 100 Subjects to prevent monopolization of
         services and an optional parameter can limit the size of the result further. A result set cannot be made
         larger as this puts the infrastructure at risk. A 'resultset-limit' (xsd:possitiveInteger) element in the
         coordination context will allow the JINDEX and/or agencies to have result sets less than 100 elements.




                 PCH Response
                  Outputs of the Possible Criminal History Query will include a list of Subjects whose
                  characteristics match those supplied in the PCH Request.




                 CACH Request
                  The CACH Query will allow a Criminal Justice Practitioner to „drill in‟ to a Subject‟s specific
                  records in Court and/or Criminal data repositories, by passing one or more of Subject
                  identifiers back to the producer data repositories.



Version 1.6Error! Bookmark not defined.                                                                              Page 23
                                      Washington JIN CACH Queries Design




             CACH Response
              Outputs from the CACH Query will include specific case and/or criminal history data from
              the Courts‟ and the State Patrol‟s data repositories. The intent is not to supply comprehensive
              information, with all information on every case and conviction, but to provide summary data
              sufficient for immediate needs and further drill down, if required (if the Criminal Justice
              Practitioner wishes to receive comprehensive information on a specific case or conviction, a
              future web service would allow further drill down, based on identification numbers).




   #                                                  Design Feature
  DF42    To simplify the identification of web service payloads, each service type has a corresponding payload
          type. The PCH Request web service uses the payload PCHRequest, PCH Response web service is
          bound to the PCHResponse payload, etc.
  DF43    The business payloads of all requests and responses used in this project will consist of GJXDM schema
          subsets, developed in accordance with the schema subsetting rules identified by the Georgia Tech

Version 1.6Error! Bookmark not defined.                                                                         Page 24
                                           Washington JIN CACH Queries Design

     #                                                     Design Feature
                 Research Institute (http://justicexml.gtri.gatech.edu/rules_for_schema_subsets.html)
    DF44         The JIN namespace contains the subset elements. Elements in this namespace can contain elements from
                 other namespaces, such as JXDM



DATA DICTIONARY

           The JIN CACH Requirements Baseline document identified the technical requirements for each of the
           JIN CACH queries, pertaining specifically to the conceptual/logical data model. The following tables
           outline the equivalent fields in the Justice XML schemas, denoted in XPath notation, along with
           corresponding data dictionary descriptions:



PCH Request
Conceptual          Schema Subset XPath(s)                                                            Description
Model
Name (first,        PCHRequest/Subject/PersonName/PersonPrefixName                                    Name prefix of a
middle, last)       PCHRequest/Subject/PersonName/PersonGivenName                                     person.
                    PCHRequest/Subject/PersonName/PersonMiddleName                                    First name of a
                    PCHRequest/Subject/PersonName/PersonSurName
                                                                                                      person.
                    PCHRequest/Subject/PersonName/PersonSuffixName
                                                                                                      Middle name of a
                                                                                                      person.
                                                                                                      Last name of a
                                                                                                      person.
                                                                                                      Name suffix of a
                                                                                                      person.
FBI Number          PCHRequest/Subject/PersonAssignedIDDetails/PersonFBIID/ID                         A unique number
                                                                                                      assigned to a
                                                                                                      defendant by the
                                                                                                      FBI based on
                                                                                                      submitted
                                                                                                      fingerprints.
State               PCHRequest/Subject/PersonAssignedIDDetails/PersonStateID/ID                       A number assigned
Identification      PCHRequest/Subject/PersonAssignedIDDetails/PersonStateID/                         to a defendant by a
Number              IDJurisdictionCode.ncicLIS                                                        state based on
                                                                                                      submitted
                                                                                                      fingerprints.
Driver‟s            PCHRequest/Subject/PersonDriversLicense/DriverAuthorizationID/ID                  Unique identifier
License             +                                                                                 assigned by the
Number              PCHRequest/Subject/PersonDriversLicense/DriverAuthorizationID/                    state to a driver's
                    IDJurisdictionCode.ncicLIS
                                                                                                      license.
                                                                                                      The state by which
                                                                                                      a defendant's
                                                                                                      driver's license was
                                                                                                      issued.
Social Security     PCHRequest/Subject/PersonAssignedIDDetails/PersonSSNID/ID                         A unique identifier
Number                                                                                                assigned to a
                                                                                                      defendant by the
                                                                                                      Social Security
                                                                                                      Administration.
AFIS Number         PCHRequest/Subject/PersonAssignedIDDetails/PersonSSNID/ID                         Unique number
                                                                                                      used by agencies
                                                                                                      when submitting


Version 1.6Error! Bookmark not defined.                                                                           Page 25
                                                Washington JIN CACH Queries Design

                                                                                                                    Fingerprinting
PCN                 Further analysis has indicated that CACH Requests should be person-based rather than incident
                    based.
Date of birth       PCHRequest/Subject/PersonBirthDate                                                              A person's date of
                                                                                                                    birth.
Sex                 PCHRequest/Subject/PersonPhysicalDetails/PersonSexCode                                          A person's gender.
Race                PCHRequest/Subject/PersonPhysicalDetails/PersonRaceCode                                         A person's race.
Address             PCHRequest/Subject/Residence/LocationAddress/AddressFullText                                    Street name and
                                                                                                                    number in a
                                                                                                                    defendant's address.
City                PCHRequest/Subject/Residence/LocationAddress/LocationCityName                                   Name of a city.
State               PCHRequest/Subject/Residence/LocationAddress/LocationStateCode/                                 Name or
                    ncicLIS                                                                                         abbreviation of the
                                                                                                                    state in a
                                                                                                                    defendant's address.
ZIP Code            PCHRequest/Subject/Residence/LocationAddress/LocationPostalCodeID/                              Postal zip code in a
                    ID                                                                                              defendant's address



        #                                                          Design Feature
      DF45      Mappings for the Possible Criminal History Request XML are based on GJXDM 3.0.2

      DF46      All elements in the request schema are optional

      DF47      Subject names will automatically map to alias names



PCH Response (shaded elements are new from the PCH Request)
Conceptual          Schema Subset XPath(s)                                                                          Description
Model
Name (first,        PCHResponse/Subject/PersonName/PersonPrefixName                                                 Name prefix of a
middle, last)       PCHResponse/Subject/PersonName/PersonGivenName                                                  person.
                    PCHResponse/Subject/PersonName/PersonMiddleName                                                 First name of a
                    PCHResponse/Subject/PersonName/PersonSurName
                                                                                                                    person.
                    PCHResponse/Subject/PersonName/PersonSuffixName
                                                                                                                    Middle name of a
                                                                                                                    person.
                                                                                                                    Last name of a
                                                                                                                    person.
                                                                                                                    Name suffix of a
                                                                                                                    person.

Aliases             PCHResponse/Subject/PersonAlternateName/PersonPrefixName                                        Name prefix of a
                    PCHResponse/Subject/PersonAlternateName/PersonGivenName                                         person.
(first,             PCHResponse/Subject/PersonAlternateName/PersonMiddleName                                        First name of a
middle, last,       PCHResponse/Subject/PersonAlternateName/PersonSurName
                                                                                                                    person.
                    PCHResponse/Subject/PersonAlternateName/PersonSuffixName
suffix)                                                                                                             Middle name of a
                                                                                                                    person.
                                                                                                                    Last name of a
                                                                                                                    person.
                                                                                                                    Name suffix of a
                                                                                                                    person.
FBI Number          PCHResponse/Subject/PersonAssignedIDDetails/PersonFBIID/ID                                      A unique number
                                                                                                                    assigned to a
                                                                                                                    defendant by the
                                                                                                                    FBI based on

Version 1.6Error! Bookmark not defined.                                                                                       Page 26
                                              Washington JIN CACH Queries Design

                                                                                                                      submitted
                                                                                                                      fingerprints.
State             PCHResponse/Subject/PersonAssignedIDDetails/PersonStateID/ID                                        A number assigned
Identification    PCHResponse/Subject/PersonAssignedIDDetails/PersonStateID/                                          to a defendant by a
Number            IDJurisdictionCoded.ncicLIS                                                                         state based on
                                                                                                                      submitted
                                                                                                                      fingerprints.
Driver‟s          PCHResponse/Subject/PersonDriversLicense/DriverAuthorizationID/ ID                                  Unique identifier
License           PCHResponse/Subject/PersonDriversLicense/DriverAuthorizationID/                                     assigned by the
Number            IDJurisdictionCode.ncicLIS                                                                          state to a driver's
                                                                                                                      license.
                                                                                                                      The state by which
                                                                                                                      a defendant's
                                                                                                                      driver's license was
                                                                                                                      issued.
Social Security   PCHResponse/Subject/PersonAssignedIDDetails/PersonSSNID/ID                                          A unique identifer
Number                                                                                                                assigned to a
                                                                                                                      defendant by the
                                                                                                                      Social Security
                                                                                                                      Administration.
PCN               Further analysis indicated that PCNs should not be included in the PCH response, since PCNs are
                  incident-based and PCH is person-based. The potential inclusion of multiple PCNs for every person
                  in a PCH response would rapidly increase the size of already large response messages.
Miscellaneous     PCHResponse/Subject/PersonAssignedIDDetails/PersonOtherID/ID                                        Miscellaneous
Identifying       PCHResponse/Subject/PersonAssignedIDDetails/PersonOtherID/ID/ IDTypeText                            Identification
Number                                                                                                                Number
(MNU), (e.g.
passport,
military ID)
Date of birth     PCHResponse/Subject/PersonBirthDate                                                                 A person's date of
                                                                                                                      birth.
Sex               PCHResponse/Subject/PersonPhysicalDetails/PersonSexCode                                             A person's gender.
Race              PCHResponse/Subject/PersonPhysicalDetails/PersonRaceCode                                            A person's race.
Address           PCHResponse/Subject/Residence/LocationAddress/AddressFullText                                       Street name and
                                                                                                                      number in a
                                                                                                                      defendant's address.
City              PCHResponse/Subject/Residence/LocationAddress/LocationCityName                                      Name of a city.
State             PCHResponse/Subject/Residence/LocationAddress/LocationStateCode/                                    Name or
                  ncicLIS                                                                                             abbreviation of the
                                                                                                                      state in a
                                                                                                                      defendant's address.
ZIP Code          PCHResponse/Subject/Residence/LocationAddress/LocationPostalCodeID/                                 Postal zip code in a
                  ID                                                                                                  defendant's address

Scars,            PCHResponse/Subject/PersonPhysicalDetails/PersonPhysicalFeature/                                    Identify scars,
                  PhysicalFeatureDescriptionText                                                                      marks, or tatoos.
Marks and
                                                                                                                      Describing and
Tattoos                                                                                                               specifying location.

Eye Color         PCHResponse/Subject/PersonPhysicalDetails/PersonEyeColorCode                                        A person's eye
                                                                                                                      color.

Hair Color        PCHResponse/Subject/PersonPhysicalDetails/PersonHairColorCode                                       A person's hair
                                                                                                                      color.

Height            PCHResponse/Subject/PersonPhysicalDetails/PersonHeightMeasure                                       A person's height.

Weight            PCHResponse/Subject/PersonPhysicalDetails/PersonWeightMeasure                                       A person's weight.


Version 1.6Error! Bookmark not defined.                                                                                          Page 27
                                                 Washington JIN CACH Queries Design

Record               PCHResponse/Subject/@sourceText                                                                 The source system
                                                                                                                     from which the
Source
                                                                                                                     Subject information
                                                                                                                     was derived



      #                                                             Design Feature
    DF48         Mappings for the Possible Criminal History Response XML are based on GJXDM 3.0.2

    DF49         The output will contain at a minimum the same values as the input

    DF50         Cardinality will allow for “more than 1” elements of category elements, such as Subject




CACH Request
Conceptual           Schema Subset XPath(s)                                                                          Description
Model
FBI Number           CACHRequest/Subject/PersonAssignedIDDetails/PersonFBIID/ID                                      A unique number
                                                                                                                     assigned to a
                                                                                                                     defendant by the
                                                                                                                     FBI based on
                                                                                                                     submitted
                                                                                                                     fingerprints.
State                CACHRequest/Subject/PersonAssignedIDDetails/PersonStateID/ID                                    A number assigned
Identification       CACHRequest/Subject/PersonAssignedIDDetails/PersonStateID/                                      to a defendant by a
Number               IDJurisdictionCoded.ncicLIS                                                                     state based on
                                                                                                                     submitted
                                                                                                                     fingerprints.
Driver‟s             CACHRequest/Subject/PersonDriversLicense/DriverAuthorizationID/ ID                              Unique identifier
License              CACHRequest/Subject/PersonDriversLicense/DriverAuthorizationID/                                 assigned by the
Number               IDJurisdictionCode.ncicLIS                                                                      state to a driver's
                                                                                                                     license.
                                                                                                                     The state by which
                                                                                                                     a defendant's
                                                                                                                     driver's license was
                                                                                                                     issued.
Social Security      CACHRequest/Subject/PersonAssignedIDDetails/PersonSSNID/ID                                      A unique identifer
Number                                                                                                               assigned to a
                                                                                                                     defendant by the
                                                                                                                     Social Security
                                                                                                                     Administration.
PCN                  Further analysis has indicated that CACH Requests should be person-based rather than incident
                     based.



      #                                                             Design Feature
    DF51         Mappings for the Case and Criminal History Request XML are based on GJXDM 3.0.2

    DF52         All elements in the request schema are optional

    DF53         Logically, at least one identifier must be present. This would be any identifier supplied by the Possible
                 Criminal History response. Such as FBI Number, Drivers License Number, State Identifier, etc.
    DF54         Further analysis indicated that PCNs should not be included in the PCH response, since PCNs are


Version 1.6Error! Bookmark not defined.                                                                                        Page 28
                                                 Washington JIN CACH Queries Design

      #                                                             Design Feature
                 incident-based and PCH is person-based. The potential inclusion of multiple PCNs for every person in a
                 PCH response would rapidly increase the size of already large response messages.
                 Additionally, the execution of the CACH query using the PCN is not feasible as there is no query
                 presently implemented that would allow the JINDEX to resolve the PCN to an SID as is required to
                 complete the criminal history queries.



CACH Response
Conceptual           Schema Subset XPath(s)                                                                               Description
Model
AOC / Case Info
PCN                  GJXDM does not inherently associate Arrests and Bookings with CourtEventCases, the natural
                     construct for AOC info. If PCNs, which are related to Bookings, needed to be included with AOC
                     data, then the local JIN CACH schema subset would need to modify CourtEventCase constructs.
                     JIN CACH would then not be interoperable at a GJXDM component level with other Justice XML –
                     compliant implementations. Since PCN is not “core” data to the courts (as are charges, cases,
                     dispositions, and sentences), it is therefore recommended not to “hack” the local schema subset to
                     include PCN.
Charge               CACHResponse/CourtEventCase/CourtCharge/ChargeID/ID
Identification       CACHResponse/CourtEventCase/CourtCharge/ChargeID/
Number               IDJurisdictionCode.ncicLIS

Charge Name          CACHResponse/CourtEventCase/CourtCharge/ChargeStatute/                                               A code that
                     StatuteOffenseCode                                                                                   identifies a criminal
                     CACHResponse/CourtEventCase/CourtCharge/ChargeStatute/                                               offense within a
                     StatuteLevelText                                                                                     code book.
                                                                                                                          Sometimes referred
                                                                                                                          to as offense code,
                                                                                                                          ordinance number.
                                                                                                                          Severity of the
                                                                                                                          charge (e.g., felony,
                                                                                                                          misdemeanor).
Charge Date          CACHResponse/CourtEventCase/CourtCharge/ChargeFilingDate                                             Date assigned by a
                                                                                                                          court upon filling of
                                                                                                                          a new case.
Charge               CACHResponse/CourtEventCase/CourtCharge/ChargeDescriptionText                                        Text describing the
Description                                                                                                               offense committed
                                                                                                                          by the defendant.
Charge               CACHResponse/CourtEventCase/CourtCharge/ChargeDisposition/                                           Details about the
Disposition          ChargeDispositionDescriptionText                                                                     results or
                                                                                                                          processing of a
                                                                                                                          charge for the
                                                                                                                          defendant.
Court Name           CACHResponse/CourtEventCase/ActivityPrimaryOrganization/
                     OrganizationName

Supervision
Sentence             CACHResponse/CourtEventCase/CourtCharge/ChargeSentence/
(optional)           SentenceDescriptionText/

WSP / Criminal Info
PCN                  CACHResponse/CriminalHistory/Arrest/Booking/BookingDocumentControlID                                 Process Control
                                                                                                                          Number associated
                                                                                                                          with the
                                                                                                                          fingerprinting event

Version 1.6Error! Bookmark not defined.                                                                                              Page 29
                                            Washington JIN CACH Queries Design

                                                                                               at the time of the
                                                                                               booking
Charge             CACHResponse/CriminalHistory/Arrest/ArrestCharge/ChargeID/ID
Identification     CACHResponse/CriminalHistory/Arrest/ArrestCharge/ChargeID/
Number             IDJurisdictionCode.ncicLIS

Charge Offense     CACHResponse/CriminalHistory/Arrest/ArrestCharge/ChargeStatute/             A code that
Code ID            StatuteCodeID/ID                                                            identifies a criminal
                                                                                               offense within a
                                                                                               code book.
                                                                                               Sometimes referred
                                                                                               to as offense code,
                                                                                               ordinance number.
Charge Offense     CACHResponse/CriminalHistory/Arrest/ArrestCharge/ChargeStatute/             Severity or level of
Level Text         StatuteLevelText                                                            the offense (e.g.,
                                                                                               Misdemeanor,
                                                                                               Gross
                                                                                               Misdemeanor,
                                                                                               Felony).
Charge             CACHResponse/CriminalHistory/Arrest/ArrestCharge/ChargeDescriptionTe        Text describing the
Description        xt                                                                          offense committed
                                                                                               by the defendant.
Charge             CACHResponse/CriminalHistory/Arrest/ArrestCharge/ChargeDisposition/         Details about the
Disposition        ChargeDispositionDescriptionText                                            results or
                                                                                               processing of a
                                                                                               charge for the
                                                                                               defendant.
Contributing       CACHResponse/CriminalHistory/Arrest/ArrestAgency/OrganizationName           The Contributing
Agency Name                                                                                    Agency starts each
                                                                                               new arrest record.
Arrest Date        CACHResponse/CriminalHistory/Arrest/ActivityDate                            The Arrest Date
                                                                                               follows each new
                                                                                               arrest record, and
                                                                                               is considered the
                                                                                               “DATE OF
                                                                                               ARREST”.
Mentally Ill       CACHResponse/Subject/SubjectCautionInformationCode
Status (if
possible)
Chemically         CACHResponse/Subject/SubjectCautionInformationCode                          If value = „20‟,
Dependent                                                                                      Subject is Known to
Status (if                                                                                     Abuse Drugs
possible)
Violent            CACHResponse/Subject/SubjectCautionInformationCode                          If value = „05‟,
Offender Status                                                                                Subject has Violent
                                                                                               Tendencies
Armed and          CACHResponse/Subject/SubjectCautionInformationCode                          If value = „00‟,
Dangerous                                                                                      Subject is Armed
Status                                                                                         and Dangerous
Registered Sex     CACHResponse/Subject/SubjectCautionInformationCode                          If value = „30‟,
Offender Status                                                                                Subject is a
                                                                                               Sexually Violent
                                                                                               Predator
Person of          CACHResponse/Subject/SubjectOffenderNoticeCaveat
Interest Status,
including name,
date, issuing
agency
Protection         CACHResponse/ProtectionOrder/ActivityPrimaryOrganization/OrganizationName
Order(s),          CACHResponse/ProtectionOrder/ActivityDate

Version 1.6Error! Bookmark not defined.                                                                   Page 30
                                           Washington JIN CACH Queries Design

including name,   CACHResponse/ProtectionOrder/ProtectionOrderConditionCode
date, issuing     CACHResponse/ProtectionOrder/ProtectionOrderRestrictedPerson/PersonName
agency            CACHResponse/ProtectionOrder/Condition/ConditionDescriptionText
Warrant(s),       CACHResponse/ArrestWarrant/ActivityPrimaryOrganization/OrganizationName
including name,   CACHResponse/ArrestWarrant/ActivityDate
date, issuing     CACHResponse/ArrestWarrant/WarrantProbableCauseText
agency



     #                                                       Design Feature
   DF55      Mappings for the Case and Criminal History Response XML are based on GJXDM 3.0.2

   DF56      Data that is retrieved is not a comprehensive list. Future web services are required to show additional
             information. There are identifiers that are retrieved that will facilitate future services – these are part of
             the logical integration domain model or GJXDM 3.0.2



SAMPLE MESSAGES

         The following section is meant to be illustrative for conveying how the web services work, and the
         sample messages that would be sent by each of the systems in a successful query scenario. For brevity,
         these samples do not include SOAP wrapper tags, but rather just focus on the Justice XML payloads,
         which would be found in the SOAP Body.
            PCH Request
         PCH Requests will contain a single subject and some of the subject‟s characteristics. The minimum
         data is first name, last name, and date of birth. This is not restricted in the schemas, but is rather a
         business rule that JIN agencies must adhere too. A PCH request containing only this information is
         bound to produce an extremely large result set. Agencies are therefore recommended to include as
         many of the Subject‟s characteristics as possible and as are known (the example shows the passing of
         height, weight, eye and hair color, sex, race, and residence state).

             <?xml version="1.0" encoding="UTF-8"?>
             <pch:PCHRequest
             xmlns:jxdm="http://www.it.ojp.gov/jxdm/3.0.2"
             xmlns:chq="http://www.jin.wa.gov/xsd/chq/2005/05/"
             xmlns:pch="http://www.jin.wa.gov/xsd/chq/pch/2005/05/"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                <chq:Subject>
                    <jxdm:PersonName>
                        <jxdm:PersonGivenName>Joe</jxdm:PersonGivenName>
                        <jxdm:PersonSurName>Perp</jxdm:PersonSurName>
                    </jxdm:PersonName>
                    <jxdm:Residence>
                        <jxdm:LocationAddress>
                             <jxdm:LocationStateCode.ncicLIS>WA</jxdm:LocationStateCode.ncicLIS>
                        </jxdm:LocationAddress>
                    </jxdm:Residence>
                    <jxdm:PersonBirthDate>1967-08-13</jxdm:PersonBirthDate>
                    <jxdm:PersonPhysicalDetails>
                        <jxdm:PersonHeightMeasure>6</jxdm:PersonHeightMeasure>
                        <jxdm:PersonWeightMeasure>200</jxdm:PersonWeightMeasure>
                        <jxdm:PersonEyeColorCode>BLU</jxdm:PersonEyeColorCode>
                        <jxdm:PersonHairColorCode>BRO</jxdm:PersonHairColorCode>
                        <jxdm:PersonSexCode>M</jxdm:PersonSexCode>
                        <jxdm:PersonRaceCode>W</jxdm:PersonRaceCode>
                    </jxdm:PersonPhysicalDetails>
                </chq:Subject>
             </pch:PCHRequest>



Version 1.6Error! Bookmark not defined.                                                                              Page 31
                                        Washington JIN CACH Queries Design

      The acknowledgment response is intended to be simple:

            <chq:Acknowledgement xmlns:chq="http://www.jin.wa.gov/xsd/chq/2005/05/"
            xmlns:jxdm="http://www.it.ojp.gov/jxdm/3.0.2"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
              <chq:Message>The query was successfully submitted</chq:Message>
              <chq:Code>OK</chq:Code>
            </chq:Acknowledgement>



          PCH Response
      PCH Responses will contain 0-n Subjects whose characteristics match those that were passed in
      through the original query request. Note that the back end systems have automatic built-in bracketing
      on several data fields, including birth date (+- 1 year), height and weight. Results returned from the
      systems will include all results that fall within the tolerance bracket. Several systems will also include
      negative responses, e.g. “NO RECORDS FOUND”. Finally, a system may not respond during the 10
      second time-to-live of the orchestration. In this case, the JINDEX server will create a response that
      indicates a system has not responded.
      (i) AOC Responds
          <?xml version="1.0" encoding="UTF-8"?>
          <pch:PCHResponse xmlns:jxdm="http://www.it.ojp.gov/jxdm/3.0.2"
          xmlns:chq="http://www.jin.wa.gov/xsd/chq/2005/05/"
          xmlns:pch="http://www.jin.wa.gov/xsd/chq/pch/2005/05/"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
               <chq:Subject jxdm:sourceText="AOC">
                    <jxdm:PersonName>                                              sourceText
                        <jxdm:PersonGivenName>Joe</jxdm:PersonGivenName>           indicates this
                        <jxdm:PersonSurName>Perp</jxdm:PersonSurName>              response is from
                    </jxdm:PersonName>                                             the AOC
                    <jxdm:PersonAlternateName>
                        <jxdm:PersonGivenName>John</jxdm:PersonGivenName>
                        <jxdm:PersonSurName>Perpetrator</jxdm:PersonSurName>
                    </jxdm:PersonAlternateName>
                    <jxdm:PersonAlternateName>
                        <jxdm:PersonGivenName>Joseph</jxdm:PersonGivenName>
                        <jxdm:PersonSurName>Perp</jxdm:PersonSurName>
                    </jxdm:PersonAlternateName>
                    <jxdm:Residence>
                        <jxdm:LocationAddress>
                            <jxdm:LocationStateCode.ncicLIS>WA</jxdm:LocationStateCode.ncicLIS>
                        </jxdm:LocationAddress>
                    </jxdm:Residence>
                    <jxdm:PersonBirthDate>1967-08-13</jxdm:PersonBirthDate>
                    <jxdm:PersonAssignedIDDetails jxdm:sourceText="AOC">
                        <jxdm:PersonOtherID>
                            <jxdm:ID>5223987</jxdm:ID>                                         The AOC returns their own
                            <jxdm:IDTypeText>AOCID</jxdm:IDTypeText>                           internal identifier, since it is
                        </jxdm:PersonOtherID>                                                  the most reliable for
                    </jxdm:PersonAssignedIDDetails>                                            producing successful CACH
                    <jxdm:PersonPhysicalDetails>                                               query results
                        <jxdm:PersonHeightMeasure>6</jxdm:PersonHeightMeasure>
                        <jxdm:PersonWeightMeasure>200</jxdm:PersonWeightMeasure>
                        <jxdm:PersonEyeColorCode>BLU</jxdm:PersonEyeColorCode>
                        <jxdm:PersonHairColorCode>BRO</jxdm:PersonHairColorCode>
                        <jxdm:PersonSexCode>M</jxdm:PersonSexCode>
                        <jxdm:PersonRaceCode>W</jxdm:PersonRaceCode>
                        <jxdm:PersonPhysicalFeature>
                            <jxdm:PhysicalFeatureDescriptionText>Snake tattoo, right
          forearm</jxdm:PhysicalFeatureDescriptionText>
                        </jxdm:PersonPhysicalFeature>
                    </jxdm:PersonPhysicalDetails>
               </chq:Subject>
          </pch:PCHResponse>

      (ii) WASIS Responds with 2 distinct Subject records that match the query criteria


Version 1.6Error! Bookmark not defined.                                                                            Page 32
                                     Washington JIN CACH Queries Design

      <?xml version="1.0" encoding="UTF-8"?>
      <pch:PCHResponse
          xmlns:chq="http://www.jin.wa.gov/xsd/chq/2005/05/"
          xmlns:pch="http://www.jin.wa.gov/xsd/chq/pch/2005/05/"
          xmlns:jxdm="http://www.it.ojp.gov/jxdm/3.0.2" xmlns:jin="http://www.jin.wa.gov"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <chq:Subject jxdm:sourceText="WASIS">
                  <jxdm:PersonName>
                        <jxdm:PersonGivenName>Joe</jxdm:PersonGivenName>
                        <jxdm:PersonSurName>Perp</jxdm:PersonSurName>
                  </jxdm:PersonName>
                  <jxdm:Residence>
                        <jxdm:LocationAddress>

            <jxdm:LocationStateCode.ncicLIS>WA</jxdm:LocationStateCode.ncicLIS>
                        </jxdm:LocationAddress>
                  </jxdm:Residence>
                  <jxdm:PersonBirthDate>1967-08-13</jxdm:PersonBirthDate>
                  <jxdm:PersonAssignedIDDetails>
                        <jxdm:PersonStateID>
                              <jxdm:ID>WA230985235</jxdm:ID>
                        </jxdm:PersonStateID>
                  </jxdm:PersonAssignedIDDetails>
                  <jxdm:PersonPhysicalDetails>
                        <jxdm:PersonHeightMeasure>6</jxdm:PersonHeightMeasure>
                        <jxdm:PersonWeightMeasure>200</jxdm:PersonWeightMeasure>
                        <jxdm:PersonEyeColorCode>BLU</jxdm:PersonEyeColorCode>
                        <jxdm:PersonHairColorCode>BRO</jxdm:PersonHairColorCode>
                        <jxdm:PersonSexCode>M</jxdm:PersonSexCode>
                        <jxdm:PersonRaceCode>W</jxdm:PersonRaceCode>
                        <jxdm:PersonPhysicalFeature>
                              <jxdm:PhysicalFeatureDescriptionText>Snake tattoo, right
      forearm</jxdm:PhysicalFeatureDescriptionText>
                        </jxdm:PersonPhysicalFeature>
                  </jxdm:PersonPhysicalDetails>
            </jin:Subject>
            <jin:Subject jxdm:sourceText="WASIS">
                  <jxdm:PersonName>
                        <jxdm:PersonGivenName>Joe</jxdm:PersonGivenName>
                        <jxdm:PersonSurName>Perp</jxdm:PersonSurName>
                  </jxdm:PersonName>
                  <jxdm:Residence>
                        <jxdm:LocationAddress>

            <jxdm:LocationStateCode.ncicLIS>WA</jxdm:LocationStateCode.ncicLIS>
                        </jxdm:LocationAddress>
                  </jxdm:Residence>
                  <jxdm:PersonBirthDate>1968-01-11</jxdm:PersonBirthDate>
                  <jxdm:PersonAssignedIDDetails>
                        <jxdm:PersonStateID>
                              <jxdm:ID>WA609872546</jxdm:ID>
                        </jxdm:PersonStateID>
                  </jxdm:PersonAssignedIDDetails>
                  <jxdm:PersonPhysicalDetails>
                        <jxdm:PersonHeightMeasure>5.6</jxdm:PersonHeightMeasure>
                        <jxdm:PersonWeightMeasure>150</jxdm:PersonWeightMeasure>
                        <jxdm:PersonEyeColorCode>BLU</jxdm:PersonEyeColorCode>
                        <jxdm:PersonHairColorCode>BRO</jxdm:PersonHairColorCode>
                        <jxdm:PersonSexCode>M</jxdm:PersonSexCode>
                        <jxdm:PersonRaceCode>W</jxdm:PersonRaceCode>
                  </jxdm:PersonPhysicalDetails>
            </chq:Subject>
      </pch:PCHResponse>

      (iii) DOC responds with a negative responses
      <?xml version="1.0" encoding="UTF-8"?>
      <pch:PCHResponse
        xmlns:chq="http://www.jin.wa.gov/xsd/chq/2005/05/"
        xmlns:pch="http://www.jin.wa.gov/xsd/chq/pch/2005/05/"
        xmlns:jxdm="http://www.it.ojp.gov/jxdm/3.0.2" xmlns:jin="http://www.jin.wa.gov"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <jin:Subject jxdm:sourceText="DOC" jxdm:commentText="No records"/>


Version 1.6Error! Bookmark not defined.                                                     Page 33
                                      Washington JIN CACH Queries Design

      </pch:PCHResponse>



      (iv) NLETS fails to respond in the allotted time. The JINDEX BizTalk Server orchestration process
      creates the message
      <?xml version="1.0" encoding="UTF-8"?>
      <pch:PCHResponse
        xmlns:chq="http://www.jin.wa.gov/xsd/chq/2005/05/"
        xmlns:pch="http://www.jin.wa.gov/xsd/chq/pch/2005/05/"
        xmlns:jxdm="http://www.it.ojp.gov/jxdm/3.0.2" xmlns:jin="http://www.jin.wa.gov"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <chq:Subject jxdm:sourceText="NLETS" jxdm:commentText="No response in allotted
      time"/>
      </pch:PCHResponse>



      (v) As the JINDEX BizTalk Server orchestration receives response messages, it consolidates and
      aggregates the responses. Messages will be associated based on the wsa:RelatesTo element (aka the
      correlation ID). Once messages that are associated with the same RelatesTo are grouped, Biztalk must
      extract and compare the following elements:
                    PCHResponse/Subject/PersonBirthDate

                    PCHResponse/Subject/PersonName/PersonGivenName

                    PCHResponse/Subject/PersonName/PersonSurName

      If these three elements are identical across responses from the various source systems, the Subject is
      deemed to be the same person (this is the same logic used in Summary Offender Profile). In that case,
      the PersonAssignedID sections from each matching Subject must be consolidated and aggregated by
      the BizTalk orchestration under a single Subject. Variances in other elements need not be preserved. In
      the examples given above, the consolidation logic would match the 1st WASIS Subject to that of the
      AOC, but the 2nd WASIS Subject is a different person with a different birth date. After the
      consolidation, BizTalk would return the following XML to the web service consumer who originally
      initiated the query:

      <?xml version="1.0" encoding="UTF-8"?>
      <pch:PCHResponse
        xmlns:chq="http://www.jin.wa.gov/xsd/chq/2005/05/"
        xmlns:pch="http://www.jin.wa.gov/xsd/chq/pch/2005/05/"
        xmlns:jxdm="http://www.it.ojp.gov/jxdm/3.0.2"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <chq:Subject>
                  <jxdm:PersonName>
                        <jxdm:PersonGivenName>Joe</jxdm:PersonGivenName>
                        <jxdm:PersonSurName>Perp</jxdm:PersonSurName>
                  </jxdm:PersonName>
                  <jxdm:PersonAlternateName>
                        <jxdm:PersonGivenName>John</jxdm:PersonGivenName>
                        <jxdm:PersonSurName>Perpetrator</jxdm:PersonSurName>
                  </jxdm:PersonAlternateName>
                  <jxdm:PersonAlternateName>
                        <jxdm:PersonGivenName>Joseph</jxdm:PersonGivenName>
                        <jxdm:PersonSurName>Perp</jxdm:PersonSurName>
                  </jxdm:PersonAlternateName>
                  <jxdm:Residence>
                        <jxdm:LocationAddress>

            <jxdm:LocationStateCode.ncicLIS>WA</jxdm:LocationStateCode.ncicLIS>
                        </jxdm:LocationAddress>
                  </jxdm:Residence>
                  <jxdm:PersonBirthDate>1967-08-13</jxdm:PersonBirthDate>
                  <jxdm:PersonAssignedIDDetails jxdm:sourceText="AOC">
                        <jxdm:PersonOtherID>
                              <jxdm:ID>5223987</jxdm:ID>

Version 1.6Error! Bookmark not defined.                                                                      Page 34
                                      Washington JIN CACH Queries Design

                              <jxdm:IDTypeText>AOCID</jxdm:IDTypeText>
                        </jxdm:PersonOtherID>
                  </jxdm:PersonAssignedIDDetails>
                  <jxdm:PersonAssignedIDDetails jxdm:sourceText="WASIS">
                        <jxdm:PersonStateID>
                              <jxdm:ID>WA230985235</jxdm:ID>
                        </jxdm:PersonStateID>
                  </jxdm:PersonAssignedIDDetails>
                  <jxdm:PersonPhysicalDetails>
                        <jxdm:PersonHeightMeasure>6</jxdm:PersonHeightMeasure>
                        <jxdm:PersonWeightMeasure>200</jxdm:PersonWeightMeasure>
                        <jxdm:PersonEyeColorCode>BLU</jxdm:PersonEyeColorCode>
                        <jxdm:PersonHairColorCode>BRO</jxdm:PersonHairColorCode>
                        <jxdm:PersonSexCode>M</jxdm:PersonSexCode>
                        <jxdm:PersonRaceCode>W</jxdm:PersonRaceCode>
                        <jxdm:PersonPhysicalFeature>
                              <jxdm:PhysicalFeatureDescriptionText>Snake tattoo, right
      forearm</jxdm:PhysicalFeatureDescriptionText>
                        </jxdm:PersonPhysicalFeature>
                  </jxdm:PersonPhysicalDetails>
            </chq:Subject>
            <chq:Subject jxdm:sourceText="WASIS">
                  <jxdm:PersonName>
                        <jxdm:PersonGivenName>Joe</jxdm:PersonGivenName>
                        <jxdm:PersonSurName>Perp</jxdm:PersonSurName>
                  </jxdm:PersonName>
                  <jxdm:Residence>
                        <jxdm:LocationAddress>
                        <jxdm:LocationStateCode.ncicLIS>WA</jxdm:LocationStateCode.ncicLIS>
                        </jxdm:LocationAddress>
                  </jxdm:Residence>
                  <jxdm:PersonBirthDate>1967-08-13</jxdm:PersonBirthDate>
                  <jxdm:PersonAssignedIDDetails>
                        <jxdm:PersonStateID>
                              <jxdm:ID>WA609872546</jxdm:ID>
                        </jxdm:PersonStateID>
                  </jxdm:PersonAssignedIDDetails>
                  <jxdm:PersonPhysicalDetails>
                        <jxdm:PersonHeightMeasure>5.6</jxdm:PersonHeightMeasure>
                        <jxdm:PersonWeightMeasure>150</jxdm:PersonWeightMeasure>
                        <jxdm:PersonEyeColorCode>BLU</jxdm:PersonEyeColorCode>
                        <jxdm:PersonHairColorCode>BRO</jxdm:PersonHairColorCode>
                        <jxdm:PersonSexCode>M</jxdm:PersonSexCode>
                        <jxdm:PersonRaceCode>W</jxdm:PersonRaceCode>
                  </jxdm:PersonPhysicalDetails>
            </chq:Subject>
            <chq:Subject jxdm:sourceText="DOC" jxdm:commentText="No records"/>
            <chq:Subject jxdm:sourceText="NLETS" jxdm:commentText="No response in alloted
      time"/>
      </pch:PCHResponse>



      In the example above, the identifiers do not need to be presented to the end user - they could be
      hidden. The agency application could present the characteristic data, such that one “Joe Perp” was 6‟,
      200 lbs, and the other was 5‟6” 150 lbs. The user could then determine which one was most
      appropriate for CACH querying. The advantage to the consuming agencies of having the BizTalk
      orchestration perform the consolidation/aggregation logic, is that they can then turn around and submit
      the single, user-selected Subject to the CACHRequest query.


         CACH Request
      The following example shows a query based on the first Subject from the PCH Response example
      shown above. Note that the Subject element structure is unchanged. The agency application would,
      however, need to re-wrap the Subject XML in appropriate SOAP constructs.

      <?xml version="1.0" encoding="UTF-8"?>


Version 1.6Error! Bookmark not defined.                                                                     Page 35
                                       Washington JIN CACH Queries Design

      <cach:CACHRequest
        xmlns:chq="http://www.jin.wa.gov/xsd/chq/2005/05/"
        xmlns:cach="http://www.jin.wa.gov/xsd/chq/cach/2005/05/"
        xmlns:jxdm="http://www.it.ojp.gov/jxdm/3.0.2"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <chq:Subject>
                  <jxdm:PersonName>
                        <jxdm:PersonGivenName>Joe</jxdm:PersonGivenName>
                        <jxdm:PersonSurName>Perp</jxdm:PersonSurName>
                  </jxdm:PersonName>
                  <jxdm:PersonAlternateName>
                        <jxdm:PersonGivenName>John</jxdm:PersonGivenName>
                        <jxdm:PersonSurName>Perpetrator</jxdm:PersonSurName>
                  </jxdm:PersonAlternateName>
                  <jxdm:PersonAlternateName>
                        <jxdm:PersonGivenName>Joseph</jxdm:PersonGivenName>
                        <jxdm:PersonSurName>Perp</jxdm:PersonSurName>
                  </jxdm:PersonAlternateName>
                  <jxdm:Residence>
                        <jxdm:LocationAddress>

            <jxdm:LocationStateCode.ncicLIS>WA</jxdm:LocationStateCode.ncicLIS>
                        </jxdm:LocationAddress>
                  </jxdm:Residence>
                  <jxdm:PersonBirthDate>1967-08-13</jxdm:PersonBirthDate>
                  <jxdm:PersonAssignedIDDetails jxdm:sourceText="AOC">
                        <jxdm:PersonOtherID>
                              <jxdm:ID>5223987</jxdm:ID>
                              <jxdm:IDTypeText>AOCID</jxdm:IDTypeText>
                        </jxdm:PersonOtherID>
                  </jxdm:PersonAssignedIDDetails>
                  <jxdm:PersonAssignedIDDetails jxdm:sourceText="WASIS">
                        <jxdm:PersonStateID>
                              <jxdm:ID>WA230985235</jxdm:ID>
                        </jxdm:PersonStateID>
                  </jxdm:PersonAssignedIDDetails>
                  <jxdm:PersonPhysicalDetails>
                        <jxdm:PersonHeightMeasure>6</jxdm:PersonHeightMeasure>
                        <jxdm:PersonWeightMeasure>200</jxdm:PersonWeightMeasure>
                        <jxdm:PersonEyeColorCode>BLU</jxdm:PersonEyeColorCode>
                        <jxdm:PersonHairColorCode>BRO</jxdm:PersonHairColorCode>
                        <jxdm:PersonSexCode>M</jxdm:PersonSexCode>
                        <jxdm:PersonRaceCode>W</jxdm:PersonRaceCode>
                        <jxdm:PersonPhysicalFeature>
                              <jxdm:PhysicalFeatureDescriptionText>Snake tattoo, right
      forearm</jxdm:PhysicalFeatureDescriptionText>
                        </jxdm:PersonPhysicalFeature>
                  </jxdm:PersonPhysicalDetails>
            </chq:Subject>
      </cach:CACHRequest>

         CACH Response
      Performing a CACH query based on the positive response of a PCH query is almost guaranteed to
      produce results, since the positive PCH response is indicative of the existence of the Subject in the
      relevant data repository. The following demonstrates ArrestWarrant, CourtEventCase,
      CriminalHistory, and ProtectionOrder data (although keep in mind that the example is written by
      technologists, not criminal justice practitioners, and may not contain logically coherent data to the
      latter)
      <?xml version="1.0" encoding="UTF-8"?>
      <cach:CACHResponse
        xmlns:chq="http://www.jin.wa.gov/xsd/chq/2005/05/"
        xmlns:cach="http://www.jin.wa.gov/xsd/chq/cach/2005/05/"
        xmlns:jxdm="http://www.it.ojp.gov/jxdm/3.0.2"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      >
            <chq:Subject>
                  <jxdm:PersonName>
                        <jxdm:PersonGivenName>Joe</jxdm:PersonGivenName>
                        <jxdm:PersonSurName>Perp</jxdm:PersonSurName>


Version 1.6Error! Bookmark not defined.                                                                       Page 36
                                   Washington JIN CACH Queries Design

                  </jxdm:PersonName>
                  <jxdm:PersonAlternateName>
                        <jxdm:PersonGivenName>John</jxdm:PersonGivenName>
                        <jxdm:PersonSurName>Perpetrator</jxdm:PersonSurName>
                  </jxdm:PersonAlternateName>
                  <jxdm:PersonAlternateName>
                        <jxdm:PersonGivenName>Joseph</jxdm:PersonGivenName>
                        <jxdm:PersonSurName>Perp</jxdm:PersonSurName>
                  </jxdm:PersonAlternateName>
                  <jxdm:Residence>
                        <jxdm:LocationAddress>

            <jxdm:LocationStateCode.ncicLIS>WA</jxdm:LocationStateCode.ncicLIS>
                        </jxdm:LocationAddress>
                  </jxdm:Residence>
                  <jxdm:PersonBirthDate>1967-08-13</jxdm:PersonBirthDate>
                  <jxdm:PersonAssignedIDDetails jxdm:sourceText="AOC">
                        <jxdm:PersonOtherID>
                              <jxdm:ID>5223987</jxdm:ID>
                              <jxdm:IDTypeText>AOCID</jxdm:IDTypeText>
                        </jxdm:PersonOtherID>
                  </jxdm:PersonAssignedIDDetails>
                  <jxdm:PersonAssignedIDDetails jxdm:sourceText="WASIS">
                        <jxdm:PersonStateID>
                              <jxdm:ID>WA230985235</jxdm:ID>
                        </jxdm:PersonStateID>
                  </jxdm:PersonAssignedIDDetails>
                  <jxdm:PersonPhysicalDetails>
                        <jxdm:PersonHeightMeasure>6</jxdm:PersonHeightMeasure>
                        <jxdm:PersonWeightMeasure>200</jxdm:PersonWeightMeasure>
                        <jxdm:PersonEyeColorCode>BLU</jxdm:PersonEyeColorCode>
                        <jxdm:PersonHairColorCode>BRO</jxdm:PersonHairColorCode>
                        <jxdm:PersonSexCode>M</jxdm:PersonSexCode>
                        <jxdm:PersonRaceCode>W</jxdm:PersonRaceCode>
                        <jxdm:PersonPhysicalFeature>
                              <jxdm:PhysicalFeatureDescriptionText>TAT L
      LEG</jxdm:PhysicalFeatureDescriptionText>
                        </jxdm:PersonPhysicalFeature>
                  </jxdm:PersonPhysicalDetails>

            <jxdm:SubjectCautionInformationCode>20</jxdm:SubjectCautionInformationCode>

            <jxdm:SubjectCautionInformationCode>00</jxdm:SubjectCautionInformationCode>
            </chq:Subject>
            <jxdm:ArrestWarrant>
                  <jxdm:ActivityDate>2004-05-11</jxdm:ActivityDate>                 ArrestWarrant info
                  <jxdm:ActivityPrimaryOrganization>
                        <jxdm:OrganizationName>DEPT JUST COMM CTR
      WASHINGTON</jxdm:OrganizationName>
                  </jxdm:ActivityPrimaryOrganization>
                  <jxdm:WarrantProbableCauseText>HOMICIDE – WILLFUL KILL – POL OFF –
      GUN</jxdm:WarrantProbableCauseText>
            </jxdm:ArrestWarrant>                                                             CourtEventCase
            <chq:CourtEventCase>                                                              (AOC) info
                  <jxdm:ActivityPrimaryOrganization>
                        <jxdm:OrganizationName>SPOKANE COUNTY COURT</jxdm:OrganizationName>
                  </jxdm:ActivityPrimaryOrganization>
                  <chq:CourtCharge>
                        <jxdm:ChargeID>
                              <jxdm:ID>236234532</jxdm:ID>
                        </jxdm:ChargeID>
                        <jxdm:ChargeDescriptionText>DRIVE WHILE UNDER THE
      INFLUENCE</jxdm:ChargeDescriptionText>
                        <jxdm:ChargeFilingDate>2003-01-12</jxdm:ChargeFilingDate>
                        <jxdm:ChargeSentence>
                              <jxdm:SentenceDescriptionText>NOT
      RECEIVED</jxdm:SentenceDescriptionText>
                        </jxdm:ChargeSentence>
                        <jxdm:ChargeStatute>
                              <jxdm:StatuteOffenseCode>09A</jxdm:StatuteOffenseCode>
                              <jxdm:StatuteLevelText>GROSS
      MISDEMEANOR</jxdm:StatuteLevelText>
                        </jxdm:ChargeStatute>


Version 1.6Error! Bookmark not defined.                                                          Page 37
                                       Washington JIN CACH Queries Design

                         <chq:ChargeDisposition>
                               <jxdm:ChargeDispositionDescriptionText>NOT
       RECEIVED</jxdm:ChargeDispositionDescriptionText>
                         </chq:ChargeDisposition>
                   </chq:CourtCharge>
             </chq:CourtEventCase>                                            Criminal History
             <chq:CriminalHistory>                                            info
                   <chq:Arrest>
                         <jxdm:Booking>
                               <jxdm:BookingDocumentControlID>
                                     <jxdm:ID>1634324532</jxdm:ID>
                               </jxdm:BookingDocumentControlID>
                         </jxdm:Booking>
                         <chq:ArrestCharge>
                               <jxdm:ChargeID>
                                     <jxdm:ID>236234532</jxdm:ID>
                               </jxdm:ChargeID>
                               <jxdm:ChargeDescriptionText>DRIVE WHILE UNDER THE
       INFLUENCE</jxdm:ChargeDescriptionText>
                               <jxdm:ChargeFilingDate>2003-01-12</jxdm:ChargeFilingDate>
                               <jxdm:ChargeSentence>
                                     <jxdm:SentenceDescriptionText>NOT
       RECEIVED</jxdm:SentenceDescriptionText>
                               </jxdm:ChargeSentence>
                               <jxdm:ChargeStatute>
                                     <jxdm:StatuteOffenseCode>09A</jxdm:StatuteOffenseCode>
                                     <jxdm:StatuteLevelText>GROSS
       MISDEMEANOR</jxdm:StatuteLevelText>
                               </jxdm:ChargeStatute>
                               <chq:ChargeDisposition>
                                     <jxdm:ChargeDispositionDescriptionText>NOT
       RECEIVED</jxdm:ChargeDispositionDescriptionText>
                               </chq:ChargeDisposition>
                         </chq:ArrestCharge>
                   </chq:Arrest>
                                                                                           Protection Order
             </chq:CriminalHistory>
             <chq:ProtectionOrder>                                                         info
                   <jxdm:ActivityDate>2001-01-04</jxdm:ActivityDate>
                   <jxdm:ActivityPrimaryOrganization>
                         <jxdm:OrganizationName>PIERCE COUNTY SHERIFFS
       OFFICE</jxdm:OrganizationName>
                   </jxdm:ActivityPrimaryOrganization>
                   <jxdm:ProtectionOrderConditionCode>P-
       06</jxdm:ProtectionOrderConditionCode>
                   <jxdm:ProtectionOrderRestrictedPerson>
                         <jxdm:PersonName>
                               <jxdm:PersonGivenName>SUE</jxdm:PersonGivenName>
                               <jxdm:PersonSurName>SMITH</jxdm:PersonSurName>
                         </jxdm:PersonName>
                   </jxdm:ProtectionOrderRestrictedPerson>
                   <chq:Condition>
                         <jin:ConditionDescriptionText>NO
       CONTACT</jin:ConditionDescriptionText>
                   </chq:Condition>
             </chq:ProtectionOrder>
       </cach:CACHResponse>



   #                                                    Design Feature
  DF57     When no response is received – as expected from an agency, a blank response will be filled in stating
           that the system is either not available, no response from the system or that the response has no data that
           matches



SOAP HEADERS

       The WS-Security and WS-Addressing emerging standards provide the semantics to security and


Version 1.6Error! Bookmark not defined.                                                                        Page 38
                                       Washington JIN CACH Queries Design

      addressing representation. In addition, WS-Reliable Exchange (the combination of WS-Reliable
      Messaging and the related WS-Reliability) Policy standards can be used in the JINDEX environment.
      WS-Security is the web services standard for providing user authentication and privacy semantics to
      SOAP based XML documents. All messages that traverse the JINDEX must include the
      UsernameToken with the submitting agencies ORI.
      WS-Addressing is required to facilitate the asynchronous communication back to the requesting web
      service. For example, when a web service client, such as the BizTalk server issues a
      queryPossibleCriminalHistory request, the addressing information dictates to which web service the
      asynchronous response is to be issued.

WS-Security
      While WSS is not presently required for its privacy and integrity features, it is useful for expressing the
      user who is invoking the web service.
     The following example is from OASIS‟s “Web Services Security Username Token Profile 1.0”
     documentation. It is used to describe how a web service can supply a Username Token as a means of
     identification.
<S11:Envelope xmlns:S11="..." xmlns:wsse="..." xmlns:wsu= "...">
<S11:Header>
  ...
          <wsse:Security>
               <wsse:UsernameToken wsu:Id=”ORI”>
                     <wsse:Username>NNK</wsse:Username>
                     <wsse:Password Type="...#PasswordDigest">
                        weYI3nXd8LjMNVksCKFV8t3rgHh3Rw==
                     </wsse:Password>
                     <wsu:Created>2003-07-16T01:24:32Z</wsu:Created>
               </wsse:UsernameToken>
          </wsse:Security>
          ...
      </S11:Header>
      ...
</S11:Envelope>
      This example demonstrates a simple username/password combination, but the password is not a
      required field. The “wsu:Id” attribute on the Username Token identifies this security token as the ORI
      that is required by WSP.

WS-Addressing
      While the WS-Address specification has not been ratified at the time of this document, it can be
      considered mature for the required fields. The goals of the WS-Address specification align with the
      goals of the Washington JIN Initiative.
     The following is an example of a Request message with WS-Addressing header information
<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
                      xmlns:wsa="http://www.w3.org/2004/08/addressing">
<S:Header>
   <wsa:MessageID>
           http://kc.wa.gov/6B29FC40-CA47-1067-B31D-00DD010662DA
   </wsa:MessageID>
   <wsa:ReplyTo>
      <wsa:Address>http://kc.wa.gov/JILS</wsa:Address>
   </wsa:ReplyTo>
   <wsa:To>http://transact.wa.gov/jindex/criminalhistory/cach</wsa:To>

Version 1.6Error! Bookmark not defined.                                                                         Page 39
                                       Washington JIN CACH Queries Design

   <wsa:Action>http://jindex.wa.gov/CACHQuery</wsa:Action>
</S:Header>
<S:Body>
   ...
</S:Body>
</S:Envelope>


     The response message would look like:
<S:Envelope
  xmlns:S="http://www.w3.org/2003/05/soap-envelope"
  xmlns:wsa="http://www.w3.org/2004/08/addressing">
  <S:Header>
    <wsa:MessageID>
      http://jindex.wa.gov/5C25GQ09-GH14-5839-B93U-23GH987255VB
    </wsa:MessageID>
    <wsa:RelatesTo>
      http://kc.wa.gov/6B29FC40-CA47-1067-B31D-00DD010662DA
    </wsa:RelatesTo>
    <wsa:To S:mustUnderstand="1">
      http://kc.wa.gov/JILS
    </wsa:To>
  <wsa:Action>http://kc.wa.gov/JILS/processCACHQueryResponse</wsa:Action>
  </S:Header>
  <S:Body>
    <jin:CACHResponse xmlns:jin="http://jindex.wa.gov"/>
  </S:Body>
</S:Envelope>



WS-Coordination
      WS-Coordination describes an extensible framework for providing protocols that coordinate the
      actions of distributed applications. Such coordination protocols are used to support a number of
      applications, including those that need to reach consistent agreement on the outcome of distributed
      activities.
      For the purposes of the criminal history queries, the semantics of sharing coordination details is what is
      relevant. While the framework defined in this specification enables an application service to create a
      context needed to propagate an activity to other services and to register for coordination protocols, the
      web services in this project will not create the information – this is the responsibility of the client web
      services.
      The framework enables existing transaction processing, workflow, and other systems for coordination
      to hide their proprietary protocols and to operate in a heterogeneous environment. In short, this
      specification describes a definition of the structure of context and the requirements for propagating
      context between cooperating services.
      While it is possible to express coordinating details or runtime parameters in an application specific
      structure, the solution is application specific and thus not loosely coupled. The advantage of using a
      well-known specification is standardization and extendable to future web services that are already
      implemented and outside the domain of influence of JIN.
      The CoordinationContext is used to pass Coordination information to parties involved in a
      coordination service. CoordinationContext elements are placed within application messages.
      Conveying a context on an application message is commonly referred to as flowing the context. A


Version 1.6Error! Bookmark not defined.                                                                         Page 40
                                         Washington JIN CACH Queries Design

        CoordinationContext provides access to a coordination registration service, a coordination type, and
        relevant extensions.
     The following is an example of a Request message with WS-Coordination header information
<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
                      xmlns:wsa="http://www.w3.org/2004/05/addressing">
<S:Header>
   <wsc:CoordinationContext
          xmlns:wsc=”http://schemas.xmlsoap.org/ws/2004/10/wscoor”>
       <wsc:Expires>86400</wsc:Expires>
       <wsc:Identifier>
          http://kc.wa.gov/6B29FC40-CA47-1067-B31D-00DD010662DA
       </wsc:Identifier>
       <wsc:CoordinatorType></wsc:CoordinatorType>
       <pch:AggregationWait for=”10”/>
   </wsc:CoordinationContext>
   <wsa:MessageID>
           http://kc.wa.gov/6B29FC40-CA47-1067-B31D-00DD010662DA
   </wsa:MessageID>
</S:Header>
<S:Body>
   ...
</S:Body>
</S:Envelope>


        Note that the element /S:Header/wsc:CoordinationContect/wsc:Expires is an unsigned integer that
        specifies the number of seconds this orchestration is to remain active. One day us 86400 seconds
        which is the default and the maximum about of time to wait for all responses.
        The element /S:Header/wsc:CoordinationContect/pch:AggregationWait is a custom element that
        accepts and attribute value “for” which is in seconds (xml:unsignedInt) or the attribute value “until”
        which is a xsd:dateTime field. Each value is validated to ensure that they do not extend the life of the
        aggregation past the expiration of the coordination service.


    #                                                     Design Feature
  DF58      SOAP is used for all web service to help WS-I Basic Profile requirements and interoperability

  DF59      The WS-Addressing web service recommendation is used for representing which web service is to be
            invoked in the response
  DF60      The WS-Addressing web service recommendation is used to express and relate messages using the
            message identifier and relates to identifiers
  DF61      The WS-Security web services recommendation is used to express the state identifier in the user name
            token, specifically the ORI
  DF62      The WS-Coordination web services recommendation is used to express runtime parameters that will be
            shared for multiple, or coordinated compositions of web services.
  DF63      The aggregation and time-to-live values can be specified in the CoordinationContext using the WS-
            Coordination specification


WS-I
        The WS-I or Web Service Interoperability Profile is a series of recommendations that encourage
        interoperability. “The profile was developed according to a set of principles that, together, form the

Version 1.6Error! Bookmark not defined.                                                                            Page 41
                                          Washington JIN CACH Queries Design

        philosophy of the Profile, as it relates to bringing about interoperability”.
     The initiate the conformance claim to the basic profile, the following must be present in every WSDL
     exchanged:
<wsdl:definitions
        xmlns:wsdl="http://schemas.xmlsoap.org/wsdl"
        xmlns:tns="http://example.org/myservice"
        xmlns:soapbind="http://schemas.xmlsoap.org/wsdl/soap"
        xmlns:wsi="http://ws-i.org/schemas/conformanceClaim/"
        targetNamespace="http://example.org/myservice">
<wsdl:portType
        name="MyPortType">
        ...
</wsdl:portType>
<wsdl:binding
        name="MyBinding"
        portType="MyPortType" >
          ...
</wsdl:binding>
<wsdl:service
        name="MyService" >
  <wsdl:port
        name="MyPort" binding="tns:MyBinding" >
    <wsdl:documentation>
       <wsi:Claim conformsTo="http://ws-i.org/profiles/basic/1.0" />
    </wsdl:documentation>
    <soapbind:address location="http://example.org/myservice/myport" />
  </wsdl:port>
</wsdl:service>
</wsdl:definitions>


        A limitation of the Basic Profile 1.0 and 1.1 is that it is limited to SOAP 1.1 messages while SOAP 1.2
        is becoming more popular and is required for WS-Security and WS-Addressing specifications. An
        update to the Basic Profile is expected in by the end of 2005 but conformance claims using SOAP 1.2
        elements will not be compliant. This specifically affects SOAP fault messages.
        Please refer to Appendix B for the requirements of the WS-I Basic Profile 1.1
    #                                                      Design Feature
   DF64     The use of the WS-I Basic Profile is put forth as the recommendation for increasing web service
            interoperability.




Version 1.6Error! Bookmark not defined.                                                                       Page 42
                                         Washington JIN CACH Queries Design

AOC ADAPTER


GENERAL DESCRIPTION

      The AOC is responsible for processing “Get Possible Criminal History” and “Case And Criminal
      History” queries. These queries are issued by the JINDEX and are expected to behave in an
      asynchronous manner. The workflow is two fold: the first query, getPossibleCriminalHistory, is
      expected to return unique identifiers based on tokens such as names and date of birth. From the
      resulting identifiers, an additional query may be issued. This is the caseAndCriminalHistory query and
      it returns more details by provided identifiers.
      In the current environment, the Administrative Office of the Courts uses a WebSphere 5.12 Enterprise
      Application Server as the foundation of the Java Enterprise (J2EE) Architecture. The skill-set at AOC
      is particularly well aligned to use this technology and we recommend leveraging that expertise when
                                                                       introducing the CACH Web Services.
                                                                       The JINDEX is responsible for
                                                                       delegating requests to the AOC.
                                                                       These requests are filtered by
                                                                       information requested – meaning that
                                                                       the AOC will only receive
                                                                       caseAndCriminalHistory requests
                                                                       when there is data that was found
                                                                       when the getPossibleCriminalHistory
      query was issued.


      WebSphere forms the foundation AOC applications and is the infrastructure required for a reliable
      J2EE application. It is assumed that the WebSphere Enterprise Application Server supports the
      following technologies:
              WebSphereMQ
                   o      Message Driven Beans
                   o      JNDI QueueFactory
                   o      JDNI Queue
              Stateless Session Beans
              Axis 1.2 (Axis2 is still beta)

SOLUTION ARCHITECTURE

      The AOC will effectively create a JAX-RPC based service that will be invoked by the JINDEX. JAX-
      RPC is the Java API for XML-Based Remote Procedure Calls and Axis is the reference
      implementation of that API. This style of web services exposes AOC API‟s as web services. The
      advantage is that a reusable service can be protected behind the web service but the service can be
      used for other purposes where web services do not make sense, such as user interfaces or other internal
      systems.
      To handle incoming web service requests, an Axis container will be required. It is responsible for
      identifying the appropriate service that will process the requests – a JAX-RPC client. The JAX-RPC
      client will be created from a WSDL agreed upon between the JINDEX teams and the AOC teams.

Version 1.6Error! Bookmark not defined.                                                                        Page 43
                                         Washington JIN CACH Queries Design

       This client responds to HTTP/S posts from JINDEX and the SOAP envelope will be passed to the
       newly created service. The service will validate that the security information is valid. It will also be
       responsible for implementing any auditing or logging requirements.
       As this request is required to be asynchronous, it is recommend that a Message Driven Bean (MDB) be
       used. This is a common and simple pattern in Java since implementing threads is not recommended in
       an application server. To invoke an MDB, a Message Queuing product is required. While several
       freely available components are available, used of WebShereMQ is preferred. WebSphereMQ is
       assumed included with the enterprise version of the application server. WebSphere Application
                                       Developer (WSAD), the WebSphere IDE provides several tools that
                                       simplify the creation and deployment of an MDB.
                                      The bound MDB is now responsible for invoking another web service
                                      client. This client is responsible for retrieving the appropriate data based
                                      on the incoming message and creating the outgoing XML message. The
                                      web service then forwards the XML document, wrapped in a SOAP
                                      envelope that conforms the specification for the WSDL.
                                      It is recommended that the web service client invoked by the MDB use a
                                      session bean façade to access data from the AOC databases. This session
                                      bean façade is designed to abstract the data access and provide a simple,
                                      consistent way to query data. This session bean façade can also be
                                      reused by other internal applications, reducing internal development
                                      efforts if similar queries are to be developed in-house.
   #                                                      Design Feature
  DF65     The Axis servlet as part of the WebSphere deployment will be used for processing incoming
           SOAP/HTTP/S requests. The AOC implementation is responsible for the creation of this Web Service
           as part of the WSDL supplied by the JINDEX
  DF66     The AOC web service implementation is responsible for maintaining the integrity and quality of the data
           supplied by the back end Case Management System
  DF67     AOC is responsible for the procurement of the X509 v3 Certificate from DST for Transact Washington




Version 1.6Error! Bookmark not defined.                                                                           Page 44
                                     Washington JIN CACH Queries Design

DIAGRAMS


Architecture




Sequence / Orchestration
      The following is a generalization of the message flow in a J2EE environment using web services and
      EJB‟s:




Version 1.6Error! Bookmark not defined.                                                                    Page 45
                                    Washington JIN CACH Queries Design




   #                                               Design Feature
  DF68    An MDB is an asynchronously invoked java bean or application component. It requires a JMS
          implementation or provider to allow a message to be created and dispatched to the MDB




Version 1.6Error! Bookmark not defined.                                                               Page 46
                                   Washington JIN CACH Queries Design

CLASS DIAGRAM




      Package                             Class                                   Description

gov.wa.aoc.jindex.cach.ws   IDofPossibleMatch               Axis generated interface representing the web service
gov.wa.aoc.jindex.cach.ws   IDofPossibleMatchService        Implementation of web service
gov.wa.aoc.jindex.cach.ws   IDofPossibleMatchStub           Axis generated client side web service invoker
gov.wa.aoc.jindex.cach      IDofPossibleMatchMDB            Message Driven Bean that is responsible for executing
                                                            the query to retrieve IDofPossibleMatches using the
                                                            Possible Criminal History Façade.
gov.wa.aoc.jindex.cach      IDofPossibleMatchFacade         Façade to query for Id‟s by possible match. This should
                                                            use transfer objects.
gov.wa.aoc.jindex.cach.ws   CaseAndCriminalHistory          Axis generated interface representing the web service
gov.wa.aoc.jindex.cach.ws   CaseAndCriminalHistoryService   Implementation of web service
gov.wa.aoc.jindex.cach.ws   CaseAndCriminalHistoryService   Axis generated client side web service invoker
                            Stub
gov.wa.aoc.jindex.cach.ws   CaseAndCriminalHistoryMDB       Message Driven Bean that is responsible for executing
                                                            the query to retrieve Case and Criminal Histories using
                                                            the Case and Criminal History Façade.

Version 1.6Error! Bookmark not defined.                                                               Page 47
                                   Washington JIN CACH Queries Design

      Package                              Class                                         Description

gov.wa.aoc.jindex.cach.ws   CaseAndCriminalHistoryFacade           Façade to query for Id‟s by possible match. This should
                                                                   use transfer objects.
gov.wa.aoc.jindex.cach.ws   WSAddress                              Utility object that validates, creates and reads WS-
                                                                   Addressing information
gov.wa.aoc.jindex.cach.ws   WSSecurity                             Utility object that validates, creates and reads WS-
                                                                   Security information
gov.wa.aoc.jindex.cach.bo   IDfromPossibleMatchesBO                Business Object containing information based between
                                                                   the IDbyPossibleMatch Façade and the XML
                                                                   serialization generated by Axis
gov.wa.aoc.jindex.cach.bo   CaseCriminalHistoriesBO                Business Object containing information based between
                                                                   the CaseAndCriminal Façade and the XML serialization
                                                                   generated by Axis

WS-Address
      Method                                                       Description

validate(SOAPHeader)            This method validates that the SOAP Header is valid. A valid SOAP
                                Header must include (in XPath notation relative to SOAP:Header):
                                                    wsa:MessageID
                                                    wsa:RelatesTo (Optional)
                                                    wsa:To
                                                    wsa:ReplyTo
                                                    wsa:Action
                                If validation fails, the method throws a service exception. This exception
                                MUST result in a SOAP Fault where the SOAP:Fault matches the fault
                                codes from the WS-Addressing specification.
                                          See: WS-Address Faults
getInstance(SOAPHeader)         This factory method creates an instance of WSAddress, populated based
                                on the contents of the SOAP header.
createHeader(SOAPHeader)        This method does the opposite of the getInstance method. It creates new
                                SOAP headers based on the contents of the WSAddress instance.



WS-Security
      Method                                                      Description

validate(SOAPHeader)          This method validates that the SOAP Header is valid. A valid SOAP
                              Header must include (in XPath notation relative to SOAP:Header):
                                                  wss:Security/wss:UsernameToken
                                                  wss:Security/wss:UsernameToken/@wssu:Id=”ORI”


Version 1.6Error! Bookmark not defined.                                                                       Page 48
                                         Washington JIN CACH Queries Design

      Method                                                       Description

                                   If validation fails, the method throws a service exception. This exception
                                   MUST result in a SOAP Fault where the SOAP:Fault matches the fault
                                   codes from the WS-Security specification.
                                   See: WS-Security Faults
                                   The only expected validation fault that is expected in this service will be
                                   wsse:FailedAuthentication
getInstance(SOAPHeader)            This factory method creates an instance of WSSecurity, populated based
                                   on the contents of the SOAP header.
createHeader(SOAPHeader)           This method does the opposite of the getInstance method. It creates new
                                   SOAP headers based on the contents of the WSSecurity instance.



COORDINATING DETAILS


Logging
      The AOC Web Services are responsible for maintaining an access audit log and an error and
      debugging log. These two logs are to be separate. Information is to be recorded using log4j an industry
      standard tool for logging application data.
      JINDEX will provide logging functions to assist in debugging and inter-agency auditing functions.
      Generally, a centralized logging service with its own secure repository should be used to store logs.
      Then the middleware infrastructure can be leveraged to keep logging as loosely coupled as possible.
      The following information should be logged as part of the WSP Adapter implementation:
                 Exception Conditions
                      o   Communication Errors with databases or external web services
                      o   Back channel communication errors with Biztalk
      Configuration of the logging is handled by the log4j framework, thus modifications of the
      “log4j.properties” file is required:
                  Property                                                  Value

log4j.category.axisprocessor
                                             ERROR
log4j.threshold                              ALL
log4j.rootAppender                           ALL, accessAuditAppender, debugAppender
log4j.logger.accessAuditAppender.access      INFO
log4j.appender.accessAuditAppender           org.apache.log4j.FileAppender
log4j.appender.accessAuditAppender.File      Destination Audit Log File
log4j.logger.debugAppender.access            DEBUG
log4j.appender.debugAppender                 org.apache.log4j.RollingFileAppender


Version 1.6Error! Bookmark not defined.                                                                          Page 49
                                          Washington JIN CACH Queries Design

                 Property                                                     Value

log4j.appender.debugAppender.File              Destination Audit Log File
log4j.appender.debugAppender.FileSize          500KB
        Ensure that the log4j.properties file has been deployed to %TOMCAT_HOME%/webapps/Axis/WEB-
        INF/classes directory.

FAULTS

     Faults are to be expressed in SOAP 1.2 Format. An example Fault message would follow this form:
<S:Envelope>
 <S:Header>
   <wsa:Action>
     http://schemas.xmlsoap.org/ws/2004/08/addressing/fault
   </wsa:Action>
   <!-- This wsa:Action header must be present for the fault message when
there is an addressing fault -->
 </S:Header>
 <S:Body>
  <S:Fault>
   <S:Code>
    <S:Value>[Code]</S:Value>
     <S:Subcode>
    <S:Value>[Subcode]</S:Value>
     </S:Subcode>
   </S:Code>
   <S:Reason>
     <S:Text xml:lang="en">[Reason]</S:Text>
   </S:Reason>
   <S:Detail>
     [Detail]
  </S:Detail>
  </S:Fault>
 </S:Body>
</S:Envelope>
        In general, the S:Detail will contain exception stack traces to aid in debugging when unexpected faults
        occur. The S:Reason will abide by the relevant specifications. If there is no specification, then text will
        be the exception message.
        Codes and subcodes are presently extraneous information.
    #                                                     Design Feature
  DF69      The AOC Web Services are implemented to fall in the existing pattern of JAX-RPC based services
            hosted in a WebSphere infrastructure.
  DF70      The Password element is required in the UsernameToken in the WS-Security specification




Version 1.6Error! Bookmark not defined.                                                                           Page 50
                                     Washington JIN CACH Queries Design

WSP ACCESS SWITCH ADAPTER




GENERAL DESCRIPTION

      The Washington State Patrol ACCESS Connector is a web service enabled wrapper for the SOP
      components. This model allows the State of Washington to leverage their investment in the Summary
      Offender Profile components. This wrapper will facilitate criminal history query requests in well-
      formed XML. An incoming XML document will adhere to the format required to generate a query.
      The result of the query will be returned asynchronously in another well-formed XML document. Due
      to the complexities of parsing the message switch messages, not all results or elements are
      canonicalized to XML.
      WSP Connector will be deployed to the DIS managed environment and require the following
      infrastructure:
             Apache Tomcat Web Services Container 5.00.30
             JavaVM 1.4.2
             Apache Axis 1.2
             Access to SOP‟s Application Libraries via separate class loader
      Apache Tomcat provides several important services to hosting the web service. First, it provides the
      management services. These will be useful for providing remote management and configuration for the
      WSP connector. It also provides the web component or servlet that will be used to process HTTP
      requests from clients. It is to this component that X.509 certificates will be configured since the

Version 1.6Error! Bookmark not defined.                                                                    Page 51
                                        Washington JIN CACH Queries Design

       container will accept HTTP/S web request.
       Requests will be passed to the Axis servlet engine that processes the SOAP envelope and converts the
       incoming XML message to Java objects for processing. Once the request has been marshaled to java
       objects, a programmatic approach to processing the request can be taken. Axis will also delegate
       requests to the correct service instance. Service stubs are generated as part of the build process and
       should be done using the agreed upon WSDL.
       It is the intention of the WSP Connector design to be a reusable solution for future ACCESS Web
       Service interfaces. Additional services, parsers and queries can be added without interfering with other
       existing services. Thus, this design is a Service Oriented Architecture (SOA), not just because it is
       loosely coupled using web services, but the implementation framework is an SOA as services can be
       exposed in multiple deployments in Axis since they are configurable using Axis XML deployment
       descriptors (WSDD).


   #                                                    Design Feature
  DF71     DST X509 Certificates will be used to validate that connections originated from JINDEX

  DF72     WSP is responsible for the procurement of the X509 v3 Certificate from Transact Washington
           authorized sources (DST)



SUMMARY OFFENDER PROFILE INTEGRATION


Overview
       The summary offender profile (SOP) was a project initiated by the JIN project to demonstrate the
       ability to interact with the WSP ACCESS Switch. SOP was a web-based application intended to be
       used by end users using a web browser. The WSP adaptor is a SOP wrapper that allows systems, not
       users to interact with ACCESS for the purpose of integration.
       SOP has several layers that are useful to the WSP Adaptor and will be leveraged. The first is the
       network query manager. This component manages connections to the switch and builds messages that
       represent responses. The responsibility of the wrapper is to create a new logical front-end or web
       service enable the query manager. The second component to be leveraged is the parsers. The process
       of handling responses from the switch is also to be changed as parsed documents are to be expressed in
       XML, then wrapped in the appropriate SOAP envelope, and dispatched to the originating web service.
       A new coordinator component will be required which is automatically invoked by the SOP/GSI
       framework.

Security
       There are two phases of authentication. The first is authentication against the WSP Adaptor Web
       Service and the second is against the ACCESS switch.




Version 1.6Error! Bookmark not defined.                                                                         Page 52
                                      Washington JIN CACH Queries Design




     The following example is from OASIS‟s “Web Services Security Username Token Profile 1.0”
     documentation. It is used to describe how a web service can supply a Username Token as a means of
     identification. In the case of the JINDEX, the user name is the ORI.
<S11:Envelope xmlns:S11="..." xmlns:wsse="..." xmlns:wsu= "...">
<S11:Header>
  ...
          <wsse:Security>
                <wsse:UsernameToken wsu:Id=”ORI”>
                   <wsse:Username>Assigned ORI</wsse:Username>
                   <wsu:Created>2003-07-16T01:24:32Z</wsu:Created>
                </wsse:UsernameToken>
               <wsse:UsernameToken wsu:Id=”user-id”>
                   <wsse:Username>username</wsse:Username>
                   <wsu:Created>2003-07-16T01:24:32Z</wsu:Created>
               </wsse:UsernameToken>
                <wsse:UsernameToken wsu:Id=”agency-id”>
                   <wsse:Username>Agency Id or Name</wsse:Username>
                </wsse:UsernameToken>
          </wsse:Security>
          ...
      </S11:Header>
      ...
</S11:Envelope>
      This example demonstrates a simple username/password combination, but the password is not a
      required field. The “wsu:Id” attribute on the Username Token identifies this security token as the ORI
      that is required by WSP. It is understood that the current iteration of clients.
     There can be multiple instances of the <UsernameToken> elements, but there can only be one unique
     UsernameToken that will be identified by the Id attribute. Note that the Id attribute must be unique
     amongst the UsernameToken‟s but can be placed anywhere else in the document to relate an element
     to a particular user instance. For example,
<S11:Envelope xmlns:S11="..." xmlns:wsse="..." xmlns:wsu= "...">
<S11:Header>
  ...
           <wsse:Security>
                <wsse:UsernameToken wsu:Id=”ORI”>
                   <wsse:Username>Assigned ORI</wsse:Username>
                   <wsu:Created>2003-07-16T01:24:32Z</wsu:Created>
                </wsse:UsernameToken>
           </wsse:Security>
           ...
      </S11:Header>
      <S11:Body>
         <jin:XXXRequest wsu:Id=”ORI”>
            ...


Version 1.6Error! Bookmark not defined.                                                                        Page 53
                                          Washington JIN CACH Queries Design

       </jin:XXXRequest>
     </S11:Body>
</S11:Envelope>
       In this example, the user identified by Id=”ORI” is bound to the <jin:XXXRequest> elements. This
       mechanism allows a document to be shared with multiple users.
       Finally, Tomcat must be configured with the server X.509 Certificate. This will be used to force only
       authentic clients (using the client X.509 certificate). While it is not necessary to do this for all URLs it
       will be applied to the HOSTNAME:8080\Axis URL at a minimum.
       The following tutorial steps the implementer through how to configure SSL in Tomcat:
       http://jakarta.apache.org/tomcat/tomcat-4.0-doc/ssl-howto.html

Logging
       JINDEX will provide logging functions to assist in debugging and inter-agency auditing functions.
       Generally, a centralized logging service with its own secure repository should be used to store logs.
       Then the middleware infrastructure can be leveraged to keep logging as loosely coupled as possible.
       However, as we will be leveraging SOP and that solution has its own logging components, additional
       information will be available that directly relates to the implementation of the web service. Thus,
       information that can be logged as part of the BizTalk logging framework will be kept out of the local
       logging. However, the following information should be logged as part of the WSP Adapter
       implementation:
                  Exception Conditions
                       o   Communication Errors with ACCESS
                       o   Back channel communication errors with BizTalk
       Configuration of the logging is handled by the GSI framework, thus modifications of the
       “wsp.properties” file is required:
             Property                                                     Value

it.log.directory                       This is the directory where log files are to be placed. It is recommended
                                       that they be placed in a location that is accessible to administrators only.
                                       Thus, since it is understood that a the web service will be deployed to a
                                       Windows 2003 Server instance, a share will be created on that server
                                       called “logs”


                                       \\servername\logs\wsp\access\
it.log.date.format.                    Format of time stamps used for logging errors
                                       Formates are:
                                       yyyy 4 digit years
                                       MM 2 digit months
                                       dd 2 digit days
                                       HH Hours in 24 hour format
                                       mm 2 digit minutes
                                       ss 2 digit seconds


Version 1.6Error! Bookmark not defined.                                                                               Page 54
                                     Washington JIN CACH Queries Design

                 Property                                            Value

                                   zz milliseconds


                                   yyyy-MM-dd HH:mm:ss zz
it.log.date.timezone               The time zone code is to be logged to.


                                   PST
it.log.entry.limit                 The log will automatically cycle after „n‟ number of entries. This
                                   prevents the log from growing to an unmanageable limit.


                                   10 000
it.log.prefix                      The filename prefix. This string forms the prefix for the filename of the
                                   log file


                                   ws-wsp-access-
it.log.suffiix                     The filename suffix or file extension


                                   .log
it.log.error.exit                  If the logger fails, this flag allows the session to terminat. A dangerous
                                   setting that should be set to false always.


                                   false
it.config.log.failure              The properties that are not found are logged to standard I/O


                                   false

CLASS DIAGRAM




FAULTS

     Faults are to be expressed in SOAP 1.2 Format. An example Fault message would follow this form:
<S:Envelope>
 <S:Header>
   <wsa:Action>
     http://schemas.xmlsoap.org/ws/2004/08/addressing/fault


Version 1.6Error! Bookmark not defined.                                                                         Page 55
                                        Washington JIN CACH Queries Design

   </wsa:Action>
   <!-- This wsa:Action header must be present for the fault message when
there is an addressing fault -->
 </S:Header>
 <S:Body>
  <S:Fault>
   <S:Code>
    <S:Value>[Code]</S:Value>
     <S:Subcode>
    <S:Value>[Subcode]</S:Value>
     </S:Subcode>
   </S:Code>
   <S:Reason>
     <S:Text xml:lang="en">[Reason]</S:Text>
   </S:Reason>
   <S:Detail>
     [Detail]
  </S:Detail>
  </S:Fault>
 </S:Body>
</S:Envelope>
      In general, the S:Detail will contain exception stack traces to aid in debugging when unexpected faults
      occur. The S:Reason will abide by the relevant specifications. If there is no specification, then text will
      be the exception message.
      Codes and subcodes are presently extraneous information.

SERIALIZATION

      The parsers are objects that convert the responses from the ACCESS switch to XML Documents. The
      following tables show the items that are parsed as part of the SOP components and how they are
      extended to create XML responses as web services. Marshalling is the process of converting object
      data to an XML
      Note that XPath mappings will be identical for the PCHResponse document, as well as the
      CACHResponse document. In order to avoid replicating this mapping this information, the shortcut
      “//” notation is used. XML elements are qualified in as much detail as possible, in order to maintain the
      correct context in instance documents.
      Note also that not all parsed SOP components are put into XML. There are several reasons for this,
      including:
               Templar has indicated that parser components work with varying degrees of success. Some
                parsers do not work reliably due to unpredictable response formats from source systems
               Much information is repeated across parsed responses from the varying systems. Name, Date
                of Birth, etc. are repeated from almost every system (NCIC, NLETS, DOC, DOL, etc.). In
                order to keep XML responses as compact and efficient as possible, duplicated information is
                not included, unless there is a good possibility that there is business value to repeating the
                information (e.g. DOC may have alias information that NLETS does not)
               State stakeholders did not identify the data elements as requirements in the conceptual/logical
                data modeling process, and as such, elements were not included in the physical model (the
                Justice XML schema subsets). There are hence no current placeholders for the data
               Performance – inclusion of all SOP data elements would be performance and bandwidth
                intensive, especially owing to the requirement to wrap all data in XML tags

Version 1.6Error! Bookmark not defined.                                                                          Page 56
                                         Washington JIN CACH Queries Design

                Service Orientation – stake stakeholders have indicated a prudent desire to service enable
                 individual system queries based on a granularity of business objects (e.g. driving record) and
                 source system (e.g. DOL). SOP provides a “bundling” of data from various systems for
                 various objects. This data will likely be web service enabled in future state projects.


    #                                                     Design Feature
   DF73     The SOP parsers are to be extended to generate the response XML

   DF74     Not all elements will be parsed, only those required

   DF75     The raw output will also be provided with the responses XML



DEPLOYMENT

        Deployment of the WSP adapter will be limited to a simple Java Archive (JAR) file that is to be
        deployed to the Axis instance. Since Axis will be deployed to Tomcat as its own service, the web
        services that will be enabled as part of that deployment will be loaded into the class path for that
        instance.
        Thus, if the Tomcat instance is set to %TOMCAT_HOME% then the jar file will be placed in:
        %TOMCAT_HOME%/webapps/Axis/WEB-INF/lib
        This gives Axis services access to the WSP services when it is loaded via the Tomcat class loaders.
     To complete the deployment of the web service, a web service deployment descriptor is required for
     each service that we will be exposing. When a generic service is to be created, then single service
     descriptor will be required for that. For example:
<?xml version="1.0"?>
<deployment name="defaultServerConfig"
xmlns="http://xml.apache.org/axis/wsdd/"
         xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">

       <service name="gov/wa/jin/wsp/access/ws/QueryXXXXXService"
provider="java:MSG">
       <parameter name="className"
value="gov.wa.jin.wsp.access.access.ws. QueryXXXXXService"/>
       </service>
</deployment>



ACCESS QUERY TRANSFORMATIONS

        The State of Washington desires to enable any ACCESS query through the architecture and framework
        established for the JINDEX and the WSP Adapter. There are approximately 200 individual queries for
        the ACCESS switch, and a consistent set of input fields across the queries. Input fields in ACCESS
        queries can either be implemented in an order-dependant fashion, or “message field codes” can be
        specified and input data can be order-independent.
        As such, a generic framework in which any ACCESS query can be implemented will see a two step
        transformation: (1) Justice XML is transformed into ACCESS XML, and (2) ACCESS XML is
        transformed into the ACCESS message format. The following diagrams show ACCESS XML for QH


Version 1.6Error! Bookmark not defined.                                                                           Page 57
                                      Washington JIN CACH Queries Design

        (PCH) and QR (CACH) queries. Other ACCESS queries could be implemented in a similar manner.
        Refer to the ACCESS manual documentation for specifications on other queries.
     Once data is in the ACCESS XML format, an additional transformation to ACCESS message formats
     can generically be implemented as follows
(sh)s(sx)//MKE+ “.” + //ORI + “. “ +
LOOP over XMLElements
         XMLElement.ElementName + “/” + XMLElement.ElementValue + “.”
ENDLOOP
(ET)


        For example, the following XML

<?xml version="1.0" encoding="UTF-8"?>
<QH xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
       <MKE>QR</MKE>
       <ATN>JOHN LAW</ATN>
       <DOB>19561125</DOB>
       <NAM>SAMPLE, JOHN</NAM>
       <ORI>yourORI</ORI>
       <PUR>C</PUR>
       <RAC>W</RAC>
       <SEX>M</SEX>
</QH>
would be translated into the following ACCESS Query
(sh)s(sx)QH.yourORI. ATN/JOHN LAW.NAM/SAMPLE,
JOHN.SEX/M.RAC/W.DOB/19561125.PUR/C(ET)




    #                                                Design Feature
  DF76      The Web Service interface is responsible for transforming the Access XML into the ACCESS Query
            string
  DF77      JINDEX is responsible for the creation of the ACCESS query XML




Version 1.6Error! Bookmark not defined.                                                                Page 58
                                        Washington JIN CACH Queries Design

CRIMINAL HISTORY TEST CLIENT

      The “Test Client” is a web based testing tool for the CACH queries. This application demonstrates the
      PCH and CACH queries by providing a single query tool that executes the Possible Criminal History
      query. With results form this query, a user will see the results and be able to „drill-down‟ or see to the
      detail of the result set from the PCH query by executing the CACH query.

POSSIBLE CRIMINAL HISTORY QUERY

      As a web form interface, the test client will be a single form.




      Once presented, the user will be able to execute the PCH Query using any of the following search
      criteria:
       Field                                                        Description
First Name              The components of a suspects name. These names should be used for both the real name and
                        the alias names
Middle Name
                        Real Name:
Last Name
                        jin:Subject/jxdm:PersonName/jxdm:PersonGivenName
                        jin:Subject/jxdm:PersonName/jxdm:PersonSurName
                        jin:Subject/jxdm:PersonName/jxdm:PersonMiddleName


                        Alias:
                        jin:Subject/jxdm:PersonAlternateName/jxdm:PersonGivenName
                        jin:Subject/jxdm:PersonAlternateName/jxdm:PersonSurName
                        jin:Subject/jxdm:PersonAlternateName/jxdm:PersonMiddleName


Version 1.6Error! Bookmark not defined.                                                                            Page 59
                                            Washington JIN CACH Queries Design

            Field                                                       Description
FBI Number                   FBI Record Number
                             jin:Subject/jxdm:PersonAssignedIDDetails/:jxdm:PersonFBIID
State Number                 State Identifier (ORI)
                             jin:Subject/jxdm:PersonAssignedIDDetails/:jxdm:PersonStateID
Drivers License              jin:Subject/jxdm:PersonDriversLicense/jxdmLPersonAuthorizationID
SSN                          jin:Subject/jxdm:PersonAssignedIDDetails/:jxdm:PersonSSNID
Date of Birth                The date of birth. This is a simple text entry field where the date is of the form
                             MM/DD/YYYY. Note that this date is a single date. No effort is made to test ranges.
                             If the date is not well formed, the user should be presented with a message with the error.
                             jin:Subject/jxdm:PersonBirthDate
Sex                          Male/Female/Unknown
                             jin:Subject/jxdm:PersonPhysicalDetails/jxdm:PersonSexCode
Address                      Street Address
                             jin:Subject/Residence/LocationAddress/AddressFullText
City                         jin:Subject/Residence/LocationAddress/LocationCityName
State                        jin:Subject/Residence/LocationAddress/LocationStateCode.ncicLIS
ZIP Code                     jin:Subject/Residence/LocationAddress/LocationPostalCodeID
           Press the Search button to execute the PCH Web Service. This web page will then be responsible for
           not only invoking the web service, but for polling for the responses. If the web service invocation
           failed, the fault information should be displayed to the user. If the query is successfully executed, the
           query section should be hidden (automatically by the hide button). Finally, pressing the Search button
           will stop any previously issued query.
           The Search criteria section is a collapsible table. Pressing the Hide button beside the title would make
           the search criteria invisible. The button title would also be changed to Show. This brings the results to
           the focus of the window and makes for a useful printout.
       #                                                     Design Feature
   DF78        All possible PCHRequest XML elements can be entered on the web page test client



POSSIBLE CRIMINAL HISTORY RESULTS

           Results will be presented in a table underneath the query section.




Version 1.6Error! Bookmark not defined.                                                                                Page 60
                                          Washington JIN CACH Queries Design

        Results will have the following columns:
          Field                                                        Description
Name                       The name is a concatenation of the First, Middle and Last Name. If this is an alias, the name
                           should be presented as an “aka”.
                           Each name is a hyperlink that executes the Case and Criminal History query for that record.
                           Name Fields are:
                           jin:Subject/PersonName/PersonGivenName,
                           jin:Subject/PersonName/PersonSurName
                           Aliases are:
                           jin:Subject/PersonAlternateName/PersonGivenName,
                           jin:Subject/PersonAlternateName/PersonSurName
Date of Birth              The date of birth in mm/dd/yyyy format
                           jin:Subject/PersonBirthDate
Address                    The address is a concatenation of the Address, City, State and ZIP codes:
                           Address Line 1
                           Address Line 2
                           City, State, ZIP


                           jin:Subject/Residence/LocationAddress/AddressFullText
                           jin:Subject/Residence/LocationAddress/LocationCityName
                           jin:Subject/Residence/LocationAddress/LocationStateCode.ncicLIS
                           jin:Subject/Residence/LocationAddress/LocationPostalCodeID
Characteristics            This is a breakdown of the personal characteristics of the suspect on file. It is intended to be
                           read in a human readable way:
                           Eye Color (jin:Subject/PersonPhysicalDetails/PersonEyeColorCode), Hair Color
                           (jin:Subject/PersonPhysicalDetails/PersonHairColorCode)
                           Height jin:Subject/PersonPhysicalDetails/PersonHeightMeasure
                           Weight jin:Subject/PersonPhysicalDetails/PersonWeightMeasure
                           Sex jin:Subject/PersonPhysicalDetails/PersonSexCode
                           Race jin:Subject/PersonPhysicalDetails/PersonRaceCode
                           Physical Features jin:Subject/PersonPhysicalDetails/PersonPhysicalFeature
Source                     The source of the record
                           jin:Subject/@sourceText
        The order of the list is to be in the order of the data supplied. Data will not be sorted.


    #                                                      Design Feature

Version 1.6Error! Bookmark not defined.                                                                            Page 61
                                        Washington JIN CACH Queries Design

   #                                                    Design Feature
  DF79      All data elements that can be returned from the PCHResponse message will be displayable in the result
            set
  DF80      Names in the resultset will be used to drive the CACH Query web service. Selecting a hyperlinked name
            will invoke the CACHRequest web service using all ID values returned from the PCHResponse



CASE AND CRIMINAL HISTORY DETAIL

       Once a possible suspect has been selected from the Possible Criminal History results, a user will be
       able to drill-down in detail for the Case and Criminal History data.

Case History Results




          Field                                                    Description
Name                     The name is a concatenation of the First, Middle and Last Name. If this is an alias, the name
                         should be presented as an “aka”.
                         Each name is a hyperlink that executes the Case and Criminal History query for that record.
                         Name Fields are:
                         jin:Subject/PersonName/PersonGivenName,
                         jin:Subject/PersonName/PersonSurName
                         Aliases are:
                         jin:Subject/PersonAlternateName/PersonGivenName,
                         jin:Subject/PersonAlternateName/PersonSurName
Address                  The address is a concatenation of the Address, City, State and ZIP codes:
                         Address Line 1
                         Address Line 2
                         City, State, ZIP
                         jin:Subject/Residence/LocationAddress/AddressFullText,
                         jin:Subject/Residence/LocationAddress/AddressFullText
                         jin:Subject/Residence/LocationAddress/LocationCityName
                         jin:Subject/Residence/LocationAddress/LocationStateCode.ncicLIS
                         jin:Subject/Residence/LocationAddress/LocationPostalCodeID

Version 1.6Error! Bookmark not defined.                                                                       Page 62
                                       Washington JIN CACH Queries Design

          Field                                                  Description
Charge Identification   jin: CourtEventCase/CourtCharge/ChargeID/ID
                        jin: CourtEventCase/CourtCharge/ChargeID/ IDJurisdictionCode.ncicLIS
Charge Name             jin: CourtEventCase/CourtCharge/ChargeStatute/StatuteOffenseCode
                        jin: CourtEventCase/CourtCharge/ChargeStatute/StatuteLevelText
Charge Date             jin:CourtEventCase/CourtCharge/ChargeFilingDate
Description             jin:CourtEventCase/CourtCharge/ChargeDescriptionText
Disposition             jin:CourtEventCase/CourtCharge/ChargeDisposition/ChargeDispositionDescriptionText
Court Name              jin:CourtEventCase/jxdm:ActivityPrimaryOrganization/:jxdm:OrganizationName
Sentence                jin:CourtEventCase/jin:CourtCharge/jxdm:ChargeSentence/jxdm:SentenceDescriptionText



Criminal History Results




          Field                                                  Description
Name                    The name is a concatenation of the First, Middle and Last Name. If this is an alias, the name
                        should be presented as an “aka”.
                        Each name is a hyperlink that executes the Case and Criminal History query for that record.
                        Name Fields are:
                        jin:Subject/PersonName/PersonGivenName,
                        jin:Subject/PersonName/PersonSurName
                        Aliases are:
                        jin:Subject/PersonAlternateName/PersonGivenName,
                        jin:Subject/PersonAlternateName/PersonSurName
Address                 The address is a concatenation of the Address, City, State and ZIP codes:
                        Address Line 1
                        Address Line 2
                        City, State, ZIP
                        jin:Subject/Residence/LocationAddress/AddressFullText,
                        jin:Subject/Residence/LocationAddress/AddressFullText
                        jin:Subject/Residence/LocationAddress/LocationCityName
                        jin:Subject/Residence/LocationAddress/LocationStateCode.ncicLIS


Version 1.6Error! Bookmark not defined.                                                                      Page 63
                                      Washington JIN CACH Queries Design

         Field                                                    Description
                        jin:Subject/Residence/LocationAddress/LocationPostalCodeID
Charge Identification   jin:CriminalHistory/jin:Arrest/jin:ArrestCharge/jxdm:ChargeID/jxdm:ID
Charge Date             jin:CriminalHistory/jin:Arrest/jin:ArrestCharge/jxdm:ChargeFilingDate
Description             jin:CriminalHistory/jin:Arrest/jin:ArrestCharge/jxdm:ChargeDescriptionText
Disposition             jin:CriminalHistory/jin:Arrest/jin:ArrestCharge/jin:
                        ChargeDisposition/jxdm:ChargeDispositionText
Arresting Agency        jin:CriminalHistory/jin:Arrest/jxdm:ActivityPrimaryOrganization/OrganizationName
Status                  jin:Subject/SubjectCautionInformationCode
                        or
                        jin:Subject/SubjectOffenderNoticeCaveat



Protection Orders




         Field                                                    Description
Issue Date              CACHResponse/ProtectionOrder/ActivityDate
Organization            CACHResponse/ProtectionOrder/ActivityPrimaryOrganization/OrganizationName
Condition               CACHResponse/ProtectionOrder/ProtectionOrderConditionCode
Name                    CACHResponse/ProtectionOrder/ProtectionOrderRestrictedPerson/PersonName
Description             CACHResponse/ProtectionOrder/Condition/ConditionDescriptionText



Warrants




         Field                                                    Description
Issue Date              CACHResponse/ArrestWarrant/ActivityDate
Organization            CACHResponse/ArrestWarrant/ActivityPrimaryOrganization/OrganizationName
Description             CACHResponse/ArrestWarrant/WarrantProbableCauseText

Version 1.6Error! Bookmark not defined.                                                                Page 64
                                         Washington JIN CACH Queries Design



   #                                                      Design Feature
  DF81     Results from the Case and Criminal History responses will be displayed in no particular order

  DF82     All elements in the responses will be displayed in the results



ARCHITECTURE

       The Case and Criminal History test client will be designed and implemented much like the SOP
       application. It will be an HTML page, hosted on the Tomcat server instance running the SOP
       application and the WSP Web Service instance.
       The key problem of the test client is that the web services are asynchronous, when a query is executed,
       the responses are not returned as part of the same call. The BizTalk server cannot simply invoke the
       browser to view the results. The browser must pull the results from some source. The messages are
       persisted as part of the aggregation process in the SQL Server database that is bound to the BizTalk
       server. The client application will poll the data source for new results. Polling for new data utilizes a
       new technology common in most browsers called Ajax. Ajax is the name for Asynchronous Java
       Scripting and use of the XMLHTTPRequest method. The goal is to be able to make web calls without
       requiring the user to refresh the browser. Using Ajax allows a web client to utilize web services.
       As the test client is a single page and state will not be maintained as part of the user sessions, there is
       no need for a supporting framework. The presentation layer will be a single pure HTML page with a
       search form, deployed on the Tomcat server. The HTML page is responsible for invoking the PCH
       Query web service. The ReplyTo address of the call must be set to local server.
   #                                                      Design Feature
  DF83     Ajax of Asynchronous JavaScript will be used to automatically retrieve results from the server. This
           better aligns with the asynchronous nature of the web services.
  DF84     The application instance of the SQL Server will be used to store aggregation data for the search results




Version 1.6Error! Bookmark not defined.                                                                              Page 65
                                       Washington JIN CACH Queries Design

Topology




      The Test Client will be deployed to a new instance of the tomcat installation, the same installation that
      hosts the WSP Access adaptor and the SOP Application. The application consists of the Servlet/JSP
      that represents the user interface shown above. The application also contains four additional servlets
      that are effectively synchronous wrappers for the asynchronous web services. These servlets are:
Servlet                            Method      Description
queryPossibleCriminalHistory       POST        This method is responsible for invoking the web service client
                                               that executes the Possible Criminal History query. This is a
                                               post because it must include all the parameters of the search
                                               form to the servlet. The servlet will then respond with the
                                               content of the response of the web service. The client page
                                               must capture the MessageID as this will be used for all the
                                               following servlets.
retrievePossibleCriminalHistory    GET         Passing the MessageID from the PCH query, this servlet will
                                               be invoked automatically by the client using Java Script
                                               embedded on the JSP. This java script uses the
                                               XMLHTTPRequest object to invoke this servlet.
                                               This servlet makes a synchronous call to the database and
                                               returns a complete XML list of the rows. This list can be
                                               generated automatically by using a JDBC web result set using
                                               any JDBC 3.0 compliant driver.
                                               When the call returns, the data must be parsed into the
                                               Possible Criminal History result list using DHTML or
                                               Dynamic HTML.
queryCaseAndCriminalHistory        GET         The CACH query servlet is executed using the get method. It
                                               uses any combination identifiers present: FBI, State
                                               Identification Number, Driver‟s License Number or SSN.


Version 1.6Error! Bookmark not defined.                                                                           Page 66
                                     Washington JIN CACH Queries Design

Servlet                           Method    Description
                                            This method invokes the CACH Query web service using a
                                            key from the previously executed query. Once this query, the
                                            results from any previously executed CACH query should be
                                            cleared.
                                            If the query returns correctly, a message should be displayed
                                            on the web page “Retrieving Case and Criminal History for
                                            <person name>” The MessageID must be saved for executing
                                            the retireveCaseAndCriminalHistory web service.
retrieveCaseAndCriminalHistory    GET       Finally, this servlet is responsible to retrieving the results of
                                            the case and criminal history query in a similar manner as the
                                            retrievePossibleCriminalHistory query.
                                            This servlet makes a synchronous call to the database and
                                            returns a complete XML list of the rows. This list can be
                                            generated automatically by using a JDBC web result set using
                                            any JDBC 3.0 compliant driver.
                                            When the call returns, the data must be parsed into the Case
                                            and Criminal History result list using DHTML or Dynamic
                                            HTML.



Servlet Sequence Diagram




      The role of the servlets is to handle the users‟ web requests. The PCH Request and CACH Request

Version 1.6Error! Bookmark not defined.                                                                         Page 67
                                       Washington JIN CACH Queries Design

      servlets are responsible for invoking the respect web services on the BizTalk server. The ReplyTo
      addresses will be set to the web service instances that must be created as part of the test client.
      Calls to the servlets are asynchronous; this is the nature of the Ajax framework. The responses are also
      asynchronous. The session listener on the web page must validate that the response that is being
      handled must is for the appropriate handler. Because there is no guarantee that the response that is
      coming back was for the last issued request, the handler must determine if the response is for any of
      the following processes:
          1. Execute Possible Criminal History Request
          2. Execute Retrieve Possible Criminal History results
          3. Execute Case and Criminal History requests
          4. Execute Retrieve Case and Criminal History results
      This is accomplished by having each servlet assign a header value to each servlets response. The
      handler can then delegate to the appropriate rendering java script function based on the value of the
      header value.



Web Service Sequence Diagram




      The web service components are responsible for converting the results of the executed queries into
      database rows. These web services are invoked asynchronously by the JINDEX.




Version 1.6Error! Bookmark not defined.                                                                       Page 68
                                       Washington JIN CACH Queries Design

Class Diagram




DEPLOYMENT

      Deployment of the test client will be limited to a simple Web Archive (WAR) file that is to be
      deployed to the Tomcat instance and a jar file that contains the web service instance that will deployed
      to the Axis service. Since Axis will be deployed to Tomcat as its own service, the web services that
      will be enabled as part of that deployment will be loaded into the class path for that instance.
      Thus, if the Tomcat instance is set to %TOMCAT_HOME% then the jar file will be placed in:
      %TOMCAT_HOME%/webapps/Axis/WEB-INF/lib
      The test client WAR file is to be deployed to:
      %TOMCAT_HOME%/webapps
      And Tomcat will automatically install the application.
     To complete the deployment of the web service, a web service deployment descriptor is required for
     each service that we will be exposing. When a generic service is to be created, then single service
     descriptor will be required for that. For example:
<?xml version="1.0"?>
<deployment name="defaultServerConfig"
xmlns="http://xml.apache.org/axis/wsdd/"
         xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">

       <service name="gov/wa/jin/ws/QueryXXXXXService"
provider="java:MSG">
       <parameter name="className"
value="gov.wa.jin.ws.QueryXXXXXService"/>
       </service>
</deployment>



Version 1.6Error! Bookmark not defined.                                                                      Page 69
                                        Washington JIN CACH Queries Design

   #                                                      Design Feature
  DF85    The Test Client will be deployed a Tomcat instance.

  DF86    Servlets will be used as synchronous reads for data

  DF87    Web Services will be used as asynchronous writes of data

  DF88    It is anticipated that no certificates are required for this client




Version 1.6Error! Bookmark not defined.                                         Page 70
                                      Washington JIN CACH Queries Design

WEB SERVICE CLIENTS

      A web service client in the context of the JINDEX is a server application that can invoke the PCH and
      CACH queries that have been designed for the JINDEX. This is not intended to limit the clients to be
      only clients, as the server applications start an asynchronous process, they are also responsible for
      hosting web services that accept the PCM and CACH responses. The semantics of this exchange is
      defined by the supplied PCH and CACH WSDL documents.

GENERAL DESCRIPTION

      For this iteration of the JINDEX implementation, King County and Yakima County are the planned
      web service partners. It is intended that they use the Possible Criminal History WSDL and Case and
      Criminal History WSDL documents exactly how the JINDEX BizTalk implementation uses them to
      invoke services in the Washington State Patrol and Administrative Office of the Courts. The web
      services that the counties invoke in the JINDEX are the same web services that the JINDEX invokes
      on AOC and WSP. The reverse is also true, the responses that AOC and WSP issue to the JINDEX is
      the same responses that JINDEX issues to the originating web services.
      While it is known that the King and Yakima Counties use BizTalk, web services are used to allow
      other counties using any web service enabled technology to use the PCH and CACH queries.

WEB SERVICE META-DATA

      Agency applications are responsible for how the PCH and CACH query data is to be used and how that
      information is to be shared with its user community. However, there are additional behaviors that have
      not been included in the WSDL documents (this is because the web service specifications that would
      support such modeling is not sufficiently mature).
      The following table enumerates additional requirements of the contract between the external web
      service clients and the JINDEX:
Requirement                                         Description
The Possible Criminal History and Case and          When the PCHRequest service is invoked, the
Criminal History requests are asynchronous. When    PCHRequest type is sent. The JINDEX response will
a query is issued an acknowledgment or a fault      either contain a simple string response acknowledging
response is expected                                the request or a SOAP Fault message detailing the
                                                    problem with the issued requst.
                                                    The process is the same for a CACHRequest.
                                                    The web service clients are responsible ensuring that
                                                    their applications respond accordingly. When the
                                                    acknowledgment is received, the application assumes
                                                    success criteria and can continue.
                                                    If a Fault is received, the application request had failed.
                                                    It is the responsibility of the agency to take appropriate
                                                    action. Altering the user of the failure and possibly
                                                    displaying the
                                                    /SOAP:Envelope/SOAP:Fault/SOAP:faultmessage to
                                                    the user and/or administrator.
                                                    As per the WS-I Basic Profiles, the HTTP response
                                                    codes will also convey success and failure information,

Version 1.6Error! Bookmark not defined.                                                                       Page 71
                                       Washington JIN CACH Queries Design

Requirement                                          Description
                                                     the SOAP message is the primary source of
                                                     information.
Any request should have a timeout control. While     This timeout may occur when the request is issued and
it is anticipated that a response will be issued     neither an acknowledgement nor a fault has been
immediately, applications should timeout if the      received.
response message has not been received in a
reasonable period. This is not the same as the
Response messages defined in the WSDL
documents.
For successfully issued query requests, a response   JINDEX will dispatch the results of the queries within
message will be issued within 10 seconds.            10 seconds of the request.
                                                     The application will be able to correlate the response
                                                     back to the original request using the wsa:RelatesTo
                                                     SOAP header. The RelatesTo identifier will match the
                                                     wsa:MessageID field of the query request
A valid wsa:ReplyTo URL be provided                  For Response messages to be dispatched back, the WS-
                                                     Addressing specification provides the construct for the
                                                     reply-to address.
                                                     This address is not validated upon receipt.
Agencies are required to have an ORI for each        An ORI user token is required for each request. This
message request                                      ORI is used for auditing query requests on the JINDEX
                                                     server. Messages that do not have this token will be
                                                     rejected
XML must be well-formed                              A seemingly obvious statement however it is not
                                                     required that the XML validate against the bound
                                                     schemas.
                                                     The broker will not be validating XML against the
                                                     GJXDM ad JIN schemas for the following reasons:
                                                             The large size of the GJXDM 3.0.2 schemes
                                                              makes it computationally expensive to
                                                              validate. Each validation process could run
                                                              over a second and when many messages are
                                                              being processed simultaneously, the load on
                                                              the JINDEX services will increase
                                                              exponentially.
                                                             The data that will be exchanged is not
                                                              guaranteed to be Justice XML compliant.
                                                              Agencies may use code values that are not
                                                              valid
                                                             Data is READ ONLY. This means that there is
                                                              no anticipated need for standardization of code
                                                              values between agencies since data will not be
                                                              persisted.




Version 1.6Error! Bookmark not defined.                                                                        Page 72
                                        Washington JIN CACH Queries Design

FAULTS

     Faults are to be expressed in SOAP 1.2 Format. An example Fault message would follow this form:
<S:Envelope>
 <S:Header>
   <wsa:Action>
     http://schemas.xmlsoap.org/ws/2004/08/addressing/fault
   </wsa:Action>
   <!-- This wsa:Action header must be present for the fault message when
there is an addressing fault -->
 </S:Header>
 <S:Body>
  <S:Fault>
   <S:Code>
    <S:Value>[Code]</S:Value>
     <S:Subcode>
    <S:Value>[Subcode]</S:Value>
     </S:Subcode>
   </S:Code>
   <S:Reason>
     <S:Text xml:lang="en">[Reason]</S:Text>
   </S:Reason>
   <S:Detail>
     [Detail]
  </S:Detail>
  </S:Fault>
 </S:Body>
</S:Envelope>
      In general, the S:Detail will contain exception stack traces to aid in debugging when unexpected faults
      occur. The S:Reason will abide by the relevant specifications. If there is no specification, then text will
      be the exception message.
      Codes and sub-code elements are presently extraneous and not required.



FAULT CODE DATA DICTIONARY



Fault Code                                    Description
soap:VersionMismatch                          Found an invalid namespace for the SOAP Envelope element
soap:MustUnderstand                           An immediate child element of the Header element, with the
                                              mustUnderstands attribute set to 1, was not understood
soap:Client                                   A message was not correctly formed or contained incorrect
                                              information
soap:Server                                   There was a problem with the server so the message could not
                                              proceed
wsa:InvalidMessageAddressingProperty          A message information property cannot be processed
wsa:MessageAddressingPropertyRequired         A required message addressing property is not present
wsa:DestinationUnreachable                    No endpoint can be found capable of acting in the role of the

Version 1.6Error! Bookmark not defined.                                                                         Page 73
                                   Washington JIN CACH Queries Design

Fault Code                                Description
                                          [acting] property
wsa:ActionNotSupported                    The [action] property cannot be processed at the receiver
wsa:EndpointUnavailable                   The endpoint is unable to process the message at this time
wsse:UnsupportedSecurityToken             An unsupported token was provided
wsse:UnsupportedAlgorithm                 An unsupported signature or encryption algorithm was used
wsse:InvalidSecurity                      An error was discovered processing the <wsse:Security> header.
wsse:InvalidSecurityToken                 An invalid security token was provided
wsse:FailedAuthentication                 The security token could not be authenticated or authorized
wsse:FailedCheck                          The signature or decryption was invalid
wsse:SecurityTokenUnavailable             Referenced security token could not be retrieved
chq:SubjectNameRequired                   This fault code can be returned for a PCHRequest or a
                                          CACHRequest where the required Subject Name parameters are
                                          absent.




Version 1.6Error! Bookmark not defined.                                                                 Page 74
                                         Washington JIN CACH Queries Design

SECURITY

       The Security models for the criminal history queries are limited to the following principles:
           1.   Privacy. Data must be visible to authorized entities. Encryption alters the contents of
                messages making it difficult for third parties to decipher. This is relevant to exchanges over
                networks that are not secured or trusted.
           2.   Auditability. It is required by the Washington State Patrol that any requests that utilize
                ACCESS must be auditable. Thus, when PCH and CACH queries are delegated to the
                ACCESS services, an ORI is required from the requesting agency
       Trust and privacy will be established between the agency‟s application and the JINDEX, and between
       JINDEX and another application‟s services using a means that “is appropriate” and is endorsed by
       trading partners. The JINDEX does not mandate the security requirements of the PCH and CACH
       queries nor does it intend to mandate the security for future exchanges.
       As King County and Yakima County already uses Transact Washington for their user authentication,
       the counties can leverage their solution to securely access the JINDEX by the purchase of a server
       certificate.




       The agencies are still required to validate the authenticity of its user base, but from the perspective of
       the JINDEX, each agency is a user.
       The use of the ACCESS services will be facilitated by a series of web services that are hosted on the
       JINDEX but are not publicly accessible. These services are considered secure by WSP as access to
       them is limited to King and Yakima Counties. The use of ACCESS is audited by JINDEX, which
       records the ORI of the party initiating the access.
       Finally, as the AOC is on the state network, the AOC is already trusted. Thus, encryption is not
       required. Unencrypted web services are assumed to scale well and are able to meet the anticipated
       demand.
   #                                                      Design Feature
  DF89     King County and the JINDEX will use X.509 Server Certificates for authentication and in establishing
           SSL sessions
  DF90     Yakima County and the JINDEX will use X.509 Server Certificates for authentication and in
           establishing SSL sessions


Version 1.6Error! Bookmark not defined.                                                                             Page 75
                                         Washington JIN CACH Queries Design

   #                                                      Design Feature
  DF91     WSP does not encrypt access to the ACCCESS web services; these services are not publicly available.

  DF92     Web Services that are invoked between the JINDEX and the AOC will not be encrypted, deprecating
           technical requirement



CERTIFICATES

       While the current solution does not define a common and restrictive security model, such a model
       should be defined as the JINDEX matures. The recommended future model should include message
       level encryption as opposed to transport level encryption using WS-Security specifications. These
       models allow reliable and secure messages with the aid of digital certificates. WS-Security can protect
       the message content and provides a verifiable identities and finally verifiable message integrity.
       Certificates offer a digital form of authentication: an encrypted code that can validate the identity of an
       individual or system. An X.509 certificate is an international standard for digital signature
       representation. It contains information about the owner, the issuer of the certificate (CA - Certificate
       Authority), the owners public key and the CA‟s signature. Certificates are exchanged and used to
       create each SSL connection.
       Digital certificates function as a form of a signature. Agency applications can digitally „sign‟ network
       access and then services can validate the digital signature. A key-pair will be established to establish
       trust. A service will sign a message in combination with the JINDEX‟s public key. Thus, only the
       service and the JINDEX will be able to communicate and the information will remain private.
       The advantages of end-to-end message based security over transport level security may be seen once
       more applications, services, and users are connected through the JINDEX, since inter-agency trust may
       be context specific. For example, the WSP trusts King County‟s JILS application and has an
       established Memorandum of Understanding (MOU) with King County reflecting this trust. If King
       County adds a new publicly accessible application, this will not fall under their existing MOU with
       WSP. Because, however, transport-level, server-to-server security had been implemented between the
       endpoints and the JINDEX, additional programming and custom mechanisms would be required to
       restrict the new, non-approved traffic.
       Message level security accounts for web service scenarios where HTTP is not used. WS-Security
       applies equally well to asynchronous message buses, SMTP and IMAP, even FTP that are all Internet
       technologies.

Transact Washington
       Transact Washington is a State of Washington service that allows internal and external agencies to
       interact with State of Washington agencies. Transact Washington uses X.509 Certificates provided by
       an external trusted certificate authority authenticating all user traffic. For the JINDEX, a TrustID
       Server Certificate is required.
       “The state of Washington has contracted with a licensed certification authority called Digital Signature
       Trust (DST) to issue digital certificates for use in the Transact Washington environment. Digital
       certificates can do more than prove a user's identity. They can be used for digitally signing and
       encrypting documents, which means that business transactions over the Internet can be completed
       without having to follow up with paper copies. The digital certificate allows these online transactions
       to be legally binding.”
       “Digital Signature Trust offers digital certificates to the state of Washington with three different levels
       of security assurance: standard, intermediate and high. The certificate level assigned to a service is


Version 1.6Error! Bookmark not defined.                                                                              Page 76
                                       Washington JIN CACH Queries Design

      based on its security requirements. For example, a certificate with a high level of assurance might be
      necessary for high-dollar transactions, while a certificate with a lower level of assurance may be all
      that's needed when purchasing certain types of permits. More information about Digital Signature
      Trust and the technology of digital certificates is available on their company website at
      www.digsigtrust.com”
          Source: http://transact.wa.gov/twAdmin/moreInfo/about.html
      However, as the JINDEX can invoke web services on other systems – such as the response messages,
      JINDEX requires a client certificate for those systems. For example, King County uses Transact
      Washington to authenticate its users against the JILS application. When JILS invokes a JINDEX web
      service, a JINDEX client certificate is required to authenticate against the JINDEX. When the JINDEX
      responds to JILS as a separate web service call, the JINDEX must authenticate against JILS using a
      different certificate.



JIN Responsibility
      JIN be responsible for procuring a server certificate that will facilitate the SSL encryption between
      Yakima county, King county and the JINDEX
Partner           Service         Certificate Level      Description
Yakima County     jindex-pch      Server                 Possible Criminal History
Yakima County     jindex-cach     Server                 Case and Criminal History
King County       jindex-pch      Server                 Possible Criminal History
King County       jindex-cach     Server                 Case and Criminal History
      These services should NOT be published as public by Transact Washington‟s service list.




Version 1.6Error! Bookmark not defined.                                                                        Page 77
                                      Washington JIN CACH Queries Design

APPENDIX A – ACCESS PARSER MAPPINGS


POSSIBLE CRIMINAL HISTORY RECORDS

      The Possible Criminal History Records are used to create individual PCHResponse messages. Each
      record type creates a single PCHResponse message.
      When the PCHRequest is received by the JINDEX, JINDEX is responsible for issuing the DW and the
      QWH queries to ACCESS. These records describe what the expected records are from ACCESS and
      how they are used to create PCHResponse messages.
      The records described in this section are not restricted to a specific query type. This means that the
      NCIC Protection Order Record can be created by both the DW and QWH queries. While the context is
      different, the parsing is the same.

NCIC Protection Order Record
WA0340500

*****WARNING -         THE FOLLOWING IS AN NCIC PROTECTION
ORDER RECORD.          DO NOT SEARCH, DETAIN, OR ARREST BASED
SOLELY ON THIS         RECORD. CONTACT ENTERING AGENCY TO
CONFIRM STATUS         AND TERMS OF PROTECTION ORDER*****

****THE SUBJECT OF THIS RECORD IS PROHIBITED FROM
RECEIVING OR POSSESSING A FIREARM UNDER FEDERAL LAW
(TITLE 18, U.S.C., SECTION 922)****

MKE/PROTECTION ORDER
ORI/WA0340500 NAM/REC0RD,TEST SEX/M RAC/W POB/WA
DOB/19490804
HGT/500 WGT/300 EYE/BR0 HAI/BR0 SKN/FAR SMT/SC R SHLD
SOC/123456789
OLN/WA123123 OLS/WA OLY/2005
PNO/TEST1234 BRD/Y ISD/20000321 EXP/NONEXP
CTI/WA034025J
PPN/REC0RD,MISSUS PSX/F PPR/W PPB/19490408
PCO/THE SUBJECT IS RESTRAINED FROM ASSAULTING,
THREATENING, ABUSING, HARASSING,
PCO/FOLLOWING, INTERFERING, OR STALKING THE PROTECTED
PERSON AND/OR THE CHILD
PCO/OF THE PROTECTED PERSON.
OCA/TEST1234
MIS/TEST REC0RD 0NLY
NIC/H490416753 DTE/20000321 1508 EST




         Field                                              XPath Map

Source                   //Subject/@sourceText=”NCIC”

Source ID                //Subject/@sourceIDText=”PROTECTION ORDER”

Name (First, Middle,     //Subject/PersonName/PersonGivenName



Version 1.6Error! Bookmark not defined.                                                                    Page 78
                                    Washington JIN CACH Queries Design

         Field                                        XPath Map
Last)                    //Subject/PersonName/PersonMiddleName

(NAM)                    //Subject/PersonName/PersonSurName

Name (First, Middle,     //Subject/PersonAlternateName/PersonGivenName
Last)                    //Subject/PersonAlternateName/PersonMiddleName

(AKA)                    //Subject/PersonAlternateName/PersonSurName

Sex (SEX)                //Subject/PersonPhysicalDetails/PersonSexCode

Race (RAC)               //Subject/PersonPhysicalDetails/PersonRaceCode

Eye Color (EYE)          //Subject/PersonPhysicalDetails/PersonEyeColorCode

Weight (WGT)             //Subject/PersonPhysicalDetails/PersonWeightMeasure

Height (HGT)             //Subject/PersonPhysicalDetails/PersonHeightMeasure

Hair (HAI)               //Subject/PersonPhysicalDetails/PersonHairColorCode

Date of Birth (DOB)      //Subject/PersonBirthDate

Scars, Marks &           //Subject/PersonPhysicalDetails/PersonPhysicalFeature/
Tattoo‟s (SMT)           PhysicalFeatureDescriptionText

Driver‟s License         //Subject/PersonDriversLicense/DriverAuthorizationID/ID
Number (MKE/OLN)
Driver‟s License State   //Subject/PersonDriversLicense/DriverAuthorizationID/
                         IDJurisdictionCode.ncicLIS
(MKE/OLS)
Driver‟s License         //Subject/PersonDriversLicense/
Expiration Year          DriverAuthorizationExpirationDate
(MKE/OLY)
Social Security          //Subject/PersonAssignedIDDetails/PersonSSNID/ID
Number (SOC)
FBI Number (FBI)         //Subject/PersonAssignedIDDetails/PersonFBIID/ID

State ID (SID)           //Subject/PersonAssignedIDDetails/PersonStateID/ID
                         //Subject/PersonAssignedIDDetails/PersonStateID/
                         IDJurisdictionCoded.ncicLIS

Street Address           //Subject/Residence/LocationAddress/AddressFullText

Address Line 1
City, State, Zip         Parse out into
                         //Subject/Residence/LocationAddress/LocationCityName
Address Line 2           //Subject/Residence/LocationAddress/LocationStateCode/ncicLIS
                         //Subject/Residence/LocationAddress/LocationPostalCodeID/ID




NCIC Wanted Person Record
WA0340500
MKE/WANTED PERSON
ORI/DSE/20500415 NAM/DOE, JOHN J SEX/M RAC/W POB/WA
DOB/19500101
HGT/511 WGT/200 EYE/BR0 HAI/BRO FBI/123456A SKN/MED


Version 1.6Error! Bookmark not defined.                                                  Page 79
                                    Washington JIN CACH Queries Design

FPC/DIPMPMP013POPOCOPI13 MNU/OA-AB1234512 SOC/555555555
OFF/DAMAGE PROP - PUBLIC-WITH EXPLOSIVE
DOW/20000405 OCA/TEST-TEST
MIS/TEST REC0RD TEST REC0RD
ORI IS SHERIFF’S OFFICE THURSTON COUNTY OLYMPIA 360 555-
1212
NIC/W370679163 DTE/20000427 1926 EDT
IMMED CONFIRM WARRANT AND EXTRADITION WITH ORI




         Field                                            XPath Map

Source                 //Subject/@sourceText=”NCIC”

Source ID              //Subject/@sourceIDText=”WANTED PERSON”

Name (First, Middle,   //Subject/PersonName/PersonGivenName
Last)                  //Subject/PersonName/PersonMiddleName

(NAM)                  //Subject/PersonName/PersonSurName

Name (First, Middle,   //Subject/PersonAlternateName/PersonGivenName
Last)                  //Subject/PersonAlternateName/PersonMiddleName

(AKA)                  //Subject/PersonAlternateName/PersonSurName

Sex (SEX)              //Subject/PersonPhysicalDetails/PersonSexCode

Race (RAC)             //Subject/PersonPhysicalDetails/PersonRaceCode

Eye Color (EYE)        //Subject/PersonPhysicalDetails/PersonEyeColorCode

Weight (WGT)           //Subject/PersonPhysicalDetails/PersonWeightMeasure

Height (HGT)           //Subject/PersonPhysicalDetails/PersonHeightMeasure

Hair (HAI)             //Subject/PersonPhysicalDetails/PersonHairColorCode

Date of Birth (DOB)    //Subject/PersonBirthDate

Scars, Marks &         //Subject/PersonPhysicalDetails/PersonPhysicalFeature/
Tattoo‟s (SMT)         PhysicalFeatureDescriptionText

Social Security        //Subject/PersonAssignedIDDetails/PersonSSNID/ID
Number (SOC)
State ID (SID)         //Subject/PersonAssignedIDDetails/PersonStateID/ID
                       //Subject/PersonAssignedIDDetails/PersonStateID/
                       IDJurisdictionCoded.ncicLIS

FBI Number (FBI)       //Subject/PersonAssignedIDDetails/PersonFBIID/ID

Misc. Identifying      //Subject/PersonAssignedIDDetails/PersonOtherID/ID
Number (MNU)           //Subject/PersonAssignedIDDetails/PersonOtherID/ID/IDTypeText

                       Minimum of four and maximum of 21 characters are required. The first two
                       characters must be a valid two-character alphabetic code from the Personal
                       Descriptors of the NCIC Code Manual. The third character must be a hyphen.
                       Entry of one zero only or a run of zeros only is prohibited in positions 4 through
                       15. An originating agency police or identification number in MNU cannot be the
                       only numeric identifier in the record.

Version 1.6Error! Bookmark not defined.                                                                     Page 80
                                   Washington JIN CACH Queries Design



WACIC Protection Order Record
WWCIC TIME: 1210 DATE: 032100 TO: LRKPD
QW.WA0340500.NAM/RECORD, TEST.DOB/19490804

------ RECORD NUMBER 1 OF 1 ------
*** NOT A WARRANT ***
RESTRAINING ORDER (BASED ON DOB,NAM)
MKE/EPO ORI/WA0340500 NAM/RECORD,TEST.M.W.WA.08/04/1949
HGT/500 WGT/300 EYE/BRO HAI/BRO SKN/FAR
OCA/TEST1234 SMT/SC R SHLD
RTP/RO   ORDER NUMBER/TEST1234   SERVED/YES   PCO/01
DOI/03/21/2000 EXD/NONEXP ORC/WA034025J BRADY/Y
MIS/TEST RECORD ONLY
PROTECTED PERSON/RECORD,MISSUS.F.W.04/08/1949

ENT: 03/21/2000 AT 1206 FROM LRKPD            BY/PD LITTLEROCK
(LRKPD)
WAC/00R0016123 NIC/H490416753




  Field                                           XPath Map

Source       //Subject/@sourceText=”WWCIC”

Source ID    //Subject/@sourceIDText=”PROTECTION ORDER”

Name         //Subject/PersonName/PersonGivenName
(First,      //Subject/PersonName/PersonMiddleName
Middle,      //Subject/PersonName/PersonSurName
Last)
(NAM)
Name         //Subject/PersonAlternateName/PersonGivenName
(First,      //Subject/PersonAlternateName/PersonMiddleName
Middle,      //Subject/PersonAlternateName/PersonSurName
Last)
(AKA)
Sex (SEX)    //Subject/PersonPhysicalDetails/PersonSexCode

Race         //Subject/PersonPhysicalDetails/PersonRaceCode
(RAC)
Eye Color    //Subject/PersonPhysicalDetails/PersonEyeColorCode
(EYE)
Weight       //Subject/PersonPhysicalDetails/PersonWeightMeasure
(WGT)
Height       //Subject/PersonPhysicalDetails/PersonHeightMeasure
(HGT)
Hair (HAI)   //Subject/PersonPhysicalDetails/PersonHairColorCode



Version 1.6Error! Bookmark not defined.                                 Page 81
                                     Washington JIN CACH Queries Design

   Field                                            XPath Map

Date of        //Subject/PersonBirthDate
Birth
(DOB)
Scars,         //Subject/PersonPhysicalDetails/PersonPhysicalFeature/
Marks &        PhysicalFeatureDescriptionText
Tattoo‟s
(SMT)
Social         //Subject/PersonAssignedIDDetails/PersonSSNID/ID
Security
Number
(SOC)
FBI            //Subject/PersonAssignedIDDetails/PersonFBIID/ID
Number
(FBI)
State ID       //Subject/PersonAssignedIDDetails/PersonStateID/ID
               //Subject/PersonAssignedIDDetails/PersonStateID/ IDJurisdictionCoded.ncicLIS
(SID)
Street         //Subject/Residence/LocationAddress/AddressFullText
Address
Address
Line 1
City, State,   Parse out into
               //Subject/Residence/LocationAddress/LocationCityName
Zip            //Subject/Residence/LocationAddress/LocationStateCode/ncicLIS
               //Subject/Residence/LocationAddress/LocationPostalCodeID/ID
Address
Line 2



WACIC Warrant
     There are two types of warrants we see, the Felony Warrant and Misdemeanor Warrants. They are of
     the same record type format.
WWCIC TIME: 1622 DATE: 042700 TO: ABCPD
QW.WA0340500.NAM/DOE, JOHN J.DOB/19500101

------ RECORD NUMBER 1 OF 1 ------
FELONY WARRANT (BASED ON DOB,NAM)
MKE/EWF ORI/WA0340500 NAM/DOE, JOHN J
.M.W.WA.01011950
HGT/511 WGT/200 EYE/BRO HAI/BRO
OCA/TEST123
OFF/4809
OFL/UNAUTH COMMUNICATION WITH PRISONER
DOW/04/05/2000 ORC/WA034013J
TOW/FS
MIS/TEST RECORD TEST RECORD
ENT: 04/27/2000 AT 1621 FROM ABCPD BY/PD ANYTOWN (ABCPD)
UPD: 04/27/2000 AT 1622 FROM
WAC/00W0071505


Version 1.6Error! Bookmark not defined.                                                                 Page 82
                                    Washington JIN CACH Queries Design



         Field                                          XPath Map

Source           //Subject/@sourceText=”WWCIC”

Source ID        //Subject/@sourceIDText=”FELONY WARRANT”

Name (First,     //Subject/PersonName/PersonGivenName
Middle,          //Subject/PersonName/PersonMiddleName
Last)            //Subject/PersonName/PersonSurName
(NAM)
Name (First,     //Subject/PersonAlternateName/PersonGivenName
Middle,          //Subject/PersonAlternateName/PersonMiddleName
Last)            //Subject/PersonAlternateName/PersonSurName
(AKA)
Sex (SEX)        //Subject/PersonPhysicalDetails/PersonSexCode

Race (RAC)       //Subject/PersonPhysicalDetails/PersonRaceCode

Eye Color        //Subject/PersonPhysicalDetails/PersonEyeColorCode
(EYE)
Weight           //Subject/PersonPhysicalDetails/PersonWeightMeasure
(WGT)
Height           //Subject/PersonPhysicalDetails/PersonHeightMeasure
(HGT)
Hair (HAI)       //Subject/PersonPhysicalDetails/PersonHairColorCode

Date of Birth    //Subject/PersonBirthDate
(DOB)
Scars, Marks     //Subject/PersonPhysicalDetails/PersonPhysicalFeature/
& Tattoo‟s            PhysicalFeatureDescriptionText
(SMT)
Social           //Subject/PersonAssignedIDDetails/PersonSSNID/ID
Security
Number
(SOC)
State ID         //Subject/PersonAssignedIDDetails/PersonStateID/ID
                 //Subject/PersonAssignedIDDetails/PersonStateID/ IDJurisdictionCoded.ncicLIS
(SID)
FBI Number       //Subject/PersonAssignedIDDetails/PersonFBIID/ID
(FBI)
Street           //Subject/Residence/LocationAddress/AddressFullText
Address
Address
Line 1
City, State,     Parse out into
                 //Subject/Residence/LocationAddress/LocationCityName
Zip              //Subject/Residence/LocationAddress/LocationStateCode/ncicLIS
                 //Subject/Residence/LocationAddress/LocationPostalCodeID/ID


Version 1.6Error! Bookmark not defined.                                                         Page 83
                                      Washington JIN CACH Queries Design

         Field                                             XPath Map

Address
Line 2



WACIC Possible Criminal History Record
      This is a general Possible Criminal History Record. Often it is found on its own, however this record
      has been used in combination with other record types. If this record is bound to another record, this
      information supercedes the other data.
Record relating to other data
*** WASIS IDENTIFICATION INFORMATION BASED ON SID/PCN IN WARRANT ***
*** POSSIBLE CRIMINAL HISTORY RECORD ***
*** DO NOT ARREST ON THIS INFORMATION ***
NAM/TEST,TEST DOB/01/22/1974 SEX/M RAC/W
SID/WA1587TEST PCN/ FBI/659012TST
HGT/500 WGT/135 EYE/BRO HAI/BLK POB/MM
DOB/04/05/1972 /12/25/1975 /01/22/1974
SOC/548657654
AKA/COLIN,TEST P /TEST,TEST COLIN /TEST,TEST E
AKA/TEST,TEST G /PERETE,GAUDENCIO C /TEST,TEST
AKA/TEST,TEST TST /TESTTET,TEST TEST /TEST,TEST C
AKA/TEST,JUAN C /TEST,T E


Solo Record
------ RECORD NUMBER 3 OF 6 ------
SID/WA1765TEST NAM/TEST,JAMES D DOB/03/26/1978
FBI/291959TEST HGT/601 WGT/250 HAI/BRO EYE/BRO
*** POSSIBLE CRIMINAL HISTORY RECORD ***
*** DO NOT ARREST ON THIS INFORMATION ***
NUMBER OF FTAs: 3

***CONVICTED FELON***


         Field                                             XPath Map

Source           //Subject/@sourceText=”WWCIC”

Source ID        //Subject/@sourceIDText=”Possible Criminal History Record”

                      Only populate for Solo record
Name (First,     //Subject/PersonName/PersonGivenName
Middle,          //Subject/PersonName/PersonMiddleName
Last)            //Subject/PersonName/PersonSurName
(NAM)
Name (First,     //Subject/PersonAlternateName/PersonGivenName
Middle,          //Subject/PersonAlternateName/PersonMiddleName
Last)            //Subject/PersonAlternateName/PersonSurName
(AKA)


Version 1.6Error! Bookmark not defined.                                                                       Page 84
                                    Washington JIN CACH Queries Design

         Field                                       XPath Map

Sex (SEX)        //Subject/PersonPhysicalDetails/PersonSexCode

Race (RAC)       //Subject/PersonPhysicalDetails/PersonRaceCode

Eye Color        //Subject/PersonPhysicalDetails/PersonEyeColorCode
(EYE)
Weight           //Subject/PersonPhysicalDetails/PersonWeightMeasure
(WGT)
Height           //Subject/PersonPhysicalDetails/PersonHeightMeasure
(HGT)
Hair (HAI)       //Subject/PersonPhysicalDetails/PersonHairColorCode

Date of Birth    //Subject/PersonBirthDate
(DOB)
Scars, Marks     //Subject/PersonPhysicalDetails/PersonPhysicalFeature/
                 PhysicalFeatureDescriptionText
& Tattoo‟s
(SMT)
Social           //Subject/PersonAssignedIDDetails/PersonSSNID/ID
Security
Number
(SOC)
State ID         //Subject/PersonAssignedIDDetails/PersonStateID/ID
                 //Subject/PersonAssignedIDDetails/PersonStateID/IDJurisdictionCoded.ncicLIS
(SID)
FBI Number       //Subject/PersonAssignedIDDetails/PersonFBIID/ID
(FBI)
Street           //Subject/Residence/LocationAddress/AddressFullText
Address
Address
Line 1
City, State,     Parse out into
                 //Subject/Residence/LocationAddress/LocationCityName
Zip              //Subject/Residence/LocationAddress/LocationStateCode/ncicLIS
                 //Subject/Residence/LocationAddress/LocationPostalCodeID/ID
Address
Line 2



DOL Record
DOLDB6849YP219.D ..WA03905L9.OLN/TEST*280QT
                           SOC/624-66-4897     06-22-05                          RESTRICTIONS:
LAST RIOS,FIRST                   DOB/11-30-1972 FEMALE
R/543 S PHILLPS RD                EYE/BRN;HGT/5-02;WGT/155
R/MABTON                   WA 98935

PDL:ISS/09-09-02           EXP/11-30-06      DUI/PC 00 VH 00 CDL:STATUS: NONE
  STATUS: CLEAR                              RECK   00 VA 00
                                             DWLS/R 1ST:00 DWLS/R 2ND:00 DWLS/R
3RD:00

Version 1.6Error! Bookmark not defined.                                                        Page 85
                                       Washington JIN CACH Queries Design




         Field                                              XPath Map

Source           //Subject/@sourceText=”DOL”

Name (First,     //Subject/PersonName/PersonGivenName
Middle,          //Subject/PersonName/PersonMiddleName
Last)            //Subject/PersonName/PersonSurName
(NAM)
Sex (SEX)        //Subject/PersonPhysicalDetails/PersonSexCode

Eye Color        //Subject/PersonPhysicalDetails/PersonEyeColorCode
(EYE)
Weight           //Subject/PersonPhysicalDetails/PersonWeightMeasure
(WGT)
Height           //Subject/PersonPhysicalDetails/PersonHeightMeasure
(HGT)                  The height is not in standard format. DOL uses 5-09 to mean 509. Remove the „-„
                       when parsing
Hair (HAI)       //Subject/PersonPhysicalDetails/PersonHairColorCode

Date of Birth    //Subject/PersonBirthDate
(DOB)
Social           //Subject/PersonAssignedIDDetails/PersonSSNID/ID
Security
Number
(SOC)
License
Number
(OLN)
Street           //Subject/Residence/LocationAddress/AddressFullText
Address
Address
Line 1 (R)
City, State,     Parse out into
                 //Subject/Residence/LocationAddress/LocationCityName
Zip              //Subject/Residence/LocationAddress/LocationStateCode/ncicLIS
                 //Subject/Residence/LocationAddress/LocationPostalCodeID/ID
Address
Line 2
(R line two)



NCIC Interstate Criminal History Record
     The interstate criminal history record is a positional based parser. For example, if the FBI No. is 57
     characters from the left, the actual number will appear 57 characters from the left on the next line.
7L01UGPPD                 V


Version 1.6Error! Bookmark not defined.                                                                       Page 86
                                    Washington JIN CACH Queries Design

WA0390400
THIS NCIC INTERSTATE IDENTIFICATION INDEX RESPONSE IS THE RESULT OF YOUR
INQUIRY ON NAM/LAST,FIRST MIDDLE SEX/M RAC/W DOB/19821008
 SOC/574702065 PUR/C
NAME                            FBI NO.        INQUIRY DATE
LAST,FIRST MIDDLE               65231NA0       2005/06/22

SEX RACE BIRTH DATE          HEIGHT WEIGHT EYES HAIR           BIRTH PLACE   PHOTO
M   W    1982/10/08          600    160    HAZ BRO             ALASKA        N

FINGERPRINT CLASS               PATTERN CLASS
                                WU WU RS WU RS WU WU LS WU AU
                                            WU LS          WU
ALIAS NAMES
LAST,FIRST GUNNAR                    LAST,FIRST
LAST,FIRST A                         LAST,FIRST ARNOLD
LAST,FIRST GUNNAR ARNOLD

SCARS-MARKS-
TATTOOS              SOCIAL SECURITY
TAT L FGR            XXX-XX-XXXX

IDENTIFICATION DATA UPDATED 2005/06/22

THE CRIMINAL HISTORY RECORD IS MAINTAINED AND AVAILABLE FROM THE

FOLLOWING:
 ALASKA         - STATE ID/AK12345678
 WASHINGTON STA - STATE ID/WA12345678

THE RECORD(S) CAN BE OBTAINED THROUGH THE INTERSTATE IDENTIFICATION
INDEX BY USING THE APPROPRIATE NCIC TRANSACTION.

END



         Field                                        XPath Map

Source           //Subject/@sourceText=”NCIC”

Source ID        //Subject/@sourceIDText=”Criminal History Record”

Name (First,          //Subject/PersonName/PersonGivenName
Middle,          //Subject/PersonName/PersonMiddleName
Last)            //Subject/PersonName/PersonSurName
(NAME)
Name (First,     //Subject/PersonAlternateName/PersonGivenName
Middle,          //Subject/PersonAlternateName/PersonMiddleName
Last)            //Subject/PersonAlternateName/PersonSurName
(ALIAS
NAMES)
Sex (SEX)        //Subject/PersonPhysicalDetails/PersonSexCode

Race             //Subject/PersonPhysicalDetails/PersonRaceCode



Version 1.6Error! Bookmark not defined.                                              Page 87
                                       Washington JIN CACH Queries Design

       Field                                               XPath Map
(RACE)
Eye Color       //Subject/PersonPhysicalDetails/PersonEyeColorCode
(EYES)
Weight          //Subject/PersonPhysicalDetails/PersonWeightMeasure
(WEIGHT)
Height          //Subject/PersonPhysicalDetails/PersonHeightMeasure
(HEIGHT)
Hair (HAIR)     //Subject/PersonPhysicalDetails/PersonHairColorCode

Date of Birth   //Subject/PersonBirthDate
(BIRTH
DATE)
Scar-Marks -    //Subject/PersonPhysicalDetails/PersonPhysicalFeature/
Tattoo          PhysicalFeatureDescriptionText

Social          //Subject/PersonAssignedIDDetails/PersonSSNID/ID
Security
Number
FBI Number      //Subject/PersonAssignedIDDetails/PersonFBIID/ID
(FBI)
State ID        //Subject/PersonAssignedIDDetails/PersonStateID/ID
                //Subject/PersonAssignedIDDetails/PersonStateID/ IDJurisdictionCoded.ncicLIS
(SID)
Street          //Subject/Residence/LocationAddress/AddressFullText
Address
Address
Line 1
City, State,    Parse out into
                //Subject/Residence/LocationAddress/LocationCityName
Zip             //Subject/Residence/LocationAddress/LocationStateCode/ncicLIS
                //Subject/Residence/LocationAddress/LocationPostalCodeID/ID
Address
Line 2



CRIMINAL HISTORY RECORDS

       The Criminal History Records are used to create individual CACHResponse messages. Each record
       type creates a single CACHResponse message. Bound to each CACHResponse message is a Subject.
       The Subject record in the response must match that of the Subject element passed to the query in the
       first place, with the possible addition of more details provided by the result records from ACCESS.
       The records described in this section are not restricted to a specific query type. This means that the
       NCIC Protection Order Record can be created by both the DW and QWH queries. While the context is
       different, the parsing is the same.




Version 1.6Error! Bookmark not defined.                                                                       Page 88
                                   Washington JIN CACH Queries Design

Washington State Criminal History Record
WWCIC    UGPPD)PAGE 1
QR.WA0390400.FBI/65231XB0.ATN/CITY ATN PAT TRUE.PUR/C

ATN/CITY ATN PAT TRUE
WASHINGTON STATE CRIMINAL HISTORY RECORD FOR SID/WA20595975
                           WASHINGTON STATE PATRO
                 IDENTIFICATION AND CRIMINAL HISTORY SECTION
                                P.O. BOX 42633
                        OLYMPIA, WASHINGTON 98504-2633
*******************************************************************************
                                   NOTICE
THE FOLLOWING TRANSCRIPT OF RECORD IS FURNISHED FOR OFFICIAL USE ONLY.
SECONDARY DISSEMINATION OF THIS CRIMINAL HISTORY RECORD INFORMATION IS
PROHIBITED UNLESS IN COMPLIANCE WITH THE WASHINGTON STATE CRIMINAL RECORDS
PRIVACY ACT, CHAPTER 10.97 RCW.

POSITIVE IDENTIFICATION CAN ONLY BE BASED UPON FINGERPRINT COMPARISON. BECAUSE
ADDITIONS OR DELETIONS MAY BE MADE AT ANY TIME, A NEW COPY SHOULD BE REQUESTED
FOR SUBSEQUENT USE. WHEN EXPLANATION OF A CHARGE OR DISPOSITION IS NEEDED,
COMMUNICATE DIRECTLY WITH THE AGENCY THAT SUPPLIED THE INFORMATION TO THE
WASHINGTON STATE PATROL.
*******************************************************************************

SID NUMBER       NAME                                FBI NUMBER     DOC NUMBER
WA20595975       LAST,FIRST G                        65231NA0

===============================================================================
                              PERSON INFORMATION
===============================================================================
   SEX   RACE HEIGHT WEIGHT      EYES    HAIR    PLACE OF BIRTH   CITIZENSHIP
    M     W      601     155     HAZ     BRO           AK             US
                                                       XX             XX

NAMES USED                            DATES OF     SOC SEC        MISC NUMBER
LAST,FIRST   GUNNAR                   BIRTH        NUMBER
LAST,FIRST   GUNNAR                   10/08/1982   574-XX-XXXX
LAST,FIRST   ARNOLD
LAST,FIRST   GUNNAR ARNOLD
LAST,FIRST
LAST,FIRST   A

DNA TAKEN: Y DNA TYPED: N

===============================================================================
                      SCARS, MARKS, TATTOOS, AMPUTATIONS
===============================================================================
LOCATION       DESCRIPTION             LOCATION       DESCRIPTION
TAT L HND

===============================================================================
                   CONVICTION AND/OR ADVERSE FINDING SUMMARY
===============================================================================

1 FELONY(S)                                                             DISPOSITION DATE
      TAKING MOTOR VEHICLE WITHOUT PERMISSIONFELONY                       09/08/2004
3 GROSS MISDEMEANOR(S)
      DOMESTIC VIOLENCE COURT ORDER VIOLATION                            04/16/2004
      OBSTRUCT LAW ENFORCEMENT OFC                                       07/26/2004
      CRIMINAL TRESPASS-1                                                02/10/2005
4 MISDEMEANOR(S)
      DRUG PARAPHERNALIA                                                 07/01/2002
      DRIVING WHILE LIC SUSP OR REVOKED 3                                07/01/2002
      DRUG PARAPHERNALIA                                                 04/14/2003

Version 1.6Error! Bookmark not defined.                                                    Page 89
                                   Washington JIN CACH Queries Design

      CRIMINAL TRESPASS-2                                               03/24/2005
10 CLASSIFICATION(S) UNKNOWN
      THEFT                                                             11/19/2001
      THEFT                                                             06/19/2002
      VUCSA-POSS MARIJ UNKNOWN AMOUNT                                   04/14/2003
      MALICIOUS MISCHIEF 3                                              01/27/2004
      DOMESTIC VIOL COURT ORD VIOL                                      09/28/2004
      ASSAULT                                                           01/13/2005
      MALICIOUS MISCHIEF 3                                              01/24/2005
      MALICIOUS MISCHIEF 3                                              01/24/2005
      ASSAULT                                                           03/04/2005
      MUNICIPALITIES CODE VIOLATION                                     03/17/2005

===============================================================================
                 NO KNOWN SEX/KIDNAPPING OFFENDER REGISTRATIONS
===============================================================================
===============================================================================
                           NO KNOWN APPLICANT DETAILS
===============================================================================
===============================================================================
                          NO KNOWN CIVIL ADJUDICATIONS
===============================================================================
===============================================================================
                          CRIMINAL HISTORY INFORMATION
===============================================================================
THE ARRESTS LISTED MAY HAVE BEEN BASED ON PROBABLE CAUSE AT THE TIME OF ARREST
OR ON A WARRANT. PROBABLE CAUSE ARRESTS MAY OR MAY NOT RESULT IN THE FILING OF
CHARGES. CONTACT THE ARRESTING AGENCY FOR INFORMATION ON THE FORMAL CHARGES
AND/OR DISPOSITIONS.

-------------------------------------------------------------------------------
ARREST 1                                                DATE OF ARREST: 06/22/2000
-------------------------------------------------------------------------------
     NAME USED:             LAST,FIRST G
     CONTRIBUTING AGENCY: WA0270000      PIERCE COUNTY SHERIFF'S OFFICE
     LOCAL ID: 226847            PCN: N/A
-------------------------------------------------------------------------------
            ARREST OFFENSES                |              DISPOSITION
07418 MINOR POSSESS, CONSUM, ACQUIRE       | CONTRIBUTOR OR RESPONSIBLE AGENCY:
    LIQUOR                                 |    WA027035J PIERCE COUNTY
  RCW:                  66.44.270(2)       |        JUVENILE COURT
  GROSS MISDEMEANOR                        |    STATUS DATE:    08/10/2000
  ORIGINATING AGENCY:   WA0270000          |
  PIERCE COUNTY SHERIFF'S OFFICE           |    STATUS:         NO CHARGE FILED
  OIN:                  J20000622001       |
  DISPO RESPONSIBILITY: WA027035J          | CONTRIBUTOR OR RESPONSIBLE AGENCY:
  DATE OF OFFENSE:      06/22/2000         |    WA027035J PIERCE COUNTY
  JUVENILE                                 |        JUVENILE COURT
                                           |    STATUS DATE:    08/10/2000
05007 MAKING FALSE OR MISLEADING           |
    STATEMENT TO A PUBLIC SRVNT            |    STATUS:         NO CHARGE FILED
  RCW:                  9A.76.175          |
  GROSS MISDEMEANOR                        |
  ORIGINATING AGENCY:   WA0270000          |
  PIERCE COUNTY SHERIFF'S OFFICE           |
  OIN:                  J20000622001       |
  DISPO RESPONSIBILITY: WA027035J          |
  DATE OF OFFENSE:      06/22/2000         |
  JUVENILE                                 |
                                           |
-------------------------------------------------------------------------------
===============================================================================
                 NO KNOWN DEPARTMENT OF CORRECTIONS INFORMATION
===============================================================================


Version 1.6Error! Bookmark not defined.                                              Page 90
                                     Washington JIN CACH Queries Design

*******************************************************************************
                                     GLOSSARY
CONTRIBUTING AGENCY: A LOCAL SHERIFF'S OFFICE, POLICE DEPARTMENT, JAIL OR
             CORRECTIONAL FACILITY THAT SUBMITS FINGERPRINT CARDS TO THE
             SECTION.
CONTRIBUTOR OR RESPONSIBLE AGENCY: THE AGENCY THAT SUBMITTED THE
             INFORMATION OR, PRIOR TO OCTOBER 1999, PRESUMED TO BE THE
             DISPOSITION REPORTER.
CONVICTION AND/OR ADVERSE FINDING SUMMARY: THE NUMBER AND TYPE OF CONVICTIONS
             AND/OR ADVERSE FINDINGS PERTAINING TO AN INDIVIDUAL. DETAILS ARE
             INCLUDED UNDER CRIMINAL HISTORY INFORMATION.
CUSTODY STATUS INFORMATION: CURRENT CUSTODY STATUS INFORMATION PROVIDED ONLINE
             BY THE STATE DEPARTMENT OF CORRECTIONS.
DISPOSITION RESPONSIBILITY: AN INDICATION OF THE PROSECUTOR, COURT, OR LAW
             ENFORCEMENT AGENCY WHICH MAY BE RESPONSIBLE FOR REPORTING THE
             DISPOSITION.
DOC NUMBER: WASHINGTON STATE DEPARTMENT OF CORRECTIONS NUMBER.
LOCAL ID:     LOCAL IDENTIFICATION NUMBER USED BY CONTRIBUTING AGENCY.
NOT RECEIVED: DISPOSITION OF ARREST OFFENSES THAT HAVE NOT BEEN SUBMITTED TO
             THE WASHINGTON STATE PATROL IDENTIFICATION SECTION.
OIN:          OTHER IDENTIFYING NUMBER. A TRACKING NUMBER ASSIGNED BY THE
             CONTRIBUTING OR ORIGINATING AGENCY.
ORIGINATING AGENCY: THE ORIGINAL LAW ENFORCEMENT AGENCY HANDLING THE CASE,
             WHICH MAY BE DIFFERENT FROM THE CONTRIBUTING AGENCY.
PCN:          PROCESS CONTROL NUMBER USED BY CRIMINAL JUSTICE AGENCIES TO LINK
             ARRESTS TO DISPOSITIONS.
RCW:          REVISED CODE OF WASHINGTON; STATUTE REFERRING TO THE CHARGE.
SEARCH PARAMETERS: REFERENCE INFORMATION USED BY SECTION STAFF.
SID NUMBER: UNIQUE STATE IDENTIFICATION SECTION RECORD NUMBER.
DNA SAMPLE: DNA SAMPLE AND TYPE, VALUES PROVIDED BY WSP CRIME LABORATORY AT
             (206) 262-6020 EXT.237.
END OF RECORD


         Field                                             XPath Map

Source           //Subject/@sourceText=”WWCIC”

Source ID        //Subject/@sourceIDText=”Criminal History Record”

Name (First,     //Subject/PersonName/PersonGivenName
Middle,          //Subject/PersonName/PersonMiddleName
Last)            //Subject/PersonName/PersonSurName
(NAME)                The name is on the line labeled NAME. The formatting is one line below the label LAST
                      NAME, FIRST NAME MIDDLE NAME
                      Appears in the preamble section – before the PERSONAL INFORMATION section
FBI Number       //Subject/PersonAssignedIDDetails/PersonFBIID/ID

                      The FBI Number is on the line below the FBI NUMBER column. Appears in the preamble
                      section – before the PERSONAL INFORMATION section
State ID         //Subject/PersonAssignedIDDetails/PersonStateID/ID
                 //Subject/PersonAssignedIDDetails/PersonStateID/IDJurisdictionCoded.ncicLIS

                      The FBI Number is on the line below the FBI NUMBER column. Appears in the preamble
                      section – before the PERSONAL INFORMATION section
Document         //Subject/PersonAssignedIDDetails/PersonOtherID/ID
                 //Subject/PersonAssignedIDDetails/PersonOtherID/ID/IDTypeText = “Document Number”
Number
                      The DOCUMENT NUMBER is on the line below the DOCUMENT NUMBER column.


Version 1.6Error! Bookmark not defined.                                                                 Page 91
                                       Washington JIN CACH Queries Design

       Field                                                  XPath Map
                      Appears in the preamble section – before the PERSONAL INFORMATION section
Sex (SEX)       //Subject/PersonPhysicalDetails/PersonSexCode

                      The SEX code is in the PERSONAL INFORMATION section
Race            //Subject/PersonPhysicalDetails/PersonRaceCode
(RACE)                The RACE code is in the PERSONAL INFORMATION section
Eye Color       //Subject/PersonPhysicalDetails/PersonEyeColorCode
(EYES)                The EYES code is in the PERSONAL INFORMATION section
Weight          //Subject/PersonPhysicalDetails/PersonWeightMeasure
(WEIGHT)              The WEIGHT code is in the PERSONAL INFORMATION section
Height          //Subject/PersonPhysicalDetails/PersonHeightMeasure
(HEIGHT)              The HEIGHT code is in the PERSONAL INFORMATION section
Hair (HAIR)     //Subject/PersonPhysicalDetails/PersonHairColorCode

Name (First,    //Subject/PersonAlternateName/PersonGivenName
Middle,         //Subject/PersonAlternateName/PersonMiddleName
Last)           //Subject/PersonAlternateName/PersonSurName
(ALIAS                The Alias Names is a list of aliases following the same formatting rules as the Name:
NAMES)                Column Header (NAMES USED) and the aliases below the heading
Date of Birth   //Subject/PersonBirthDate
(BIRTH                The DATES OF BIRTH code is in the PERSONAL INFORMATION section. It is
DATE)                 assumed that there can be multiple dates of births, which is supported by multiple
                      PersonBirthDate elements
Social          //Subject/PersonAssignedIDDetails/PersonSSNID/ID
Security              The SOC SEC NUMBER‟s is in the PERSONAL INFORMATION section. It is assumed
Number                that there can be multiples SSNs, which is supported by multiple PersonBirthDate elements
Scar-Marks -    //Subject/PersonPhysicalDetails/PersonPhysicalFeature/
Tattoo          PhysicalFeatureDescriptionText

                      The SCARS, MARKS, TATTOOS, AMPUTATIONS its own section. It follows a two
                      column format – LOCATION, DESCRIPTION, LOCATION, DESCRIPTION
                      The first SMTA appears in the first LOCATION and when there is a description that is
                      associated with it, it appears in the DESCRIPTION field. When there is a second SMTA, it
                      will appear to the right of the first occurrence.
                      Wrapping occurs when the text in a column is longer than the width of a logical column.
      Criminal History Information: There are potentially many arrests, thus each arrest section results in a new
      //CriminalHistory/Arrest element. Arrest Offenses map to Arrest Charges in the resulting documents and
      Arrest elements can contain many ArrestCharges
Arrest Date     //CriminalHistory/Arrest/ActivityDate

                      The Arrest Number follows each new arrest record. To the Right of each Arrest record
                      count is the DATE OF ARREST: field which is used to mark the arrest activity date
Contributing    //CriminalHistory/Arrest/ArrestAgency/OrganizationORIID



Version 1.6Error! Bookmark not defined.                                                                       Page 92
                                      Washington JIN CACH Queries Design

         Field                                               XPath Map
Agency ID             The CONTRIBUTING AGENCY starts each new arrest record. It follows the “NAME
                      USED” line. The Agency ID is the first token following the CONTRIBUTING AGENCY
                      field.
Contributing     //CriminalHistory/Arrest/ArrestAgency/OrganizationName
Agency                The CONTRIBUTING AGENCY starts each new arrest record. It follows the “NAME
Name                  USED” line. The Agency Name follows the Agency ID token and complets the line read
Charge           //CriminalHistory/Arrest/ArrestCharge/ChargeID/ID
Identification        The Charge Identification Number starts each new charge. It follows either the heading
Number                “Arrest Offenses” or a blank line
Charge           //CriminalHistory/Arrest/ArrestCharge/ChargeDescription
Description           The text inside the “Arrest Offenses” section following the Charge Identification Number
                      until the RCW: token
Charge           //CriminalHistory/Arrest/ArrestCharge/ChargeStatute/StatuteCodeID/ID
Offence               Text after RCW: with the whitespace removed.
Code ID
Charge           //CriminalHistory/Arrest/ArrestCharge/ChargeDisposition
                 /ChargeDispositionDescriptionText/
Disposition
                      Text on the line after RCW: and before ORIGINATING AGENCY:
Description
Text
Originating      //CriminalHistory/Arrest/ArrestAgency/ChargeStatute/StatuteCodeID
Agency                Text after RCW: with the whitespace removed.
Charge           //CriminalHistory/Arrest/ArrestCharge/ChargeDisposition/ChargeDispositionCondition

Disposition           The text after the DATE OF OFFENSE field.
Condition




NCIC Protection Order Record
WA0340500

*****WARNING -        THE FOLLOWING IS AN NCIC PROTECTION
ORDER RECORD.         DO NOT SEARCH, DETAIN, OR ARREST BASED
SOLELY ON THIS        RECORD. CONTACT ENTERING AGENCY TO
CONFIRM STATUS        AND TERMS OF PROTECTION ORDER*****

****THE SUBJECT OF THIS RECORD IS PROHIBITED FROM
RECEIVING OR POSSESSING A FIREARM UNDER FEDERAL LAW
(TITLE 18, U.S.C., SECTIN 922)****

MKE/PROTECTION ORDER
ORI/WA0340500 NAM/REC0RD,TEST SEX/M RAC/W POB/WA
DOB/19490804
HGT/500 WGT/300 EYE/BR0 HAI/BR0 SKN/FAR SMT/SC R SHLD
SCO/123456789


Version 1.6Error! Bookmark not defined.                                                                    Page 93
                                    Washington JIN CACH Queries Design

OLN/WA123123 OLS/WA OLY/2005
PNO/TEST1234 BRD/Y ISD/20000321 EXP/NONEXP
CTI/WA034025J
PPN/REC0RD,MISSUS PSX/F PPR/W PPB/19490408
PCO/THE SUBJECT IS RESTRAINED FROM ASSAULTING,
THREATENING, ABUSING, HARASSING,
PCO/FOLLOWING, INTERFERING, OR STALKING THE PROTECTED
PERSON AND/OR THE CHILD
PCO/OF THE PROTECTED PERSON.
OCA/TEST1234
MIS/TEST REC0RD 0NLY
NIC/H490416753 DTE/20000321 1508 EST




         Field                                          XPath Map

Source                   //Subject/@sourceText=”NCIC”

Source ID                //Subject/@sourceIDText=”PROTECTION ORDER”

Name (First, Middle,     //Subject/PersonName/PersonGivenName
Last)                    //Subject/PersonName/PersonMiddleName

(NAM)                    //Subject/PersonName/PersonSurName

Name (First, Middle,     //Subject/PersonAlternateName/PersonGivenName
Last)                    //Subject/PersonAlternateName/PersonMiddleName

(AKA)                    //Subject/PersonAlternateName/PersonSurName

Sex (SEX)                //Subject/PersonPhysicalDetails/PersonSexCode

Race (RAC)               //Subject/PersonPhysicalDetails/PersonRaceCode

Eye Color (EYE)          //Subject/PersonPhysicalDetails/PersonEyeColorCode

Weight (WGT)             //Subject/PersonPhysicalDetails/PersonWeightMeasure

Height (HGT)             //Subject/PersonPhysicalDetails/PersonHeightMeasure

Hair (HAI)               //Subject/PersonPhysicalDetails/PersonHairColorCode

Date of Birth (DOB)      //Subject/PersonBirthDate

Scars, Marks &           //Subject/PersonPhysicalDetails/PersonPhysicalFeature/
Tattoo‟s (SMT)           PhysicalFeatureDescriptionText

Driver‟s License         //Subject/PersonDriversLicense/DriverAuthorizationID/ID
Number (MKE/OLN)
Driver‟s License State   //Subject/PersonDriversLicense/DriverAuthorizationID/
                         IDJurisdictionCode.ncicLIS
(MKE/OLS)
Driver‟s License         //Subject/PersonDriversLicense/
Expiration Year          DriverAuthorizationExpirationDate
(MKE/OLY)
Social Security          //Subject/PersonAssignedIDDetails/PersonSSNID/ID
Number (SOC)


Version 1.6Error! Bookmark not defined.                                            Page 94
                                    Washington JIN CACH Queries Design

         Field                                          XPath Map

FBI Number (FBI)         //Subject/PersonAssignedIDDetails/PersonFBIID/ID

State ID (SID)           //Subject/PersonAssignedIDDetails/PersonStateID/ID
                         //Subject/PersonAssignedIDDetails/PersonStateID/
                         IDJurisdictionCoded.ncicLIS

Street Address           //Subject/Residence/LocationAddress/AddressFullText

Address Line 1
City, State, Zip         Parse out into
                         //Subject/Residence/LocationAddress/LocationCityName
Address Line 2           //Subject/Residence/LocationAddress/LocationStateCode/ncicLIS
                         //Subject/Residence/LocationAddress/LocationPostalCodeID/ID

Protection Order         //ProtectionOrder/Condition/ConditionDescriptionText
Conditions (PCO,
MIS)
Protected Person Name    //ProtectionOrder/ProtectionOrderRestrictedPerson/PersonName
(PPN)
Protected Person Sex     //ProtectionOrder/ProtectionOrderRestrictedPerson/
                         PersonPhysicalDetails/PersonSexCode
(PSX)
Protected Person Race    //ProtectionOrder/ProtectionOrderRestrictedPerson/
                         PersonPhysicalDetails/PersonRaceCode
Code (PPR)
Protected Person Birth   //ProtectionOrder/ProtectionOrderRestrictedPerson/PersonBirthDate
Date (PPB)
Protection Order         //ProtectionOrder/@expirationDate
Expiration Date (EXP)



NCIC Wanted Person Record
WA0340500
MKE/WANTED PERSON
ORI/DSE/20500415 NAM/DOE, JOHN J SEX/M RAC/W POB/WA
DOB/19500101
HGT/511 WGT/200 EYE/BR0 HAI/BRO FBI/123456A SKN/MED
FPC/DIPMPMP013POPOCOPI13 MNU/OA-AB1234512 SOC/555555555
OFF/DAMAGE PROP - PUBLIC-WITH EXPLOSIVE
DOW/20000405 OCA/TEST-TEST
MIS/TEST REC0RD TEST REC0RD
ORI IS SHERIFF’S OFFICE THURSTON COUNTY OLYMPIA 360 555-
1212
NIC/W370679163 DTE/20000427 1926 EDT
IMMED CONFIRM WARRANT AND EXTRADITION WITH ORI




         Field                                          XPath Map

Source                   //Subject/@sourceText=”NCIC”

Source ID                //Subject/@sourceText=”WANTED PERSON”



Version 1.6Error! Bookmark not defined.                                                      Page 95
                                    Washington JIN CACH Queries Design

        Field                                             XPath Map

Name (First, Middle,   //Subject/PersonName/PersonGivenName
Last)                  //Subject/PersonName/PersonMiddleName

(NAM)                  //Subject/PersonName/PersonSurName

Name (First, Middle,   //Subject/PersonAlternateName/PersonGivenName
Last)                  //Subject/PersonAlternateName/PersonMiddleName

(AKA)                  //Subject/PersonAlternateName/PersonSurName

Sex (SEX)              //Subject/PersonPhysicalDetails/PersonSexCode

Race (RAC)             //Subject/PersonPhysicalDetails/PersonRaceCode

Eye Color (EYE)        //Subject/PersonPhysicalDetails/PersonEyeColorCode

Weight (WGT)           //Subject/PersonPhysicalDetails/PersonWeightMeasure

Height (HGT)           //Subject/PersonPhysicalDetails/PersonHeightMeasure

Hair (HAI)             //Subject/PersonPhysicalDetails/PersonHairColorCode

Date of Birth (DOB)    //Subject/PersonBirthDate

Scars, Marks &         //Subject/PersonPhysicalDetails/PersonPhysicalFeature/
Tattoo‟s (SMT)         PhysicalFeatureDescriptionText

Social Security        //Subject/PersonAssignedIDDetails/PersonSSNID/ID
Number (SOC)
FBI Number (FBI)       //Subject/PersonAssignedIDDetails/PersonFBIID/ID

State ID (SID)         //Subject/PersonAssignedIDDetails/PersonStateID/ID
                       //Subject/PersonAssignedIDDetails/PersonStateID/
                       IDJurisdictionCoded.ncicLIS

Misc. Identifying      //Subject/PersonAssignedIDDetails/PersonOtherID/ID
Number (MNU)           //Subject/PersonAssignedIDDetails/PersonOtherID/ID/IDTypeText

                       Minimum of four and maximum of 21 characters are required. The first two
                       characters must be a valid two-character alphabetic code from the Personal
                       Descriptors of the NCIC Code Manual. The third character must be a hyphen.
                       Entry of one zero only or a run of zeros only is prohibited in positions 4 through
                       15. An originating agency police or identification number in MNU cannot be the
                       only numeric identifier in the record.



WACIC Protection Order Record
WWCIC TIME: 1210 DATE: 032100 TO: LRKPD
QW.WA0340500.NAM/RECORD, TEST.DOB/19490804

------ RECORD NUMBER 1 OF 1 ------
*** NOT A WARRANT ***
RESTRAINING ORDER (BASED ON DOB,NAM)
MKE/EPO ORI/WA0340500 NAM/RECORD,TEST
.M.W.WA.08/04/1949
HGT/500 WGT/300 EYE/BRO HAI/BRO SKN/FAR
OCA/TEST1234 SMT/SC R SHLD
RTP/RO   ORDER NUMBER/TEST1234   SERVED/YES                       PCO/01

Version 1.6Error! Bookmark not defined.                                                                     Page 96
                                     Washington JIN CACH Queries Design

DOI/03/21/2000 EXD/NONEXP ORC/WA034025J BRADY/Y
MIS/TEST RECORD ONLY
PROTECTED PERSON/RECORD,MISSUS.F.W.04/08/1949

ENT: 03/21/2000 AT 1206 FROM LRKPD                 BY/PD LITTLEROCK
(LRKPD)
WAC/00R0016123 NIC/H490416753




  Field                                              XPath Map

Source       //Subject/@sourceText=”WWCIC”

Source ID    //Subject/@sourceText=”PROTECTION ORDER”

Name         //Subject/PersonName/PersonGivenName
(First,      //Subject/PersonName/PersonMiddleName
Middle,      //Subject/PersonName/PersonSurName
Last)
(NAM)
Name         //Subject/PersonAlternateName/PersonGivenName
(First,      //Subject/PersonAlternateName/PersonMiddleName
Middle,      //Subject/PersonAlternateName/PersonSurName
Last)
(AKA)
Sex          //Subject/PersonPhysicalDetails/PersonSexCode

                  The sex code is derived from the string after the NAM field.
             NAM/SUBJECT NAME.SEX CODE.RACE CODE.PLACE OF BIRTH.DATE OF BIRTH
Race         //Subject/PersonPhysicalDetails/PersonRaceCode
(RAC)             The race code is derived from the string after the NAM field.
             NAM/SUBJECT NAME.SEX CODE.RACE CODE.PLACE OF BIRTH.DATE OF BIRTH
Eye Color    //Subject/PersonPhysicalDetails/PersonEyeColorCode
(EYE)
Weight       //Subject/PersonPhysicalDetails/PersonWeightMeasure
(WGT)
Height       //Subject/PersonPhysicalDetails/PersonHeightMeasure
(HGT)
Hair (HAI)   //Subject/PersonPhysicalDetails/PersonHairColorCode

Date of      //Subject/PersonBirthDate
Birth             The date of birth is derived from the string after the NAM field.
(DOB)
             NAM/SUBJECT NAME.SEX CODE.RACE CODE.PLACE OF BIRTH.DATE OF BIRTH
Scars,       //Subject/PersonPhysicalDetails/PersonPhysicalFeature/
Marks &      PhysicalFeatureDescriptionText
Tattoo‟s


Version 1.6Error! Bookmark not defined.                                               Page 97
                                       Washington JIN CACH Queries Design

   Field                                               XPath Map
(SMT)
Social         //Subject/PersonAssignedIDDetails/PersonSSNID/ID
Security
Number
(SOC)
FBI            //Subject/PersonAssignedIDDetails/PersonFBIID/ID
Number
(FBI)
State ID       //Subject/PersonAssignedIDDetails/PersonStateID/ID
               //Subject/PersonAssignedIDDetails/PersonStateID/ IDJurisdictionCoded.ncicLIS
(SID)
Street         //Subject/Residence/LocationAddress/AddressFullText
Address
Address
Line 1
City, State,   Parse out into
               //Subject/Residence/LocationAddress/LocationCityName
Zip            //Subject/Residence/LocationAddress/LocationStateCode/ncicLIS
               //Subject/Residence/LocationAddress/LocationPostalCodeID/ID
Address
Line 2
Protection     //ProtectionOrder/Condition/ConditionDescriptionText
Order
Conditions
(PCO)
Protected      //ProtectionOrder/ProtectionOrderRestrictedPerson
Person
Name
(PPN)
Protected      //ProtectionOrder/ProtectionOrderRestrictedPerson/
               PersonPhysicalDetails/PersonSexCode
Person Sex
                     The sex code is derived from the string after the PPN field.
               PPN/SUBJECT NAME.SEX CODE.RACE CODE.PLACE OF BIRTH.DATE OF BIRTH
Protected      //ProtectionOrder/ProtectionOrderRestrictedPerson/
               PersonPhysicalDetails/PersonRaceCode
Person
Race Code            The sex code is derived from the string after the PPN field.
               PPN/SUBJECT NAME.SEX CODE.RACE CODE.PLACE OF BIRTH.DATE OF BIRTH
Protected      //ProtectionOrder/ProtectionOrderRestrictedPerson/PersonBirthDate
Person               The sex code is derived from the string after the PPN field.
Birth Date
               PPN/SUBJECT NAME.SEX CODE.RACE CODE.PLACE OF BIRTH.DATE OF BIRTH
Protection     //ProtectionOrder/@expirationDate
Order
Expiration
Date (EXD)


Version 1.6Error! Bookmark not defined.                                                       Page 98
                                    Washington JIN CACH Queries Design



WACIC Warrant
WWCIC TIME: 1622 DATE: 042700 TO: ABCPD
QW.WA0340500.NAM/DOE, JOHN J.DOB/19500101

------ RECORD NUMBER 1 OF 1 ------
FELONY WARRANT (BASED ON DOB,NAM)
MKE/EWF ORI/WA0340500 NAM/DOE, JOHN J
.M.W.WA.01011950
HGT/511 WGT/200 EYE/BRO HAI/BRO
OCA/TEST123
OFF/4809
OFL/UNAUTH COMMUNICATION WITH PRISONER
DOW/04/05/2000 ORC/WA034013J
TOW/FS
MIS/TEST RECORD TEST RECORD
ENT: 04/27/2000 AT 1621 FROM ABCPD BY/PD ANYTOWN (ABCPD)
UPD: 04/27/2000 AT 1622 FROM
WAC/00W0071505


         Field                                          XPath Map

Source           //Subject/@sourceText=”WWCIC”

Source ID        //Subject/@sourceIDText=”FELONY WARRANT” or warrant type

Name (First,     //Subject/PersonName/PersonGivenName
Middle,          //Subject/PersonName/PersonMiddleName
Last)            //Subject/PersonName/PersonSurName
(NAM)
Name (First,     //Subject/PersonAlternateName/PersonGivenName
Middle,          //Subject/PersonAlternateName/PersonMiddleName
Last)            //Subject/PersonAlternateName/PersonSurName
(AKA)
Sex (SEX)        //Subject/PersonPhysicalDetails/PersonSexCode

Race (RAC)       //Subject/PersonPhysicalDetails/PersonRaceCode

Eye Color        //Subject/PersonPhysicalDetails/PersonEyeColorCode
(EYE)
Weight           //Subject/PersonPhysicalDetails/PersonWeightMeasure
(WGT)
Height           //Subject/PersonPhysicalDetails/PersonHeightMeasure
(HGT)
Hair (HAI)       //Subject/PersonPhysicalDetails/PersonHairColorCode

Date of Birth    //Subject/PersonBirthDate
(DOB)
Scars, Marks     //Subject/PersonPhysicalDetails/PersonPhysicalFeature/
                 PhysicalFeatureDescriptionText
& Tattoo‟s

Version 1.6Error! Bookmark not defined.                                     Page 99
                                        Washington JIN CACH Queries Design

        Field                                                XPath Map
(SMT)
Social           //Subject/PersonAssignedIDDetails/PersonSSNID/ID
Security
Number
(SOC)
FBI Number       //Subject/PersonAssignedIDDetails/PersonFBIID/ID
(FBI)
State ID         //Subject/PersonAssignedIDDetails/PersonStateID/ID
                 //Subject/PersonAssignedIDDetails/PersonStateID/ IDJurisdictionCoded.ncicLIS
(SID)
Street           //Subject/Residence/LocationAddress/AddressFullText
Address
Address
Line 1
City, State,     Parse out into
Zip              //Subject/Residence/LocationAddress/LocationCityName
                 //Subject/Residence/LocationAddress/LocationStateCode/ncicLIS
Address          //Subject/Residence/LocationAddress/LocationPostalCodeID/ID
Line 2
Warrant          /ArrestWarrant/ActivityPrimaryOrganization/OrganizationName
Issuing                 Extracted from the Entered (ENT) line. This is the BY/ text.
Agency
Name                    ENT: DATE AT TIME FROM LOCID BY/AGENCY

Warrant          /ArrestWarrant/ActivityDate
Issued Date             Must be eight numeric characters representing year, month, and day in that order.
(DOW)                   Must be equal to or less than the current date. Days cannot be more than the
                        maximum for the month. Unless the year is a leap year, the date February 29, (----
                        0229) will not be allowed. For Wanted Juvenile records, the date of violation (DOV)
                        is entered in this field.
Warrant          /ArrestWarrant/WarrantProbableCauseText
Text (OFL,              Concatenation of the Offence Literal code and the Miscellaneous Text
MIS)



WACIC Possible Criminal History Record
        This is a general Possible Criminal History Record. Often it is found on its own, however this record
        has been used in combination with other record types. If this record is bound to another record, this
        information here supercedes the other data.


Record relating to other data
*** WASIS IDENTIFICATION INFORMATION BASED ON SID/PCN IN WARRANT ***
*** POSSIBLE CRIMINAL HISTORY RECORD ***
*** DO NOT ARREST ON THIS INFORMATION ***
NAM/TEST,TEST DOB/01/22/1974 SEX/M RAC/W
SID/WA1587TEST PCN/ FBI/659012TST


Version 1.6Error! Bookmark not defined.                                                                         Page 100
                                      Washington JIN CACH Queries Design

HGT/500 WGT/135 EYE/BRO HAI/BLK POB/MM
DOB/04/05/1972 /12/25/1975 /01/22/1974
SOC/548657654
AKA/COLIN,TEST P /TEST,TEST COLIN /TEST,TEST E
AKA/TEST,TEST G /PERETE,GAUDENCIO C /TEST,TEST
AKA/TEST,TEST TST /TESTTET,TEST TEST /TEST,TEST C
AKA/TEST,JUAN C /TEST,T E


Solo Record
------ RECORD NUMBER 3 OF 6 ------
SID/WA1765TEST NAM/TEST,JAMES D DOB/03/26/1978
FBI/291959TEST HGT/601 WGT/250 HAI/BRO EYE/BRO
*** POSSIBLE CRIMINAL HISTORY RECORD ***
*** DO NOT ARREST ON THIS INFORMATION ***
NUMBER OF FTAs: 3

***CONVICTED FELON***


         Field                                          XPath Map

Source           //Subject/@sourceText=”WWCIC”

Source ID        //Subject/@sourceIDText=”Possible Criminal History Record”

                      Only populate for Solo record
Name (First,     //Subject/PersonName/PersonGivenName
Middle,          //Subject/PersonName/PersonMiddleName
Last)            //Subject/PersonName/PersonSurName
(NAM)
Name (First,     //Subject/PersonAlternateName/PersonGivenName
Middle,          //Subject/PersonAlternateName/PersonMiddleName
Last)            //Subject/PersonAlternateName/PersonSurName
(AKA)
Sex (SEX)        //Subject/PersonPhysicalDetails/PersonSexCode

Race (RAC)       //Subject/PersonPhysicalDetails/PersonRaceCode

Eye Color        //Subject/PersonPhysicalDetails/PersonEyeColorCode
(EYE)
Weight           //Subject/PersonPhysicalDetails/PersonWeightMeasure
(WGT)
Height           //Subject/PersonPhysicalDetails/PersonHeightMeasure
(HGT)
Hair (HAI)       //Subject/PersonPhysicalDetails/PersonHairColorCode

Date of Birth    //Subject/PersonBirthDate
(DOB)
Scars, Marks     //Subject/PersonPhysicalDetails/PersonPhysicalFeature/
& Tattoo‟s            PhysicalFeatureDescriptionText



Version 1.6Error! Bookmark not defined.                                       Page 101
                                   Washington JIN CACH Queries Design

        Field                                       XPath Map
(SMT)
Social          //Subject/PersonAssignedIDDetails/PersonSSNID/ID
Security
Number
(SOC)
FBI Number      //Subject/PersonAssignedIDDetails/PersonFBIID/ID
(FBI)
State ID        //Subject/PersonAssignedIDDetails/PersonStateID/ID
                //Subject/PersonAssignedIDDetails/PersonStateID/ IDJurisdictionCoded.ncicLIS
(SID)
Street          //Subject/Residence/LocationAddress/AddressFullText
Address
Address
Line 1
City, State,    Parse out into
                //Subject/Residence/LocationAddress/LocationCityName
Zip             //Subject/Residence/LocationAddress/LocationStateCode/ncicLIS
                //Subject/Residence/LocationAddress/LocationPostalCodeID/ID
Address
Line 2




Version 1.6Error! Bookmark not defined.                                                        Page 102
                                        Washington JIN CACH Queries Design

APPENDIX B – WS-I BASIC PROFILE REQUIREMENTS

      To aid in the compliance to the basic profile, the following items are to be implemented in the web
      services:
      Claim                                                        Detail
R1000 When a MESSAGE contains a soap:Fault                   This claim will not be supported as the
element, that element MUST NOT have element children         SOAP:Fault for v1.1 does not contain sufficient
other than faultcode, faultstring, faultactor and detail.    details required.
                                                             Also, fault messages need not be generated for
                                                             invalid fault messages.
R4001 A RECEIVER MUST accept messages that
include the Unicode Byte Order Mark (BOM).
R9980 - An ENVELOPE MUST conform to the                      This WS-I Requirement will not be endorsed.
structure specified in SOAP 1.1 Section 4, "SOAP             However the SOAP 1.1 should be followed as
Envelope" (subject to amendment by the Profile).             closely as possible. The recommendation is the
                                                             keep
R1032 – The soap:Envelope, soap:Header, and
soap:Body elements in an ENVELOPE MUST NOT
have attributes in the namespace "http://schemas.
xmlsoap.org/soap/envelope/".
R1033 – An ENVELOPE SHOULD NOT contain the
namespace declaration xmlns:xml="http://www.w3.org/
XML/1998/namespace".
R1034 – A DESCRIPTION SHOULD NOT contain the
namespace declaration xmlns:xml="http://www.w3.org/
XML/1998/namespace".
R1127 – A RECEIVER MUST NOT rely on the value of             The HTTP Header is limited to the HTTP
the SOAPAction HTTP header to correctly process the          Protocol. Use the SOAP construct for portability
message.(SOAP12)
R2803 – In a DESCRIPTION, the namespace attribute
of the wsdl:import MUST NOT be a relative URI.
R4005 – A DESCRIPTION SHOULD NOT contain the
namespace declaration xmlns:xml="http://www.w3.org/
XML/1998/namespace".
R2030 – In a DESCRIPTION the wsdl:documentation
element MAY be present as the first child element of
wsdl:import, wsdl:part and wsdl:definitions in addition to
the elements cited in the WSDL1.1
specification.(WSDL20)
R2212 – An ENVELOPE MUST contain exactly one
part accessor element for each of the wsdl:part elements
bound to the envelope's corresponding soapbind:body
element.
R2213 – In a doc-literal description where the value of      Must prune empty elements in the SOAP:Body

Version 1.6Error! Bookmark not defined.                                                                        Page 103
                                         Washington JIN CACH Queries Design

       Claim                                                         Detail
the parts attribute of soapbind:body is an empty string,
the corresponding ENVELOPE MUST have no element
content in the soap:Body element.
R2214 – In a rpc-literal description where the value of       All web services are to be document based.
the parts attribute of soapbind:body is an empty string,
the corresponding ENVELOPE MUST have no part
accessor elements.
R2755 – The part accessor elements in a MESSAGE               All web services are to be document based.
described with an rpc-literal binding MUST have a local
name of the same value as the name attribute of the
corresponding wsdl:part element.
R1015 A RECEIVER MUST generate a fault if they                The soap:Envelope node is the root, the web
encounter an envelope whose document element is not           services is then responsible for traversing the
soap:Envelope                                                 soap:Header, soap:Body, and the message
                                                              contents for processing
R1014 The children of the soap:Body element in an
ENVELOPE MUST be namespace qualified.
R1008 An ENVELOPE MUST NOT contain a
Document Type Declaration.
R1009 An ENVELOPE MUST NOT contain Processing
Instructions.
R1027 A RECEIVER MUST generate a                              The addressing and security nodes must use the
"soap:MustUnderstand" fault when an envelope contains         soap:MustUnderstand attributes
a mandatory header block (i.e., one that has a
soap:mustUnderstand attribute with the value "1")
targeted at the receiver (via soap:actor) that the receiver
does not understand
R1028 When a fault is generated by a RECEIVER,                The messages in the JINDEX are presently
further processing SHOULD NOT be performed on the             atomic and read only. No rollback logic is
SOAP envelope aside from that which is necessary to           required
rollback, or compensate for, any effects of processing the
envelope prior to the generation of the fault. SOAP12
R1029 Where the normal outcome of processing a                A fault message must exist for all processing
SOAP envelope would have resulted in the transmission         exceptions. In the JINDEX, all workflows have
of a SOAP response, but rather a fault is generated           acknowledgements. When there is a failure, the
instead, a RECEIVER MUST transmit a fault in place of         Fault message is the negative-acknowledgement.
the response                                                  The web service invoker must expect a response
                                                              and process the Fault if present.
R1030 A RECEIVER that generates a fault SHOULD                This is the responsibility of the notifications
notify the end user that a fault has been generated when      framework. Faults are a form of an exception,
practical, by whatever means is deemed appropriate to         critical exceptions must be escalated and users
the circumstance.                                             (administrators or end-users) must be notified.
R1107 A RECEIVER MUST interpret a SOAP message                The presence of a soap:Fault in the header or
as a Fault when the soap:Body of the message has a            body is automatically categorized as a fault
single soap:Fault child.

Version 1.6Error! Bookmark not defined.                                                                         Page 104
                                       Washington JIN CACH Queries Design

      Claim                                                      Detail
R1001 When an ENVELOPE is a Fault, the element
children of the soap:Fault element MUST be unqualified.
R1002 A RECEIVER MUST accept faults that have any
number of elements, including zero, appearing as
children of the detail element. Such children can be
qualified or unqualified.
R1003 A RECEIVER MUST accept faults that have any
number of qualified or unqualified attributes, including
zero, appearing on the detail element. The namespace of
qualified attributes can be anything other than
"http://schemas.xmlsoap.org/soap/envelope/".
R1016 A RECEIVER MUST accept faults that carry an
xml:lang attribute on the faultstring element.
R1004 When an ENVELOPE contains a faultcode
element, the content of that element SHOULD be either
one of the fault codes defined in SOAP 1.1 (supplying
additional information if necessary in the detail
element), or a Qname whose namespace is controlled by
the fault's specifying authority (in that order of
preference).
R1031 When an ENVELOPE contains a faultcode                Use subcodes as per SOAP 1.2
element the content of that element SHOULD NOT use
of the SOAP 1.1 "dot" notation to refine the meaning of
the fault.
R1141 A MESSAGE MUST be sent using either
HTTP/1.1 or HTTP/1.0.
R1140 A MESSAGE SHOULD be sent using
HTTP/1.1.
R1132 A HTTP request MESSAGE MUST use the                  HHTP GET is not accepted
HTTP POST method.
R1108 A MESSAGE MUST NOT use the HTTP
Extension Framework (RFC2774).
R1109 The value of the SOAPAction HTTP header              But the SOAPAction is not a required field as it
field in a HTTP request MESSAGE MUST be a quoted           externalizes SOAP functionality
string.
R1119 A RECEIVER MAY respond with a fault if the
value of the SOAPAction HTTP header field in a
message is not quoted.
R1127 A RECEIVER MUST NOT rely on the value of
the SOAPAction HTTP header to correctly process the
message.SOAP12
R1124 An INSTANCE MUST use a 2xx HTTP status               For HTTP based web services HTTP status
code on a response message that indicates the successful   codes must be in sync with SOAP functions


Version 1.6Error! Bookmark not defined.                                                                   Page 105
                                      Washington JIN CACH Queries Design

      Claim                                                      Detail
outcome of a HTTP request.
R1111 An INSTANCE SHOULD use a "200 OK"
HTTP status code on a response message that contains
an envelope that is not a fault.
R1112 An INSTANCE SHOULD use either a "200
OK" or "202 Accepted" HTTP status code for a response
message that does not contain a SOAP envelope but
indicates the successful outcome of a HTTP request.
R1130 An INSTANCE MUST use the "307 Temporary
Redirect" HTTP status code when redirecting a request
to a different endpoint.
R1131 A CONSUMER MAY automatically redirect a
request when it encounters a "307 Temporary Redirect"
HTTP status code in a response.
R1125 An INSTANCE MUST use a 4xx HTTP status               If a SOAP Fault is use, the protocol must issue a
code for a response that indicates a problem with the      response code >= 400
format of a request.
R1113 An INSTANCE SHOULD use a "400 Bad
Request" HTTP status code, if a HTTP request message
is malformed.
R1114 An INSTANCE SHOULD use a "405 Method
not Allowed" HTTP status code if a HTTP request
message's method is not "POST".
R1115 An INSTANCE SHOULD use a "415
Unsupported Media Type" HTTP status code if a HTTP
request message's Content-Type header field-value is not
permitted by its WSDL description.
R1126 An INSTANCE MUST return a "500 Internal
Server Error" HTTP status code if the response envelope
is a Fault.
R1120 An INSTANCE MAY use the HTTP state                   However, using cookies for maintaining state is
mechanism ("Cookies").                                     not encouraged. State should be expressed in the
                                                           SOAP headers and body.
R1122 An INSTANCE using Cookies SHOULD
conform to RFC2965.
R1121 An INSTANCE SHOULD NOT require
consumer support for Cookies in order to function
correctly.
R1123 The value of the cookie MUST be considered to
be opaque by the CONSUMER.
R0001 Either an INSTANCE's WSDL 1.1 description,
its UDDI binding template, or both MUST be available
to an authorized consumer upon request.
R2028 A DESCRIPTION using the WSDL namespace

Version 1.6Error! Bookmark not defined.                                                                    Page 106
                                     Washington JIN CACH Queries Design

      Claim                                                     Detail
(prefixed "wsdl" in this Profile) MUST be valid
according to the XML Schema found at
"http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd".
R2028 A DESCRIPTION using the WSDL namespace
(prefixed "wsdl" in this Profile) MUST be valid
according to the XML Schema found at
"http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd".
R2001 A DESCRIPTION MUST only use the WSDL                Do not use other XML import nomenclature for
"import" statement to import another WSDL description.    other WSDL references
R2803 In a DESCRIPTION, the namespace attribute of
the wsdl:import MUST NOT be a relative URI.
R2002 To import XML Schema Definitions, a
DESCRIPTION MUST use the XML Schema "import"
statement.
R2003 A DESCRIPTION MUST use the XML Schema
"import" statement only within the xsd:schema element
of the types section.
R2004 In a DESCRIPTION the schemaLocation
attribute of an xsd:import element MUST NOT resolve
to any document whose root element is not "schema"
from the namespace
"http://www.w3.org/2001/XMLSchema".
R2009 An XML Schema directly or indirectly imported
by a DESCRIPTION MAY include the Unicode Byte
Order Mark (BOM).
R2010 An XML Schema directly or indirectly imported
by a DESCRIPTION MUST use either UTF-8 or UTF-
16 encoding.
R2011 An XML Schema directly or indirectly imported
by a DESCRIPTION MUST use version 1.0 of the
eXtensible Markup Language W3C Recommendation.
R2007 A DESCRIPTION MUST specify a non-empty              Cannot use empty references
location attribute on the wsdl:import element.
R2008 A CONSUMER MAY, but need not, retrieve a
WSDL description from the URI specified in the location
attribute on a wsdl:import element.
R2022 When they appear in a DESCRIPTION,
wsdl:import elements MUST precede all other elements
from the WSDL namespace except wsdl:documentation.
R2023 When they appear in a DESCRIPTION,
wsdl:types elements MUST precede all other elements
from the WSDL namespace except wsdl:documentation
and wsdl:import.



Version 1.6Error! Bookmark not defined.                                                                  Page 107
                                       Washington JIN CACH Queries Design

      Claim                                                      Detail
R4004 A DESCRIPTION MUST use version 1.0 of the
eXtensible Markup Language W3C Recommendation.
R4005 A DESCRIPTION SHOULD NOT contain the
namespace declaration
xmlns:xml="http://www.w3.org/XML/1998/namespace".
R4002 A DESCRIPTION MAY include the Unicode
Byte Order Mark (BOM).C
R4003 A DESCRIPTION MUST use either UTF-8 or               UTF-8 is the preferred encoding especially since
UTF-16 encoding.                                           it is used with GJDXM.
R2005 The targetNamespace attribute on the
wsdl:definitions element of a description that is being
imported MUST have same the value as the namespace
attribute on the wsdl:import element in the importing
DESCRIPTION.
R2030 In a DESCRIPTION the wsdl:documentation
element MAY be present as the first child element of
wsdl:import, wsdl:part and wsdl:definitions in addition
to the elements cited in the WSDL1.1
specification.WSDL20
R2025 A DESCRIPTION containing WSDL extensions
MUST NOT use them to contradict other requirements
of the Profile.
R2026 A DESCRIPTION SHOULD NOT include
extension elements with a wsdl:required attribute value
of "true" on any WSDL construct (wsdl:binding,
wsdl:portType, wsdl:message, wsdl:types or
wsdl:import) that claims conformance to the Profile.
R2027 If during the processing of a description, a
consumer encounters a WSDL extension element that has
a wsdl:required attribute with a boolean value of "true"
that the consumer does not understand or cannot process,
the CONSUMER MUST fail processing.
R2101 A DESCRIPTION MUST NOT use QName
references to WSDL components in namespaces that
have been neither imported, nor defined in the referring
WSDL document.
R2102 A QName reference to a Schema component in a
DESCRIPTION MUST use the namespace defined in the
targetNamespace attribute on the xsd:schema element, or
to a namespace defined in the namespace attribute on an
xsd:import element within the xsd:schema element.
R2105 All xsd:schema elements contained in a
wsdl:types element of a DESCRIPTION MUST have a
targetNamespace attribute with a valid and non-null
value, UNLESS the xsd:schema element has xsd:import

Version 1.6Error! Bookmark not defined.                                                                   Page 108
                                        Washington JIN CACH Queries Design

      Claim                                                   Detail
and/or xsd:annotation as its only child element(s).
R2110 In a DESCRIPTION, declarations MUST NOT
extend or restrict the soapenc:Array type.
R2111 In a DESCRIPTION, declarations MUST NOT
use wsdl:arrayType attribute in the type declaration.
R2112 In a DESCRIPTION, elements SHOULD NOT
be named using the convention ArrayOfXXX.
R2113 An ENVELOPE MUST NOT include the
soapenc:arrayType attribute.
R2201 A document-literal binding in a DESCRIPTION
MUST, in each of its soapbind:body element(s), have at
most one part listed in the parts attribute, if the parts
attribute is specified.
R2209 A wsdl:binding in a DESCRIPTION SHOULD
bind every wsdl:part of a wsdl:message in the
wsdl:portType to which it refers with a binding extension
element.
R2210 If a document-literal binding in a
DESCRIPTION does not specify the parts attribute on a
soapbind:body element, the corresponding abstract
wsdl:message MUST define zero or one wsdl:parts.
R2202 A wsdl:binding in a DESCRIPTION MAY
contain soapbind:body element(s) that specify that zero
parts form the soap:Body.
R2203 An rpc-literal binding in a DESCRIPTION
MUST refer, in its soapbind:body element(s), only to
wsdl:part element(s) that have been defined using the
type attribute.
R2211 An ENVELOPE described with an rpc-literal
binding MUST NOT have the xsi:nil attribute with a
value of "1" or "true" on the part accessors.
R2207 A wsdl:message in a DESCRIPTION MAY
contain wsdl:parts that use the elements attribute
provided those wsdl:parts are not referred to by a
soapbind:body in an rpc-literal binding.
R2204 A document-literal binding in a DESCRIPTION
MUST refer, in each of its soapbind:body element(s),
only to wsdl:part element(s) that have been defined using
the element attribute.
R2208 A binding in a DESCRIPTION MAY contain
soapbind:header element(s) that refer to wsdl:parts in the
same wsdl:message that are referred to by its
soapbind:body element(s).
R2212 An ENVELOPE MUST contain exactly one part

Version 1.6Error! Bookmark not defined.                                      Page 109
                                       Washington JIN CACH Queries Design

      Claim                                                  Detail
accessor element for each of the wsdl:part elements
bound to the envelope's corresponding soapbind:body
element.
R2213 In a doc-literal description where the value of the
parts attribute of soapbind:body is an empty string, the
corresponding ENVELOPE MUST have no element
content in the soap:Body element.
R2214 In a rpc-literal description where the value of the
parts attribute of soapbind:body is an empty string, the
corresponding ENVELOPE MUST have no part
accessor elements.
R2205 A wsdl:binding in a DESCRIPTION MUST
refer, in each of its soapbind:header,
soapbind:headerfault and soapbind:fault elements, only
to wsdl:part element(s) that have been defined using the
element attribute.
R2206 A wsdl:message in a DESCRIPTION containing
a wsdl:part that uses the element attribute MUST refer, in
that attribute, to a global element declaration.
R2301 The order of the elements in the soap:body of an
ENVELOPE MUST be the same as that of the
wsdl:parts in the wsdl:message that describes it.
R2302 A DESCRIPTION MAY use the parameterOrder
attribute of an wsdl:operation element to indicate the
return value and method signatures as a hint to code
generators.
R2303 A DESCRIPTION MUST NOT use Solicit-
Response and Notification type operations in a
wsdl:portType definition.
R2304 A wsdl:portType in a DESCRIPTION MUST
have operations with distinct values for their name
attributes.
R2305 A wsdl:operation element child of a
wsdl:portType element in a DESCRIPTION MUST be
constructed so that the parameterOrder attribute, if
present, omits at most 1 wsdl:part from the output
message.
R2306 A wsdl:message in a DESCRIPTION MUST
NOT specify both type and element attributes on the
same wsdl:part.
R2401 A wsdl:binding element in a DESCRIPTION
MUST use WSDL SOAP Binding as defined in WSDL
1.1 Section 3
R2701 The wsdl:binding element in a DESCRIPTION


Version 1.6Error! Bookmark not defined.                                     Page 110
                                        Washington JIN CACH Queries Design

      Claim                                                   Detail
MUST be constructed so that its soapbind:binding child
element specifies the transport attribute.
R2702 A wsdl:binding element in a DESCRIPTION
MUST specify the HTTP transport protocol with SOAP
binding. Specifically, the transport attribute of its
soapbind:binding child MUST have the value
"http://schemas.xmlsoap.org/soap/http".
R2705 A wsdl:binding in a DESCRIPTION MUST
either be a rpc-literal binding or a document-literal
binding.
R2706 A wsdl:binding in a DESCRIPTION MUST use
the value of "literal" for the use attribute in all
soapbind:body, soapbind:fault, soapbind:header and
soapbind:headerfault elements.
R2709 A wsdl:portType in a DESCRIPTION MAY
have zero or more wsdl:bindings that refer to it, defined
in the same or other WSDL documents.
R2710 The operations in a wsdl:binding in a
DESCRIPTION MUST result in operation signatures
that are different from one another.
R2711 A DESCRIPTION SHOULD NOT have more
than one wsdl:port with the same value for the location
attribute of the soapbind:address element.
R2712 A document-literal binding MUST be serialized
as an ENVELOPE with a soap:Body whose child
element is an instance of the global element declaration
referenced by the corresponding wsdl:message part.
R2714 For one-way operations, an INSTANCE MUST
NOT return a HTTP response that contains an envelope.
Specifically, the HTTP response entity-body must be
empty.
R2750 A CONSUMER MUST ignore an envelope
carried in a HTTP response message in a one-way
operation.
R2727 For one-way operations, a CONSUMER MUST
NOT interpret a successful HTTP response status code
(i.e., 2xx) to mean the message is valid or that the
receiver would process it.
R2716 A document-literal binding in a DESCRIPTION
MUST NOT have the namespace attribute specified on
contained soapbind:body, soapbind:header,
soapbind:headerfault and soapbind:fault elements.
R2717 An rpc-literal binding in a DESCRIPTION
MUST have the namespace attribute specified, the value


Version 1.6Error! Bookmark not defined.                                      Page 111
                                        Washington JIN CACH Queries Design

      Claim                                                   Detail
of which MUST be an absolute URI, on contained
soapbind:body elements.
R2726 An rpc-literal binding in a DESCRIPTION
MUST NOT have the namespace attribute specified on
contained soapbind:header, soapbind:headerfault and
soapbind:fault elements.
R2718 A wsdl:binding in a DESCRIPTION MUST
have the same set of wsdl:operations as the
wsdl:portType to which it refers. C
R2719 A wsdl:binding in a DESCRIPTION MAY
contain no soapbind:headerfault elements if there are no
known header faults.
R2740 A wsdl:binding in a DESCRIPTION SHOULD
contain a soapbind:fault describing each known fault.
R2741 A wsdl:binding in a DESCRIPTION SHOULD
contain a soapbind:headerfault describing each known
header fault.
R2742 An ENVELOPE MAY contain fault with a detail
element that is not described by a soapbind:fault element
in the corresponding WSDL description.
R2743 An ENVELOPE MAY contain the details of a
header processing related fault in a SOAP header block
that is not described by a soapbind:headerfault element in
the corresponding WSDL description.
R2720 A wsdl:binding in a DESCRIPTION MUST use
the part attribute with a schema type of "NMTOKEN" on
all contained soapbind:header and soapbind:headerfault
elements.
R2749 A wsdl:binding in a DESCRIPTION MUST
NOT use the parts attribute on contained
soapbind:header and soapbind:headerfault elements.
R2721 A wsdl:binding in a DESCRIPTION MUST
have the name attribute specified on all contained
soapbind:fault elements.
R2754 In a DESCRIPTION, the value of the name
attribute on a soapbind:fault element MUST match the
value of the name attribute on its parent wsdl:fault
element.
R2722 A wsdl:binding in a DESCRIPTION MAY
specify the use attribute on contained soapbind:fault
elements. C
R2723 If in a wsdl:binding in a DESCRIPTION the use
attribute on a contained soapbind:fault element is
present, its value MUST be "literal".

Version 1.6Error! Bookmark not defined.                                      Page 112
                                        Washington JIN CACH Queries Design

      Claim                                                   Detail
R2707 A wsdl:binding in a DESCRIPTION that
contains one or more soapbind:body, soapbind:fault,
soapbind:header or soapbind:headerfault elements that
do not specify the use attribute MUST be interpreted as
though the value "literal" had been specified in each
case.
R2724 If an INSTANCE receives an envelope that is
inconsistent with its WSDL description, it SHOULD
generate a soap:Fault with a faultcode of "Client", unless
a "MustUnderstand" or "VersionMismatch" fault is
generated.
R2725 If an INSTANCE receives an envelope that is
inconsistent with its WSDL description, it MUST check
for "VersionMismatch", "MustUnderstand" and "Client"
fault conditions in that order.
R2729 An ENVELOPE described with an rpc-literal
binding that is a response MUST have a wrapper element
whose name is the corresponding wsdl:operation name
suffixed with the string "Response".
R2735 An ENVELOPE described with an rpc-literal
binding MUST place the part accessor elements for
parameters and return value in no namespace.
R2755 The part accessor elements in a MESSAGE
described with an rpc-literal binding MUST have a local
name of the same value as the name attribute of the
corresponding wsdl:part element.
R2737 An ENVELOPE described with an rpc-literal
binding MUST namespace qualify the descendents of
part accessor elements for the parameters and the return
value, as defined by the schema in which the part
accessor types are defined.
R2738 An ENVELOPE MUST include all
soapbind:headers specified on a wsdl:input or
wsdl:output of a wsdl:operation of a wsdl:binding that
describes it.
R2739 An ENVELOPE MAY contain SOAP header
blocks that are not described in the wsdl:binding that
describes it.
R2753 An ENVELOPE containing SOAP header blocks
that are not described in the appropriate wsdl:binding
MAY have the mustUnderstand attribute on such SOAP
header blocks set to '1'.
R2751 The order of soapbind:header elements in
soapbind:binding sections of a DESCRIPTION MUST
be considered independent of the order of SOAP header


Version 1.6Error! Bookmark not defined.                                      Page 113
                                        Washington JIN CACH Queries Design

      Claim                                                       Detail
blocks in the envelope.
R2752 An ENVELOPE MAY contain more than one
instance of each SOAP header block for each
soapbind:header element in the appropriate child of
soapbind:binding in the corresponding description.
R2744 A HTTP request MESSAGE MUST contain a                 If the SOAPAction construct is used, the action
SOAPAction HTTP header field with a quoted value            must be in quotations.
equal to the value of the soapAction attribute of
soapbind:operation, if present in the corresponding
WSDL description.
R2745 A HTTP request MESSAGE MUST contain a
SOAPAction HTTP header field with a quoted empty
string value, if in the corresponding WSDL description,
the soapAction of soapbind:operation is either not
present, or present with an empty string as its value.
R2747 A CONSUMER MUST understand and process                The WS-Address and WS-Security elements are
all WSDL 1.1 SOAP Binding extension elements,               required and listed as required in the WSDL
irrespective of the presence or absence of the
wsdl:required attribute on an extension element; and
irrespective of the value of the wsdl:required attribute,
when present.
R2748 A CONSUMER MUST NOT interpret the
presence of the wsdl:required attribute on a soapbind
extension element with a value of "false" to mean the
extension element is optional in the envelopes generated
from the WSDL description.
R2800 A DESCRIPTION MAY use any construct from
XML Schema 1.0.
R2801 A DESCRIPTION MUST use XML Schema 1.0
Recommendation as the basis of user defined datatypes
and structures.
R3002 REGDATA of type uddi:tModel representing a            UDDI is not being implemented for this iteration
conformant Web service type MUST use WSDL as the
description language.
R3003 REGDATA of type uddi:tModel representing a
conformant Web service type MUST be categorized
using the uddi:types taxonomy and a categorization of
"wsdlSpec".
R3010 REGDATA of type uddi:tModel representing a
conformant Web service type MUST follow V1.08 of
the UDDI Best Practice for Using WSDL in a UDDI
Registry.
R3011 The wsdl:binding that is referenced by
REGDATA of type uddi:tModel MUST itself conform to
the Profile.

Version 1.6Error! Bookmark not defined.                                                                       Page 114
                                       Washington JIN CACH Queries Design

      Claim                                                        Detail
R5000 An INSTANCE MAY require the use of                    HTTP/S is required for all JINDEX transports.
HTTPS.                                                      All URLS for posts use https://hostname
R5001 If an INSTANCE requires the use of HTTPS, the
location attribute of the soapbind:address element in its
wsdl:port description MUST be a URI whose scheme is
"https"; otherwise it MUST be a URI whose scheme is
"http".
R5010 An INSTANCE MAY require the use of HTTPS              The instances do use X.509 Certificates for
with mutual authentication.                                 mutual authentication but this is not represented
                                                            in the WSDL with the exception of the https url
                                                            type.




Version 1.6Error! Bookmark not defined.                                                                     Page 115
                                       Washington JIN CACH Queries Design

APPENDIX C – CACH SCHEMA




CACH SCHEMA

       The CACH Schema text is not included, but rather the schemas are included as external files.




   #                                                   Design Feature
  DF93     CACH Schemas have been developed using the GJXDM 3.0.2 standards.

  DF94     The WSDL that enables each web service exchange is included as a separate package

  DF95     The schemas that validate each message type are included as a separate package




Version 1.6Error! Bookmark not defined.                                                               Page 116
                                        Washington JIN CACH Queries Design

APPENDIX D – DESIGN FEATURE TRACEABILITY

       This section presents the Technical Requirements from the Technical Requirements Baseline and
       relates them to the design features of this document. Design features are listed as DFn
   #                                               Technical Requirements
  TR1      Authorization to obtain records via the National Crime Information Center (NCIC) Interstate
           Identification Index (III) is governed by federal laws and state statutes approved by the U. S. Attorney
           General that are applicable to the U.S. Department of Justice, Federal Bureau of Investigation, and
           NCIC 2000.
           As such, all requests for information through CACH Query Services shall include:
                            The Originating Agency Identifier (ORI) from which the request is generated, and
                            A valid Purpose Code
                  DF61
  TR2      While not required by law and statute, all requests for information through CACH Query Services shall
           also include:
                            The name of the individual within the criminal justice agency requesting the
                             information
           This has been identified by the State Patrol as a likely future requirement for NCIC and III. It will also
           assist in debugging and auditing.
                  DF61
  TR3      The Possible Criminal History Query will allow a Criminal Justice Practitioner to query on a person‟s
           characteristics and attributes, in order to determine if the person exists in existing Court and/or Criminal
           data repositories. Possible inputs into this query include:
           Because the Criminal Justice Practitioner will likely have incomplete information on a subject, all of
           these parameters will be optional in the query. This will allow for very flexible querying based on a
           wide range of inputs (e.g. “Joe Perp, Caucasian, Male”, “Jane Doe, Hispanic, Female, Tacoma, WA”,
           etc.)
                  DF45, DF46
  TR4      The ID of Possible Match Query will use the input Name fields to automatically query against backend
           systems‟ Name and Alias fields, without requiring the service consumer to explicitly denote aliases in
           the request.
                  DF47
  TR5      Outputs of the ID of Possible Match Query will include all of the same data elements as the query input,
           as well as the source of the record. Note that this response does not include PCN, since a single subject
           may have multiple PCNs.
           This will allow the Criminal Justice Practitioner to determine the appropriate record(s) that corresponds
           most closely to the subject on whom they are querying. For example, if the Criminal Justice Practitioner
           queries on Joe Perp, Caucasian, Male”, the result might be a lengthy list
                  DF49, DF50
  TR6      The CACH Query will allow a Criminal Justice Practitioner to „drill in‟ to a person‟s specific records in
           Court and/or Criminal data repositories. Possible inputs into this query include:


Version 1.6Error! Bookmark not defined.                                                                        Page 117
                                       Washington JIN CACH Queries Design

   #                                              Technical Requirements
          Criminal Justice Practitioners will only need to supply one of the identification numbers in order to
          execute this query; however, the provision of all available identifiers will increase the likelihood of
          getting the best possible dataset back.
                 DF51, DF52, DF53
  TR7     While the PCN is „incident‟ rather than „person‟ based (i.e. a single person may have multiple PCNs),
          stakeholders felt that Criminal Justice Practitioners would want the option to “find me all records for the
          person associated with this incident/PCN”. As such, CACH queries will be executable based on PCN.
                 Not a required feature: DF54
  TR8     Outputs from the CACH Query will include specific case and/or criminal history data from the Courts‟
          and the State Patrol‟s data repositories. The intent is not to supply comprehensive information, with all
          information on every case and conviction, but to provide summary data sufficient for immediate needs
          and further drill down, if required (if the Criminal Justice Practitioner wishes to receive comprehensive
          information on a specific case or conviction, a future web service would allow further drill down, based
          on identification numbers).
                 DF55, DF56
  TR9     JIN CACH will create GJXDM schema subsets in accordance with rules and conventions set forth by
          the Department of Justice – Office of Justice and Georgia Tech Research Institute.
                 DF43
  TR10    CACH GJXDM schema subsets will exist within a namespace specific to the State of Washington JIN
          program. This namespace may import elements from other namespaces, as determined during project
          design.
                 DF42, DF44
  TR11    Artifacts recommended by the GJXDM Information Exchange Package Description Guidelines, dated
          January 24, 2005, will be produced as part of the CACH project in order to produce consistent
          documentation and models for future JIN projects.
                 DF79, DF81
  TR12    CACH queries will implement a splitter component, which will take a single request from a service
          consumer and split the request into multiple requests to the service providers
                 DF13, DF31
  TR13    CACH queries will implement an aggregator component, which will combine multiple responses
          related to a single request into a single response. The aggregator will combine multiple responses from
          different systems into a single response, but will not perform logical manipulation or duplicate
          suppression of the data contained therein.
                 DF32
  TR14    The aggregator will have administrator-configurable Time To Live and Number of Responses
          parameters. These will be changeable by JINDEX system administrators without requiring
          programming.
                 DF33, DF34
  TR15    Negative responses will be explicitly identified in responses to consumers. Negative responses will
          distinguish between (1) system unavailable, (2) response is still pending, and (3) system has no data to
          match the query


Version 1.6Error! Bookmark not defined.                                                                       Page 118
                                       Washington JIN CACH Queries Design

   #                                                  Technical Requirements
                  DF57
  TR16    The splitter and aggregator will allow for transmission and tracking of message identifiers, correlation
          identifiers, and return addresses.
                  DF33, DF34
  TR17    The following fields are required and should be expressed as part of the SOAP headers.
                   Security Token for WSP – ORI
                   Message Identifiers
                   Correlation Identifiers
                   Return Address
                  DF36, DF37, DF39, DF40, DF41, DF58, DF59, DF60, DF61
  TR18    WS-Security standards shall be used for conveying security tokens
                  DF61
  TR19    WS-Addressing standards shall be used for conveying the message identifiers, correlation identifier and
          the return address.
                  DF39, DF40, DF41, DF59, DF60
  TR20    JINDEX will log information pertaining to WHO accessed WHAT, and WHEN they did it. As such, for
          ID of Possible Match and CACH Requests and Responses, JINDEX will extract from the messages and
          log:
                            The agency initiating the post (e.g. this will be KC or Yakima for requests, AOC or
                             WSP for responses)
                            ORI
                            Username
                            Date and time of the post
                            Message identifier
                            Correlation identifier
                            Return address
                            Type of message (e.g. ID of Possible Match Request or Response, CACH Request or
                             Response, eCitations or future message types)
          Note that the contents messages will not be persisted. Logging this level of information will allow
          JINDEX administrators to support the community in determining the nature of the traffic that was
          routed through the framework, but not the contents of the traffic.
                  DF20
  TR21    Access to JINDEX logs will be limited by Access Control Lists (ACLs). JINDEX administrators will be
          the only personnel in these ACLs.
                  DF23
  TR22    Endpoint agencies will continue the current activities that facilitate compliance with established audit


Version 1.6Error! Bookmark not defined.                                                                      Page 119
                                      Washington JIN CACH Queries Design

   #                                             Technical Requirements
          requirements and agreements.
                 DF20
  TR23    JINDEX will facilitate the logging of exception events, such as endpoint system unavailability, mal-
          formed incoming messages, etc. Exception events shall be separately distinguishable from normal traffic
          in the JINDEX (this will likely be specific to the specific platform selected for the JINDEX and its
          associated tools/management consoles)
                DF28
  TR24    For ID of Possible Match (PCH) and CACH queries and responses, if an endpoint system is unavailable
          at the time when the JINDEX attempts to initiate a post, the JINDEX will not attempt to retransmit.
                Not Designed – It‟s a negative feature
  TR25    Depending on the native functionality of the platform selected for the JINDEX, administrators should be
          able to view a management console which displays the „up‟ or „down‟ status of endpoint systems and
          web services.
                DF28
  TR26    Depending on the native functionality of the platform selected for the JINDEX, administrators should be
          able to view a management console which displays the load on particular web services (e.g. number of
          requests in a given time period), CPU utilization of the JINDEX server(s), etc. Ideally, the console will
          allow the administrator to configure load alert thresholds, which, if exceeded, would allow for
          automated notification.
                DF28
  TR27    Agency applications will be responsible to alert/notify front end users when a back-end web service is
          not available. If JINDEX does not provide a response, or provides an error response code, agencies
          must determine if and how to present this information to users.
                DF35
  TR28    If JINDEX cannot successfully connect to an endpoint system for ID of Possible Match (PCH) and
          CACH queries and responses, JINDEX support staff shall be notified immediately (this may be
          implemented in a number of manners, with email being the most likely, to be decided at design.)
                DF30
  TR29    Alert notifications should be dispatched once and only once, while the error condition exists. (For
          example, if the AOC system is down, the administrator should receive but a single (or limited number
          of) notifications, even if numerous CACH requests are received prior to the problem resolution). Once
          the error has resolved, either by a manual process or automatically, notifications should be dispatched
          again if the condition returns.
                DF27, DF29
  TR30    Traffic between the JINDEX and agency systems (AOC, King and Yakima counties) will be secured
          using server-to-server certificate-based authentication, i.e. transport level security. This is equally
          applicable to any agency, regardless of the network their server resides on (i.e. IGN, SGN, or Internet)
                DF6, DF21, DF71
                It is important to note that server-to-server authentication is a client-to-server as server
                certificates authenticates other client certificates only. In addition, the requirement for SGN
                authentication is being demoted, as the computational overhead of SSL is unnecessarily


Version 1.6Error! Bookmark not defined.                                                                      Page 120
                                      Washington JIN CACH Queries Design

   #                                              Technical Requirements
                 excessive for given the reasonable confidence of the security of the SGN.


  TR31    Connectivity between the JINDEX and the ACCESS switch will be secured using a TCP connection
          over a VPN.
                 DF5
  TR32    Agencies will be responsible for acquiring their own server certificates.
                 DF67
                 JIN will be responsible for purchasing the King County and Yakima County certificates
  TR33    The JIN CACH will provide WSDL to the AOC for the requests and the responses to the ID of Possible
          Match (Possible Criminal History) and the CACH queries. The WSDL will define implementation
          specifics for both SOAP headers (WS-Security and WS-Addressing), and SOAP bodies (CACH-
          specific Justice XML)
                 DF65, DF72
  TR34    The AOC will be responsible for any back end logic (e.g. SQL calls, stored procedures, API or method
          invocation, etc.) necessary to execute the web service queries once they are received by WebSphere.
                 DF66
  TR35    Because query responses will be sent asynchronously from query requests, WebSphere will need to
          implement a basic message store, tracking the state of completion of individual conversations. Further
          detail on this requirement will be conveyed in the Design Document.
                 DF68
  TR36    Connectivity with ACCESS will be achieved by establishing a TCP connection, in accordance with all
          requirements outlined in MSS External Interface Programmer‟s Guide
                 DF11
  TR37    JINDEX services will transform and translate from CACH Justice XML message formats, into the
          terminal syntax message formats defined in the ACCESS Manual
                 DF76, DF77
  TR38    When responses are posted from ACCESS (and hence its connected systems, such as NLETS and III)
          back to the JINDEX, the JINDEX will parse the character stream into the CACH Justice XML message
          formats.
                 DF73
  TR39    Due to performance considerations of parsing from a raw character stream (analogous to „screen
          scraping‟) not all data from ACCESS will be transformed into XML. The entire, raw text string will,
          however, be provided in an appropriate XML element, such that no information is lost over what is
          currently provided by ACCESS.
                 DF74, DF75
  TR40    CACH will implement a web page that will allow a user to input all data elements identified in technical
          requirement T3, for the ID of Possible Match Query. Normal web conventions shall be used for
          validation or enumerated options (such as radio groups or drop downs for Sex, Race, and State, format
          validation for Date of Birth)


Version 1.6Error! Bookmark not defined.                                                                   Page 121
                                      Washington JIN CACH Queries Design

   #                                             Technical Requirements
                DF78
  TR41    CACH will implement a web page that will display all data elements contained in the results of the ID
          of Possible Match Query, identified in technical requirement T5. The display will contain a default sort
          order (to be established in the design document), but will not implement dynamic re-ordering of display
          results.
                DF79
  TR42    The results page from the ID of Possible Match Query will hyperlink subject names in order to invoke
          the CACH Query web service. There will not be a separate web page through which to manually invoke
          the CACH Query web service (e.g. a page that allows for the manual entry of the various types of
          identifiers). Clicking on a subject name hyperlink will pass all data identified in technical requirement
          T6 to the CACH Query.
                DF80
  TR43    CACH will implement a web page that will display all data elements contained in the results of the
          CACH Query, identified in technical requirement T8. The display will contain a default sort order (to be
          established in the design document), but will not implement dynamic re-ordering of display results.
                DF81, DF82
  TR44    Because HTTP is a connection-less protocol and web service query results will be returned
          asynchronously, user web pages will need to be refreshed, either manually or automatically, in order to
          display query results.
                DF83
  TR45    An intermediate data store may be required in order to store and collate query results for when the user
          refresh occurs. The data store does not need to be production quality.
                 DF84
  TR46    The user interface will not require graphic design (apart from implementation of the JIN logo)
                 See sample U/I
  TR47    The user interface can make use of the most current version of Internet Explorer, and does not need to
          be designed for cross-browser or cross-version support.
                Ajax and JavaScript is supported in Internet Explorer, Firefox, Safari
  TR48    The user interface will not require user authentication and the associated requirement for maintenance
          of a username/password data store. The JIN Program Office will determine how access to the user
          interface will be controlled.
                There is no Design Feature for a non requirement




Version 1.6Error! Bookmark not defined.                                                                    Page 122
                                        Washington JIN CACH Queries Design

APPENDIX E – GLOSSARY OF TERMS

Several terms and 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, common services 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 (Case and Criminal History).
Web Service – A software system designed to support interoperable machine-to-machine interaction over a
network. It has an interface described in a format that machines can process (specifically WSDL). Other
systems interact with the Web service in a manner prescribed by its description using SOAP messages,
typically conveyed using HTTP with XML serialization in conjunction with other Web-related standards
(W3C).
A programmatic interface to a capability that is in conformance with WSnn protocols
Service-Oriented Architecture SOA – The policies, practices, frameworks that enable application
functionality to be provided and consumed as sets of services published at a 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 as a style resulting from the use of particular policies, practices and frameworks that deliver services
that conform to certain norms. Examples include certain granularity, independence from the implementation,
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.
MESSAGE – As defined by the WS-I standards adopted by JINDEX. Protocol elements that transport the
ENVELOPE (e.g., SOAP/HTTP messages).
ENVELOPE – The serialization of the soap:Envelope element and its content.
DESCRIPTION – descriptions of types, messages, interfaces and their concrete protocol and data format
bindings, and the network access points associated with Web Services (e.g., WSDL descriptions).
INSTANCE – Software that implements a wsdl:port or a uddi:bindingTemplate.
CONSUMER – Software that invokes an INSTANCE.
SENDER – Software that generates a message according to the protocol(s) associated with it.
RECEIVER – Software that consumers a message according to the protocol(s) associated with it.
REGDATA – Registry elements that are involved in the registration and discovery of Web Services (e.g.
UDDI tModels)




Version 1.6Error! Bookmark not defined.                                                                       Page 123

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:16
posted:8/14/2011
language:English
pages:129