HJIP Architecture Plan

Document Sample
HJIP Architecture Plan Powered By Docstoc
					Hennepin Justice
Integration
Program (HJIP)
HJIP Architecture Plan
Version 1.8
May 10, 2006
HJIP – Hennepin County Justice Integration Program                                                                                                 HJIP Architecture Plan
                                                                                                                                                       Table of Contents




Table of Contents

1     EXECUTIVE SUMMARY .....................................................................................................................................1
      1.1      INTRODUCTION..............................................................................................................................................1
      1.2      DOCUMENT PURPOSE...................................................................................................................................1
      1.3      AUDIENCE .....................................................................................................................................................1
      1.4      HJIP REFERENCE ARCHITECTURE (SUMMARY) ............................................................................................2
2     ARCHITECTURAL PRINCIPLES .......................................................................................................................3
      2.1      BUSINESS DRIVEN ........................................................................................................................................3
      2.2      FLEXIBILITY ...................................................................................................................................................3
      2.3      ADAPTABILITY ...............................................................................................................................................4
      2.4      AVAILABILITY .................................................................................................................................................5
      2.5      SECURITY .....................................................................................................................................................6
      2.6      SIMPLICITY....................................................................................................................................................7
      2.7      INFORMATION SHARING.................................................................................................................................7
      2.8      INTEROPERABILITY ........................................................................................................................................8
      2.9      DATA REDUNDANCY......................................................................................................................................8
      2.10     FLEXIBLE IMPLEMENTATION...........................................................................................................................9
      2.11     SKILL SET VARIATION....................................................................................................................................9
3     SERVICE LAYERS.............................................................................................................................................10
      3.1      BUSINESS SERVICES...................................................................................................................................10
      3.2      INTEGRATION SERVICES..............................................................................................................................11
      3.3      APPLICATION SERVICES ..............................................................................................................................12
      3.4      DATA SERVICES..........................................................................................................................................12
      3.5      INFRASTRUCTURE SERVICES ......................................................................................................................13
      3.6      SERVICE LAYER – TECHNOLOGY STANDARD MATRIX ..................................................................................13
4     DEVELOPMENT STANDARDS........................................................................................................................15
      4.1      USER INTERFACE STANDARDS ....................................................................................................................15
      4.2      BASE SERVICES..........................................................................................................................................15
      4.3      J2EE STANDARDS AND CONVENTIONS .......................................................................................................16
      4.4      MESSAGE BROKER STANDARDS AND CONVENTIONS ..................................................................................18
5     DATA STANDARDS ..........................................................................................................................................19
      5.1      DATA ARCHITECTURE .................................................................................................................................19
      5.2      INTEGRATION XML SCHEMA ARCHITECTURE ..............................................................................................21
6     HJIP REFERENCE ARCHITECTURE..............................................................................................................28
      6.1      HJIP REFERENCE ARCHITECTURE DIAGRAM ..............................................................................................28
      6.2      HJIP INTEGRATION STYLES ........................................................................................................................28
7     SYSTEM TOPOLOGY .......................................................................................................................................35
      7.1      SYSTEM CONTEXT DIAGRAM.......................................................................................................................35
8     DEVELOPMENT PROCESS .............................................................................................................................38
      8.1      HJIP DEVELOPMENT METHODOLOGY .........................................................................................................38
      8.2      DEVELOPMENT PROCESS ...........................................................................................................................39
REVISION HISTORY .................................................................................................................................................41




Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                                               Page i of ii                                                      Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                                                                       HJIP Architecture Plan
                                                                                                                                    Table of Figures and Tables




Table of Figures and Tables

Figure 1-1. HJIP Reference Architecture (Summary).................................................................................................2
Figure 3-1. HJIP Architecture Service Layers .......................................................................................................... 10
Table 3-2. HJIP Technology Standards ................................................................................................................... 14
Figure 4-2. Common Logging Service ..................................................................................................................... 16
Figure 4-3. RAD Workspace Organization .............................................................................................................. 18
Figure 4-4. Message Broker Message Flow Naming Conventions ........................................................................ 18
Figure 5-1. Enterprise Architecture ........................................................................................................................... 19
Figure 5-2. Standard Abbreviation Search Using TSO ........................................................................................... 20
Figure 5-3. Mapping from MNCIS Status to SWATS Status .................................................................................. 21
Table 5-4. Hennepin County Domain Name/Agency or Functional Grouping Name............................................ 24
Figure 5-5. SOAP Message Example Outline ......................................................................................................... 27
Figure 6-1. HJIP Reference Architecture (Detail) .................................................................................................... 28
Figure 6-2. Asynchronous Request/Response Integration Style ............................................................................ 30
Figure 6-3. Asynchronous Request/Response Integration Style with Orchestration............................................. 30
Figure 6-4. Point-to-Point Web Services .................................................................................................................. 31
Figure 6-5. Fire and Forget Request ........................................................................................................................ 33
Figure 6-6. Publish/Subscribe ................................................................................................................................... 34
Table 7-1. System Topology ..................................................................................................................................... 35
Figure 7-2. HJIP Production - System Context Diagram (proposed) ..................................................................... 36
Figure 8-1. HJIP Key Program and Project Deliverables ........................................................................................ 38
Table 8-2. Documentation Locations........................................................................................................................ 39




Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                                           Page ii of ii                                                Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                                HJIP Architecture Plan
                                                                                                    Executive Summary




1 Executive Summary

1.1 Introduction

Hennepin County has established the Hennepin Justice Integration Program (HJIP) to prepare for the
implementation of MNCIS and retirement of SIP. HJIP is a collection of interrelated projects driven by the
business, under the guidance and sponsorship of the PPM Steering Committee.

The long term goal of HJIP is to align criminal justice agencies in Hennepin County for eventual sharing of
critical justice information statewide. Program goals are:

         To accurately identify individuals who have been in contact with the criminal justice system within
          Hennepin County
         To make sure that criminal justice records are complete, accurate, and readily available within the
          Hennepin County Criminal Justice System
         To ensure the availability of an individual’s current status in the Hennepin County Criminal Justice
          System: what is going on with the person right now, status of their case, in/out of custody, etc.
         To maintain the security of information within Hennepin County

This document outlines the architecture planned for HJIP. The purpose of establishing an architecture is to
provide a standardized environment that is more reliable, less expensive, and more agile than an environment
where many different technologies are licensed and supported. An architecture establishes the technical
direction and provides a decision making framework to achieve a future vision. Understanding business goals is
critical to the HJIP architecture, because the business drives IT investments for HJIP.

1.2 Document Purpose

This document is a decision making guide to architects, designers, and developers. Best practices for design
and development of software solutions are embedded throughout the document, with an emphasis on
integration styles and considerations important to facilitate the exchange of information between agency
applications.

The applications supporting Hennepin justice agencies have been implemented on a portfolio of very disparate,
highly distributed technologies within and beyond Hennepin County firewalls, including:

         z/Linux, AIX, Windows
         Two-tier, N-tier applications
         Java, PowerBuilder, proprietary VB type language
         Microsoft SQL Server, Sybase, DB/2

The HJIP architecture has been established around specialized core technologies: IBM’s WebSphere
Application Server (WAS) and Message Broker. These products are designed to support integration between
disparate technologies similar to the HJIP environment. While other products may be considered suitable
replacements, a change in direction is not acceptable during the life of HJIP. The implementation time and
learning curve associated with introducing other products would pose a serious risk to the success of HJIP.

1.3 Audience

This document is intended for a technical audience. Architects, designers, and developers assigned to HJIP, as
well as agency IT staff should use the document to aid their development activities.



Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                     Page 1 of 41                                Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                                          HJIP Architecture Plan
                                                                                                              Executive Summary


1.4 HJIP Reference Architecture (Summary)

This diagram below summarizes the HJIP reference architecture, the standard set of interconnecting
technologies that make up the HJIP program. The reference architecture is described and illustrated in detail in
section 6, HJIP Reference Architecture.

                             HJIP
                           Application

                                                                                 HJIP Reference
                                                                                  Architecture
                                                                                   (Summary)

                            Web
 Agency                    Service
                          Messages
  User                                IBM HTTP                                             Information Storage
                                     Web Server
                                                             IBM WebSphere
                                 (Web Service Listener)     Application Server




                                                                CORE
                                                           BUSINESS LOGIC
                                                                                                   SQL Server
                                                                                                   Database/s
                                                             IBM WebSphere
                                                             Message Broker
       Agency
      Application

                           Queued
                          Messages                                               Base Services

                                                                                     Logging
                                                                                                       Security
                                                                                     Auditing



                                                           Guaranteed
                                                           Messages
                                                                                  Directory Services

                                  IBM WebSphere MQ




                                                                                              RACF                 Active
                                                                                       (via z/Linux LDAP)         Directory


Figure 1-1. HJIP Reference Architecture (Summary)




Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                          Page 2 of 41                                   Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                                 HJIP Architecture Plan
                                                                                                   Architectural Principles




2 Architectural Principles

Principles are the conceptual guidelines of the architecture; they are rules or maxims that guide architectural
decisions.

Each principle is stated as simply as possible, followed by a brief explanation and a list of possible architectural
implications.

2.1 Business Driven

Architecture choices must be driven by business requirements, rather than the other way around.

2.1.1 Explanation

Technology investments must serve business needs, and not be for the sake of implementing the latest whiz-
bang technology. Technology choices should be driven by what best serves the business need.

2.1.2 Implications

Application
     Business requirements must be defined as the first step in application development.
     Business users must set priorities and determine the scope of applications.
     Business users must drive acceptance of the application solution.

Technical Infrastructure
    Technical Infrastructure choices should be driven by business requirements, and not the reverse.

2.2 Flexibility

The architecture must be flexible to support the integration of many diverse criminal justice agencies, both within
Hennepin County and outside of it.

2.2.1 Explanation

Many agencies are involved in the overall criminal justice system, including: Hennepin County Sheriff’s Office,
Hennepin County Attorney’s Office, Hennepin County Community Corrections, Fourth District Court,
Minneapolis City Attorney’s Office, Hennepin County Public Defender’s Office, Hennepin County Adult
Corrections Facility (workhouse), local law enforcement within Hennepin County, and state agencies, such as
the BCA and DVS. The HJIP program does not directly control any of these entities. These various agencies do
not necessarily share the same perspectives on the criminal justice business process.

2.2.2 Implications

Application
     Applications may require “wrapper” services and adapters to connect to the integration environment.
         This provides two benefits: (1) the application doesn’t need to change its internal structure to connect to
         the integration environment, and (2) the application can be changed in the future without necessarily
         changing its ability to connect to the integration environment (only the wrapper needs to be updated).
     Industry technical trends and best practices should influence the architecture.

Technical Infrastructure

Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                     Page 3 of 41                                 Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                              HJIP Architecture Plan
                                                                                                Architectural Principles


         Technical choices cannot be dictated to these agencies. The HJIP program must allow flexibility in
          connecting to HJIP integration services.

2.3 Adaptability

The architecture should adapt to business and technical evolution and be effective and maintainable over a long
life span.

2.3.1 Explanation

The architecture must be robust to respond to changing requirements over time (likely several decades). For
example:

         Legislative mandates
         Business process changes
         Technology evolution
         Added functionality from new software or upgrades and extensions to existing software

The chosen architecture should accommodate these changes without degradation.

2.3.2 Implications

Application
     The application will remain acceptable to the majority of the users over time by staying responsive to
         changes in business needs.
     Certain features of vendor-specific tools must be avoided if they tie us too tightly to that vendor.
     The architecture may be realized using a variety of tools, rather than one comprehensive tool, resulting
         in developers needing more initial and ongoing training.
     Change control procedures must be defined, managed, and maintained.
     The architecture should strive to localize changes within a particular functional area, rather than having
         a ripple effect throughout the system. Likely techniques for this include well-factored components and
         layering of services.

Data
         Business rules must be stored so that they facilitate change impact analysis and maintainability.
         Change control procedures must be defined, managed, and maintained.
         A metadata strategy must be defined, managed, and maintained.
         If multiple storage environments (operational, long-term) are used, database changes must be able to
          be replicated to all environments.
         Data structures should be flexible with optimum levels of abstraction to minimize the impact of data
          model changes.

Integration
     Integration services need to be decoupled from other system components and services.
     Handling messaging to and from different types of systems is required.

Technical Infrastructure
    Hardware and network infrastructure must plan for future expansion, as required by business users.
    Technical infrastructure must support interoperable heterogeneous technologies through existing and
        future life cycles.
    Technical infrastructure must provide its services through standard abstract services and interfaces.

Other


Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                     Page 4 of 41                             Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                                 HJIP Architecture Plan
                                                                                                   Architectural Principles


         Some new organizational roles or duties may need to be defined.
         Technical documentation must be created and maintained as the application and architecture evolve.
         Various standards will need to be developed (for example, server naming standards, table naming
          standards, and attribute naming standards).

2.4 Availability

The Criminal justice system relies on functional quality, continual system availability, and satisfactory
performance.

2.4.1 Explanation

Business operations depend on system availability, performance, and continual operation. The business
community must set the availability requirements.

         The system must be available during required hours of operation and meet uptime requirements.
         The system must be scalable and responsive to meet the demands of the user community.

The criminal justice system’s business must continue, despite natural disasters or component failures.

2.4.2 Implications

Application
     Quality must remain the first priority.
     Performance engineering will be conducted throughout the system development lifecycle and as an
         ongoing standard operating procedure.
     Effective application design will make hardware scaling more effective.
     Application support will expand to meet the availability and operational requirements.
     The application architecture will associate priority levels and availability windows to processes.
     System updates will be carefully coordinated to prevent failure.

Data
         Data access, storage, presentation, and movement technologies will be scalable.

Integration
     The integration between systems (and not just the systems themselves) must be reliable and
         maintainable.
     Integrated applications need to apply the same editing and quality assurance to data received from
         other systems as it does against data produced internally.

Technical Infrastructure
    Performance engineering must be conducted throughout the system development lifecycle and as an
        ongoing standard operating procedure.
    Availability, reliability, uptime, and recovery must meet the business goals. This should include
        sufficient network bandwidth and quality of service.
    Technology costs and operational complexity dramatically increase as assured availability approached
        24x7 and as reliability increases.
    Technology must meet or exceed business expectations to recover from a disaster in a timely fashion.
    All single points of failure in the system (network, servers, database, etc) should be identified and
        minimized (if not eliminated completely).




Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                     Page 5 of 41                                Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                               HJIP Architecture Plan
                                                                                                 Architectural Principles


2.5 Security

Information must be accessible only to legitimate and authorized users.

2.5.1 Explanation

Information should be secured from unauthorized access or tampering. This includes authenticating all user
access, authorizing access to application or data resources, encrypting data transmission as necessary, and
logging access for auditing purposes.

2.5.2 Implications

Application
     Application processes will occur within a security context requiring authentication, authorization,
         encryption, and audit logging.
     Application resources will be at a granular scale consistent with business needs.
     Application security should be dynamic to support users with different roles, locations, etc.

Data
         The security profile for each authorized user will determine what data views and accesses are
          permitted.
         Recordkeeping metadata will be maintained to support audit trails for data updates as well as to identify
          inappropriate access or browsing by authorized users.

Integration
     Integration services must ensure that the requesting party is authenticated and authorized to use the
         service.
     Status information will need to accompany integration transactions. For example, the security
         requirements of data may change depending on the business context.
     Encryption protocols will be required to encode/decode sensitive information.

Technical Infrastructure
    The infrastructure will provide for the integrity and confidentiality of information through authentication
        and encryption methods.
    The infrastructure will provide a secure perimeter, using such techniques as firewalls, intrusion
        detection, and virus detection.




Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                     Page 6 of 41                               Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                               HJIP Architecture Plan
                                                                                                 Architectural Principles



2.6 Simplicity

Keep things simple.

2.6.1 Explanation

This principle balances out the competing principles of ultimate flexibility and complexity. To meet the business
requirements and achieve success, the integration system must strive to avoid unnecessary complexity
wherever possible. All else being equal, the simpler solution to a problem is better.

“Entities should not be multiplied unnecessarily.”
– William of Occam

“Everything should be made as simple as possible … but no simpler.”
– Albert Einstein

2.6.2 Implications

Application
     Before adopting a new technology, we must be certain it will add value to the application without adding
         unnecessary complexity.
     Keeping the application simple reduces developer training, reduces error rates, and makes ongoing
         maintenance easier.

Data
         Any variability should be based on business needs.

Integration
     To promote simplicity, standards must be clear.

Technical Infrastructure
    The system must be supportable by county or agency staff, with reasonable training and expertise.
        Additional staff may be required to support the integration system; however, keeping the system simple
        will ameliorate the increase.
    Architectural choices that lead to heavy system management requirements should be discouraged.

2.7 Information Sharing

The criminal justice system values sharing information with the many legitimate users of that information as
conveniently as possible and within legal and regulatory constraints.

2.7.1 Explanation

Many classes of legitimate users need convenient access to appropriately authorized portions of criminal justice
data.

2.7.2 Implications

Application
     Information sharing might need to be real time or at mutually acceptable intervals.
     Information sharing should not be the responsibility of the users manually initiating a process at a
         particular agency; wherever possible, it should be automatically performed by the system.


Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                     Page 7 of 41                              Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                                HJIP Architecture Plan
                                                                                                  Architectural Principles


Data
         The data architecture will need to address the key common data elements that will be used for
          interoperating across the criminal justice system.
         Certain types of metadata may need to be provided as part of the information that is shared (currency
          of data, whom to contact with questions or issues, etc.).
         Data privacy laws and confidentiality requirements must be obeyed, as required by statute.

Integration
     Information sharing, motherhood, and apple pie are all good things.
     HJIP needs to continue to take a proactive approach to promote information sharing across the criminal
         justice enterprise within Hennepin County and with the state.
     Integration services need to be designed and built so that criminal justice agencies can share
         information conveniently, legally, and according to the rights of citizens. HJIP business sponsors will
         need to make policy decisions on the degree of accessibility.
     The justice system needs to have metadata available and maintained. This will allow for a better
         understanding of shared information.
     Data quality assurance procedures need to be in place to ensure that high quality data is shared.
     Services should adhere to industry standards designed to facilitate open, non-proprietary interchange.
         (The definition of “open” must be pragmatic and according to wide industry acceptance, rather than any
         academic definition.)

Technical Infrastructure
    The technical infrastructure will likely support an increasingly greater group of business partners. The
        architecture should proactively plan for this scalability growth.
    Availability and quality of service levels must be carefully defined.

2.8 Interoperability

Integration services should be technically neutral, to maximize interoperability between agencies’ systems.

2.8.1 Explanation

Suppliers and consumers of criminal justice data will not be required to adopt a specific product set to use
criminal justice information or processes. The integration architecture will have to interact with systems that are
based on a variety of technologies but that are based on fundamental standards, such as TCP/IP and XML.

2.8.2 Implications

         Services should adopt or adhere to industry standards designed to facilitate open, non-proprietary
          interchange. (The definition of “open” must be pragmatic and according to wide industry acceptance,
          rather than any academic definition.)
         “Wrapper” services and adapters may be required for older technologies that may not directly support
          standards. This may include the requirement that adapters be built.
         Handle messaging from different types of systems will be required.
         Candidate solutions must be limited to those following appropriate standards.
         Integration services must be decoupled from agency operational systems

2.9 Data Redundancy

Strive to minimize the creation of redundant data.




Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                     Page 8 of 41                                Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                              HJIP Architecture Plan
                                                                                                Architectural Principles


2.9.1 Explanation

Data should be stored in only one place and managed by the business owner of that data. When data needs to
be updated, the change only needs to occur in one place. We should avoid storing data redundantly. As an
example, our direction is not to store many copies of the MNCIS database.

2.9.2 Implications

         Replicating one or more copies of a particular data store is not recommended.
         A common understanding of data definitions is required.
         Metadata must be available and maintained.
         Data quality procedures are required.
         Data providers need to build integration services that data consumers can use to request the specific
          data elements they need to integrate into their operational system.
         The only time redundant data storage should be considered is for reporting needs, where a runtime
          request for data elements would not suffice.

2.10 Flexible Implementation

All organizations or systems will not be ready to implement integration at the same time.

2.10.1 Explanation

Different agencies have different levels of resources and existing systems. Some agencies can more easily
participate in integration.

2.10.2 Implications

Solutions to integration (API, wrapper technologies) need to accommodate the different levels of readiness.

2.11 Skill Set Variation

The knowledge and skill sets of the participating agencies must be adequate to implement processes to
consume and produce information for exchange.

2.11.1 Explanation

Smaller agencies involved in the criminal justice system have little or no access to data processing services.

2.11.2 Implications

The integration architecture will have to plan for agencies and systems of varying levels of sophistication. Some
large systems will require multiple, complex integrations, often with interdependencies. Other systems may only
require a small number of simple integrations.




Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                     Page 9 of 41                              Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                              HJIP Architecture Plan
                                                                                                       Service Layers




3 Service Layers

The overall HJIP architecture can be viewed as layers of necessary services, the upper layers building on the
lower ones. This section describes each of these layers, as well as the standard tools used to implement each
layer.


                          Business Services Layer


          Application Services Layer     Integration Services Layer


                            Data Services Layer


                        Infrastructure Services Layer


Figure 3-1. HJIP Architecture Service Layers

3.1 Business Services

3.1.1 Agency Applications

Agencies will continue to use their existing applications. HJIP provides integration between agency applications;
it does not replace them.

         MNCIS
         JMS
         Etc.

3.1.2 HJIP Applications

HJIP will build a small number of common applications, where necessary to fulfill functionality needs that are not
currently met by existing agency applications.

These two applications are currently in scope:

         SILS
         Countywide Criminal Calendar

3.1.3 Business Rule Services

The architecture must implement business rule logic within integrations that govern the business process
execution.

For example, if a booking document doesn’t contain a SILS number, it should call the SILS search service to
search for one.




Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                           Page 10 of 41                       Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                              HJIP Architecture Plan
                                                                                                       Service Layers


3.1.4 Business Process Orchestration

The architecture must orchestrate business processes that span across agency applications. This orchestration
is a composition of other services that together fulfill the business process. Integration tools should provide
support for graphical scripting of this orchestration.

For example, a booking document notification may require several other integrations to be coordinated to a
successful conclusion: a custody status update sent to MNCIS, and then an add/update sent to SILS, etc.

3.2 Integration Services

The HJIP program uses integration services to transmit information between collaborating agency applications
to realize overall business processes that span agencies.

3.2.1 Service Oriented Architecture (SOA)

Simply stated, a service oriented architecture (SOA) is a strategy for encapsulating business software
components and making them easy to access across an enterprise by requesting applications, often in an
aggregated fashion. Requesting applications should not have to worry about the technical details of how a
particular software component is implemented technically, what platform it resides on, or what network path or
protocol is required to access it.

The key characteristics of an SOA are as follows:

         Encapsulated software components: The technical implementation of a component is hidden from
          the requesting application.
         Well-defined business services: A service should provide a well-defined business service. This may
          include the service in turn calling other services to fulfill the overall request.
         Implementation-neutral interfaces: The interface method to access a software component is
          independent from the technical implementation. It should follow standard interface techniques, such as
          XML, SOAP, web services, or messaging (for example, JMS or MQ).
         Transparent service requests: The service request should be independent of the service’s technical
          implementation, connection method, or protocol.

3.2.2 Enterprise Service Bus (ESB)

The enterprise service bus (ESB) provides the interconnection layer on which an SOA is implemented. The
ESB provides reliability, scalability, and security to the SOA services.

The key characteristics of an ESB are as follows:

         Universal connectivity of services via XML messaging: Connecting requesters and providers
          across diverse platforms and data models, providing a common backbone for requests, messages, and
          events.
         Vendor-independent communication standards: Such as SOAP and Java Messaging Service
          (JMS).
         Quality of service: Guaranteed delivery of messages, response time, etc.
         Service mediation: Loose coupling of requesters and providers
         Scalability and availability: The ESB solution must have proven scalability and high availability.
         Transaction management: Coordinating transactions across multiple services.
         Security: The ESB provides a standard security platform that the SOA services depend on.
         Monitoring and management: As an enterprise service, the ESB requires monitoring and
          management capabilities to ensure its continual performance.


Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                     Page 11 of 41                            Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                                HJIP Architecture Plan
                                                                                                         Service Layers


         Graphical design tools: Development productivity is enhanced by effective design tools in the ESB.
         Content-based routing of services via XML messaging: Connecting requesters and providers
          across diverse platforms and data models, providing a common backbone for requests, messages, and
          events.

3.2.3 Process Orchestration

Process orchestration provides for the composition of multiple services together to fulfill a business process
requirement.

Orchestration requires several capabilities for maintaining the consistency and integrity of the overall process:

         Persistence and correlation: State must be maintained across multiple service calls, especially when
          they are asynchronous. Data persistence and message correlation enable this state to be maintained in
          higher-level conversations.
         Exception handling and transactions: Orchestrations often contain long running transactions. The
          ESB infrastructure must provide exception handling for failed transactions.

3.3 Application Services

Within the HJIP program, the SILS application and the Countywide Criminal Calendar application will require
presentation layer services and application logic services.

3.3.1 Presentation Layer Services

Because of the very wide distribution of HJIP users, HJIP applications need to provide a thin-client presentation
without installation and maintenance of client applications.

To achieve this requirement, HJIP will use an Internet browser standard for this layer.

3.3.2 Application Logic Services

The application logic layer executes and controls the application logic.

3.4 Data Services

Data services define the meaning of data, transform data between different formats, and persist data to a
storage medium.

3.4.1 Metadata Definition

Metadata is data about data, describing the structure and meaning of data. In the case of XML messaging, the
HJIP architecture will use XML schema to define the structure and semantics of HJIP data exchanges. See
section 5.2.1, Overall Schema Approach for HJIP, for more details on the XML schema approach.

For databases, HJIP will use Sybase PowerDesigner for data model design.

3.4.2 Data Transformation

Data exchanges through HJIP integration environment will often require two data transformation services:
encoding and semantics.



Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                     Page 12 of 41                              Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                                          HJIP Architecture Plan
                                                                                                                   Service Layers


3.4.2.1 Encoding

Data must be transformed from one encoding to another: EBCDIC to/from ASCII, Base64 encoding, etc.

3.4.2.2 Semantics

Messages must be transformed from one semantic meaning to another.

For example, a MNCIS notification message might specify a charge sequence ID, which needs to be
transformed into a count number for the County Attorney.

3.4.3 Data Persistence

Data persistence reliably places data onto a storage medium for later retrieval.

3.5 Infrastructure Services

Infrastructure services provide the lowest level of services that all the higher services build on.

3.5.1 Security

The security layer must provide authentication, resource authorization, and encryption services to the ESB. See
section 4.2.1, Security, for a description of the standard HJIP security service.

3.5.2 Logging

The logging layer must provide audit logging of resource access, as well as different levels of error and
performance logging for diagnostic purposes. See section 4.2.2, Logging, for a description of the standard HJIP
logging service.

3.5.3 Operating System

The operating system provides the base software platform on the hardware server on which the higher levels of
software can run.

3.5.4 Hardware Server

The hardware server environment provides the physical computing resources for all higher software layers. It
should provide the following features:

         High availability: Single points of failure should be eliminated so that the servers will continue to
          operate if one of them fails.
         Load balanced performance: Multiple servers that are load balanced provide higher performance.

3.6 Service Layer – Technology Standard Matrix

           Service Layer                                          Technology Standard
Business Services
Agency applications                     Existing applications per agency, except the new MNCIS application for
                                        District Court.



Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                          Page 13 of 41                                   Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                                                HJIP Architecture Plan
                                                                                                                         Service Layers


           Service Layer                                                Technology Standard
HJIP applications                       SILS
                                        Countywide Calendar System
Business rule services                  IBM WebSphere Message Broker
Business process orchestration          IBM WebSphere Message Broker
Integration Services
Service Oriented Architecture (SOA)     IBM WebSphere Application Server (WAS)
                                        IBM WebSphere Message Broker
Enterprise Service Bus                  WebSphere Message Broker
Client Message Queuing Software         For sending/receiving MQ messages:
                                                    MQ client (free)
                                                    MQ Queue Manager (not free) – but allows client-side message
                                                     persistence
Application Services
Presentation layer services             Microsoft Internet Explorer
                                        Netscape Navigator
Application logic services              IBM WebSphere Application Server (WAS)
Data Services
Metadata definition                     For data exchanges: XML schema
                                        For database modeling: Sybase PowerDesigner
Data transformation                     IBM WebSphere Message Broker
                                        e-SQL and XSLT
Data persistence                        Microsoft SQL Server 2000 or 2005
Infrastructure Services                 TBD. As of this revision, county IT is still deciding on the infrastructure
                                        standards.
Security                                See section 4.2.1, Security.
Logging                                 See section 4.2.2, Logging.
Operating system                        TBD.
                                        Either Windows Server 2003 or z/Linux
Hardware server                         TBD.
                                        Either Windows/Intel platform or mainframe.
Application Monitoring                  Qpasa will be used for the monitoring of all MQ instances as well as being
                                        used for alerting. Qpasa will watch error and dead queues to send alerts to
                                        the operational support team for esculation level support of all jobs.
Table 3-2. HJIP Technology Standards




Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                             Page 14 of 41                                      Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                              HJIP Architecture Plan
                                                                                               Development Standards




4 Development Standards

4.1 User Interface Standards

HJIP will leverage existing Hennepin County user interface standards and guidelines for projects that include UI
deliverables.

Hennepin County’s content management system provides a convenient link to these resources, including:

         Section 508 requirements to make electronic and information technology accessible to people with
          disabilities
         Color palette
         Screen size and resolution
         Fonts
         Icons and images

UI standards and guidelines can be referenced from:
http://cantata.co.hennepin.mn.us/prototype/style/resources.htm

Currently no Hennepin County standards specify minimum browser requirements. However, resources are
available and will be used to evaluate usability and browser compatibility against a common set of browsers and
a limited number of browser versions.

Struts Tiles and JavaServer Faces (JSF) will be used as a framework for UI development.

4.2 Base Services

A standard security process and logging service will be used for all J2EE and Message Broker applications
developed by HJIP.

4.2.1 Security

Security for HJIP will follow the approved Hennepin County Security Governance Group’s approach to
messaging security. WS-Security will be endorsed with different levels of implementation necessary based on
the type of data and whether the transactions are limited to internal or external networks. Internal networks are
defined as all networks on fiber or private line to Hennepin County core system (e.g., Hennepin County Core,
LOGIS, and MNCIS).

The 3 security levels will be:

     1. General Public data, Internal or External – No SSL or WS-Security information will be required.

     2. Sensitive Data on Internal or Private Network – SSL and endpoint authentication along with WS-
        Security User tokens will be required. Transactions of this type will be communicated over 128 bit SSL
        connections, and will require strong userid/password authentication for all MQ or HTTPS connections.
        WS-Security will be implemented for these types of transactions but will only require the UserToken for
        any role-based authorization required by the consuming application. Strong password connections will
        not be expected to expire or rotate.

     3. Sensitive Data on External Networks – This will be handled on a case by case scenario by the
        Hennepin County Security Governance Group.


Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                     Page 15 of 41                             Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                                                                                   HJIP Architecture Plan
                                                                                                                                                    Development Standards




4.2.2 Logging

A common logging service will provide a single point of service for processing errors, performing logging
functions, and performing audits. All HJIP and non-HJIP implementations, whether they are services or online
applications, will be able to use the logging service.

The logging process will consist of an asynchronous broker consumer that will accept messages from any
application and provide a common method of handling messages to files, databases, or queues. All exception
handling with escalation levels will follow the same process.

The diagram below shows a logical view of the logging service.

                               Common Logging Service
                                   Logical View                    Load properties
                                                              Related to destinations of
                                                                                                                                               Database Views
                                                             Logging/Auditing/Exceptions
                                                                                                                                                By Application
                                                                   Cached Values
                                                                                                    HJIP Data Source
 Application X
WAS or Alternate                                                                                       SQL Server


                   Async Queue Put

                                                                                            Auditing or Long Term
                                                  MQ Get   WMB
                                                                                           Log/Exception Messages

                                     Logging MQ
                   Async Queue Put



                                                                                                                        Consolidated View of
                                                                                                           File                                       XPOLOGS
                                                                   File based messages                                    Multiple log files
  Application Y                                                                                            Log
                                                                                                           Dynamic                                  Viewer/Monitor
                                                                                                                          Per application
     WMB                                                                                                   File Log




                                                                 Queued Messages
                                                                                                                                                       QPASA
                                                                                                                                                       Viewer

                                                                 Exception Messages                     Dynamic
                                                                         Or                         Queue Destination
                                                                                                                                                                     Support
                                                                     WMB Down                        Per Application                                                  Alerts
                                                                                                                                                                      -------
                                                                                                                                                                     Message
                                                                                                                                                                     Content
                                                                                                                                                                      Based
                                                                                                                                                       QPASA
                                                                                                                                                     Alert Monitor
                                                                                                    Dead Queue
                                                                                               Catch All type messages
                                                                                             Where WMB had problems with                               Support
                                                                                                    Message Flow                                        Alerts




                                                                                                                                                      Operations
                                                                                                                                                        Alert



Figure 4-1. Common Logging Service


The physical design for logging is in the HJIP QuickPlace:

http://www.hennplace.com/QuickPlace/hjip/PageLibrary8625713F006643D8.nsf/h_5FD0A99D1B264CBA8625
713F0067A871/306CE5D3CE17A48E86257154006D0496/?OpenDocument

4.3 J2EE Standards and Conventions

Naming and coding conventions used by J2EE projects will be based on Sun Microsystems recommendations.
The standards address:

                 J2EE application, module, and component names


Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                                         Page 16 of 41                                                              Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                           HJIP Architecture Plan
                                                                                            Development Standards


         EJB component names
         Web component names
         Web service names
         Reference names

The standards are available at:

http://java.sun.com/blueprints/code/namingconventions.html.

http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html#15411

J2EE projects will follow Sun’s code conventions: http://java.sun.com/docs/codeconv/index.html

JSP code conventions:
http://java.sun.com/developer/technicalArticles/javaserverpages/code_convention/

The J2EE project directory reflects the current ClearCase project structure (shown below). The RAD workspace
with J2EE project directories is placed in the CC “src” directory.

         ClearCase
               ClearCase Project Dev View

                      doc
                      model
                            units
                            schemas
                      src
                            sql
                            workspace
                                    dist
                                    build

                                  J2EE project
                                    build.xml
                                  EJB project 1 (one or more)

                                    build.xml
                                  WEB project 1 (one or more)
                                    build.xml
                                  Test
                                            lib
                                    build.xml

              ClearCase Project Integration View




Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                       Page 17 of 41                       Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                            HJIP Architecture Plan
                                                                                             Development Standards


Figure 4-2. RAD Workspace Organization



4.4 Message Broker Standards and Conventions

4.4.1 Naming conventions

Message flow naming conventions are shown below.

         Message flows include a four-letter system prefix when applicable.
         Message flow names should be mixed case




Figure 4-3. Message Broker Message Flow Naming Conventions

4.4.2 Adapter Coding Requirements

If the client application uses MQ Queue Manager, it must be careful about committing units of work so that the
Broker Queue Manager logs don’t fill up.

If the client application uses MQ Client:
 The Application is responsible for handling Application errors and abends.
 The Application is responsible for re-connecting to the Hennepin Broker Queue Manager if it loses its
     connection (because of scheduled or unscheduled outages).
 The Application has close its connection by disconnecting from the Broker Queue Manager before it
     reconnects. Otherwise, we can get orphaned client channel instances that eventually exceed the
     maximum number of channels that can be open at one time. When this happens, no other
     applications can connect to the Broker Queue Manager.




Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                     Page 18 of 41                           Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                           HJIP Architecture Plan
                                                                                                   Data Standards




5 Data Standards

Data architecture, standards, and guidelines describe the policies and practices by which data is managed and
shared in support of business integration activities and functions. It is but one facet of the enterprise
architecture, which helps us understand, coordinate, and evolve complex processes.




Figure 5-1. Enterprise Architecture



5.1 Data Architecture

5.1.1 Data Modeling

Persistent data stores and message data will be modeled logically using entity relationship (ER) modeling
techniques for understanding what data is required and what inherent relationships exist between the data.
Persistent data stores will be physically modeled and documented using detailed ER modeling. However,
message data will be physically modeled using W3C XML Schema specifications. (See XML schema guidelines
for details.) Data models are subject to regular peer review and validation against business requirements.

5.1.2 Data Naming Guidelines

ISO 11179-5 will provide the guidance for the desired data naming standards. (For the Hennepin County
interpretation, see “Data Documentation Guidelines” in the Lotus Notes Technology Information Sharing
database.) (Standard abbreviations: CLSS TSO option = A.6.2. This needs to be improved.)




Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                     Page 19 of 41                          Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                                  HJIP Architecture Plan
                                                                                                          Data Standards




Figure 5-2. Standard Abbreviation Search Using TSO


XML schema elements are named using UpperCamelCase format, and XML attributes are named using
lowerCamelCase format. (See XML schema guidelines for additional design details.)

5.1.3 Data Integrity

Data integrity refers to the validity of data; that is, available data represents what was intended. Data integrity
can be compromised in a number of ways:

         Human data entry errors
         Errors that occur when data is transmitted from one computer to another
         Software bugs or malicious activity, such as viruses
         Hardware malfunctions, such as disk crashes or network failure
         Unexpected disasters, such as fires and floods

We attempt to minimize these threats to data integrity in several ways:

         Backing up data regularly: infrastructure support for database backup, disaster recovery, etc.
         Controlling access to data via security mechanisms: user authentication
         Using error detection and correction software when transmitting data messages.
         Designing application interfaces that prevent the input or transformation of invalid data: encoded value
          domains, enforced referential integrity constraints, semantic data maps, etc.

Each database application requires a decision about implementing database enforced integrity constraints. A
Universal Table System (UTS) is one option for managing reference data. If a coded data element is only
associated with a description and little else and is a stable value set, then it is a good candidate for UTS.
Integrity is maintained by the application code. On entry, these values are selected from a list from the UTS
table. If entry is via batch processes, the values are verified against the UTS table. The assumption is that
data is only entered through tested application code; no other points of entry are allowed. This has been
a common and accepted practice at Hennepin County for several years and can greatly simplify database
design and the application code needed for entry and maintenance of reference data.

Message maps are a tool used to validate semantic equivalence between data from disparate information
systems. In addition, asymmetric domain value sets must be mapped based on business-defined rules that are
not always apparent as in the example below.




Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                     Page 20 of 41                                 Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                                  HJIP Architecture Plan
                                                                                                          Data Standards




Figure 5-3. Mapping from MNCIS Status to SWATS Status


A combination of validating message schemas and application edits must be implemented before updating an
application database. Message data quality will be enforced with the following policies and practices.

The published message schema defines the data element, syntax, semantics, and structure that can be
included in a HJIP message and is an important component of the integration service level agreement.
Messages that are not “schema valid,” that is, they do not conform to the expected schema version (see the
schema versioning approach in section 5.2.6, XML Schema Versioning), should be rejected and returned to
sender with discrepancies noted.

In addition to sending schema valid messages, source data systems are responsible for the integrity of
inherently varying data such as Name or Text type data (for example, SubjectName). This kind of data will be
passed “as-is” through any middleware to the intended consuming applications, including any errors such as
misspellings or character transposition. This is a business risk that all HJIP agencies must accept and manage
outside of the integration architecture.

The message broker processes have the responsibility of implementing consistent transformation of data when
required. Data transformations within the broker will be limited to relatively static data translations. For example,
gender code value “1” from one system is translated to NCIC code value “M” in another system. These
translations will be specified in a mapping document, which also becomes a component of the integration
service level agreement.

Transformations may also be performed in an application messaging interface. The decision of where
transforms are performed needs be determined for each integration project.

All message consuming applications have the responsibility for implementing data integrity edits similar to any
other interface. Agencies should assume that the data quality of received electronic messages will be no better
than what a monkey can enter with a GUI. Messages that fail an edit should be returned to the sender with the
errors noted.

5.2 Integration XML Schema Architecture

5.2.1 Overall Schema Approach for HJIP

XML messages are designed and documented using the W3C XML Schema specification. Standardizing on
commonly understood schema components maximizes the opportunities for reuse and improves the rate of
integration message development. Managing the complexity of schema components is accomplished with three
kinds of schemas: message, internal architectural, external architectural.




Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                        Page 21 of 41                             Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                            HJIP Architecture Plan
                                                                                                    Data Standards


5.2.1.1 Message Schema

A message schema documents a functional message exchange service by assembling element and content
type schema modules previously defined using import or include (for example, BookingDocument, Citation, or
Complaint). Each message schema represents an implied agreement about what data can be transmitted in the
message. As such, message schema validation is important during the testing phase; however, for performance
reasons it may be turned off during production implementation. Isolating functionally related message schemas
(that is, services) to a single file may help minimize complexity but reduce flexibility.

5.2.1.2 Internal Architectural Schema

An internal architectural schema defines local business domain exchange XML schema components or extends
and constrains imported external XML schema components. Only data that can potentially be exchanged is
defined here. These schemas can either define relatively small modular components or be broader in scope.
This offers flexibility for frequent evolutionary development modifications without necessarily impacting
associated schema modules.

5.2.1.3 External Architectural Schema

An external reference schema is a schema owned, defined, and managed by an organization external to
Hennepin County, for example, National Information Exchange Model (NIEM), Global Justice XML Data Model
(GJXDM), or MNJustice. These schemas are generally imported into either an internal reference vocabulary
schema or directly into a message schema.

5.2.2 XML Schema Target Namespace Strategy

5.2.2.1 Guidance

Hennepin County integration will implement XML namespaces for specifying XML element uniqueness and
ownership. Each locally defined schema will have a target namespace that assigns uniqueness and ownership
to any element locally defined.

5.2.2.2 Explanation

An XML namespace is a collection of data names or data vocabulary identified by a universal resource identifier
(URI). The primary purpose of a namespace is to facilitate the most concise name for each element or attribute
within the context of a business domain. This minimizes the chances for name collisions resulting from the
same tag name being used to represent different contextual semantics (for example, Sheriff: RaceCode vs.
Court: RaceCode) as XML messages are being exchanged by various agencies.

A secondary purpose of an XML namespace is to identify the owners of a particular XML tag name. Ownership
comes with the responsibility for maintaining and publishing clear definitions for each component within the
namespace.

A namespace can also be used to version an XML schema vocabulary, usually by embedding a version
number in the namespace name. In the process of exchanging XML messages, version control can be enforced
by various namespace aware processing tools. Hennepin County integration will use a slightly different version
strategy as explained in section 5.2.6, XML Schema Versioning.




Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                     Page 22 of 41                           Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                               HJIP Architecture Plan
                                                                                                       Data Standards


5.2.3 Target Namespace Implementation

5.2.3.1 Guidance

In the interest of acknowledging and respecting political and jurisdictional autonomy, Hennepin County agencies
may choose to own and maintain a local namespace under the Hennepin County URL (for example,
“http://www.co.hennepin.mn.us/Sheriff”).

5.2.3.2 Explanation

One option is to have a centrally maintained default vocabulary target namespace
“http://www.co.hennepin.mn.us/Justice” for all new locally defined global data exchange elements. The fact that
data is being exchanged implies that a common semantic meaning must be understood and could therefore be
defined in one namespace. This option promotes and supports the notion of a harmonized or uniform
messaging data model that is built up by composition and extended as message data is defined. Namespace
schema ownership and version control is centrally managed and published. Duplication of content type design
is minimized, and chances for component reuse are maximized. The complexity of data transformation tends to
be dispersed to the local application interface. The disadvantage is the potential creation of an integration
process bottleneck, which would be unacceptable.

A second option is to define multiple agency vocabulary target namespaces, such as
“http://www.co.hennepin.mn.us/Sheriff.” Agencies define global elements and content types according to their
own needs using business familiar names. Agencies have the flexibility and ownership of defining, maintaining,
and publishing their information exchange vocabulary (for example, CourtXML for MNCIS). This option tends to
encourage the complexity of transforming data between agency vocabularies to become a more centralized
function. A disadvantage with this option is less information component re-use, likely duplication, and more time
spent on clarifying data semantics and transformations.

A third option is to employ a mix of both approaches and accommodate the various needs and comfort levels of
information exchange agencies on the basis of an integration service level agreement. The flexibility of this
strategy will help level out work loads and expedite integrations. An integration architecture decision tree along
with data exchange standards can help with the decision making process and offer a benchmark for peer
design reviews. A free market of reusable Hennepin County XML schema components will determine how this
evolves.

5.2.4 Namespace Names

5.2.4.1 Guidance

Use a target namespace name consistently to identify ownership and create unique XML tag names.

5.2.4.2 Explanation

Below are examples of potential Hennepin County XML namespace names and tag prefix recommended for
use with justice agencies. A URL is used because it can easily assure uniqueness for the enterprise, is widely
recognized, and could potentially be used to physically locate files if needed. However, currently files cannot
actually be published at the location.

Prefix                  Unique Namespace Name                               Owner
Hcit      “http://www.co.hennepin.mn.us/Common”                    HC Integration Team
Hcc       “http://www.co.hennepin.mn.us/Corrections”               Community Corrections
Hca       “http://www.co.hennepin.mn.us/CountyAttorney”            County Attorney


Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                          Page 23 of 41                        Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                             HJIP Architecture Plan
                                                                                                     Data Standards


Prefix                  Unique Namespace Name                                Owner
Hcs       “http://www.co.hennepin.mn.us/Sheriff”                   County Sheriff
Hcpd      “http://www.co.hennepin.mn.us/PublicDefender”            Public Defender
Lle       “http://www.co.hennepin.mn.us/LocalLawEnforcement”       ?
Hccrt     “http://www.co.hennepin.mn.us/Court”                     District Court
Hcj       “http://www.co.hennepin.mn.us/Justice”                   HC Integration Team
Table 5-4. Hennepin County Domain Name/Agency or Functional Grouping Name


5.2.5 Conformance to External Reference Models

5.2.5.1 Guidance

Where the semantic fit is good, reuse! Message schema should be designed to reuse as much as possible
preexisting schema components defined by external industry groups, such as the National Information
Exchange Model (NIEM) or the Global Justice XML Data Model (GJXDM).

5.2.5.2 Explanation

The degree to which component reuse conforms to the expectations of an external model can vary depending
on the completeness of the model, understanding and capability to implement, and the modeler’s willingness or
availability to expend the required effort. Conformance to a data dictionary definition is a bare minimum.
Consistency with model substructures is a step up in the conformance hierarchy. In some circumstances,
conforming via schema validation may be possible.

5.2.6 XML Schema Versioning

5.2.6.1 Guidance

The schema file will be the unit that is versioned using a major and minor version number in the schema version
attribute (for example, version=“1.0”). Schema version numbers should also be recorded in the schema file
name (for example, CitationDocument-v1-0.xsd). This will minimize the chance that an XML message
document will not being processed just because a different schema file version number is required. The schema
location attribute file path will help identify the appropriate schema version number for debugging (for example,
xsi:schemaLocation=http://www2.co.hennepin.mn.us/schema/justice/citation/1-0/CitationDocument-v1-0.xsd).

5.2.6.2 Explanation

Hennepin County integration requirements call for message versioning that allows for disparate evolution of
XML component changes with minimal chances of “breaking” existing implementations. The desire is strong to
minimize the number of modifications required to implement newer component versions. (Are any business
risks associated with this assumption?)

Two primary mechanisms are used in practice to differentiate versions in an XML instance document. One
method is to use a version attribute on the root element, while the other method is to use the namespace name
of the elements as the versioning mechanism.

Versioning based on namespaces is very popular for reference vocabularies. The primary problem with
versioning XML instances using the namespace name in subsequent versions is that it means XML
namespace-aware applications that process the documents will no longer work with the documents and will
have to be upgraded. This is primarily beneficial with document formats whose versions change infrequently as


Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                          Page 24 of 41                       Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                                HJIP Architecture Plan
                                                                                                        Data Standards


in changing the semantics of elements and attributes, thus requiring that all processors no longer work with the
newer versions for fear of misinterpreting them. Also, managing the complexity of multiple schemas evolving
under any one namespace version is very difficult.

On the other hand, an XML document versioning mechanism based on a version attribute on the root element is
sufficient in a number of scenarios. A version attribute is primarily beneficial when changes in the document's
structure are backward compatible. The following situations are appropriate for using a version attribute:

         Semantics of elements and attributes will not be altered.
         Changes to the document involve the addition, but rarely the removal, of elements and attributes.
         Interoperability between applications with various versions of the processing software is desirable.

So, to a namespace-aware processor, if the namespace URI is changed from
“http://www.co.hennepin.mn.us/Sheriff/1.0” to “http://www.co.hennepin.mn.us/Sheriff/1.1,” the name of every
construct in the language is changed. A more stable namespace name, such as
“http://www.co.hennepin.mn.us/Sheriff,” will help minimize the changes required for XML message processing
tools in a rapidly evolving exchange environment.

The version number includes a major and minor component. Major releases that break prior releases are
represented at the integer level (for example, 1.0, 2.0). When you see the integer increment, you know that an
existing application with a different major release number may break. The major version number component
represents a backward incompatible change. This is a change that most likely will cause some processing
algorithm to not function as expected. These kinds of changes need to be carefully planned and communicated
with exchange partners.

Examples of a major XML vocabulary change include:

         Change the essential semantic business meaning of an existing element tag name.
         Change an existing type structure (for example, rearrange sequence)
         Delete an existing element or type.

Minor single point releases will not break applications based on previous releases within the major release.
Typically, these changes will be extensions or additions to subject matter. This includes changes to enumerated
simple types, which do not invalidate the structure of XML documents but do provide different domain
constraints on the expected values. The minor version number component represents a backward compatible
change. This is a change in the XML vocabulary that an application should be able to process as before, and
the message may or may not have the most current component features. Minor versions are indicated with a
decimal change in the version attribute (for example, from 1.1 to 1.2).

Examples of a minor XML vocabulary change include:

         Extension of a type definition
         Addition of a new element or type
         Addition of value enumerations

5.2.7 XML Message Packaging

5.2.7.1 Guidance

XML messages must be in the form of a Simple Object Access Protocol (SOAP) message. This provides a
commonly understood protocol that is platform independent. Previously built integrations may have been built
without using SOAP. Whether they should continue in this format or be modified should be considered on a
case by case basis.



Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                     Page 25 of 41                              Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                              HJIP Architecture Plan
                                                                                                      Data Standards


Explanation

A SOAP message is an ordinary XML document containing the following elements:

         A required Envelope element that identifies the XML document as a SOAP message
         An optional Header element that contains header information
         A required Body element that contains call and response information
         An optional Fault element that provides information about errors that occurred while processing the
          message

All the elements above are declared in the default namespace for the SOAP envelope:
http://www.w3.org/2001/12/soap-envelope

The default namespace for SOAP encoding and data types is:
http://www.w3.org/2001/12/soap-encoding

A SOAP message must always have an Envelope element associated with the
“http://www.w3.org/2001/12/soap-envelope” namespace.

If a different namespace is used, the application must generate an error and discard the message.




Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                     Page 26 of 41                             Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                              HJIP Architecture Plan
                                                                                                      Data Standards


Below is a SOAP message example outline.



          <?xml version="1.0"?>
          <soap:Envelope
          xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
          soap:encodingStyle="http://www.w3.org/2001/12/soap-
          encoding">
          <soap:Header>
            ...
            ...
          </soap:Header>
          <soap:Body>
            ...
            ...
            <soap:Fault>
              ...
              ...
            </soap:Fault>
          </soap:Body>
          </soap:Envelope>

Figure 5-5. SOAP Message Example Outline


The optional SOAP Header element contains application-specific information (authentication, trace logs, etc)
relevant to the SOAP message. If the Header element is present, it must be the first child element of the
Envelope element. All immediate child elements of the Header element must be namespace-qualified.

5.2.7.2 Interoperability and Vulnerability Testing

As a part of each development effort, HJIP will run all messages through tools to provide interoperability and
vulnerability testing. The Hennepin County Security and Internal Audit groups will be involved with all HJIP
projects to review and ensure a consistent and approved implementation of data security.

Definitions

Vulnerability: No software can be absolutely protected from malicious activity. Web services are no different.
Within the HJIP development and testing process, the HJIP team members will run all services through
vulnerability testing tools to expose any known weaknesses that may exist. In addition, within each logical
review, the Internal Audit and Security groups will be engaged to review the data protection needs. If
deficiencies are identified, these issues will be addressed through code revision or acknowledgement of risk by
signoff of agency management. The Hennepin County Security group will handle this on a project-by-project
basis.

Interoperability: Although web services are based on standard protocols, vendor implementations are slightly
different. HJIP will ensure that schemas defined within the HJIP program have no interoperability or compatibility
issues between vendor implementations.




Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                     Page 27 of 41                             Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                                                                                                                                                                                                                                       HJIP Architecture Plan
                                                                                                                                                                                                                                                                                                    HJIP Reference Architecture




6 HJIP Reference Architecture

The HJIP reference architecture outlines the standard implementation for the HJIP project.

6.1 HJIP Reference Architecture Diagram


                                                                                                                                        HJIP Reference Architecture
                                                                                                                                                                                                                                                                                                                          Informational
                               Client Zone                                          Presentation                                                                                                        Business Objects                    Business Service
                                                                                                                                                                                                                                                                                                                              Zone
                                                                                       Zone
                                                                                                                                                                                               2                             3                                                                        4
                                             1
                                                 County Agency Customers




                                                                                                                                             [J2EE – Spring/Struts/Hibernate/EJB]




                                                                                                                                                                                                                                     JMS/LegalEdge/MNCIS/CORRIS/Little Rock
                                                                                                                                                                                                                                                                                                                  zLDAP??
                                                                                                                        IBM Webshpere




                                                                                    HTTP




                                                                                                                                                                                                                                                Partner Integration
                                                                                   Messages
                                                                                              IBM HTTP



                                                                                                                                                                                                   Security




                                                                                                                                                                                                                                                                                         Auditing
                                                                                                                                                                                                                                                                               Logging
                                                                                            Web Listeners
                                                                                               Software
                                                                                            Load balanced
                                                                                                                                                                                                                                                                                                               Active Directory


                                                                                          Guaranteed
                                                                                          Messages

                                                                                                    HTTP
                                                                                                   Messages
                                                                                                                                                                                                                                                                                                                FTP Servers
 Non-County Agency Customers




                                                                                     JMS                                                                                                                                         SFTP/SCPY
                                                                                   Messages
                                                                                                                                                                                                                     JDBC
                                                                                                                                        XSLT/Java Transformations]
                                                                                                                 IBM Message Broker

                                                                                                                                           [ESQL & JAVA J2SE




                                                                                                                                                                                                                            ODBC
                                                                                                                                                                                                   J2SE Components




                                                                                                                                                                                                                                                                                                                 SQL Server
                                                                                                                                                                                                        E-SQL
                                                                                                                                                                                                        XSLT




                                                                                                                                                                                     ODBC                                                                                                                         Database
                                                                                                                                                                                    Adapters


                                                                                           MQ Series
                                                                                                                                                                                                                            ODBC

                                                                                                   File Pickup
                                                                                                                                                                                                                                                                                                                DB2 – UDB 8.2
                                                                                                                                                                                                                                                                              Monitori
                                                                                                                                                                                                                                                                              QPASA




                                                                                                                                                                                               2                             3                                                                        4       Broker Support Only
                                                                                                                                                                                                                                                                                ng




                                             1
                                                                           FTP Servers


Figure 6-1. HJIP Reference Architecture (Detail)



6.2 HJIP Integration Styles

The majority of the project work will comprise middleware services and EAI integration between MNCIS, several
agencies, and within the Hennepin County agencies. The reference architecture depicts the recommended
implementation solutions to address the various common types of messaging and integration efforts.

We will be using four primary integration styles to facilitate message integration.

                                 1.      Asynchronous Request/Response via messaging
                                 2.      Point-to-Point Web Services exposed through SOAP
                                 3.      Asynchronous Fire and Forget
                                 4.      Publish/Subscribe




Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                                                                                                                                                     Page 28 of 41                                                                                                        Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                             HJIP Architecture Plan
                                                                                          HJIP Reference Architecture


For all styles, a service provider and at least one consumer are required to complete the exchange of
information.

6.2.1 Asynchronous Request/Response

6.2.1.1 Definition

Request/response integration process is sometimes described as a point-to-point messaging. In this case, a
client initiates a request and waits for an acknowledgement that the transaction is complete. Many times this
type of transaction is used when you need to have an acknowledgement that an action has properly completed
(for example, receiving a confirmation number for a financial deposit). This approach is similar to synchronous
web services; however, it has the following advantages and disadvantages:

Advantages
    Guarantees that all requests are processed, regardless of the back-end services being down or
       unavailable.
    Supports a large volume of requests with predictive application performance. As the load increases,
       requests are queued on message-oriented middleware (MOM) technology. Messaging software, such
       as IBM MQSeries, protects the responding service from receiving more simultaneous requests than the
       maximum number that it can handle.
    Implements security. Although MQSeries can be implemented anywhere, it is typically a service that is
       provided within the core or protected area of a corporate infrastructure or communicated across private
       lines. Many times MOM services are not left open to the public for open communication. You need to
       know specific connection information to use a messaging product. This alone doesn’t make it secure,
       but you have a better start than with web services, especially if web services are exposed to the
       Internet.

Disadvantages
     Requesting application may time out. Because the application will never handle more load than it has
       established as the maximum performance volume, requests may wait on queues without any
       guarantee about when they will be processed. If the queue has a large volume of waiting requests,
       then the time to process the request may exceed the amount of time the client is willing to wait for a
       response. The calling application may time out and quit waiting for the response. Because the request
       and response are asynchronous, the service provider has no knowledge of the requesting application
       disconnecting. Therefore, unless both the requester and provider time outs are synchronized, the
       server will continue to process the request to completion without any application knowledge that the
       request ever completed. This can cause confusion of committed work, if the consuming application
       never got a response of successfully completed.
     Responding application may time out. Even if the volume is not great at any one time, the responding
       application may still time out waiting for another dependent service that it calls.
     Transactional coordination of back-end services may be difficult. Coordinating the commit and rollback
       of services that provide update services to back-end services is difficult.
     Message length limitations. Most messaging products, such as MQSeries, are limited to a fixed length
       for message transport. If you anticipate messages that might exceed the maximum string or object
       definition, then the service will need to appropriately limit the data on the message transport.

The diagram below illustrates the Asynchronous request/response integration style.




Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                     Page 29 of 41                           Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                                               HJIP Architecture Plan
                                                                                                            HJIP Reference Architecture




                                                                      Reads request with
                                                 Request             assigned correlated id

                Consumer Request,
  Start                                                                                Service Provider
                Wait for Response
                                                                    Puts response
                                       Response                     On queue with
                                                                  Same correlated ID




Figure 6-2. Asynchronous Request/Response Integration Style


The diagram below illustrates the asynchronous request/response integration style with an orchestration of two
back-end services to fulfill the service request.



                                                                                Request



                                                                                                            Service Provider



                                                                                              Response
                                   Request


             Consumer Request,
  Start                                                     HC Broker
             Wait for Response

                                                                                              Request
                                             Response
                                                                                                          Service Provider



                                                                                 Response




Figure 6-3. Asynchronous Request/Response Integration Style with Orchestration

6.2.1.2 When to Use Asynchronous Request/Response

         The message needs to be guaranteed delivery, even if no response is ever given back to the
          consumer.
         The service is read-only.
         Consumer applications may have unexpected peaks of volume.
         Consumer applications are messaging based or are known to have programming language barriers.




Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                           Page 30 of 41                                        Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                               HJIP Architecture Plan
                                                                                            HJIP Reference Architecture


6.2.2 Point-to-Point Web Services Exposed Through SOAP

6.2.2.1 Definition

Web services are similar to the point-to-point messaging exchange except for the following:

         The transport of the messages communicates over HTTP or HTTPS, which is the web standard for
          web services transport. HTTP is a communication standard approved by the W3C (http://www.w3.org),
          which extends TCP/IP communication.
         Web services are synchronous instead of asynchronous. This means that once a consumer application
          makes a service request, the consumer will hold a connection directly with the service provider until it
          either gets a response from the service provider or the transaction times out.
         Web services are not guaranteed. Transactions that need guaranteed delivery should not be
          implemented as web services.

Although it is not required, the standard protocol of SOAP, defined through WSDL, is the most common
implementation of web services.

Simple Object Access Protocol (SOAP) definition: SOAP is the standard for web services messages. Based
on XML, SOAP defines an envelope format and various rules for describing its contents. Along with WSDL and
UDDI, SOAP is one of the three foundation standards of web services. SOAP is the preferred protocol for
exchanging web services, but by no means is it the only one (REST is another).

Advantages
    Web services have been around for quite a while and are very simple to implement. The only
       requirement is a web server that listens for requests. Today numerous development tools and tool kits
       are focused on the rapid development, testing, and deployment of web services.
    Since the consumer makes a request directly to the service provider, the action response is
       immediately executed (compared to MOM asynchronous processing, where the request may be
       queued to process at a later time).

Disadvantages
     When the consuming application makes a request for web services, it establishes a direct connection
       with the service provider. Rather than being processed off a request queue, that request is immediately
       processed by the service provider. As the load increases, the performance of the service may degrade.
       This degradation could lead to requests that time out or even become completely unavailable.

The diagram below illustrates how the delivery of a request/response for web services is completed. For
simplicity, this diagram does not show the additional steps required for the handshake establishing a secure
HTTPS connection.


                                                     Request
                Consumer Request,
  Start                                                                  Service Provider
                Wait for Response
                                                     Response



Figure 6-4. Point-to-Point Web Services



6.2.2.2 When to Use

         Synchronous requests for information.



Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                        Page 31 of 41                          Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                              HJIP Architecture Plan
                                                                                           HJIP Reference Architecture


         Read-only service requests, where assurance of information delivery is not absolutely required. If a
          request times out or does not succeed, the requesting application will be able to deal with the
          appropriate message or re-attempt the call. Two examples of this are a stock quote request and a bank
          balance request.

6.2.3 Asynchronous Fire and Forget

6.2.3.1 Definition

Asynchronous fire and forget transactions are from consumer applications that make a request to a service
provider to execute a guaranteed action. Although the service provider does ensure that the event will occur, it
does not guarantee the timing of the event or the result of the event. The service provider decides if the
transaction will be done immediately upon receiving the request or at a later time. Since the consuming
application does not wait for any response, an alternate mechanism is required to notify the consumer if an error
occurs. Possible mechanisms include a publish/subscribe notification, a web service, an e-mail, an SNMP alert,
a workflow task, or even a manual report. The consuming application is then responsible for retrieving the
notification from the service provider.

Advantages
    Extremely efficient mechanism for requesting that another service performs an action on your behalf
       without slowing down your process waiting to make sure it completes the task.
    Appropriate when you need to queue events to happen when an external event occurs, such as a
       specific time of the day or the completion of an orchestration action (for example, approval of a work
       request by a supervisor manager).

Disadvantages
     Not workable when the requesting application needs an immediate response that the requesting action
       has been completed as either successful or failed. Since these types of transactions come with no
       guarantee that they will be even processed immediately, they should be avoided for these types of
       uses.
     Not workable when the result of the service provider action is needed by the consuming application.
       Although consumers can be designed to subscribe to notifications, this will be an additional task by the
       consumer.




Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                     Page 32 of 41                            Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                                   HJIP Architecture Plan
                                                                                                HJIP Reference Architecture


The diagram below illustrates the delivery of the fire and forget request.



                                                                        Request



                                                                                                Service Provider


                     Consumer Sends Request with
                                                                                   Response
                          no reply expected

              Consumer makes                           HC Broker
  Start          Request. No             Request
                                                     Service Provider
              response is given
                                                                                   Request

                                                                                              Service Provider



                                                                        Response



Figure 6-5. Fire and Forget Request



6.2.3.2 When to Use

         Loosely coupled activity that is not time-dependent on the actual work being completed.
         Transactions that do not need immediate acknowledgement that an action has been completed.
         Business process orchestration activities where workflow or human involvement is required.
         Appropriate examples include logging, auditing, exceptions, task approval, or batched requests.

6.2.4 Publish/Subscribe

6.2.4.1 Definition

Publish/subscribe refers to topic-based messaging, which is more efficient and loosely coupled than point-to-
point messaging. With publish/subscribe, the service provider is responsible for putting, or publishing, a single
message on a topic for anyone who is listening or subscribing. Any consumer that has previously subscribed to
that message will be notified and delivered the message that is available. The service provider does not need to
keep track of who is subscribing to a specific message. Managing the messages is handled by the MOM. This
transfers the ownership of the message to the MOM and away from the broker or application. Because
consumers are managed in this type of transaction, often the service provider never knows who is subscribing
to the service, and so, in many cases, the service is implemented with anonymous access. A good example of
this is a news service that notifies subscribers headline news events occur.

Advantages
    Extremely efficient and loosely coupled implementation of messaging that can support point-to-point
       transactions, as well as long-running business process orchestration transactions.
    Managing who needs to receive the message is abstracted from the publishing application.

Disadvantages



Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                     Page 33 of 41                                  Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                                  HJIP Architecture Plan
                                                                                               HJIP Reference Architecture


         Security is not tightly coupled to the implementation of this type of service. The application typically has
          no knowledge of who is subscribing to the service. Therefore, the information that is transmitted in the
          message should be public information.

The diagram below shows a generic illustration of how the Broker publish/subscribe engine may be used. A
technical evaluation should be completed to determine the appropriate solution(s) for Dynamic Routing.



                                                                                                     Subscribing App




                                                                                                     Subscribing App
                                                HC Broker                  Pub
  Start           Business Event
                                              Service Provider            Message


                                                                                                     Non-Subscribing
                                                                                                          App



                                                                                                     Subscribing App

Figure 6-6. Publish/Subscribe



6.2.4.2 When to Use

         When an event within your (publishing) system should be known by other receiving systems. The
          publishing system doesn’t need to know about the receiving systems.
         When you need to trigger an event between loosely coupled systems.

6.2.5 Governance

Currently the county has not established an SOA governance team to manage what SOA services are made
available and to whom they are made available. Today, this is accomplished on a project-by-project basis and
will be reviewed by the HJIP team only. Governance at the enterprise level within the county is not believed to
exist at this point and is not within scope of the HJIP program.




Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                          Page 34 of 41                            Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                                              HJIP Architecture Plan
                                                                                                                    System Topology




7 System Topology

The system topology outlines the configuration and deployment of the hardware for the project. The diagram
below depicts the production environment only. In addition to the production build-out, the current environment
will be enhanced to include a full development cycle environment for support of all HJIP projects.

Development integration environment: Partial production environment used primarily as the sandbox
environment for validating development builds and testing server configuration changes. This is the only
environment that is fully accessible by the developers to make server configuration changes and deployment of
code. The code is only deployed to the development environment after it has been fully unit tested within each
developer’s local configuration.

QA environment: Partial production environment used for functional testing by the QA group. QA will execute
the test plans as defined within Test Manager.

UAT environment: This will be a full environment that will be set up as an exact copy of the production
environment. It will be used for user end-to-end testing. It will also be used to accommodate any required
performance testing. Since this environment is a mirror of production, it will be used to do predict performance of
the production environment.

ET (external testing) environment: This environment is dedicated to the agency for integration testing. The
code hosted in this environment will not be changed as frequently as other environments. During the conception
phases of the project, this may have “stubs” hosted, so other agencies can start on their development before
any working code has been being completed. In the final stages and post implementation, this environment will
contain only code that has been fully tested and accepted by the QA group and users, and it will mimic the
production code.

Production environment: This is the production environment that will contain production data and used by all
end users.

The primary difference between the partial and full environments is the redundancy, or failover, of hardware or
services at each logical level.

                                        Partial Environments              Full (Production/UAT Environments) **
Server                        Single application server                   Redundant application servers
Queue                         Single queue or queue broker                Redundant remote clusters for all queues
Load balancers                None                                        Cisco load balancers
Clustering                    None                                        Memory clustering at application server
Database                      Single SQL database                         Upgraded database, but still single
                                                                          physical machine
** Assuming 99% uptime and not full disaster-recovery environment
Table 7-1. System Topology



7.1 System Context Diagram

<Updated diagram will be provided by Operations as part of the infrastructure build out cost bid – TBD
(4/20/06)>




Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                          Page 35 of 41                                    Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                                                                                                                                                                                                             HJIP Architecture Plan
                                                                                                                                                                                                                                                                                   System Topology


                                                                                                                         HJIP PROD Environment
                                                                                                                                Proposed                                                                                                                                   Items not known:
                                                                                                                                                                                                                                                                           1) Content switch location
         Internet                                            Internal Core
                                                                                                                                                                                                                                                                           2) Router switches that are used
                                                                                                                                                                                                                                                                           3) Scheduling tools available
                                                                                                                                                                                                                                                                           4) FTP servers/services available




                                                                                                                                                                                                                                 (HAWK – MF zSeries)
                                                                             SSL Certificate with SSL Acceleration




                                                                                                                                                                                                                                  ( Apps: Chorus only )
                                                                                                                                                                                                                                                                           5) Ability for LDAP to contain alternate




                                                                                                                                                                                                                                    DB2 – Version 7.1
                                                                              Software Load Balancing Enabled
                                                                              IBM HTTP Web Server Version 6




                                                                                                                                                                                                                                     4 Physical CPU
                                                                                                                                         IBM HTTP Web Server Version 6
                                                                                                                                         (Calhoun – SuSE zLinux LPAR)
                                    1                                                                                                                                                                                                                                      schemas other than RACF
                                                                                                                                                                                         DB2 Client




                                                                                                                                               IBM Webshpere 6
                                                                                        (DMZ WWW16)



                                                                                        4 Physical CPU
                                                                                                                                                                                      JDBC Type 2 Driver




                                                                                                                                                4 Physical CPU
                                                                                                                                                                                                                                                                           Issues:
                                                                                                                     Non SSL                                                                                                                                               1) No isolation of of DB environment
                                                                                                                     Reverse                                                                                                                                               between all non-prod.
Monitoring Needs                                                                                                      Proxy                                                                                                                                                2) Version of SQL Server on 2000
                                                                                                                                                                                                                                                                           instead of 2005

                                        Internal Customers
 to be done at all                                                                                                                                                                                                                                                         3) Version of DB2 does not support
hardware level and                                                                                                                                                                                                                                                         type 4 drivers
                                                                                                                                                                                                                                                                           4) WAS is on Lunix partitions that do
custom scripts for                                               HTTPS                                                                                                                                                                                                     have maintenance windows of 2
  application up-                                               Messages                                                                                                                                                                                                   hours per month.. If 24X7 we will
                                                                                                                                                                                                                                                                           need to spread WAS across
monitoring of HTTP                                                                                                   Memory




                                                                                                                                                                                                                               LDAP – Version and Vendor Unknown
                                                                                                                                                                                                                                                                           distributed platform to achieve up-time




                                                                                                                                                                                                                                **Can only support RACF accounts
                                                                                                                     Clustered
and MQ Requests.                                                                                                                                                                                                                                                           SLA




                                                                                                                                                                                                                                    Tivoli Workflow Scheduler
                                                                                                                                        IBM HTTP Web Server Version 6
                                                                                                                                         (Phalen – SuSE zLinux LPAR)




                                                                                                                                                                                                                                          4 Physical CPU
                                                                                                                                                                                                                                           (MF zSeries)
                                                                                                                                               IBM Webshpere 6
                                                                                                                                                4 Physical CPU
                                                                                 Non SSL
                                                                                 Reverse
                                                                                  Proxy
                                                                                                                                                                                                     JDBC Type 4




                                                                                                                                                                              (Other Apps on Box MQ WorkFlow)
                                                                                                                                                                               DB2 Version 8.1 for Broker Only
                                                                                                                                                                                IBM Message Broker Version 6
                                                                                                                                                                                   (CHOMATIC – W 2003)
                                                                                                                                                                                                                                                                                          Requires all Apps




                                                                                                                                                                                     MQ Series Version 6
                                                                                                                                                                                                                                                                                          to to go SQL
                                                                                                                      HTTP                                                                                                                                                                2005




                                                                                                                                                                                           1 CPU
               External Customers




                                                                                                                                                                                                                          ( Apps – all except Chorus and JMS)
                                                                                                                                                                                                                               (Unison – Window 2003)

                                                                                                                                                                                                                                 4 CPU ( 3 SQL/1 OS)
                                                                                                                                                                                                                                 MS SQL Server 2005
                                                                                                                                                                                                                   ODBC                                            Fail Safe




                                                                                                                                                                                                                                                                                   ( Apps – all except Chorus and JMS)
                                                                                                                                                                                                                                    (SQL Dedicated)
                                                                                                                               (Other Apps on Box MQ WorkFlow)



                                                                                                                                                                                                                                                                   Mirroring
                                                                                                                                DB2 Version 8.1 for Broker Only
                                                                                                                                 IBM Message Broker Version 6




                                                                                                                                                                                                                                                                                        (Concert – Window 2003)
                                                                                                                                                                                                                                                                    Witness




                                                                                                                                                                                                                                                                                          4 CPU ( 3 SQL/1 OS)
                                                                                                                                                                                                                                                                                          MS SQL Server 2005
                                                                                                                                      MQ Series Version 6
                                                                                                                                       (CODA – W2003)




                                                                                                                                                                                                                                                                                             (SQL Dedicated)
                                                                                                                                                                                                                                                                     Slave
                                                                                                                                                                                                                                                                   Automatic
                                                                                                                                            1 CPU




                                                                                              MQ                                                                                                                                                                    Failover
                                                                                             Cluster

                                                                                                                                                                                                         ODBC




                                    1



Figure 7-2. HJIP Production - System Context Diagram (proposed)

7.1.1 Hardware/Operating System

                       The mainframe z/Linux will host all WebSphere Application servers (WAS) and the IBM HTTP web
                        servers. Each instance of an environment and logical tier will be partitioned through z/Linux lpars.
                       Windows 2003 with multiple CPUs will be used for all windows application hosting. Each server
                        supports more than one environment through Windows Virtual Hosting. These servers will be primarily
                        used for the hosting of the MQBroker and database software.
                       The BI environment will be used for all reporting needs. This is a shared environment, which is not part
                        of the HJIP deployment environment and is not represented within the diagram above. Since this is a
                        shared environment, the BI team will take complete responsibility for updating and deploying this
                        environment.
                       Cisco routers will be used for load balancing of all redundant listeners, such as IBM HTTP web servers.
                       Local development environment will use Windows XP and locally installed development tools.

7.1.2 Server Software

                       WebSphere Application Server (WAS): WAS will be the preferred J2EE container for hosted J2EE
                        applications that have user interfaces or for any J2EE back-end services.
                       WebSphere Message Broker: This will be the preferred application development for all ESB
                        functionality needed for the HJIP program. Hosting of web services, JMS services, and routing and
                        orchestration of back-end services will be primarily developed within the WMB application.
                       MQSoftware Q Pasa – Q Pasa will be used throughout the HJIP program for the viewing, monitoring
                        and alerting of applications. Maintenance of the messages within the queues will be performed by MQ
                        as well as by the HJIP applications.
                       IBM WebSphere MQ: MQ will be the preferred message-oriented middleware (MOM) for transporting
                        JMS messages. For the production release of HJIP, we expect that that all MQ instances will leverage
                        remote clustered queuing for failover capability.


Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                                                                                                                                    Page 36 of 41                                                                                        Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                                    HJIP Architecture Plan
                                                                                                          System Topology


         IBM HTTP Web Server: This has been defined as the preferred solution for all web listening or HTTP
          traffic. This will typically be hosted within the DMZ and be forward proxied to the WAS instance behind
          the first line of firewalls. For web listening within the core network, the web containers hosted within
          WAS will be used.
         Cognos – County standards will be used for all program reporting needs. The enterprise standard tool
          is Cognos.
         SQL Server 2000 or 2005: SQL Server will host all database needs for the HJIP program. The county
          has currently standardized on the SQL 2000 standard edition, but it is expected to migrate to SQL 2005
          before the end of the HJIP program.

7.1.3 Development Software

         Rational Application Developer (RAD) from IBM/Rational will be the approved environment for all
          Java/J2EE/Broker development. This will also be the preferred environment for all UML design and
          unit-level development of test cases.
         ANT will be the preferred tool for scripting of the continuous build and test execution. This will be used
          along with Cruise Control for the automation of the night builds.
         Cruise Control will automate the nightly build process.
         Clear Case is the county-approved source repository system for all code management.
         Clear Quest is the county-approved defect management system. This will be integrated with Requisite
          Pro (used by the business analyst team) and Test Manager (used by the QA team) for traceability
          between code and associated defect/requirement.
         JUNIT/XMLUNIT/Cactus, in combination, will be used for unit-level testing of any Java components.
         SOATEST will be used for the complete endpoint testing of all messages. SOATEST will be used for
          unit level, regression testing, continuous test execution, interoperability, and vulnerability testing of all
          service testing, regardless of whether the service is implemented as a web service or as a JMS
          transaction. Because this tool has a collaboration feature, it will be shared between development and
          QA primarily.
         XMLSPY will be used primarily by the data architects for the development of schemas.




Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                      Page 37 of 41                                 Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                                                                                       HJIP Architecture Plan
                                                                                                                                                         Development Process




8 Development Process

The HJIP development team will follow the test driven Test-First development methodology on all projects.
Within this approach, the development team will focus on developing test cases before writing any runable
code. Test cases will be created using either a Unit framework or SOATEST to automate the execution of the
tests. Each test case will be derived from the business requirements associated with the project. The proper
execution of the Test First approach will ensure that all software maintained as part of the project is held to the
highest standards and is business focused with real requirements from the BRD. The following two sections
outline the HJIP development methodology and the details of the development process.

8.1 HJIP Development Methodology

The HJIP methodology is based on the Total Business Integration Methodology developed by the EAI Industry
Consortium. The methodology integrates quality through all phases of a project lifecycle.

A description of the methodology and deliverable templates are in the HJIP QuickPlace:

http://www.hennplace.com/QuickPlace/hjip/PageLibrary86257108007B8667.nsf/h_Index/ECF13A13313FC4B1
8625712200705357/?OpenDocument

An overview of project deliverables by phase is illustrated below:


                                 HJIP Key Program and Project Deliverables
                     Program
                                  Statement of                  QA Plan                   Architecture                Deployment
                                      Work                                                   Plans                       Plan




                     Project(s)
                         1. Define                        2. Design                     3. Build                      4. Deploy
                                Project
                            Definition Doc
   Project Manager            (includes
                             schedule)



                              Business
      Business
                            Requirements
       Analyst
                                Doc



      Architect/                                           Logical Design               Physical Design
      Designer                                                  Doc                          Doc




     Developer
                                                                                            Code



                                                                                        Tested Software                 Tested Software
                            Test Plan Doc
   QA/QC Analyst                                                                         (Functional &                      (User &
                                                                                          End-to-end)                    Performance)

                                User
                             Acceptance
                            Test Plan Doc                                                                                 Production
                                                                                                                                               QA
                                                                                                                         Support Doc
                                                                                                                                            Milestone


                                                 QA                            QA                            QA
                                              Milestone                     Milestone                     Milestone
                                                                                                                                          Production

HJIP Methodology Deliverables 1-31-2006.vsd


Figure 8-1. HJIP Key Program and Project Deliverables




Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                                                    Page 38 of 41                                                       Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                                        HJIP Architecture Plan
                                                                                                          Development Process


The HJIP QuickPlace is the repository of final documentation for each project. Additional repositories are
needed for other deliverables as summarized below.

                     Deliverable                                               Repository
 Project documentation                               http://www.hennplace.com/QuickPlace/hjip/Main.nsf/
 XML schema, WSDL, etc. (Internet access)            http://www2.co.hennepin.mn.us/schema/justice/
 XML schema, WSDL, etc. (internal LAN access)        http://abinodji/
 Source code                                         Clear Case
 Defects, issues, risks                              Clear Quest
Table 8-2. Documentation Locations



8.2 Development Process

The steps below outline the activity and associated artifacts that should be a part of each phase of the
development process. This flow starts when the Business Analysis team hands off the business requirements.

8.2.1 Logical Design

Responsibility: Architect

Tools: RAD modeling, MS Word template, Visio

Artifacts: Logical design diagrams and documents are in the HJIP QuickPlace:

http://www.hennplace.com/QuickPlace/hjip/PageLibrary862570E4005A861E.nsf/h_Index/35D423572CC0045D
86257149004A46BA/?OpenDocument

Review: At least one other architect, QA architect, and data architect and the lead designer that will be working
on the physical design.

8.2.2 Physical Design

Responsibility: Lead designer

Tools: RAD modeling, MS Word template, Visio

Artifacts: Physical design document based on the standard template containing all UML – Class and Sequence
diagrams. For a message broker, it may contain the message flow diagram.

http://www.hennplace.com/QuickPlace/hjip/PageLibrary862570E4005A861E.nsf/h_Index/85E354761C019281
862571300062FA18/?OpenDocument

Review: Application architect, QA architect, and data architect

8.2.3 Define and Create Interface Code Model

Responsibility: Lead designer for J2EE (code generated out of RAD), lead developer for WMB (stub service
within WMB Toolkit)

Tools: RAD Modeling and WMB Toolkit


Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                       Page 39 of 41                                  Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                               HJIP Architecture Plan
                                                                                                 Development Process


Artifacts: Interface-level non-functioning code

Review: Self reviewed

8.2.4 Define and Create All Test Cases

Responsibility: Lead developer

Tools: RAD and WMB Toolkit

Artifacts: JUNIT, XMLUNIT, and SOATEST test cases and assertions

Review: Self reviewed

8.2.5 Code Development and Unit Testing

Responsibility: Lead developer

Tools: RAD and WMB Toolkit

Artifacts: Java code, WMB coding, or alternate as needed. All code must be properly checked into ClearCase.

Review: Self reviewed

8.2.6 Code Review

Responsibility: Lead developer

Tools: NA

Artifacts: Actual code, test case review, and all test case reports, such as Junit, XMLUNIT, or SOA test. If
possible, alternate reporting related to code coverage and check-style should be provided.

Review: Architect, lead designer, peer developer

8.2.7 QA Handoff and Promotion

Responsibility: Lead developer

Tools: NA

Artifacts: Provide to deployment manager all updated documents for release notes, configuration change
requests, and updated project information. Create and add all test scripts to the night build process. Provide
deployable artifacts (EAR, BAR, script, etc.) to the deployment manager.

http://www.hennplace.com/QuickPlace/hjip/PageLibrary862570E4005A861E.nsf/h_Toc/ce6a3d6b1f546c94052
56708001671ff/?OpenDocument

If the release is correcting a defect, ClearQuest must be updated.

Lead developer will label all code in ClearCase with the version number.

Review: Architect, QA lead, deployment manager


Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                     Page 40 of 41                              Last Updated: 2/9/2012
HJIP – Hennepin County Justice Integration Program                                                 HJIP Architecture Plan
                                                                                                         Revision History




Revision History

       Date             Version                                 Description                         Authors
March 15, 2006        0.1            Initial working draft                                 Pete McNair
May 1, 2006           1.6            First published draft                                 Pete McNair
May 9, 2006           1.7            Technical writer review                               Harry Silver
May 10, 2006          1.8            Several more edits (Yuriy, Phyllis, Adeola, Mark H)   Pete McNair




Doc: 41b35efa-5bf4-46c8-a9c3-00b2f3bc7781.doc
Prepared by HJIP                                             Page 41 of 41                       Last Updated: 2/9/2012

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:12
posted:2/9/2012
language:Latin
pages:44