Get documents about "HJIP Architecture Plan
Shared by: yaohongm
-
Stats
- views:
- 12
- posted:
- 2/9/2012
- language:
- Latin
- pages:
- 44
Document Sample
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
