![](media/image1.png){width="5.996527777777778in"
height="1.1847222222222222in"}

> The Justice Reference Architecture (JRA)
>
> Specification
>
> Working Draft V 1.2
>
> by
>
> The Global Infrastructure/Standards Working Group
>
> ***August 8, 2006***

![](media/image2.png){width="5.991666666666666in"
height="0.7777777777777778in"}

# Table of Contents

Table of Contents [3](#table-of-contents)

Acknowledgements [5](#acknowledgements)

How to Use This Document [6](#how-to-use-this-document)

Executive Summary [7](#executive-summary)

Introduction [8](#introduction)

Global's SOA Initiative [8](#globals-soa-initiative)

An Interoperability Strategy [9](#an-interoperability-strategy)

What Is the Justice Reference Architecture?
[10](#what-is-the-justice-reference-architecture)

Justice System Requirements [12](#justice-system-requirements)

> Functional Requirements [12](#justice-system-requirements)

JRA Non-Functional Requirements 17

Justice Reference Architecture [18](#justice-reference-architecture)

Graphical Overview [18](#graphical-overview)

Concepts and Relationships [20](#concepts-and-relationships)

OASIS Service-Oriented Architecture Reference Model
[20](#oasis-reference-model-for-service-oriented-architecture)

Services, Service Consumers, Capabilities, and Real-World Effects
[21](#core-concepts---services-service-consumers-capabilities-and-real-world-effects)

Business Process Models and the Service/Capability Hierarchy
[23](#business-process-models-and-the-servicecapability-hierarchy)

Interaction, Visibility, Service Models, and Service Interfaces
[24](#interaction-visibility-service-models-and-service-interfaces)

Design and Description of Service Interfaces
[27](#design-and-description-of-service-interfaces)

Capabilities in Detail [28](#capabilities-in-detail)

Policies, Contracts, and Agreements
[29](#service-policies-service-contracts-and-service-agreements)

Execution Context [30](#execution-contexts)

Services and Related Deliverables
[34](#services-and-related-deliverables)

Services [34](#services)

Service Design Principles [34](#service-design-principles)

Future Services Deliverables [34](#future-services-deliverables)

Business Process Models [35](#business-process-models)

Interaction, Service Models and Related Concepts
[35](#__RefHeading___Toc139275877)

Information Model [35](#information-model)

Domain Vocabularies [35](#domain-vocabularies)

Registries/Repositories [36](#registriesrepositories)

Future Interaction and Service Model Deliverables
[36](#future-interaction-and-service-model-deliverables)

Design and Description of Service Interfaces
[37](#design-and-description-of-service-interfaces-1)

Service Interaction Requirements [37](#service-interaction-requirements)

Service Interaction Profiles [38](#service-interaction-profiles-1)

Message Exchange Patterns [38](#message-exchange-patterns)

Future Service Interaction Deliverables
[38](#future-service-interaction-deliverables)

Capabilities in Detail and Related Components
[39](#capabilities-in-detail-and-related-components)

Provisioning Models [39](#provisioning-models)

Enterprise Integration Patterns [39](#enterprise-integration-patterns)

Future Deliverables [39](#future-deliverables)

Model Policies and Contracts [39](#model-policies-and-contracts)

Model Agreements [39](#model-agreements)

What Is Outside the Justice Reference Architecture?
[41](#what-is-outside-the-justice-reference-architecture)

Governance [41](#governance)

System Design [41](#system-design)

System Interfaces [42](#system-interfaces)

# Acknowledgements

# The Justice Reference Architecture (JRA) was developed through a collaborative effort of the Global Justice Information Sharing Initiative (Global), Office of Justice Programs (OJP), United States Department of Justice (DOJ).

# Global aids its member organizations and the people they serve through a series of important initiatives. These include the facilitation of Global Working Groups. The Global Infrastructure/Standards Working Group (GISWG) is one of four Global Working Groups covering critical topics such as intelligence, privacy, security, and standards. The GISWG is under the direction of Tom Clarke, Ph.D., National Center for State Courts. The GISWG consists of three committees, including Management and Policy, Services Interaction, and Services Committees.

# Although this document is the product of Global and its GISWG membership, it was primarily adapted from the technical reference architecture developed by the state of Washington, and sincere appreciation is expressed to Mr. Scott Came, Enterprise Architecture Program Director, Washington Department of Information Services, for his guidance and leadership. In addition, parts of the architecture were derived from the OASIS Service-Oriented Architecture Reference Model. Other major contributors deserving of recognition include the OASIS Court Filing Technical Committee, OASIS SOA Reference Model Technical Committee, Messaging Focus Group, and GISWG Executive Architecture Committee. 

# While each member of the GISWG is recognized for their contributions and for volunteering their time to the Justice Reference Architecture, Global would like to recognize the following members of the Executive Architecture Committee for their important contributions to this document. 

# Mr. Scott Came---State of Washington, Services Interaction Committee

Dr. Tom Clarke---National Center for State Courts, Chair GISWG

# Mr. Scott Fairholm---National Center for State Courts, Chair, GISWG Services Committee

Mr. Kael Goodman---IJIS Institute, Chair, GISWG Services Interaction
Committee

# Mr. Ron Hawley---SEARCH, The National Consortium for Justice Information and Statistics, Chair, GISWG Management & Policy Committee

# Mr. Eric Sweden, National Association for State Chief Information Officers, Vice Chair, GISWG

# How to Use This Document

**Policymakers, Executives, and Decision Makers**

Global is committed to providing Service-Oriented Architecture (SOA)
resources, such as this document, to local, state, regional, tribal, and
federal justice and public safety organizations. As additional resources
become available, these materials will demonstrate the value of the
architecture to the stakeholders in a way that is targeted to their
particular needs. Other planned resources include strategy, executive
summary, case studies from early implementers, management and policy,
and other planning briefings which will be targeted towards managers,
chiefs, and executives.

For the purposes of this document, Global has selected a distinguished
group of technical and domain representatives from a group of skilled
peers who have volunteered to develop this material as a starting point
in establishing the Justice Reference Architecture Specification for
Service-Oriented Architecture.

Keep in mind that the sections in this document referencing the
conceptual diagram, high-level components, and relationships establish
definitions that are intended for use by technical architects and
project managers who are responsible for identifying all the elements
necessary within their jurisdiction to implement SOA. **This document is
intended as a formal and complete architectural specification for people
with previous SOA and Web Service knowledge.**

**Project Managers, Architects, and Technologists**

This report is intended as a resource for a technical audience,
including Global Justice XML Data Model (Global JXDM) implementers,
architects, developers, system integrators and other justice and public
safety technical practitioners. It provides the background and
concepts---a strong foundation---required for the implementation of SOA.
The JRA is a new term coined for the justice community, and it is
derived from the OASIS Reference Model for Service-Oriented Architecture
1.0 Committee Specification 1, July 19, 2006 (SOA-RM). After reading
this document, the reader should plan to spend considerable time
familiarizing themselves with the OASIS Reference Model for SOA. The JRA
is intended to facilitate your SOA implementation by establishing a
common language that can be used to exchange data with partner
organizations.

The most current version of this paper and further elaboration of the
concepts are posted at http://it.ojp.gov/.

# Executive Summary

This document states a set of requirements for justice interoperability
and then describes the Justice Reference Architecture (concepts,
relationships, and high-level components) Specification that satisfies
those requirements. The document then illustrates the architecture
through a set of actual scenarios. Finally, the document provides an
initial elaboration of some of the concepts and components in the
architecture.

# 

#  

# Introduction

## Global's SOA Initiative

On September 29, 2004, the Global Justice Information Sharing Initiative
(Global) Advisory Committee (GAC) unanimously adopted SOA and the
recommendations in the report titled *A Framework for Justice
Information Sharing:  Service-Oriented Architecture (SOA)*.

Global provides support for SOA by:

-   Recognizing SOA as the recommended framework for development of
    justice information sharing systems;

-   Promoting the utility of SOA for the justice community; and,

-   Encouraging the members of the justice community to take these
    recommended incremental steps in the development of their own
    systems.

Global's approval was based on the understanding that SOA is an approach
that is most likely to result in an infrastructure that will support its
vision of how information should be shared among the justice community.
If SOA is to be used successfully as the framework for justice
information sharing architecture, Global must play a proactive
leadership role in several areas. The development of the Justice
Reference Architecture was based on the following actions recommended by
Global.

-   Incorporate SOA into the activities of all of the Global Working
    Groups. SOA raises issues for security, privacy and information
    quality, and intelligence that will be given explicit attention and
    treated as part of a broad initiative.

-   Encourage the creation of a mechanism for drawing together the
    experiences and lessons from the field.

-   Reach out to existing national systems to incorporate their efforts
    into the design of an overall strategy.

-   Address the following six issues as priorities---services,
    standards, interagency agreements, registries, security, and privacy
    and data quality---will be a major part of the agenda for the next
    set of activities of Global.

-   Develop a multi-tiered strategy for the public sector to influence
    standards. It will include encouraging the creation of a public
    process (as it did with XML); taking part in industry groups
    developing standards that are relevant to justice (e.g., OASIS); and
    developing partnership processes with industry and other public
    entities.

## An Interoperability Strategy

Solving interoperability challenges continues to be a significant
problem and a high priority for the justice and public safety community.
There are approximately 100,000 justice agencies that have the critical
need to share information across their various information systems, and
this variety creates multiple layers of interoperability problems
because hardware, software, networks and business rules for data
exchange are different. The need for information sharing has lead to
this interoperability strategy and the Justice Reference Architecture
(JRA).

The strategy for developing the JRA involves many steps. This paper
details some highly technical and abstract concepts. Understanding these
concepts may require significant effort from the reader. Though it may
seem strategically questionable to place such a high hurdle at the
beginning of a multi-step process, doing so actually creates a flexible
vocabulary and conceptual framework that will enable the desired
interoperability to flourish. Additionally, subsequent steps that will
build from this framework will be incrementally more concrete, and will
ultimately lead to actual implementation specifications that can be used
by practitioners in the field. Global believes that this dynamic
interoperability strategy will help to prevent incompatibilities, guide
vendors and organizations on how to fit components together, and
facilitate communication and interoperability between disparate
communities.

Global's strategy for the JRA, like other work that has preceded it,
follows a five step process:

Step One: Agree on common concepts

Step Two: Agree on the relationships and deliverables

Step Three: Assign the work

Step Four: Produce the deliverables

Step Five: Revise the deliverables

As an example, when the GJXDM project started it had a small set of
limited solutions. Through many iterations, the GJXDM has been expanded
and refined and addresses a successively larger set of justice domains.

**Consensus on the OASIS Reference Model for SOA**

One of the justice requirements is to create a common language for
talking about architecture across major domains. For instance, it is
currently difficult for emergency management personnel to talk to
justice personnel about how their respective systems might share data
beyond the content standards issue because their ways of communicating
about architecture are so different.

After considerable discussions among the stakeholders, Global adopted
the Organization for the Advancement of Structured Information Standards
(OASIS) Reference Model for Service-Oriented Architecture 1.0 Committee
Specification 1. This standards body is developing a reference model for
describing different architectures using comparable language. Global is
adopting the OASIS framework for describing its architecture and holding
conversations with other domains, and it will incorporate the OASIS
developments as required.

**Creating the Justice Reference Architecture**

It is important to note that the OASIS Reference Model for SOA 1.0
(SOA-RM) provides a roadmap for not only the justice community, but for
any industry to create a reference architecture. The JRA builds on the
SOA-RM concepts by specifying additional relationships, and defining and
specifying these adopted concepts.

While there is no perfect solution and since there is a need to start
somewhere, the JRA is recommended as the best place to start Global SOA
work efforts. Global began by mapping the SOA components, documenting
and leveraging the work that has been already done, like the GJXDM, and
finally, identifying and filling the gaps.

Specifically, Global is developing a modular architecture that cleanly
and appropriately identifies and separates technical and governance
layers so that standards can be developed to improve interoperability.

## What Is the Justice Reference Architecture?

This section defines the Justice Reference Architecture (JRA) for
Service-Oriented Architecture (SOA) and explains why a reference
architecture is useful. Keep in mind that there are potentially many
justice reference architectures, but that this JRA focuses entirely on
SOA for the justice and public safety community. Out of scope components
are listed on page
[46](#what-is-outside-the-justice-reference-architecture).

The JRA is a description of the important concepts in the justice domain
and the relationships between those concepts. The JRA also identifies,
at a high level, the kinds of "components" (software systems, hardware
infrastructure, policies, practices, intersystem connections, and so on)
necessary to bring those concepts to life in a particular context. The
JRA is generally not specific enough to govern the implementation of any
individual software system implementation. Rather, it is a framework for
guiding implementations in general, with the aim of standardizing or
harmonizing certain key aspects of those implementations to support
reusability or interoperability.

The JRA is driven by functional and non-functional requirements. These
requirements have been generated through interactions with other
committees, JAD sessions, interviews, and committee meetings. By driving
the development of the JRA from formal requirements, the JRA and
subsequent deliverables that will be developed through Global's
iterative process, will follow a traceable development life cycle. For
example, when an application developer writes test scripts,[^1] they
should be able to trace those test scripts back to the originating
requirements of the JRA.

It is important to note that at this time the JRA is not complete. Many
sections of this document are still under development, but the document
does attempt to identify the necessary concepts, relationships, and
components that will require further elaboration and/or implementation.

# Justice System Requirements

This section documents the business requirements to be addressed and
satisfied by the Justice Reference Architecture.

## Functional Requirements

As previously described in the Introduction, the justice world has close
to 100,000 justice agencies, and most of these are very small and have
few information technology resources. They use different applications,
hardware, and networks that have diverse topologies and interoperability
capabilities. Nonetheless, the JRA must reflect the influence of the
following factors, representing the key characteristics of the justice
and public safety environment.

**Requirement 1.0 -- The Justice Reference Architecture must recognize
innumerable independent agencies and funding bodies from local, state,
tribal, and federal governments.**

For anyone connected to the justice community, this requirement is
self-evident. One factor has not changed throughout American history:
the business of justice is largely the province of local, state, and
tribal government. The independence and number of entities that need to
share justice information is almost overwhelming. Certainly, it is
beyond the ability of existing conceptual frameworks, computer models,
financial resources or jurisdictional authority to create an integrated
network using traditional technology. SOA, however, can be a meaningful
bridge. A quote from SOA literature makes this fit clear: "Designing for
SOA involves thinking of the parts of a given system as a set of
relatively autonomous services, each of which is (potentially)
independently managed and implemented, which are linked together with a
set of agreements and protocols into a federated structure."
**\[Sholler\]** "Autonomous," "independent," "agreements," and
"federated" capture the environment for justice information sharing.

**Requirement 1.1 -- The JRA must accommodate information sharing across
agencies that represent divergent disciplines, branches of government,
and operating assumptions.**

It is difficult, if not impossible, to define precisely the boundaries
of the justice community. The obvious list of participants---law
enforcement, prosecution, courts, defense counsel, probation, and
corrections---is only the beginning. Accurate, timely, and appropriate
justice information sharing among the entities is necessary for
effective apprehension, prosecution, adjudication and punishment of an
offender. However, these are only some of the objectives.

This same information, or portions of it, is necessary to meet the
business requirements of related justice, public safety, and homeland
security agencies. For example, this information is required to regulate
the sale of firearms; complete criminal background checks of employees
at schools, child care services, and elder care facilities; identify
aliens who have been convicted of crimes or have entered the country
illegally; notify the local community of the release and location of
sexual predators; prevent training in the operation of aircraft by
aliens or other designated individuals who may present a risk to
aviation and national security; or do background checks of those
transporting hazardous materials; create information models to provide
information and predict the spread of disease and its effects, and
decide on countermeasures for potential health epidemics like the avian
flu.

The events of September 11, 2001, resulted in the creation of the\
U.S. Department of Homeland Security (DHS) with its constituent
agencies, such as the U.S. Citizenship and Immigration Services, U.S.
Customs and Border Protection, and the U.S. Coast Guard. September 11
also elevated the importance of information sharing between and among
public safety agencies such as fire, emergency medical services, and
other first-responder organizations.

The list would not be complete without the recognition of the numerous
entities outside of the justice and public safety communities---such as
schools, child care services, transportation, and licensing
agencies---that need critical justice-related information to perform
daily business activities, such as hiring new personnel, approving gun
purchases, or granting professional licenses.

Finally, the list of relevant constituencies also includes the public,
who expect greater accountability and access to justice information that
is considered sensitive or protected by privacy laws in some settings
(e.g., state criminal history records in many state repositories and the
FBI system), while viewed as public record in others (e.g., criminal
history record information in the courts). Increasingly, the public also
expects that this access be automated and online.

The diversity of justice information consumers carries an attendant
consideration: different types of users have different requirements. A
judge making a sentencing decision has more time for their task---and a
less expedited need for response to inquiry---than an officer on the
scene requiring instant access to succinct information.

The purposes also vary. For example, it is one thing if the primary
objective is to validate the identity or status of an individual (e.g.,
a law enforcement officer communicating with the Department of Motor
Vehicles to check on a driver's license), but another when an exhaustive
search for information is required (e.g., a probation officer conducting
a presentence investigation of a convicted offender).

Different sources also mean differences in expectations about who can
use what information. Privacy and data quality issues, which are
demanding enough when dealing with a single information system, grow
exponentially when dealing with different disciplines. It is one thing
to share the records of a criminal sentencing hearing held in open
court; it is quite another when dealing with health records or an
ongoing criminal investigation. Incomplete or inaccurate data may be an
annoyance if the task is to identify leads for subsequent
investigations; they are a different issue entirely if they prohibit one
from getting a job, traveling on an airplane, or lead to incarceration.
Working documents in one setting can become dispositive evidence in
another.

What this means is that the information system design cannot begin with
a clear definition of the boundaries of the organization. Nor can we
assume that all of those who participate share a common set of
objectives or an understanding of the process. On the contrary, the
information system design must assume diversity, even conflicts, in the
operating procedures and objectives of the participating organizations.

**Requirement 1.2 -- The JRA must be able to accommodate an infinite
range of scales, from small operations with few participants in a rural
county to national processes that reach across local, state, federal,
and even international boundaries.**[^2]

The context for information sharing in the justice community is not
singular. The scale will depend upon the objectives and the geographical
setting. It is one thing if the objective is to move cases quickly from
investigation to arrest through adjudication in a rural county where all
of the participants know each other and have ongoing contact on a
personal level. It is quite another thing if the objective is to share
information about warrants between law enforcement and the judiciary in
a large state on a real-time basis. And it is different still if the
context moves to a national level, and the objective is to share
information among many local, state, tribal, and federal law enforcement
and health agencies about a reported health epidemic.

The resources required to develop the JRA infrastructure for justice
information sharing will come from many independent sources, the largest
body of which will be local. It is safe to assume the funds will be
spent to meet the immediate needs of the entities within the funding
source's jurisdiction and not as a result of priorities that are
provided by a state or national plan. An approach to infrastructure
design that cannot be adapted to the different scales without losing its
internal integrity will quickly be marginalized.

**Requirement 1.3 -- The JRA must be able to accommodate data sources
that differ widely in software, hardware, structure, and design.**

The history of efforts to develop integrated information systems among
local criminal justice agencies around a single hardware and software
platform is large and filled with many disappointments. When the focus
shifts to the state and national level, the success rate becomes even
smaller and is largely populated by single-purpose efforts. The
explanation for this phenomenon is relatively simple: technology
investment decisions are made by funding sources with their own tax
base, budget cycle, and spending priorities. The result is that
information system development among local, state, tribal, or federal
justice community entities rarely occurs in concert.

The reality is that no infrastructure development strategy can assume
that all participants will be at the same point in the technology cycle.
To paraphrase: new technologies are important, but legacy systems will
always be with us.

**Requirement 1.4 -- The JRA must reflect and incorporate the lessons
and developments of the private sector.**

It often surprises the justice community to learn how much of the
technology needed to share information is common to the private sector
as well. When you think about it, only parts of the data and the
transaction definitions are unique to the justice world. The several
other technical layers in a transaction that provides a service are
driven by open standards defined by private industry and implemented in
their tool sets and products. The justice community must learn how to
incorporate and leverage private industry.

The Global process and the projects sponsored by it must take these
powerful trends in the private sector into account. The justice
community can have some influence on such decisions, even in the private
sector, by more fully participating in the open standards bodies that
decide what will be proposed to the market for implementation;
continuing collaboration with industry partners such as the IJIS
Institute will be necessary to succeed. Often, such participation and
collaboration will educate us on how to develop and/or reuse the
standards without needing to invent something new and unique for our
business problems. And, as Global puts together an agenda for progress,
lessons learned are provided from initiatives that have failed as well
as succeeded. These discoveries and lessons learned from the private
sector will save us money and facilitate the sharing of critical data in
ways that increase public safety.

**Requirement 1.5 -- The JRA must be dynamic, capable of evolving as the
information sharing requirements change and the technology is
transformed.**

The operational requirements of members of the justice community are in
constant change. The events of September 11 have elevated intelligence
information to a leading priority for law enforcement; the rise of
domestic violence cases has expanded the judiciary's need to reach out
to the family services community; the increased mobility of the
population has complicated probation's efforts to monitor offenders; and
the spread of AIDS has put a premium on health management by corrections
administrators. An infrastructure design that cannot adapt to an
evolving definition of the boundaries and critical components of the
justice community will, before long, become irrelevant.

# JRA Non-Functional Requirements

### 

### Requirement 2.0 -- The JRA should leverage open industry standards where possible.

The justice environment will benefit from the stabilization of standards
as the basis for an overall approach to interoperability among large and
diverse organizations. The evolution of open industry standards for
systems integration has reached a point where these standards will
facilitate interoperability. Many prominent programming languages,
software development environments, packaged applications, and
integration platforms/tools support the standards. While some common
integration needs are met by competing standards, the number and
significance of competing standards continue to shrink.

### Requirement 2.1 -- The JRA must support marketplace diversity.

The marketplace for integration products is highly diverse and is likely
to remain so for the foreseeable future. Support for Web services
standards, key integration capabilities (such as transformation,
content-based routing, and orchestration), and off-the-shelf adapters
for organization applications (such as Enterprise Resource Planning
(ERP) packaged applications) exist from a variety of vendors.

### Requirement 2.2 -- The JRA should use a service-oriented design philosophy.

### Requirement 2.3 -- The JRA should be driven by business need.

### Requirement 2.4 -- The JRA should derive service requirements from business process requirements. 

### Requirement 2.5 -- The JRA should preserve data control by the source organization.

### Requirement 2.6 -- The JRA should minimize dependencies among justice business processes and supporting information systems.

### Requirement 2.7 -- The JRA should treat services as reusable assets to be shared beyond the original context as required.

### Requirement 2.8 -- The JRA should support business agility as the fundamental business requirement.

### Requirement 2.9 -- The JRA should be developed in an iterative way.

### Requirement 2.10 -- The JRA should evolve indefinitely in response to changing business requirements.

#  Justice Reference Architecture

## Graphical Overview

The following diagram depicts the concepts, high-level components, and
relationships in the Justice Reference Architecture V1.2. These elements
are described in detail in the following sections.

![](media/image3.png){width="5.99375in" height="8.098611111111111in"}

## Concepts and Relationships

The following sections describe the concepts, components, and
relationships depicted on the diagram on the previous page.

### OASIS Reference Model for Service-Oriented Architecture 

The Justice Reference Architecture depicted in the diagram above (and
defined in this document) adopts and builds on the Reference Model for
Service-Oriented Architecture (SOA-RM) developed by OASIS.

The SOA-RM defines its purpose as follows:

> "A reference model is an abstract framework for understanding
> significant relationships among the entities of some environment. It
> enables the development of specific reference or concrete
> architectures using consistent standards or specifications supporting
> that environment. A reference model consists of a minimal set of
> unifying concepts, axioms, and relationships within a particular
> problem domain and is independent of specific standards, technologies,
> implementations, or other concrete details" (**\[SOA-RM\]**, p. 4).
>
> "The goal of this reference model is to define the essence of
> service-oriented architecture and emerge with a vocabulary and a
> common understanding of SOA. It provides a normative reference that
> remains relevant for SOA as an abstract and powerful model,
> irrespective of the various and inevitable technology evolutions that
> will impact SOA" (**\[SOA-RM\]**, p. 4).

While the SOA-RM is a powerful model that provides a vendor-neutral,
open-standard definition of service-oriented architecture , its abstract
nature means that further work must be done to create reference
architecture. OASIS lays out a roadmap for the creation of such
reference architecture. **Specifically, OASIS recommends that the
reference model guide the development of an architecture; that
protocols, profiles, specifications, and standards are considered; and
that requirements, motivations, and goals are taken in to account.**
(**\[SOA-RM\]**, p. 5).

**The JRA does just this. It takes the reference model and adds the
protocols, profiles, specifications, standards, requirements,
motivations, and goals appropriate for the justice community.**

In the JRA diagram, OASIS SOA-RM concepts are shaded yellow with a
dashed line as the border. Concepts and components particular to the
conceptual JRA defined by this document are shaded light blue with a
solid border. Relationships between concepts (indicated by arrows) are
defined in the SOA-RM if the arrows connect concepts shaded yellow.
Relationships between cyan-shaded concepts or between cyan-shaded and
yellow-shaded concepts are particular to the JRA.

![](media/image4.png){width="2.057638888888889in"
height="3.8958333333333335in"}The descriptions of SOA-RM concepts
provided in the following sections are intended to be brief summaries;
consequently, they omit certain details that appear in the SOA-RM.
Concepts listed in bold, blue caps are listed in the glossary at the end
of this document, and the glossary contains definitions of the SOA-RM
concepts which are repeated from the SOA-RM glossary for convenience.
The SOA-RM itself is the primary source for full exposition of SOA-RM
concepts and the relationships between them.

### Core Concepts - Services, Service Consumers, Capabilities, and Real-World Effects

These four concepts make up the core of the SOA RM and, the Global JRA.
All other concepts support these concepts. It is strongly advised that
these concepts be clearly grasped before reading the section called
Support Concepts.

The JRA begins from the premise that a group of justice partners have
**[capabilities]{.smallcaps}** that they provide to one another. These
capabilities "solve or support a solution for the problems
\[businesses\] face in the course of their business" (**\[SOA-RM\]**, p.
8). That is, capabilities are the things organizations have to solve
problems and therefore add value, directly or indirectly, to their
stakeholders.

Note that the JRA is generic enough to support virtually any kind of
capability. However, the purpose of the JRA is to describe an approach
to achieving interoperability among automated, computer software-based
information systems. Therefore, the JRA only considers those business
capabilities that are provided by (or implemented by) information
systems. The JRA calls these systems **[provider systems]{.smallcaps}**
and establishes that provider systems implement capabilities.

Each capability produces one or more **[real-world
effects]{.smallcaps}**, each of which is an outcome of the business
value sought by one of the partners. A real-world effect can be either
the obtaining of information, the changing of something of business
relevance to the participating partners, or both. Because the JRA
establishes that capabilities are implemented by provider systems,
real-world effects consist of the functional business requirements of
provider systems. That is, real-world effects in the JRA are essentially
the information made available by provider systems or the outcomes
resulting from business processes and workflows automated by provider
systems, or both. \[

In a service-oriented architecture, a **[service]{.smallcaps}** is the
way in which one partner gains access to a capability offered by another
partner. A partner that uses a service to gain access to another
partner's capability is called a **[service consumer]{.smallcaps}**. As
with capabilities, the architecture is generic enough to support
virtually any kind of service consumer. However, since the purpose of
the Justice Reference Architecture is to describe an approach to
information systems interoperability, the JRA only considers those
service consumers implemented by information systems. The JRA calls such
systems **[consumer systems]{.smallcaps}**.

One of the most important features of the JRA is the separation of
consumer systems from provider systems by services in the middle. This
is the defining characteristic of a service-oriented architecture and is
the key to decoupling systems as called for in many of the Justice
System Requirements listed in the section on page
[15](#justice-system-requirements).

The fact that information sharing is one kind of real-world effect
allows the architecture to support the traditional view of system
integration as "data exchange" or "information sharing." The JRA
improves this view by encouraging systems to share information in a way
that minimizes the dependencies of each system on the implementation of
other systems.

### Supporting Concepts

**[Service design principles]{.smallcaps}**[^3] provide consistent
guidance regarding the overall partitioning of capabilities into
services and the relationships between services. For instance, service
design principles may call for services to represent one concise,
self-contained function and may also suggest that services should
completely hide the implementation details of the capabilities to which
they provide access.

There is a wide variety of ways in which a service can provide access to
a capability. In some cases, the provider system that implements the
capability may already expose all or some of its functionality as
services (through one or more service interfaces, described on page
[30](#service-interface)). In other cases, the business partner that
provisions the capability can purchase an off-the-shelf adapter from the
provider system vendor (or a third party) that exposes the system's
functionality as a set of services. Finally, the provider system may
require reimplementation or custom adaptation to expose functionality as
services. This is often expensive and risky, and the desire to avoid
this situation should be addressed in the Service Design Guidelines.

In general, a given information system can be both a provider system and
a consumer system. Similarly, a particular business organization may
offer capabilities to its partners and, at the same time, be a consumer
of the capabilities offered by others. This has important implications
for how the organization should conceive and describe its information
systems assets and how it assigns responsibilities for the maintenance
and support of those assets. For example, in the past it was common to
think of systems having "client" and "server" components (or "browser"
and "server" components), which in turn influenced thinking about
systems deployment, networking, security, support, and a range of other
issues. These issues deserve reconsideration in an architecture in which
a system or system component can be both a "client" (consumer of
services) and "server" (provider of services) at the same time. The
discussion of service interaction on page [27](#Interaction), and the
subsequent elaboration of interaction mechanisms in future iterations of
the JRA, will reflect the impact of these issues.

Note that the concept of a service in the JRA does not equate to a "Web
service." The term "Web services" is a label for a family of standards
and an associated technical approach to communicating between service
consumers and services. The architecture supports flexibility in how
this communication happens through the notion of service interaction
profiles (discussed on page [31](#service-interaction-profiles)). A Web
service profile will be developed for the Web services family of
standards; however, the JRA will include additional profiles that adopt
other communication mechanisms, such as MQ, JMS, and ebXML (discussed on
page [42](#service-interaction-profiles-1)).

### Business Process Models and the Service/Capability Hierarchy

The previous section described the basic concepts involved in the
integration of provider systems and consumer systems. In short, consumer
systems seek a real-world effect provided by a capability, and they
produce that effect by accessing a service that provides access to the
capability. However, these concepts by themselves do not provide the
context for the integration of a particular consumer and particular
provider. That is, the concepts do not provide a way of describing why a
consumer seeks the effect made available by a provider through a
service.

A **[business process model]{.smallcaps}** provides this contextual
justification. A business process model is a description (usually formal
and often graphical) of a series of activities that culminate in the
achievement of some outcome of business value. Some (but not necessarily
all) of the steps in this series of activities involve producing a
real-world effect provided by a capability, and some of the steps
require a consumer to use a service. Each one of these steps, then,
provide the contextual justification for service interaction between a
particular consumer and particular provider.

The execution of the steps described in a business process model can be
considered a capability in and of itself. In addition, each of the steps
in a business process model can unfold into yet another business process
model at a more focused level of detail. In this way, each step in a
series of service interactions can itself be a series of service
interactions. (And, in theory, this recursion of models can go on
forever, though in practice it rarely exceeds three or four levels of
containment.) So, services and capabilities form a hierarchy, where a
service provides access to a capability whose real-world effect is to
accomplish the coordination of multiple services at a lower level of
detail.

The JRA supports this hierarchy through orchestrations and
intermediaries, discussed on page
[32](#orchestrations-and-intermediaries).

### Interaction, Visibility, Service Models, and Service Interfaces

Services define what features of a provider system the system owner
makes accessible to business partners. Services also provide a logical
description of the information exchanged between consumer and provider
systems as the consumer accesses the capability.

The JRA refers to a consumer's accessing the features of a capability
through a service as []{#Interaction
.anchor}**[interaction]{.smallcaps}**, defined as "the performing \[of\]
actions against a service" (**\[SOA-RM\]**, p. 15). Service interaction
generally involves the exchange of information between the consumer and
the service.

Interaction depends on two things. First, the designers of potential
consumers need to be able to find services and, once found, establish a
physical interaction mechanism with them. These needs are addressed by
the concept of **[visibility]{.smallcaps}**. Second, the designers of
potential consumers need a description of the actions that can be
performed on a service, as well as the structure and meaning of
information exchanged during the interaction. These needs are addressed
by the concept of a service's **[information model]{.smallcaps}** and
**[behavior model]{.smallcaps}**, collectively called **[service
models]{.smallcaps}** in the JRA.

#### Visibility

Visibility, as the name implies, defines how service consumers and the
providers of capabilities "see" each other in a way that enables
interaction between them. The JRA identifies three aspects of
visibility.

-   A service consumer must have information that makes it aware of the
    existence of a service; the possession of this information is called
    **[awareness.]{.smallcaps}**

```{=html}
<!-- -->
```
-   The service (or capability accessed through the service) must be
    willing to interact with the consumer; this is called
    **[willingness.]{.smallcaps}**

-   The consumer and service must be able to communicate with one
    another, through some kind of communication path or channel; the
    existence of such a communication path is called
    **[reachability.]{.smallcaps}**

In the JRA, a **[repository]{.smallcaps}** will support awareness by
hosting service models and service interfaces. "Hosting" in this context
means storing models and interface descriptions in a central location
that is accessible to appropriate stakeholders. A repository will permit
searching for models and interface descriptions based on a range of
identifying criteria. A repository will also map logical service
identifiers with physical addresses. When a consumer wishes to
communicate with a service (identified by a logical identifier), the
consumer queries the repository for the physical address associated with
the service's logical identifier. This decouples the consumer from the
physical location of a service at any point in time, thereby permitting
the physical relocation of the service without impacting the
implementation of the consumer.

The concept of willingness is related to authorization and access
control policies, in that a common reason for lack of willingness to
interact is that the consumer is not authorized to conduct the requested
interaction. Willingness often manifests in service descriptions, as
well as policies, contracts, and agreements (discussed on page
[33](#service-policies-service-contracts-and-service-agreements)). A
**[service model]{.smallcaps}** is defined as the information needed in
order to use, or consider using, a service.

The concept of reachability is closely related to the concept of
execution context (discussed on page [34](#execution-contexts)).

#### Service Models

Service models, consisting of a service's information and behavior
models, define the semantics of interaction with the service. The
behavior model defines the actions that can be performed on the service;
that is, it defines what the service "does." The information model
describes the information that consumers exchange with the service in
the course of performing those actions.

Note that the SOA-RM considers the orchestration and choreography of
multiple services to be "part of the process model of a given
architecture." Yet the SOA-RM also indicates that a process model (part
of the behavior model) applies to a single service (**\[SOA-RM\]**, p.
15). Because of this lack of clarity in the SOA-RM, this JRA identifies
orchestration as a type of capability that leverages other services; it
is described on page [32](#orchestrations-and-intermediaries).

In general, service models will be described at conceptual and logical
levels of detail. (Service models have a physical manifestation as well,
in the form of the service interface discussed in the next section.) A
conceptual description of a service model will typically describe, in
prose text form, the capability to which the service provides access, a
listing and brief textual description of each action, and a brief
textual description of the information model (e.g., key information
entities, key properties on those entities, and brief definitions). A
logical description of a service model will describe the actions and
information structures in detail but independent of any physical
implementation mechanism. Often this description will be graphical and
follow a standard diagramming or modeling technique, such as Uniform
Modeling Language (UML).

A **[message]{.smallcaps}**[^4] is defined as the entire "package" of
information sent between service consumer and service (or vice versa),
even if there is a logical partitioning of the message into segments or
sections. For instance, if an interface expresses actions as operations
or functions that take arguments, and a particular operation has two
arguments, both arguments would be considered part of the same message,
even though they may be logically separated within the message
structure. A message also includes the concept of an "attachment," in
which there are several additional sections (attachments) that relate to
a distinct, "primary" section.

In the JRA, the exchange of messages is the only way in which consumers
and services can communicate. Also, there is a linkage between the
Federal Enterprise Architecture Data Reference Model (FEA DRM) and the
JRA. Basically, the message is the Information Exchange Package (IEP)
and the Service's Information Model is the Information Exchange Package
Documentation (IEPD).

The concept of **[domain vocabularies]{.smallcaps}** in the JRA includes
canonical data models, data dictionaries, and markup languages that
standardize the meaning and structure of information for a topical or
business domain. Domain vocabularies can improve the interoperability
between consumer and provider systems by providing a neutral, common
basis for structuring and assigning semantic meaning to information
exchanged as part of service interaction. Domain vocabularies can
usually be extended to address information needs specific to the service
interaction or to the business partners integrating their systems.

**[service modeling guidelines]{.smallcaps}** govern the style,
structure, and description of service models.

As previously stated, a repository should contain service model
description artifacts for each level of detail. The availability of
service model descriptions to consumer system designers, implementers,
and purchasers is a key factor in establishing visibility and the reuse
of services.

#### Service Interface

Service models describe the actions available from a service and the
information exchanged between a consumer and the service during the
performance of those actions. In this way, the service models describe
the "what" of interaction.

A **[service interface]{.smallcaps}** "is the means for interacting with
a service. It includes the specific protocols, commands, and information
exchange by which actions are initiated \[on the service\]"
(**\[SOA-RM\]**, p. 22). A service interface is what a system designer
or implementer (programmer) uses to design or build executable software
that interacts with the service. That is, the service interface
represents the "how" of interaction.

The JRA considers the service interface to be the physical manifestation
of the service models. Best practices call for a service interface to be
described in an open-standard, referenceable format (that is, a format
whose contents are capable of automated processing by a computer).

Note that at least some policies and contracts can be described in a
service's interface.

The format, structure, and allowable contents of a service interface are
established by **[interface description requirements]{.smallcaps}**,
described in the following section.

### Design and Description of Service Interfaces

The JRA identifies four architectural elements that guide the design and
description of service interfaces.

**[Service interaction requirements]{.smallcaps}** define common rules
of service interaction. Typically, these requirements are directly
related to the capability used by the service consumer, nor are they
related to the real-world effect resulting from use of that capability.
Rather, the requirements enforce (or support the enforcement of)
policies or contracts or otherwise protect the interests of particular
business partners or the business organization overall.

Common service interaction requirements address areas such as security,
reliability, and availability. An initial elaboration of service
interaction requirements appears on page
[41](#service-interaction-requirements).

**[Interface description requirements]{.smallcaps}** establish common
characteristics of service interface descriptions. These requirements
address areas such as required interface contents, naming rules,
documentation rules, and specification of a standard structure and
format for descriptions.

**[Message exchange patterns]{.smallcaps}** identify common sequences of
message transmission between service consumers and services. They
provide a label to a series of message transmissions that have some
logical interrelationship. An initial elaboration of message exchange
patterns appears on page [42](#message-exchange-patterns).

**[Message definition mechanisms]{.smallcaps}** are closely related to
interface description requirements, described above. Unlike interface
description requirements, message definition mechanisms establish a
standard way of defining the structure and contents of a message. Note
that since a message includes the concept of an "attachment," the
message definition mechanism must identify how different sections of a
message (for example, the main section and any "attachment" sections)
are separated and identified and how attachment sections are structured
and formatted.

#### Service Interaction Profiles

A **[service interaction profile]{.smallcaps}** defines a family of
industry standards or other technologies or techniques that together
demonstrate implementation or satisfaction of:

-   Service interaction requirements.

-   Interface description requirements.

-   Message exchange patterns.

-   Message definition mechanisms.

Service interaction profiles are included in the JRA to promote
interoperability without forcing the organization to agree on a single
way of enabling service interaction. Each service interface will support
a single profile; a service will have multiple interfaces if it supports
multiple profiles. By supporting a profile, an interface establishes the
mode of interoperation it allows from service consumers; any consumer
that also supports that profile can "reach" the service.

**[Service interaction profile guidelines]{.smallcaps}** define
precisely what is required of a service interaction profile and,
therefore, provide guidance and clear requirements for developers of
potential profiles.

### Capabilities in Detail

The JRA identifies several types of capabilities, to assist decision
makers in understanding where certain capabilities should be deployed in
the organization and what relationships they may have to other
capabilities and services.

#### Orchestrations and Intermediaries

An **[orchestration]{.smallcaps}** is a capability that coordinates
interaction with multiple services. An orchestration is often
implemented using an open industry standard implementation mechanism
(referred to as an **[orchestration mechanism]{.smallcaps}** in the
JRA), which allows the implementation to be shared across tools and
platforms. Also, it is often possible to implement orchestrations using
a graphical, model-driven approach, in which the implementer diagrams
business processes and work flows, the steps of which are services that
already exist. After the diagram is complete, the implementer generates
a standards-based artifact that is deployed into a software component
that exposes the work flow as a service through a service interface. The
promise of this model-driven approach is that less technical
implementers with greater business expertise can be responsible for the
implementation of orchestrated capabilities.

A **[router]{.smallcaps}** is a capability that receives a message,
examines it, and transmits it to one or more destinations based on the
contents. In general, routers can be designed to operate on any of the
information contained within the message; they may use information about
the origin of the message, routing directive information contained
within the message or the main content of the message itself.

A **[transformer]{.smallcaps}** is a capability that receives a message
and transforms it into another format before transmitting it on to
another destination.

Routers and transformers are collectively called
**[intermediaries]{.smallcaps}**. This term indicates that routers and
transformers generally sit between other services and "mediate" the
interaction by managing the transmission of messages between them or by
reformatting messages in transit.

Routers and transformers are useful mechanisms for decoupling the
senders and recipients of messages. They tend to centralize and share
certain kinds of logic so that the logic can be maintained independently
of the provider and consumer capabilities at the edges; sharing also
improves the likelihood of reuse, since it is easier to reuse
functionality if it encapsulates a single task.

Support for router, transformer, and orchestration capabilities is a
common feature in many integration platforms, and therefore support for
these capabilities is a consideration in choice of execution context
(discussed on page [34](#execution-contexts)).

Routing, transformation, and orchestration capabilities are well
understood and well documented in the integration architecture
literature. The most common flavors of these capabilities have been
collected into pattern form as **[enterprise integration
patterns]{.smallcaps}**, in **\[Patterns\]**. The JRA will incorporate
these patterns by reference.

Orchestrations and intermediaries are a key component in implementing
business process models and also lead to the formation of
service/capability hierarchies.

### Service Policies, Service Contracts, and Service Agreements

**[Service policies]{.smallcaps}** and **[service
contracts]{.smallcaps}** express rules that govern the interaction
between a service consumer and a service. A policy is an assertion by
either a consumer or service provider of that participant's requirements
for willingness to interact. A policy also has an enforcement aspect and
must be stated in such a way as to permit enforcement. A **[service
contract]{.smallcaps}** is an agreement by the parties involved, and
there is a process associated with the agreement action. Whereas a
policy is an assertion by one participant in the interaction, a contract
is an agreement between the participants that expresses some expectation
or requirement of the interaction. And whereas policy enforcement is
generally the responsibility of the participant who asserts the policy,
contract enforcement may involve resolution of disputes that arise
between the parties.

A **[service agreement]{.smallcaps}** is a document that establishes
policies and contractual elements for a given interaction or set of
interactions (that is, for one or more services).

### Execution Contexts

**[execution contexts]{.smallcaps}** is "the set of infrastructure
elements, process entities, policy assertions, and agreements that are
identified as part of an instantiated service interaction"
(**\[SOA-RM\]**, p. 24).

Execution context is the primary enabler of the reachability aspect of
visibility. Execution context includes the set of infrastructure
elements that provide a physical communication path between service
consumers and services.

The JRA considers execution context to be primarily the supporting
infrastructure elements that permit service consumers and services to
interact. These infrastructure elements consist of:

-   Data networks used by service consumers and services to exchange
    information.

-   Integration infrastructure (hardware and software) that makes
    service interfaces available and handles higher-level message
    routing, transformation, and orchestration.

-   Consumers of certain common capabilities (via services) that support
    service interaction; examples include directory services and
    metering services.

Execution context can implement (or support the implementation of) some
service interaction requirements, such as reliability and availability.
Service interaction profiles, contracts, and policies can constrain the
behavior of execution context elements, by requiring particular
technologies or techniques or establishing service level policies (for
example).

Finally, execution context can support certain kinds of capabilities
directly in the integration infrastructure, such as routing,
transformation, and orchestration.

**Illustration Scenarios**

These scenarios will showcase the benefits of SOA, such as reuse and
interoperability of services. Note that this section is illustrative
only and is not intended to establish these scenarios as standards or
intended approaches to specific projects. The first scenario is listed
as a simple example of the reference architecture and its key concepts
to provide a basis for understanding the terminology.  The second
scenario is more representative of actual systems that implement the
architecture. The third scenario shows how SOA could potential work
within other domains and among our Justice partners.

**Scenario A---Warrant Look-up Service**

It is a Friday night, and you're a patrol officer making a routine
traffic stop. You need to safely and accurately determine the status of
the driver who you have stopped for speeding and expired plates. You
need to find information the **[service provider]{.smallcaps}** that can
tell you about this individual, including whether he has any current
warrants.

You consult your in-squad Mobile Data Computer and run a Warrant Check
against the local and State "hot files" looking for hits on John NMN Doe
Jr. DOB 12/14/1961. Transparent to you, the information technology folks
have implemented an architecture that uses a
**[repository]{.smallcaps}** to find available services, such as the
Warrant Look-up against the State "hot files." So the state "hot files"
system is available to you when you need it, and it provides **[service
consumers]{.smallcaps}** with **[visibility]{.smallcaps}** into the many
local and regional jurisdictions with active warrants on file.

-   The "hot files" system specifies the **[willingness]{.smallcaps}**
    of each service provider to provide the **[service]{.smallcaps}**
    you desire (warrant look-ups, warrant locates, warrant
    confirmations).

-   The system features describe how to query the local agency by
    providing a web address and procedures
    (**[reachability]{.smallcaps}**).

-   The system describes the business **[service model]{.smallcaps}**
    with information such as: "These warrant files are updated weekly,
    use confirmation service before arrest."

-   The system uses an implicit **[information model]{.smallcaps}** to
    describe the features if provides and the services it offers (all
    "active" misdemeanor, gross misdemeanor and felony warrants
    available; local traffic warrants not reported)

-   The system describes the **[behavior model]{.smallcaps}** that the
    service provider embodies when it provides the service: "Upon
    positive ID of a warrant suspect, we will send locate and
    confirmation service upon request."

-   Their business **[policies]{.smallcaps}** are also described: "We
    will confirm all warrant hits within 10 minutes and return reply for
    action and details of extradition limits."

-   The service is based on compliant Global JXDM data naming structures
    (**[domain vocabularies]{.smallcaps}**) to aid in consistent
    terminology and interoperation of local warrant services.

You want to know if John NMN Doe Jr., DOB 12/14/1961 has any active
warrants? You can have an **[interaction]{.smallcaps}** by phone call by
calling the local sheriff's office, or having your dispatch center
contact them for you. Thanks to the "hot files" system, you can also
make this inquiry through their warrant information service.

You log onto the "hot files" system (**[service
interface]{.smallcaps}**), including your User ID and Password. On the
log-in page, there is a disclaimer that describes the terms & conditions
I agree to by signing into the Acceptable Use Policy (**[policies and
contracts]{.smallcaps}** for consumer **[agreements]{.smallcaps}** with
service provider).

The "hot files" system will requires you to choose a type of "query".
You utilize the **[capabilities]{.smallcaps}** of the "hot files" system
to conduct a "warrant status check". You enter the full name and DOB of
my suspect into the Warrant query fields and submit. To provide a
comprehensive and timely response, the "hot files"
**[provisioning]{.smallcaps}** **[model]{.smallcaps}** seeks to
coordinate the inquiry against many local, state, regional and federal
information services that report active warrants.

The "hot files" system **[orchestrates]{.smallcaps}** the
**[routing]{.smallcaps}** of the warrant suspect inquiry
(**[message]{.smallcaps}**), which goes first to the Statewide Warrant
File. The State CJIS center is an **[intermediary]{.smallcaps}** that
**[transforms]{.smallcaps}** and re-routes the request via the
capabilities of its specialized information systems. The distributed
request also goes to all local sheriff offices who provide a coordinated
warrant file look-up service, to the regional information centers who
also respond to this specialized request, and to NCIC for a national
warrant, wants or holds response.

Within minutes all of the local, state, regional and federal systems
have responded to the State CJIS center. The "hot files" system can now
assemble the responses, package them in a standard response format, and
return the collected response about John NMN Doe Jr. DOB 12/14/1961 to
you in your squad car. There is, according the Taylor County Sheriff's
Office, an active gross misdemeanor arrest warrant for Mr. Doe for
Theft. The service has achieved the **[real-world effect]{.smallcaps}**
that you desired.

The Taylor County Sheriff's Office emails the link and phone number
which are included in the warrant response from the "hot files" system.
You have dispatch contact the Taylor County warrant office (**[service
interface]{.smallcaps}**) to confirm the status of the warrant and the
parameters of extradition. Taylor County is over 100 miles from here,
but the return confirmation message is that the warrant is still active,
that the arrest should be made, and that Taylor County will send a
transport officer to receive the defendant from the local jail before
noon tomorrow.

**Scenario B---Inmate Lookup Notification Service**

To be completed.

**Scenario C---Pandemic Notification Service**

To be completed.

**Specification Roadmap**

The purpose of this section is to establish a direction and initial
"straw model" for the components to be defined in detail within the JRA.
Note that many of these components are currently deliverables within the
JRA Work Plan for the 2006 time frame. The GISWG will develop these
concepts in incremental steps over time as noted in the Plan. The
components that are future deliverables and the other concepts which are
more mature are also listed below. The most current version of this
paper and further elaboration of the concepts will be posted on
<http://it.ojp.gov/jra>.

### Services and Related Deliverables

## The JRA deliverables related to services are documented in this section. To cross reference the definitions of corresponding concepts in this section see page [24](#core-concepts---services-service-consumers-capabilities-and-real-world-effects). 

## Services 

The SEARCH Justice Information Exchange Model (JIEM) Reference Model 1.1
will be used as the starting point to define services in the JRA. The
list of key Information Exchange Package Documentation (IEPD) that have
already been developed will be used to further narrow the initial list
of services to define (see <http://it.ojp.gov/iepd/>).

## Service Design Principles 

The following initial list of service design principles is summarized
from **\[Erl\]**.

-   Services should be designed for reuse.

-   Services should be designed so that they may participate in a
    composition with other services to form a higher-level service.

-   Services should share only a formal contract with their consumers.
    (Consumers are dependent only on the service's interface not the
    implementation details of the capability to which the service
    provides access.)

-   Services are stateless, meaning that during an interaction with a
    service, a service consumer supplies all information necessary to
    conduct the interaction and makes no assumptions about information
    retained from prior interactions.

## 

## Future Services Deliverables

-   ***Service Definitions***

-   ***Service Design Guidelines***

## Business Process Models

## Business Process Models are explained starting on page [26](#business-process-models-and-the-servicecapability-hierarchy). 

While not part of the normative JRA, these business process models may
be drawn from normative guidance within specific communities for
specific services, such as fusion centers or the exchange of classified
intelligence data. They are also useful as guides to more complex
orchestrated services that support core business processes within the
justice community. []{#__RefHeading___Toc139275877 .anchor}

## Interaction, Service Models and Related Concepts

## To cross reference the concepts and related deliverables in this section, please see page [27](#interaction-visibility-service-models-and-service-interfaces). 

## Information Model

## The service information model for the JRA is the Information Exchange Package Documentation (IEPD). This is consistent with the FEA DRM. 

## Domain Vocabularies

## The data vocabulary for the JRA is the Global Justice XML Data Model (Global JXDM) Version 3.0.3. Information about the data model can be accessed at:

<http://it.ojp.gov/jxdm>

An expanded data model drawing on parts of the National Information
Exchange Model (NIEM) may be incorporated when NIEM 1.0 becomes
available. Information on its status may be obtained at:

[http://www.niem.gov](http://www.niem.gov/)

Reusable data components are not yet identified in the GJXDM. Version
3.1 may or may not begin to support this feature. NIEM also intends to
identify data components into universal, core and domain specific
namespaces.

A target list of IEPD's has not been identified. JRA principles suggest
that IEPD's should be developed incrementally according to prioritized
business needs. The SEARCH Reference Justice Information Exchange Model
(JIEM) contains a list of over one hundred exchange documents from which
a starter list of IEPD's has been compiled. To see which documents
currently have available IEPD's, access the IEPD Clearinghouse at:

<http://it.ojp.gov/iepd>

## Registries/Repositories

Several SOA registries are now under pilot development in the justice
community and could potentially be used to host the JRA. Further
research is being compiled, and the documentation listed below is
currently under development.

## Future Interaction and Service Model Deliverables

The GISWG is currently evaluating various approaches to best elaborate
the following components. These components will be completed as part of
the JRA Work Plan, and will be documented once the deliverables have
been solidified.

-   ***Registries/Repositories Principles***

-   ***Registries/Repositories Requirements***

-   ***Registries/Repositories Guidelines***

-   ***Service Description***

-   ***Service Modeling Guidelines***

### Design and Description of Service Interfaces

## As a cross reference, the concepts and related deliverables in this section correspond to the concepts which are explained in the section starting on page [31](#design-and-description-of-service-interfaces). The JRA Work Plan includes the following deliverables. 

## Service Interaction Requirements

The following is an initial list of candidate service interaction
requirements.

-   **Service Consumer Authentication:** Information provided with
    messages transmitted from service consumer to service that verify
    the identity of the consumer.

-   **Service Consumer Authorization:** Information provided with
    messages transmitted from service consumer to service that document
    the consumer's authorization to perform certain actions on and/or
    access certain information via the service.

-   **Service Authentication:** The ability of a service to provide a
    consumer with information that demonstrates the service's identity
    to the consumer's satisfaction.

-   **Message Nonrepudiation:** Information provided in a message to
    allow the recipient to prove that a particular authorized sender in
    fact sent the message.

-   **Message Integrity:** Information provided in a message to allow
    the recipient to verify that the message has not changed since it
    left the control of the sender.

-   **Message Confidentiality:** Information provided in a message to
    protect anyone except an authorized recipient from reading the
    message or parts of the message.

-   **Message Addressing:** Information provided in a message that
    indicates where a message originated, the ultimate destination of
    the message (beyond physical end point), a specific recipient to
    whom the message should be delivered (this includes sophisticated
    metadata designed specifically to support routing), and a specific
    address or entity to which reply messages (if any) should be sent.

-   **Reliability:** Information provided with messages to permit
    message senders to receive notification of the success or failure of
    message transmissions, and to permit messages sent with specific
    sequence-related rules either to arrive as intended, or fail as a
    group.

-   **Transaction Support:** Information provided with messages to
    permit a sequence of messages to be treated as an atomic transaction
    by the recipient.

-   **Service Metadata Availability:** The ability of a service to
    capture and make available (via query) metadata about the service.
    (Metadata is information that describes or categorizes the service
    and often assists consumers in interacting with the service in some
    way.)

-   **Service Availability:** A commitment of a service to be reachable
    at a stated percent of the time with specified conditions.

-   **Service Responsiveness:** A commitment of a service to return a
    response (synchronous or asynchronous) within a specified period of
    time.

## Service Interaction Profiles

Several service interaction profiles have already been prioritized for
development: Web services, MQ, JMS, ebXML, fixed wireless, and mobile
wireless. A draft of the Web services service interaction profile is
available as part of the OASIS Legal XML Electronic Court Filing 3.0
committee draft specification.

## Message Exchange Patterns

The JRA will identify the following message exchange patterns:

The **[fire-and-forget]{.smallcaps}** pattern calls for the sender of a
message (which could be the service consumer or service) to send the
message and not expect a reply message back from the recipient. This
pattern is useful for one-way transmission of information, such as
notification that an event has occurred.

The **[request-reply]{.smallcaps}** pattern calls for the sender of a
message to send the message and expect a reply back from the recipient.

These two patterns are considered "primitive" patterns, in that they are
the fundamental building blocks of more complex information exchange
scenarios. For instance, the complex **[publish-subscribe]{.smallcaps}**
pattern involves an initial request-reply exchange in which the
subscriber subscribes to a service, followed by the service using the
fire-and-forget pattern to notify subscribers of an event.

## Future Service Interaction Deliverables

-   ***Service Interaction Profile Guidelines***

-   ***Interface Description Requirements***

-   ***Message Definition Mechanisms***

## Capabilities in Detail and Related Components

## To cross reference the concepts and related deliverables in this section, please review page [32](#capabilities-in-detail). The JRA Work Plan includes the following deliverables. 

## Provisioning Models

While not part of the normative JRA, these best practices provide
guidance on how best to implement key facilitation services like message
validation, orchestration, routing and transformation using
intermediaries or other means. The GISWG plans on documenting
Provisioning Model Guidelines and Principles.

## Enterprise Integration Patterns

While not part of the normative JRA, the existing best practices can be
combined with the provisioning models to indicate preferred approaches
to the implementation of key services within a community. The GISWG will
adopt existing best practices by reference **\[Patterns\].**

## Future Deliverables

-   ***Orchestration Guidelines***

-   ***Orchestration Principles***

-   ***Orchestration Mechanisms***

**Policies, Contracts, and Agreements**

## Model Policies and Contracts

It is possible for every JRA service provider to establish a unique set
of policies and business requirements for each service. This approach
would create almost insurmountable barriers to the widespread
consumption of services for cost reasons alone. The definition of model
policies and contracts will provide reusable policies across common
services and sets of related services, based on national policies on
security, privacy and other policy requirements. Given the current state
and local variations in policy based on statute and court rule, these
model policies must necessarily be aspirational initially. The GISWG
will develop and recommend potential model policies and contracts.

## Model Agreements

These model agreements (termed MOU's, etc.), together with model
contracts, lay out standard provisions for consuming JRA services. The
GISWG will develop and recommend potential model agreements.

**Execution Context**

Execution Content provides direction on a practical network strategy for
JRA service interactions. It is not part of the normative JRA, but it
does suggest an efficient approach that leverages existing network
capabilities while retaining the loosely coupled nature of an SOA. The
GISWG plans on documenting any potential execution context issues.

## What Is Outside the Justice Reference Architecture?

This document does not identify everything necessary for a successful
approach to interoperability among various justice information systems.
Other essential factors that need to be addressed but that are not
addressed in this document are governance, detailed systems designs,
infrastructure specification, or specification of interfaces between
justice systems. These other factors will likely relate to concepts and
components in the JRA, so as companion documents that address these
other factors are developed, they should reference the JRA when
appropriate.

### Governance

The issue of interoperability among justice and public safety
information systems raises a set of governance and decision-making
questions, such as:

-   Under what circumstances and through what process is a shared
    interface to an information system allowed to change?

-   Through what process does the organization assess the compliance of
    system interfaces with architectural standards?

-   Through what process does the organization adopt new architectural
    standards (or change existing ones)?

-   How does the organization reach agreement on the meaning of
    information exchanged between interoperable systems?

Governance business processes and standards will be delivered as a
companion document to the JRA. Governance areas of particular concern
include registries, intermediaries, orchestration and the execution
context. The JRA currently does not include these and other aspects of
political governance that underpin or support the technical
architecture.

Technical governance is another area that remains to be specified.
Issues like change control and version management go beyond political
decisions to practical administration when operational systems implement
a set of technical standards.

The governance document will include at least the following
deliverables:

-   Model policies, agreements and contracts

-   IEPD and SIP governance processes

-   Principles for registries, orchestration, services and provisioning
    models

### System Design 

The JRA does not include actual applications nor does it propose a
design of any information system. The requirements addressed by the JRA
focus on the interoperability of systems, not the systems themselves.
The JRA does identify the need for a set of design guidelines that
should impact information system design choices. But these guidelines
will address only the integration aspects of systems in support of
business processes that involve the sharing of justice information.

The JRA is a set of reference standards and guidelines that such systems
may implement to improve interoperability and information sharing.
Global will reach out to existing national, state, local and tribal
systems to incorporate the JRA specification into their technical
strategies.

**Infrastructure Specifications**

The JRA does not include networks nor does it propose a detailed design
for an infrastructure to support systems integration. Requirements for
integration infrastructure could be derived from further elaboration and
specification of some of the concepts and components documented in the
JRA. The pipes for moving justice information across the country already
exist in Nlets, the American Association of Motor Vehicle Administrators
network (AAMVAnet), Regional Information Sharing Systems (RISS), FBI
CJIS, HSIN, etc. The objective of the national strategy is to use these
pipes and existing networks to their best advantage, not to supplant
them.

### System Interfaces

The JRA does not identify specific interfaces between systems. It is
intended to provide a framework or road map for the definition of these
interfaces. Specific services based on the JRA set of policies,
guidelines and standards may be implemented by any system that finds it
useful as a guide. The governance document may separately recommend that
certain systems implement certain services or that certain types of
organizations consume services from particular systems, but that is
beyond the scope of the JRA.

**Glossary**

**Service Agreements**

> A document that establishes policies and contractual elements for a
> given interaction or set of interactions (that is, for one or more
> services).

**Architecture**

> A set of artifacts (that is: principles, guidelines, policies, models,
> standards and processes) and the relationships between these
> artifacts, that guide the selection creation, and implementation of
> solutions aligned with business goals.

**Awareness**

> A state whereby one party has knowledge of the existence of the other
> party. Awareness does not imply willingness or reachability.

**Behavior Model**

> The characterization of (and responses to, and temporal dependencies
> between) the actions on a service.

**Business Process Model**

> A description (usually formal and often graphical) of a series of
> activities that culminate in the achievement of some outcome of
> business value. Some (but not necessarily all) of the steps in this
> series of activities involve producing a real-world effect provided by
> a capability, and some of the steps require a consumer to use a
> service. Each one of these steps, then, provide the contextual
> justification for service interaction between a particular consumer
> and particular provider.

**BPEL**

Business Process Execution Language is used to describe a business
process that will take place across the Web in such a way that any
cooperating entity can perform one or more steps in the process the same
way.

**BPMN**

Business Process Modeling Notation provides a graphical notation for
expressing business processes in a business process diagram. The
objective of BPMN is to support business process management by both
technical and business users by providing a notation that is intuitive
to business users yet able to represent complex process semantics.

**Capability**

A real-world effect that a service provider is able to provide to a
service consumer.

**Consumer System**

The information system that gains access to another partner's capability
offered by means of a service.

**Service Contracts**

An agreement by two or more parties regarding the conditions of use of a
service.

**Domain Vocabularies**

> Includes canonical data models, data dictionaries, and markup
> languages that standardize the meaning and structure of information
> for a domain. Domain vocabularies can improve the interoperability
> between consumer and provider systems by providing a neutral, common
> basis for structuring and assigning semantic meaning to information
> exchanged as part of service interaction. Domain vocabularies can
> usually be extended to address information needs specific to the
> service interaction or to the business partners integrating their
> systems.

**Enterprise Integration Patterns**

> Enterprise integration has to deal with connecting multiple
> applications running on multiple platforms in different locations.
> Enterprise Integration Patterns help integration architects and
> developers design and implement integration solutions more rapidly and
> reliably. Most of the patterns assume a basic familiarity with
> messaging architectures. However, the patterns are not tied to a
> specific implementation.

**Execution Context s**

> The set of technical and business elements that form a path between
> those with needs and those with capabilities and that permit service
> providers and consumers to interact.

**Framework**

> A set of assumptions, concepts, values, and practices that constitutes
> a way of viewing the current environment.

**Information Model**

> The characterization of the information that is associated with the
> use of a service. The scope of the information model includes the
> format of information that is exchanged, the structural relationships
> within the exchanged information and also the definition of terms
> used.

**Interaction**

> The activity involved in making use of a capability offered, usually
> across an ownership boundary, in order to achieve a particular desired
> real-world effect.

**Interface Description Requirements**

Establishes common characteristics of service interface descriptions.
These requirements address areas such as required interface contents,
naming rules, documentation rules, and specification of a standard
structure and format for descriptions.

**Intermediaries**

> Routers and transformers are collectively called intermediaries. This
> term indicates that routers and transformers generally sit between
> other services and "mediate" the interaction by managing the
> transmission of messages between them or by reformatting messages in
> transit.

**Justice Reference Architecture**

> JRA is an abstract framework for understanding significant components
> and relationships between them within a Service-Oriented environment.
> It lays out common concepts and definitions as the foundation for the
> development of consistent SOA implementations within the justice and
> public safety communities. The term refers to the modular architecture
> that cleanly and appropriately identifies and separates technical and
> governance layers so that standards can be developed to improve
> interoperability. The JRA is being developed by Global, leverages the
> work of others, for example, the State of Washington, and builds upon
> the work of OASIS.

**Message**

> The entire "package" of information sent between service consumer and
> service (or vice versa), even if there is a logical partitioning of
> the message into segments or sections.

**Message Definition Mechanisms**

> Establishes a standard way of defining the structure and contents of a
> message, for example GJXDM- or NIEM-conformant schema sets. Note that
> since a message includes the concept of an "attachment," the message
> definition mechanism must identify how different sections of a message
> (for example, the main section and any "attachment" sections) are
> separated and identified and how attachment sections are structured
> and formatted.

**Message Exchange Patterns**

Identifies common sequences of message transmission between service
consumers and services. They provide a label to a series of message
transmissions that have some logical interrelationship.

**Message Validators**

**Nonfunctional Requirements**

> Nonfunctional requirements are known as service interaction
> requirements. These are not directly related to the capability and
> real-world effect resulting from the use of a capability. Rather,
> nonfunctional requirements support the service interaction by
> typically enforcing policies and contracts.

**Orchestration**

> A capability that coordinates interaction with multiple services. An
> orchestration is often implemented using an open industry standard
> implementation mechanism (referred to as an orchestration mechanism in
> the JRA), which allows the implementation to be shared across tools
> and platforms.

**Orchestration Mechanism**

The standards or tools used for orchestration as specified by the JRA,
for example, Business Process Execution Language (BPEL).

**Service Policies**

> A statement of obligations, constraints or other conditions of use,
> deployment or description of an owned entity as defined by any
> participant.

**Process Model**

> The characterization of the temporal relationships between and
> temporal properties of actions and events associated with interacting
> with the service.

**Provider System**

The information system that offers the use of capabilities by means of a
service.

**Provisioning Models**

The responsibility/models for making a service available to customers in
a manner consistent with formal (or occasionally informal) customer
expectations.

**Reachability**

> The ability of a service consumer and service provider to interact.
> Reachability is an aspect of visibility.

**Real-World Effect**

> The actual result of using a service, rather than merely the
> capability offered by a service provider.

**Reference Architecture**

> A reference architecture is an architectural design pattern that
> indicates how an abstract set of mechanisms and relationships realizes
> a predetermined set of requirements.

**Reference Model**

> A reference model is an abstract framework for understanding
> significant relationships among the entities of some environment that
> enables the development of specific reference or concrete
> architectures using consistent standards or specifications supporting
> that environment**.**

A reference model consists of a minimal set of unifying concepts, axioms
and relationships within a particular problem domain, and is independent
of specific standards, technologies, implementations, or other concrete
details.

**Repository**

> Stores models and interface descriptions in a central location that is
> accessible to appropriate stakeholders. A repository will permit
> searching for models and interface descriptions based on a range of
> identifying criteria. A repository will also map logical service
> identifiers with physical addresses.

**Router**

> A capability that receives a message, examines it, and transmits it to
> one or more destinations based on the contents. In general, routers
> can be designed to operate on any of the information contained within
> the message; they may use information about the origin of the message,
> routing directive information contained within the message or the main
> content of the message itself.

**Semantics**

> A conceptualization of the implied meaning of information, that
> requires words and/or symbols within a usage context.

**Service**

> The means by which the needs of a consumer are brought together with
> the capabilities of a provider.

**Service Consumer**

> An entity which seeks to satisfy a particular need through the use of
> capabilities offered by means of a service.

**Service Design Principles**

The documentation to provide consistent guidance regarding the overall
partitioning of capabilities into services and the relationships between
services.

**Service Interaction Profiles**

> Defines a family of industry standards or other technologies or
> techniques that together demonstrate implementation or satisfaction
> of:

-   Service interaction requirements.

-   Interface description requirements.

-   Message exchange patterns.

-   Message definition mechanisms.

> Service interaction profiles are included in the JRA to promote
> interoperability without forcing the organization to agree on a single
> way of enabling service interaction. Each service interface will
> support a single profile; a service will have multiple interfaces if
> it supports multiple profiles.

**Service Interaction Profile Guidelines**

> Define precisely what is required of a service interaction profile
> and, therefore, provide guidance and clear requirements for developers
> of potential profiles.

**Service Interaction Requirements**

> Define common rules of service interaction. Typically, these
> requirements are nonfunctional in nature, in that they are not
> directly related to the capability used by the service consumer, nor
> are they related to the real-world effect resulting from use of that
> capability. Rather, the requirements enforce (or support the
> enforcement of) policies or contracts or otherwise protect the
> interests of particular business partners or the business organization
> overall.

**Service Interface**

> The means by which the underlying capabilities of a service are
> accessed.

**Service Model**

> Interaction depends on two things. First, the designers of potential
> consumers need to be able to find services and, once found, establish
> a physical interaction mechanism with them. Second, the designers of
> potential consumers need a description of the actions that can be
> performed on a service, as well as the structure and meaning of
> information exchanged during the interaction. These needs are
> addressed by the concept of a service's information model and
> behavioral model, collectively called service models in the JRA.

**Service Modeling Guidelines**

Documents guidelines for services provided and consumed among partners.
It provides guidance as well as compliance information regarding the
modeling and description of services to promote consistency.

**Service-Oriented Architecture (SOA)**

> Service-Oriented Architecture is a paradigm for organizing and
> utilizing distributed capabilities that may be under the control of
> different ownership domains. It provides a uniform means to offer,
> discover, interact with and use capabilities to produce desired
> effects consistent with measurable preconditions and expectations.

**Service Provider**

> An entity (person or organization) that offers the use of capabilities
> by means of a service.

**Transformer**

> A capability that receives a message and transforms it into another
> format before transmitting it on to another destination.

**Visibility**

> The capacity for those with needs and those with capabilities to be
> able to interact with each other.

**Willingness**

> A predisposition of service providers and consumers to interact.

**References**

**Erl** Erl, Thomas. *Service-Oriented Architecture: Concepts,
Technology, and Design*. Prentice-Hall, 2005

**GISWG** GISWG. A Framework for Justice Information Sharing:
*Service-Oriented Architecture*. Global, December 9, 2004.

**Patterns** Hohpe, Gregor, and Woolf, Bobby. *Enterprise Integration
Patterns: Designing, Building, and Deploying Messaging Solutions*.
Addison Wesley, 2004.
[Http://www.eaipatterns.com](http://www.eaipatterns.com/)

**Scholler** Sholler, Daniel. *Demystifying Service-Oriented
Architecture*, META Practice, June 9, 2004.

**SOA-RM** *Reference Model for Service-Oriented Architecture 1.0,
Committee Specification 1*. OASIS, July 19, 2006.
<http://www.oasis-open.org/>

**Document History**

+----------------+-------+----------------+---------------------------+
| Date           | Ve    | Editor         | Change                    |
|                | rsion |                |                           |
+================+=======+================+===========================+
| March 25, 2006 | 1.0   | Scott Came     | Initial Draft             |
+----------------+-------+----------------+---------------------------+
| March 28, 2006 | 1.0   | Tish           | Editorial changes and IIR |
|                |       | Cunningham     | QC                        |
|                |       |                |                           |
|                |       | Kim Geer       |                           |
+----------------+-------+----------------+---------------------------+
| May 1, 2006    | 1.1   | Monique La     | Integrate comments from   |
|                |       | Bare           | EAC, glossary,            |
|                |       |                | introduction,             |
|                |       |                | acknowledgements, insert  |
|                |       |                | scenario, editing page    |
|                |       |                | numbers                   |
+----------------+-------+----------------+---------------------------+
| June 1, 2006   | 1.1   | Tom Clarke     | Elaboration of concepts   |
|                |       |                | and principles.           |
+----------------+-------+----------------+---------------------------+
| June 28, 2006  | 1.1   |                | Reordered Elaboration of  |
|                |       |                | concepts, added warrant   |
|                |       |                | scenario                  |
+----------------+-------+----------------+---------------------------+

[^1]: A test script is a typical final step that is executed prior to
    the acceptance of a system.

[^2]: For clarity, we have changed the original language in the
    documents to fit the current terminology that is based on the OASIS
    and JRA work efforts. This current work is based on the requirements
    from the document titled, A Framework for Justice Information
    Sharing: Service-Oriented Architecture (SOA), December 9, 2004,
    which was written by The Global Infrastructure/Standards Working
    Group.

[^3]: Principles and guidelines are important components of the
    conceptual JRA, however, these principles and guidelines are not
    illustrated on the diagram because they will exist for most of the
    components.

[^4]: The JRA will conform to the Federal Enterprise Architecture Data
    Reference Model (FEA DRM). The concept of a message is similar to
    the Information Exchange Package (IEP), and the Service Information
    Model is consistent with the Information Exchange Package
    Documentation (IEPD). These concepts will be defined in the Service
    Modeling Guidelines.