1Justice Reference Architecture Specification Version 1.7
36 Table of Contents
37 Table of Contents............................................................................................................................i
39 The Justice Reference Architecture (JRA) was developed through a collaborative effort of the
40Global Justice Information Sharing Initiative (Global), Office of Justice Programs (OJP), U.S.
41Department of Justice (DOJ)...........................................................................................................ii
42 Global aids its member organizations and the people they serve through a series of important
43initiatives. These include the facilitation of Global Working Groups. The Global
44Infrastructure/Standards Working Group (GISWG) is one of five Global Working Groups covering
45critical topics such as intelligence, privacy, security, outreach, and standards. The GISWG is
46under the direction of Tom Clarke, Ph.D., National Center for State Courts. The GISWG consists
47of three committees—Management and Policy, Services Implementation, and Enterprise
49 Although this document is the product of Global and its GISWG membership,
50it was adapted primarily from the technical reference architecture developed by
51the state of Washington, and sincere appreciation is expressed to Mr. Scott Came, state of
52Washington and SEARCH, The National Consortium for Justice Information and Statistics, for his
53guidance and leadership. In addition, parts of the architecture were derived from the
54Organization for the Advancement of Structured Information Standards (OASIS) Reference Model
55for Service-Oriented Architecture 1.0
56(SOA-RM). Other major contributors include the OASIS Court Filing Technical Committee,
57OASIS SOA-RM Technical Committee, and the Messaging Focus Group. ....................................ii
58 Although all members of the GISWG are recognized for their contributions and for volunteering
59their time to the development of the architecture, Global would also like to recognize the
60members of the GISWG Executive Architecture Committee..........................................................iii
61 How to Use This Document...........................................................................................................iv
62 Policymakers, Executives, and Decision Makers..............................................................iv
63 Project Managers, Architects, and Technologists.............................................................iv
64 Document Conventions.................................................................................................................vi
65 Executive Summary.........................................................................................................vii
67 1.1. Global’s SOA Initiative................................................................................................1
68 1.2. An Interoperability Strategy.........................................................................................2
69 1.3. Consensus on the OASIS Reference Model for SOA.................................................4
70 1.4. Creating the JRA.........................................................................................................5
71 1.5. What Is the JRA?........................................................................................................6
72 1.6. What the JRA Is Not....................................................................................................6
732. Architecture Requirements.........................................................................................................8
74 This section documents the business requirements to be addressed and satisfied by the
75 JRA. These requirements are stated in the form of principles, the intent of which is to guide
76 and constrain the choices made in developing the architecture...............................................8
773. The JRA....................................................................................................................................15
4Justice Reference Architecture Specification Version 1.7
78 3.1. Graphical Overview...................................................................................................15
794. Concepts and Relationships.....................................................................................................17
80 OASIS Reference Model for Service-Oriented Architecture .................................................17
81 Core Concepts—Services, Service Consumers, Capabilities, and Real-World Effects.........18
82 Supporting Concepts.............................................................................................................20
83 Interaction, Visibility, Service Models, and Service Interfaces...............................................20
84 Design and Description of Service Interfaces........................................................................26
85 Capabilities in Detail..............................................................................................................28
86 Service Policy, Service Contract, and Service Agreement....................................................31
87 Execution Context.................................................................................................................31
88 Provisioning Model................................................................................................................32
895. Reconciliation of Architecture With Principles...........................................................................33
906. Elaboration of Service Interaction Requirements......................................................................37
939. Document History.....................................................................................................................49
95 The Justice Reference Architecture (JRA) was developed
96 through a collaborative effort of the Global Justice
97 Information Sharing Initiative (Global), Office of Justice
98 Programs (OJP), U.S. Department of Justice (DOJ).
99 Global aids its member organizations and the people they
100 serve through a series of important initiatives. These
101 include the facilitation of Global Working Groups. The Global
102 Infrastructure/Standards Working Group (GISWG) is one of
103 five Global Working Groups covering critical topics such as
104 intelligence, privacy, security, outreach, and standards. The
105 GISWG is under the direction of Tom Clarke, Ph.D., National
106 Center for State Courts. The GISWG consists of three
107 committees—Management and Policy, Services
108 Implementation, and Enterprise Architecture.
109 Although this document is the product of Global and its
110 GISWG membership,
111 it was adapted primarily from the technical reference
112 architecture developed by
113 the state of Washington, and sincere appreciation is
114 expressed to Mr. Scott Came, state of Washington and
7Justice Reference Architecture Specification Version 1.7
115 SEARCH, The National Consortium for Justice Information
116 and Statistics, for his guidance and leadership. In addition,
117 parts of the architecture were derived from the Organization
118 for the Advancement of Structured Information Standards
119 (OASIS) Reference Model for Service-Oriented Architecture
121 (SOA-RM). Other major contributors include the OASIS
122 Court Filing Technical Committee, OASIS SOA-RM Technical
123 Committee, and the Messaging Focus Group.
124 Although all members of the GISWG are recognized for their
125 contributions and for volunteering their time to the
126 development of the architecture, Global would also like to
127 recognize the members of the GISWG Executive
128 Architecture Committee.
129Mr. Scott Came—State of Washington and SEARCH, The
130NationalConsortium for Justice Information and Statistics,
131GISWG Services Implementation Committee
132Dr. Tom Clarke—National Center for State Courts, Chair,
134Mr. Scott Fairholm—National Center for State Courts, Chair,
135GISWG Services Committee (2005–2008)
136Mr. Dale Good—Judicial Council of California, Chair, GISWG
137Management and Policy Committee
138Mr. Kael Goodman—IJIS Institute, Chair, GISWG Services
139Interaction Committee (2005–2007)
140Mr. Ron Hawley—SEARCH, The National Consortium for Justice
141Information and Statistics, GISWG Management and Policy
142Committee Chair (2005–2006)
143Mr. Eric Sweden—National Association for State Chief
144Information Officers, Vice Chair, GISWG (2005–2008)
10Justice Reference Architecture Specification Version 1.7
145 How to Use This Document
146 Policymakers, Executives, and Decision Makers
147Global is committed to providing Service-Oriented Architecture
148(SOA) resources, such as this document, to local, state,
149regional, tribal, and federal justice and public safety
150organizations. As additional resources become available,
151these materials will demonstrate the value of the architecture
152to the stakeholders in a way that is targeted to their particular
153needs. Other planned resources include strategy, executive
154summary, case studies from early implementers, management
155and policy, and other planning briefings, which will target
156managers, chiefs, and executives.
157For the purposes of this document, Global has selected a
158distinguished group of technical and domain representatives
159from a group of skilled peers who have volunteered to develop
160this material as a starting point in establishing the Justice
161Reference Architecture (JRA).
162Keep in mind that the sections in this document referencing the
163conceptual diagram, high-level components, and relationships
164establish definitions that are intended for use by technical
165architects and project managers who are responsible for
166identifying all the elements necessary within their jurisdictions
167to implement SOA. This document is intended as a formal and complete
168architectural specification for people with previous knowledge of technical
169architecture, service-oriented architecture, and supporting industry standards
170(such as Web services).
171 Project Managers, Architects, and Technologists
172This report is intended as a resource for a technical audience,
173including Global Justice XML Data Model (Global JXDM) and
174National Information Exchange Model (NIEM) implementers,
175architects, developers, system integrators, and other justice
176and public safety technical practitioners.
178Itprovides the background and concepts—a strong foundation
179—required for the implementation of SOA. The JRA is a new
13Justice Reference Architecture Specification Version 1.7
180term coined for the justice community, and it is derived from
181the OASIS Reference Model for Service-Oriented Architecture
1821.0 [SOA-RM]. The reader should refer to the SOA-RM for more
183detailed information about many of the concepts in this
184document. JRA is intended to facilitate your SOA
185implementation by establishing a common language that can
186be used to exchange data with partner organizations.
16Justice Reference Architecture Specification Version 1.7
187 Document Conventions
188In this document, use of a bold small-caps typeface, as in this
189EXAMPLE, indicates an important concept or a term defined either
190inthe glossary or in the body of the text at the point where the
191term or concept is first used.
193In this document, use of a bold caps typeface, as in this
194[EXAMPLE], indicates an important resource document noted in the
195Reference Section of this document.
19Justice Reference Architecture Specification Version 1.7
196 Executive Summary
197In2004, Global endorsed service-oriented architecture (SOA)
198as a recommended strategy for integrating justice information
199systems. This document—the Justice Reference Architecture
200Specification—is a first step towards achieving this vision.
201SOA promises many benefits to state, local, and tribal justice
202partners. It promotes the sharing of information in a manner
203that maximizes agility—the ability of partners to change
204business processes and technology solutions rapidly at
205minimum cost. In today’s dynamic justice business
206environment, this is more important than ever. It also gives
207justice partners a set of tools that allow them to share
208infrastructure by identifying where interoperability is important,
209thus enabling them to make smart investments that stretch
210every dollar. Finally, SOA offers the promise of an over-arching
211umbrella framework that demonstrates how all of Global’s
212work products fit together as a cohesive approach to
213improving information sharing.
214While recognizing these benefits, it is also important to
215recognize that SOA is not trivial to implement, especially if
216practitioners do not share lessons learned and best practices
217across jurisdictions. The cost of reimplementing SOA from
218scratch in every state, county, municipality, and tribal
219organization in the United States would be overwhelming. The
220JRA aims to solve this problem by providing practitioners with a
221set of documents that represent the national justice
222community’s very best practices, experiences, and lessons
223learned from implementing SOA. A state, local, or tribal
224integration architect or project manager can start with these
225documents rather than starting from nothing, dramatically
226accelerating his or her jurisdiction’s path to SOA. Along the
227way, the JRA will lead the jurisdiction to adoption of the other
228products that Global and its partners have developed.
229This document—the JRA Specification—is a conceptual
230framework for SOA that is based on an industry standard, the
231OASIS SOA Reference Model, which was developed by a
232committee of industry and government SOA experts, including
233some of the GISWG members who authored the JRA. The
234Specification defines a set of key concepts in a standard way,
235so that across the country, justice practitioners and their
236industry partners can adopt a consistent vocabulary for
22Justice Reference Architecture Specification Version 1.7
237communicating about SOA. The framework also provides a
238jumping-off point for the rest of the broader reference
239architecture, by identifying areas where the community needs
240more thorough standards and guidelines. Separate documents
241within the JRA elaborate these concepts, which include:
242 • A methodology for identifying what services—
243 exchange points—a jurisdiction should develop to
244 solve some identified business problem
245 • A standard for describing services so they can be
246 used, understood, and consumed across
248 • Recommended requirements for infrastructure
249 necessary to support SOA
250 • Technical communications protocols, based on
251 industry standards such as Web services and
252 XML, for transmitting information as messages
253 between justice partners and their systems
254 • Guidelines for governing and managing an SOA in
255 a jurisdiction—how to assign decision rights and
256 responsibilities for implementing elements of an
258If you are an executive-level decision-maker without direct
259day-to-day management responsibilities over technology, you
260should view this document (and the remainder of the JRA) as
261important guidance for your technology staff to follow as you
262plan (or participate in planning) information sharing in your
263jurisdiction. Even if you are not technically oriented, you still
264have ultimate accountability for the wise investment of public
265funds in your community, and you should be aware of the
266JRA’s power to lead you and your partners to an agile,
267standards-based, shared approach to information sharing.
268Ifyou are a chief information officer, architect, senior project
269manager, or other technology leader responsible for
270implementation of information sharing solutions, the JRA holds
271the promise of saving you a great deal of time, effort, and
272money in implementing the best practices inherent in SOA.
273This document is primarily for you.
25Justice Reference Architecture Specification Version 1.7
28Justice Reference Architecture Specification Version 1.7
2871.1.Global’s SOA Initiative
288On September 29, 2004, the Global Justice Information Sharing
289Initiative (Global) Advisory Committee (GAC) unanimously
290adopted SERVICE-ORIENTED ARCHITECTURE (SOA) and the
291recommendations in the report titled A Framework for Justice Information
292Sharing: Service-Oriented Architecture (SOA). [SOA-REC]
293 Global provides support for SOA by:
295 • Recognizing SOA as the recommended FRAMEWORK
296 for development of justice information sharing
298 • Promoting the utility of SOA for the justice
300 • Encouraging the members of the justice
301 community to take these recommended
302 incremental steps in the development of their own
305Global’s approval was based on the understanding that SOA is
306the approach most likely to result in an infrastructure that will
307support its vision of how information should be shared within
308the justice community. If SOA is to be used successfully as the
309framework for justice information sharing ARCHITECTURE, Global
310must play a proactive leadership role in several areas. The
311development of the JUSTICE REFERENCE ARCHITECTURE was based on the
312following actions recommended by Global:
314 • Incorporate SOA into the activities of all Global
315 Working Groups. SOA raises issues for security,
316 privacy and information quality, and intelligence
317 that will be given explicit attention and treated as
318 part of a broad initiative.
319 • Encourage the creation of a mechanism for
320 drawing together the experiences and lessons
321 from the field.
31Justice Reference Architecture Specification Version 1.7
322 • Reach out to existing national systems to
323 incorporate their efforts into the design of an
324 overall strategy.
325 • Address the following six issues as priorities—
326 services, standards, interagency agreements,
327 registries, security, and privacy and data quality—
328 because they will be a major part of the agenda
329 for the next set of Global activities.
330 • Develop a multitiered strategy for the public
331 sector to influence standards. It will include
332 encouraging the creation of a public process (as
333 it did with XML), taking part in industry groups that
334 are developing standards relevant to justice (e.g.,
335 OASIS), and developing partnership processes
336 with industry and other public entities.
3371.2.An Interoperability Strategy
338Solving interoperability challenges continues to be a significant
339problem and a high priority for the justice and public safety
340community. Approximately 100,000 justice agencies have the
341critical need to share information across their various
342information systems, and this variety creates multiple layers of
343interoperability problems because hardware, software,
344networks, and business rules for data exchange are different.
345The need for information sharing has led to this interoperability
346strategy and the JRA.
347The strategy for developing JRA involves many steps. This
348paper details some highly technical and abstract concepts.
349Understanding these concepts may require significant effort
350from the reader. Though it may seem strategically
351questionable to place such a high hurdle at the beginning of a
352multistep process, doing so actually creates a flexible
353vocabulary and a conceptual framework that will enable the
354desired interoperability to flourish. Additionally, subsequent
355steps that will build from this framework will be incrementally
356more concrete and will ultimately lead to actual
357implementation specifications that can be used by
358practitioners in the field. Global believes that this dynamic
359interoperability strategy will help to prevent incompatibilities,
360guide vendors and organizations on how to fit components
361together, and facilitate communication and interoperability
362among disparate communities.
34Justice Reference Architecture Specification Version 1.7
363Global’s strategy for JRA, like other work that has preceded
364it, follows a five-step process:
365 Step One: Agree on common concepts
366 Step Two: Agree on the relationships and
368 Step Three: Assign the work
369 Step Four: Produce the deliverables
370 Step Five: Revise the deliverables
371As an example, when the Global JXDM project started, it had a
372small set of limited solutions. Through much iteration, Global
373JXDM has been expanded and refined and addresses a
374successively larger set of justice domains.
37Justice Reference Architecture Specification Version 1.7
3751.3.Consensus on the OASIS Reference Model for SOA
376One of the justice requirements is to create a common
377language for talking about architecture across major domains.
378For instance, it is currently difficult for emergency
379management personnel to talk to justice personnel about how
380their respective systems might share data beyond the content
381standards issue because their ways of communicating about
382architecture are so different.
383After considerable discussions among the stakeholders, Global
384adopted the Organization for the Advancement of Structured
385Information Standards (OASIS) Reference Model for Service-
386Oriented Architecture 1.0 [SOA-RM]. OASIS has approved this
387standard reference model for describing different
388architectures using comparable, vendor-neutral language.
389Global is adopting the OASIS framework for describing its
390architecture and holding conversations with other domains.
40Justice Reference Architecture Specification Version 1.7
3911.4.Creating the JRA
392Itis important to note that SOA-RM provides a conceptual
393foundation not only for the justice community but also for any
394other domain to create a REFERENCE ARCHITECTURE. JRA builds on the
395SOA-RM concepts by specifying additional relationships and
396defining and specifying these adopted concepts.
397Although there is no perfect solution and since there is a need
398to start somewhere, SOA-RM is recommended as the best
399place to start Global’s SOA work efforts. Global began by
400mapping the SOA components, documenting, and leveraging
401the work that has been done already—like the Global JXDM—
402and finally, worked to identify and fill the gaps.
404 Justice Reference Architecture is derived from the OASIS Reference
405 Model for Service-Oriented Architecture 1.0. The OASIS work was
406 developed to provide a conceptual foundation for creating a reference
architecture. As intended by OASIS, the JRA builds on or expands
from the OASIS model.
Global is developing a modular architecture that
411clearly and appropriately identifies and separates technical
412and governance layers so that standards can be developed to
43Justice Reference Architecture Specification Version 1.7
4141.5.What Is the JRA?
415This section defines the JRA and explains why a reference
416architecture is useful. Keep in mind that there are many
417potential justice reference architectures but that the JRA
418focuses entirely on SOA for the justice and public safety
JRA is an abstract framework for understanding significant
421 components and the relationships between them within a Service-
422 Oriented Architecture. It lays out common concepts and definitions
423 as the foundation for the development of consistent SOA
implementations within the justice and public safety communities.
425The JRA is a description of the important concepts in a justice
426information sharing architecture and of the relationships
427between those concepts. The JRA also identifies, at a high
428level, the kinds of components (software systems, hardware
429infrastructure, policies, practices, intersystem connections,
430and so on) necessary to bring those concepts to life in a
431particular context. The JRA is generally not specific enough to
432govern the implementation of any individual software system
433implementation. Rather, it is a framework for guiding
434implementations in general, with the aim of standardizing or
435harmonizing certain key aspects of those implementations to
436support reusability or interoperability.
437Itis important to note that at this time, the JRA is not complete.
438Many sections of this document are still under development,
439but the document does attempt to identify the necessary
440concepts, relationships, and components that will require
441further elaboration and/or implementation.
4421.6.What the JRA Is Not
443The JRA is a reference architecture for information sharing
444and, as such, does not address the following:
445 • Detailed specifications for justice agencies’
446 operational systems (e.g., police records
447 management systems, court case management
46Justice Reference Architecture Specification Version 1.7
449 • Detailed specifications of information exchanges
450 or services
451 • Recommendations or standards for integration
452 infrastructure products
49Justice Reference Architecture Specification Version 1.7
453 2.Architecture Requirements
454 This section documents the business requirements to be
455 addressed and satisfied by the JRA. These requirements
456 are stated in the form of principles, the intent of which is to
457 guide and constrain the choices made in developing the
459Principle: Independence of Information Sharing Partners
460A reference architecture for justice information sharing should
461accommodate a large number of independent information
462sharing partners at the federal, state, local, and tribal levels of
465It is a plain fact that organizations responsible for functions in
466the criminal justice process are independent and autonomous
467from other organizations playing roles in that process. In
468general, it is not possible for one partner or set of partners to
469dictate to others how they conduct their business, what
470information systems they use, how they store information, and
472It is also true—especially at the state, regional, and national
473levels—that the number of partners that need to share
474information is large and growing. To make agreement on
475information sharing possible, it is necessary to reduce or
476eliminate the need to agree on how partners’ systems and
477business processes function and to move towards open
478industry standards instead of proprietary approaches.
479While partners may readily agree on the need to share
480information, their individual objectives and incentives for doing
481so may differ.
482Any information sharing architecture that does not
483accommodate these facts will face difficulty in its adoption and
484implementation by the community. Where adopted and
485implemented, an architecture that does not accommodate
486these facts will likely fail to scale to include the large number of
52Justice Reference Architecture Specification Version 1.7
488Note: This principle also summarizes the first two
489requirements for SOA established by the Global Infrastructure/
490Standards Working Group in its 2004 paper, A Framework for Justice
491Information Sharing: Service-Oriented Architecture [SOA-REC, pages 2–5].
493This principle implies the following about the JRA:
494 • The JRA should encourage the definition of
495 system interfaces that focus only on what system
496 functionality or information is to be shared, not on
497 how organizations design, deploy, or operate
498 their systems
499 • The JRA should encourage information sharing
500 mechanisms and approaches based on open
501 industry standards rather than on approaches
502 proprietary to one vendor, one domain, one level
503 of government, or one specific partner
504 • The JRA should identify issues on which justice
505 information sharing partners will typically need to
506 reach and enforce agreement, which conversely
507 will identify issues on which they can continue to
508 take independent approaches
510A reference architecture for justice information sharing should
511provide useful guidance to integrated justice enterprises of all
512sizes, from small operations with a few participants, to national
513processes that reach across local, state, tribal, federal, and
514even international boundaries.
516The national justice community consists of enterprises large
517and small, from the smallest rural county to the largest
518metropolitan areas and most populous states. To enable
519sharing of justice information within and among these
520jurisdictions, a consistent set of technical standards,
521guidelines, and infrastructure requirements is necessary. An
522information sharing architecture that addresses only one size
523of jurisdiction will fall short of the goal of fulfilling a truly national
55Justice Reference Architecture Specification Version 1.7
525In addition, experience and practical considerations indicate
526that information sharing architecture is most often
527implemented in an incremental fashion. Jurisdictions should be
528able to implement modest standards and infrastructure at first,
529with confidence that as their scope and capabilities grow,
530there will be minimal rework and reinvestment. This principle
531promotes an architecture that will satisfy the needs of an initial
532implementation and that will retain its relevance as the
534Note: This principle also summarizes the third requirement for
535SOA established by the Global Infrastructure/Standards
536Working Group [SOA-REC, pages 5–6].
538This principle implies the following about the JRA:
539 • The JRA should adopt a modular approach that
540 allows jurisdictions to implement a subset of the
541 full architecture, achieving some initial benefit
542 while retaining the option of adopting more of the
543 architecture later
544 • The JRA should encourage the adoption of
545 industry standards with a broad range of
546 implementations available in the marketplace,
547 from less expensive implementations with modest
548 capabilities, to larger investments that support an
549 increased volume of information sharing
550 • The JRA should encourage the clear description,
551 the straightforward discovery, and ultimately the
552 reuse of services across jurisdictions to provide
553 information more economically (particularly to
554 smaller jurisdictions)
555Principle: Diversity of Data Source Architectures
556A reference architecture for justice information sharing should
557accommodate data sources and partner systems that differ
558widely in software, hardware, structure, and design.
58Justice Reference Architecture Specification Version 1.7
560There is not now—nor will there be in the foreseeable future—a
561single solution or system for any particular domain within
562criminal justice. Because of the independence and autonomy
563of jurisdictions (and organizations within jurisdictions), it will in
564general be impossible for the sharing of justice information to
565rely on a single vendor system, application platform, or
566database. Even if it were possible to achieve, implementing a
567single vendor’s solution across all the partners within a
568jurisdiction introduces interdependencies that reduce agility
569and impede technical and policy innovation.
570In addition, today’s optimal choice of systems and platforms
571will likely be different than tomorrow’s. When a partner
572wishes to swap out old software or hardware for a new
573solution, that ought not to cause chaos for its information
575Note: This principle also summarizes the fourth requirement
576for SOA established by the Global Infrastructure/Standards
577Working Group [SOA-REC, page 6].
579This principle implies the following about the JRA:
580 • The JRA should encourage the sharing of
581 information and functionality between systems in
582 a way that minimizes the implementation
583 dependencies between them
584 • The JRA should encourage communication
585 between systems using open industry standards
586 rather than proprietary approaches
587 • The JRA should use vendor-neutral terminology
588 and concepts in defining the architecture
589 • The JRA should adopt a modular approach to
590 intersystem communication mechanisms and
591 protocols so that the entire architecture need not
592 change when improved protocols are developed
593 in the future
595A reference architecture for justice information sharing should
596accommodate changes in policy, information flow, and partner
61Justice Reference Architecture Specification Version 1.7
597system implementation without forcing investments or changes
598in unrelated systems or exchanges.
600While the events in the justice community that trigger
601information exchange remain fairly constant (arrests, bookings,
602charging decisions, case filing, disposition, supervision, etc.),
603the policy responses and the flow of information following
604these events are in constant change. This principle promotes
605an architecture that allows information sharing practitioners to
606respond to—and even to thrive in—this dynamic environment.
607Technologies within partner organizations change frequently as
608well. The days of purchasing a line of business system, such
609as a records system or a case management system, and
610leaving it untouched for years at a time are long past. New
611capabilities available from vendors and improvements in
612internal operations both compel a more rapid rate of change.
613This principle promotes an architecture that separates
614partners’ system implementations from one another, reducing
615the impact of change to one on the others.
616Note: This principle also reflects the sixth requirement for SOA
617established by the Global Infrastructure/Standards Working
618Group [SOA-REC, pages 7–8].
620This principle implies the following about the JRA:
621 • The JRA should encourage the sharing of
622 information and functionality between systems in
623 a way that minimizes the implementation
624 dependencies between them
625 • The JRA should encourage the definition of
626 system interfaces that reflect what the interfaces
627 do, as opposed to how they work
628 • The JRA should provide mechanisms to separate
629 the logic of information exchange (e.g., the
630 routing and transforming of messages that flow
631 between partners) from the logic of line-of-
632 business systems
64Justice Reference Architecture Specification Version 1.7
633Principle: Reuse and Sharing of Assets
634A reference architecture for justice information sharing should
635promote the use of existing system interfaces, information
636exchanges, and infrastructure to support new business
639Organizations responsible for criminal justice are, like many
640public sector organizations, being asked by citizens to do more
641with less. In addition, reusing system interfaces and
642information exchange implementations can improve
643consistency and reliability of information by having all
644information consumers draw from the same source. This
645principle reflects these factors by encouraging an architecture
646that supports reuse of interfaces and infrastructure.
648This principle implies the following about the JRA:
649 • The JRA should encourage the definition of
650 system interfaces that do not require usage in
651 particular contexts
652 • The JRA should provide mechanisms to separate
653 the logic of information exchange (e.g., the
654 routing and transforming of messages that flow
655 between partners) from the logic of line-of-
656 business systems
657Principle: Alignment With Best Practices and Experience
658A reference architecture for justice information sharing should
659reflect concepts and mechanisms that have proven viable in
660actual, real-world information exchange scenarios; the
661architecture should reflect the experiences of both public- and
662private-sector information exchange implementation projects.
664There is considerable experience, both in the private and
665public sectors, with implementing information sharing
666architecture. This principle encourages the JRA to help future
67Justice Reference Architecture Specification Version 1.7
667implementers avoid the pitfalls of the past, while adopting
668those practices that have proven effective.
669Note: This principle also reflects the fifth requirement for SOA
670established by the Global Infrastructure/Standards Working
671Group [SOA-REC, pages 6–7].
673This principle implies the following about the JRA:
674 • The JRA should base proposed standards and
675 infrastructure requirements on practices that
676 have proven effective
70Justice Reference Architecture Specification Version 1.7
678 3.The JRA
680The following diagram depicts the concepts, high-level
681components, and relationships in the JRA specification Version
6821.7. These elements are described in detail in the following
73Justice Reference Architecture Specification Version 1.7
can be supported by
Collaboration act as
Message Validators Intermediaries types of
Process Model Integration Patterns
provide Service Providers
Action Model provider systems
Capabilities Real-World Effects
leverage information contained in
Behavior Model provide access to seek
Services Service Consumers
contains defines semantics of
Service Model are composed of
can contain some
provide access to
constrain use of or
hosts Repository expected result
is described by of using
conform to, are assembled from
are aspects of Agreement
can be specified in
structure and content determined by
Reachability Policy and Contract can constrain
Interaction Service Interfaces
are the means of
accomplished by exchange of
guide design and Service Interaction
description of Profiles
define common rules of
describe ways of exchanging Message Exchange
define structure of
enables and determines essential aspects of
G lobal JRA version 1.5 Legend
May 1, 2007
Concepts from OASIS SOA-RM
Concepts particular to the JRA
76Justice Reference Architecture Specification Version 1.7
685 4.Concepts and Relationships
686The following sections describe the concepts, components,
687and relationships depicted in the diagram on the previous
689 OASIS Reference Model for Service-Oriented Architecture
690The JRA depicted in the diagram above (and defined in this
691document) adopts and builds on the OASIS SOA-RM.
692The SOA-RM defines its purpose as follows:
693 “A REFERENCE MODEL is an abstract framework for
694 understanding significant relationships among the
695 entities of some environment. It enables the
696 development of specific reference or concrete
697 architectures using consistent standards or
698 specifications supporting that environment. A
699 reference model consists of a minimal set of unifying
700 concepts, axioms and relationships within a
701 particular problem domain, and is independent of
702 specific standards, technologies, implementations,
703 or other concrete details.” [SOA-RM, p. 4]
704 “The goal of this reference model is to define the
705 essence of service-oriented architecture, and
706 emerge with a vocabulary and a common
707 understanding of SOA. It provides a normative
708 reference that remains relevant for SOA as an
709 abstract and powerful model, irrespective of the
710 various and inevitable technology evolutions that will
711 influence SOA deployment.” [SOA-RM, p. 4]
712While the SOA-RM is a powerful model that provides a vendor-
713neutral, open-standard definition of service-oriented
714architecture, its abstract nature means that further work must
715be done to create a reference architecture. This work should
716include the definition of specific standards and guidelines for
717information sharing and should define minimum requirements
718for infrastructure necessary to enable information sharing while
719supporting those standards and guidelines. It should do this in
79Justice Reference Architecture Specification Version 1.7
720a way that satisfies the goals and requirements of the
721enterprise creating the reference architecture.
722The JRA is just such a reference architecture, intended to
723satisfy the goals and requirements of justice information
724sharing by identifying specific standards, guidelines, and
725infrastructure requirements for any group of justice partners
726interested in sharing information among themselves.
727In the JRA diagram, OASIS SOA-RM concepts are shaded
728yellow. Concepts and components particular to the conceptual
729architecture defined by this document are shaded cyan.
730Relationships between concepts (indicated by arrows) are
731defined in the SOA-RM if the arrows connect concepts shaded
732yellow. Relationships between cyan-shaded concepts or
733between cyan-shaded and yellow-shaded concepts are
734particular to the JRA.
735The descriptions of SOA-RM concepts provided in the following
736sections are intended to be brief summaries; consequently,
737they omit certain details that appear in the SOA-RM. The SOA-
738RM itself is the primary source for full exposition of
739SOA-RM concepts and the relationships between them.
740 Core Concepts— Services, Service Consumers, Capabilities, and
741 Real-World Effects
742These four concepts make up the core of the JRA. All other concepts support these
744The JRA begins from the premise that a group of justice
745partners have CAPABILITIES that they provide to one another.
746These capabilities “solve or support a solution for the
747problems [businesses] face in the course of their business.”
748[SOA-RM, p. 8] That is, capabilities are the things organizations
749have to solve problems and therefore add value, directly or
750indirectly, to their stakeholders.
751Note that the JRA is generic enough to support virtually any
752kind of capability. However, the purpose of the JRA is to
753describe an approach to achieving interoperability among
754automated, computer software-based information systems.
755Therefore, the JRA considers only those business capabilities
82Justice Reference Architecture Specification Version 1.7
756thatare provided by information systems. The JRA calls these
757systems PROVIDER SYSTEMS.
758Each capability produces one or more REAL-WORLD EFFECTS, each of
759which is an outcome of the business value sought by one of
760the partners. A real-world effect can be either the obtaining of
761information, the changing of something of business relevance
762to the participating partners, or both. Because the JRA
763establishes that capabilities are implemented by provider
764systems, real-world effects consist of the functional business
765requirements of provider systems. That is, real-world effects
766in the JRA are essentially the information made available by
767provider systems or the outcomes resulting from business
768processes and workflows automated by provider systems, or
770In a service-oriented architecture, a SERVICE is the way in which
771one partner gains access to a capability offered by another
772partner. A partner that uses a service to gain access to
773another partner’s capability is called a SERVICE CONSUMER. As with
774capabilities, the architecture is generic enough to support
775virtually any kind of service consumer. However, since the
776purpose of the JRA is to describe an approach to information
777systems interoperability, the JRA narrows the SOA-RM
778definition of service consumer to information systems that
779interact with services directly through an interface that
780conforms to a service interaction profile (as defined below).
781The JRA calls such systems CONSUMER SYSTEMS.
782One of the most important features of the JRA is the
783separation of consumer systems from provider systems by
784services in the middle. This is the defining characteristic of a
785service-oriented architecture and is the key to minimizing the
786implementation dependencies between systems, which is
787identified as part of the rationale of several of the JRA
788principles listed above.
789The fact that information sharing is one kind of real-world
790effect allows the architecture to support the traditional view of
791system integration as “data exchange” or “information
792sharing.” The JRA improves this view by encouraging systems
793to share information in a way that minimizes the dependencies
794of each system on the implementation of other systems.
85Justice Reference Architecture Specification Version 1.7
795 Supporting Concepts
796Beyond the four core concepts of real-world effects,
797capabilities,services, and service consumers, the remainder of
798the concepts in the JRA deal with the following three important
800 • How consumers may find out that a service exists
801 • Once they find the service, how consumers may
802 understand what the service does and what
803 information flows in and out of it
804 • How a consumer may reach and interact or
805 communicate with the service
806The remaining concepts that address these concerns are
807called “supporting concepts” and are defined in this section.
808 Interaction, Visibility, Service Models, and Service Interfaces
809Servicesdefine what features of a provider system the system
810owner makes accessible to business partners. Services also
811provide a logical description of the information exchanged
812between consumer and provider systems as the consumer
813accesses the capability.
815The JRA refers to a consumer’s accessing the features of a
816capability through a service as INTERACTION, defined as “the
817performing [of] actions against a service.” [SOA-RM, p. 15]
818Service interaction generally involves the exchange of
819information between the consumer and the service.
820Interaction depends on two things. First, the designers of
821potential consumers need to be able to find services and, once
822found, establish a physical interaction mechanism with them.
823These needs are addressed by the concept of VISIBILITY. Second,
824the designers of potential consumers need a description of the
825actions that can be performed on a service, as well as the
826structure and meaning of information exchanged during the
827interaction. These needs are addressed by the concept of a
88Justice Reference Architecture Specification Version 1.7
828service’s INFORMATION MODEL and BEHAVIOR MODEL, collectively called
829SERVICE MODELS in the JRA.
as the name implies, defines how service consumers
832and the providers of capabilities “see” each other in a way
833that enables interaction between them. The JRA identifies
834three aspects of visibility.
835 • A service consumer must have information that
836 makes it aware of the existence of a service; the
837 possession of this information is called AWARENESS.
838 • The service (or capability accessed through the
839 service) must be willing to interact with the
840 consumer; this is called WILLINGNESS.
841 • The consumer and service must be able to
842 communicate with one another through some
843 kind of communication path or channel; the
844 existence of such a communication path is called
846In the JRA, a REPOSITORY will support awareness by hosting service
847models and service interfaces. “Hosting” in this context
848means storing models and interface descriptions in a central
849location that is accessible to appropriate stakeholders. A
850repository will permit searching for models and interface
851descriptions based on a range of identifying criteria. A
852repository will also map logical service identifiers with physical
853addresses. When a consumer wishes to communicate with a
854service (identified by a logical identifier), the consumer queries
855the repository for the physical address associated with the
856service’s logical identifier. This decouples the consumer from
857the physical location of a service at any point in time, thereby
858permitting the physical relocation of the service without
859affecting the implementation of the consumer.
860The concept of willingness is related to authorization and
861access control policies, in that a common reason for lack of
862willingness to interact is that the consumer is not authorized to
863conduct the requested interaction. Willingness often manifests
864in service descriptions, as well as policies, contracts, and
91Justice Reference Architecture Specification Version 1.7
865agreements (discussed on page 31). A SERVICE MODEL is defined as
866the information needed in order to use, or consider using, a
868The concept of reachability is closely related to the concept of
869execution context (discussed on page 31).
871Service models, consisting of a service’s behavior and
872information models, define the semantics of interaction with
874The behavior model of a service consists of two parts—the
875action model, which defines the operations available to
876consumers (in effect, what the service does) and the process
877model, which defines how consumers may invoke the
878service’s actions together or in sequence to accomplish some
879larger business process.
880The information model of a service describes the structure and
881meaning of data that consumers send to and receive from the
882service in the course of interaction.
883In general, service models will be described at conceptual and
884logical levels of detail. (Service models have a physical
885manifestation as well, in the form of the service interface
886discussed in the next section.) A conceptual description of a
887service model will typically describe, in prose text form, the
888capability to which the service provides access, a listing and
889brief textual description of each action, and a brief textual
890description of the information model (e.g., key information
891entities, key properties on those entities, and brief definitions).
892A logical description of a service model will describe the
893actions and information structures in detail but independent of
894any physical implementation mechanism. Often this
895description will be graphical and follow a standard
896diagramming or modeling technique, such as Uniform Modeling
931The OASIS SOA-RM term “process model” is consistent with the JRA
94definition given here; however, it is somewhat at odds with the popular
95notion of “Business Process Modeling,” which generally refers to
96documenting/modeling the interactions between many services or
97capabilities. The JRA remains consistent with the OASIS SOA-RM, but
98readers are cautioned not to confuse the two definitions of this term.
100Justice Reference Architecture Specification Version 1.7
898A MESSAGE is defined as the entire “package” of information sent
899between service consumer and service (or vice versa), even if
900there is a logical partitioning of the message into segments or
901sections. For instance, if an interface expresses actions as
902operations or functions that take arguments, and a particular
903operation has two arguments, both arguments would be
904considered part of the same message, even though they may
905be logically separated within the message structure. A
906message also includes the concept of an “attachment,” in
907which there are several additional sections (attachments) that
908relate to a distinct, “primary” section.
909In the JRA, the exchange of messages is the only way in which
910consumers and services can communicate. This establishes a
911linkage between the Federal Enterprise Architecture Data
912Reference Model (FEA DRM) and the JRA—a message in the
913JRA equates to an Information Exchange Package (IEP) in the
914FEA DRM. In the JRA, all service interaction is accomplished
915via message (information) exchange, and each message
916triggers the invocation of an action in the service’s action
918The concept of DOMAIN VOCABULARIES in the JRA includes canonical
919data models, data dictionaries, and markup languages that
920standardize the meaning and structure of information for a
921topical or business domain. Domain vocabularies can improve
922the interoperability between consumer and provider systems
923by providing a neutral, common basis for structuring and
924assigning semantic meaning to information exchanged as part
925of service interaction. Domain vocabularies can usually be
926extended to address information needs specific to the service
927interaction or to the business partners integrating their
929The information model for a service generally should be built
930from components in one or more domain vocabularies to
931promote semantic interoperability. In the justice domain, the
932information model for services should be built from
933components in the National Information Exchange Model
934(NIEM) when NIEM components exist that satisfy the semantic
935requirements of the model.
103Justice Reference Architecture Specification Version 1.7
936SERVICE DESIGN PRINCIPLES provide consistent guidance regarding the
937overall partitioning of capabilities into services and the
938relationships between services. For instance, service design
939principles may call for services to represent one concise, self-
940contained function and may also suggest that services should
941completely hide the implementation details of the capabilities
942to which they provide access.
943There is a wide variety of ways in which a service can provide
944access to a capability. In some cases, the provider system
945that implements the capability may already expose all or some
946of its functionality as services (through one or more service
947interfaces, described on page 25). In other cases, the
948business partner that provisions the capability can purchase an
949off-the-shelf adapter from the provider system vendor (or a
950third party) that exposes the system’s functionality as a set of
951services. Finally, the provider system may require
952reimplementation or custom adaptation to expose functionality
953as services. This is often expensive and risky, and the desire
954to avoid this situation should be addressed in the service
956In general, a given information system can be both a provider
957system and a consumer system. Similarly, a particular
958business organization may offer capabilities to its partners and,
959at the same time, be a consumer of the capabilities offered by
960others. This has important implications for how the
961organization should conceive and describe its information
962systems assets and how it assigns responsibilities for the
963maintenance and support of those assets. For example, in the
964past, it was common to think of systems as having “client”
965and “server” components (or “browser” and “server”
966components), which in turn influenced thinking about systems
967deployment, networking, security, support, and a range of
968other issues. These issues deserve reconsideration in an
969architecture in which a system or system component can be
970both a “client” (consumer of services) and a “server”
971(provider of services) at the same time. The discussion of
972service interaction on page 20, and the subsequent
973elaboration of interaction mechanisms in future iterations of the
974JRA, will reflect the impact of these issues.
1052Principles and guidelines are important components of the conceptual JRA;
106however, these principles and guidelines are not illustrated on the diagram
107because they will exist for most of the components.
109Justice Reference Architecture Specification Version 1.7
975Note that the concept of a service in the JRA does not equate
976to a Web service. The term “Web services” is a label for a
977family of standards and an associated technical approach to
978communicating between service consumers and services. The
979architecture supports flexibility in how this communication
980happens through the notion of service interaction profiles
981(discussed on page 27). A Web service profile has been
982developed for the Web services family of standards; however,
983the JRA will include additional profiles that adopt other
984communication mechanisms, such as MQ, JMS, and ebXML.
985[WSSIP AND ebXMLSIP]
986As previously stated, a repository should contain service model
987description artifacts for each level of detail. The availability of
988service model descriptions to consumer system designers,
989implementers, and purchasers is a key factor in establishing
990visibility and the reuse of services.
992Service models describe the actions available from a service
993and the information exchanged between a consumer and the
994service during the performance of those actions. In this way,
995the service models describe the “what” of interaction.
996A SERVICE INTERFACE “is the means for interacting with a service. It
997includesthe specific protocols, commands, and information
998exchange by which actions are initiated [on the service].” [SOA-
999RM, p. 22] A service interface is what a system designer or
1000implementer (programmer) uses to design or build executable
1001software that interacts with the service. That is, the service
1002interface represents the “how” of interaction.
1003In many cases, the capability to which a service provides
1004access is some kind of information system. The JRA calls such
1005a system a provider system, as discussed above on page 15.
1006However, in general, a provider system will not conform to or
1007satisfy the constraints imposed by the service interface
1008through which consumers access the capability. A software
1009component called an ADAPTER is required to transform
1010interactions with the provider system into interactions that
1011conform to the service interface. Depending on the type of
1012provider system, adapters may be available from the system
112Justice Reference Architecture Specification Version 1.7
1013vendor or a different vendor; in other cases, the service
1014provider may need to build a custom adapter.
1015The JRA considers the service interface to be the physical
1016manifestation of the service models. Best practices call for a
1017service interface to be described in an open-standard,
1018referenceable format (that is, a format whose contents are
1019capable of automated processing by a computer).
1020Many service interaction profiles use the term “endpoint” or
1021“endpoint interface” to refer to the physical point that
1022receives a message sent by a consumer. There is a one-to-
1023one correspondence between a service interface and an
1024endpoint interface, and the JRA considers the two terms to be
1026A given service may have multiple interfaces that conform to
1027the same service interaction profile, where the multiple
1028interfaces expose different sets of the service’s actions. For
1029instance, a service may have one “query” action and three
1030“update” actions; the query action may be exposed by one
1031Web services interface, while the three update actions may be
1032exposed by a separate Web services interface. These
1033interfaces would reside at separate endpoints.
1034Note that at least some policies and contracts can be
1035described in a service’s interface.
1036The format, structure, and allowable contents of a service
1037interface are established by INTERFACE DESCRIPTION REQUIREMENTS,
1038described in the following section.
1039 Design and Description of Service Interfaces
1040The JRA identifies four architectural elements that guide the
1041design and description of service interfaces.
1042SERVICE INTERACTION REQUIREMENTS define common rules of service
1043interaction. Typically, these requirements are not directly
1044related to the capability used by the service consumer, nor are
1045they related to the real-world effect resulting from use of that
1046capability. Rather, the requirements enforce (or support the
1047enforcement of) policies or contracts or otherwise protect the
1048interests of particular business partners or the business
115Justice Reference Architecture Specification Version 1.7
1050Common service interaction requirements address areas such
1051as security, reliability, and availability. An initial elaboration of
1052service interaction requirements appears on page 29.
1053INTERFACE DESCRIPTION REQUIREMENTS establish common characteristics of
1054service interface descriptions. These requirements address
1055areas such as required interface contents, naming rules,
1056documentation rules, and specification of a standard structure
1057and format for descriptions.
1058MESSAGE EXCHANGE PATTERNS identify common sequences of message
1059transmission between service consumers and services. They
1060providea label to a series of message transmissions that have
1061some logical interrelationship.
1062MESSAGE DEFINITION MECHANISMS are closely related to interface
1063description requirements, described above. Unlike interface
1064description requirements, message definition mechanisms
1065establish a standard way of defining the structure and contents
1066of a message. Note that since a message includes the
1067concept of an “attachment,” the message definition
1068mechanism must identify how different sections of a message
1069(for example, the main section and any attachment sections)
1070are separated and identified and how attachment sections are
1071structured and formatted.
1072Service Interaction Profiles
1073A SERVICE INTERACTION PROFILE defines a family of industry standards or
1074other technologies or techniques that together demonstrate
1075implementation or satisfaction of:
1076 • Service interaction requirements
1077 • Interface description requirements
1078 • Message exchange patterns
1079 • Message definition mechanisms
1080Service interaction profiles are included in the JRA to promote
1081interoperability without forcing the organization to agree on a
1082single way of enabling service interaction. Each service
1083interface will support a single profile; a service will have
1084multiple interfaces if it supports multiple profiles. By supporting
1085a profile, an interface establishes the mode of interoperation it
118Justice Reference Architecture Specification Version 1.7
1086allows from service consumers; any consumer that also
1087supports that profile can “reach” the service.
1088The JRA explicitly recognizes that a service interaction profile
1089may be further constrained by an implementer to require
1090specific techniques, technologies, or mechanisms, as long as
1091the additional constraints remain consistent with the original
1093 Capabilities in Detail
1094The JRA identifies several types of capabilities to assist
1095decision makers in understanding where certain capabilities
1096should be deployed in the organization and what relationships
1097they may have to other capabilities and services.
1099An INTERMEDIARY is any capability that receives messages from a
1100consumer and subsequently, as a service consumer itself,
1101interacts with another service. The term “intermediary”
1102indicates that these capabilities sit between other services and
1103“mediate” the interaction by managing, controlling, brokering,
1104or facilitating the transmission of messages between them. An
1105intermediary is the mechanism by which the JRA separates the
1106logic of integration from the logic of line-of-business systems,
1107which is a key feature of SOA.
1108The JRA identifies five types of intermediary but recognizes
1109that other types are possible. The five identified types are
1110orchestrations, routers, message validators, transformers, and
1112An ORCHESTRATION is a capability that coordinates interaction with
1113multiple services. It is a declarative technique used to
1114compose hierarchical and self-contained service-oriented
1115business processes that are executed and coordinated by a
1116single conductor [SOA-RA, p. 69]. An orchestration is often
1117implemented using an open industry standard implementation
1118mechanism such as Business Process Execution Language
1119(BPEL) that allows the implementation to be shared across
1120tools and platforms.
121Justice Reference Architecture Specification Version 1.7
1121It is often possible to design and model orchestrations using a
1122graphical approach, in which the implementer diagrams
1123business processes and work flows, the steps of which are
1124services that already exist. After the diagram is complete, the
1125implementer generates a standards-based artifact that is
1126deployed into a software component that exposes the work
1127flow as a service through a service interface. The promise of
1128this approach is that less technical implementers with greater
1129business expertise can be responsible for the implementation
1130of orchestrated capabilities.
1131Note that the execution of the steps described in a business
1132process model can be considered a capability in and of itself.
1133In addition, each of the steps in a business process model can
1134unfold into yet another business process model at a more
1135focused level of detail. In this way, each step in a series of
1136service interactions can itself be a series of service
1137interactions. And, in theory, this recursion of models can go on
1138forever, though in practice it rarely exceeds three or four levels
1139of containment. So, services and capabilities form a hierarchy,
1140where a service provides access to a capability whose real-
1141world effect is to accomplish the coordination of multiple
1142services at a lower level of detail.
1143As a side effect, each of the steps in a business process model
1144provides a contextual justification for service interaction
1145between a particular consumer and a particular provider. It is
1146often useful to capture this information in a taxonomy to
1147promote a better understanding of where services are being
1148used and to add value.
1149Note that an orchestration is different from a choreography, in
1150that a choreography is a description of how a group of
1151business peers coordinate a service-oriented business
1152process without the direction of a controller.
1153ROUTERS are capabilities that receive a message, examine it, and
1154transmit it to one or more destinations based on the contents.
1155In general, routers can be designed to operate on any of the
1156information contained within the message; they may use
1157information about the origin of the message, routing directive
1158information contained within the message or the main content
1159of the message itself.
124Justice Reference Architecture Specification Version 1.7
1160TRANSFORMERS are capabilities that receive a message and
1161transform it into another format before transmitting it to
1163MESSAGE VALIDATORS are capabilities that examine a message to
1164ensure that the contents adhere to established business rules.
1165INTERCEPTORS are capabilities that receive a message and use the
1166message content to trigger a secondary action; generally, the
1167interceptors pass the message unaltered to the next step in a
1168process. Most interceptors capture information from the
1169message for reporting or analytical purposes.
1170Routers and transformers are useful mechanisms for
1171decoupling the senders and recipients of messages. They
1172tend to centralize and share certain kinds of logic so that the
1173logic can be maintained independently of the provider and
1174consumer capabilities at the edges; sharing also improves the
1175likelihood of reuse, since it is easier to reuse functionality if it
1176encapsulates a single task.
1177Support for router, transformer, and collaboration capabilities
1178isa common feature in many integration platforms; therefore,
1179support for these capabilities is a consideration in choice of
1180execution context (discussed on page 25).
1181Routing, transformation, and collaboration capabilities are well
1182understood and well documented in the integration
1183architecture literature. The most common flavors of these
1184capabilities have been collected into pattern form as ENTERPRISE
1185INTEGRATION PATTERNS. [PATTERNS] The JRA incorporates these patterns
1187Intermediaries are a key component in implementing business
1188process models and also lead to the formation of
1263The concept of interceptor defined here is similar to, but separate and
127distinct from, the notion of an interceptor as defined in the SOAP protocol
128[reference needed to SOAP standard]. The definition of this concept in JRA
129is not intended to imply any implementation technique or technology.
131Justice Reference Architecture Specification Version 1.7
1190 Service Policy, Service Contract, and Service Agreement
1191SERVICE POLICIES and SERVICE CONTRACTS express rules that govern the
1192interaction between a service consumer and a service. A
1193policy is an assertion by either a consumer or a service
1194provider of that participant’s requirements for willingness to
1195interact. A policy also has an enforcement aspect and must be
1196stated in such a way as to permit enforcement. A SERVICE CONTRACT
1197is an agreement by the parties involved, and there is a process
1198associated with the agreement action. Whereas a policy is an
1199assertion by one participant in the interaction, a contract is an
1200agreement between the participants that expresses some
1201expectation or requirement of the interaction. And whereas
1202policy enforcement is generally the responsibility of the
1203participant who asserts the policy, contract enforcement may
1204involve resolution of disputes that arise between the parties.
1205A SERVICE AGREEMENT is a document that establishes policies and
1206contractual elements for a given interaction or set of
1207interactions (that is, for one or more services).
1208 Execution Context
1209EXECUTION CONTEXT is “the set of infrastructure elements, process
1210entities, policy assertions, and agreements that are identified
1211as part of an instantiated service interaction.” [SOA-RM, p. 24]
1212Execution context is the primary enabler of the reachability
1213aspect of visibility. Execution context includes the set of
1214infrastructure elements that provide a physical communication
1215path between service consumers and services.
1216The JRA considers execution context to be primarily the
1217supporting infrastructure elements that permit service
1218consumers and services to interact. These infrastructure
1219elements consist of:
1220 • Data networks used by service consumers and
1221 services to exchange information.
1222 • Integration infrastructure (hardware and
1223 software) that makes service interfaces available
1224 and handles higher-level message routing,
1225 transformation, and collaboration.
134Justice Reference Architecture Specification Version 1.7
1226 • Infrastructure technology to support service
1227 interaction; examples include access control,
1228 policy decision-making and enforcement, public
1229 key infrastructure (PKI), and metering.
1230Execution context can implement (or support the
1231implementation of) some service interaction requirements,
1232such as reliability and availability. Service interaction profiles,
1233contracts, and policies can constrain the behavior of execution
1234context elements by requiring particular technologies or
1235techniques or establishing service level policies, for example.
1236Finally,execution context can support intermediary capabilities
1237(as defined above) directly in the integration infrastructure.
1238 Provisioning Model
1239A PROVISIONING MODEL determines the organizational (perhaps
1240contractual or legal) responsibility for providing a capability, via
1241services, to achieve consumers’ desired real-world effect.
1242The entity identified in a provisioning model as responsible for
1243providing a capability is called a SERVICE PROVIDER.
137Justice Reference Architecture Specification Version 1.7
1244 5.Reconciliation of Architecture With Principles
1245The JRA seeks to support and encourage the set of principles
1246identified earlier in this document.
1247Principle: Independence of Information Sharing Partners
1248Principle: Diversity of Data Source Architectures
1250These three principles are all interrelated. What ties them
1251together is the notion that in the justice business domain,
1252partners who exchange information and collaborate in
1253business processes must remain autonomous, separately
1254governed organizations. They must retain the ability to
1255establish policy and practice in their own organizations, while
1256at the same time establishing common policy and practice for
1257the common enterprise in which they all participate. They will
1258maintain different information systems from different vendors
1259(in some cases, building critical systems in-house); these
1260systems will be written in diverse programming languages and
1261will leverage diverse database management systems and
1262application servers. An architecture that required uniformity in
1263these areas would be doomed to failure.
1264To maintain this autonomy and yet be effective, partners must
1265adopt an architecture that gives them agility, or the ability to be
1266responsive to changing circumstances. These circumstances
1267could involve the factors just mentioned—changing internal
1268policies, changing system vendors, or changing technologies.
1269But the circumstances could originate from external forces
1270that affect all participants equally—changes in citizen needs
1271and expectations, changes in legislation, changing
1272requirements for sharing information with federal partners, and
1273so on. The architecture must support a responsive, flexible
1274approach to information sharing between partners.
1275The JRA promotes business agility in those organizations that
1276adopt it by encouraging systems, agencies, information
1277exchanges, and business process to have minimal
1278dependencies on one another. It accomplishes this in several
140Justice Reference Architecture Specification Version 1.7
1280 • It encourages the conceptualization of information
1281 exchanges as actions on services, which
1282 introduce a layer between systems that exchange
1283 information. This allows one agency to change
1284 anything about its internal operations and system
1285 behavior without disrupting partners’
1286 businesses. This in turn increases the rate at
1287 which partners can change, which is agility.
1288 • It introduces a service identification methodology
1289 (in a separate document) that establishes
1290 principles and techniques for service design that
1291 minimize the dependency of one service on
1293 • It introduces the concept of a service interaction
1294 profile, which encourages justice partners to
1295 adopt standards-based, vendor-neutral
1296 approaches to the transmission and encoding of
1297 information between agencies.
1298Principle: Reuse and Sharing of Assets
1299TheJRA encourages the reuse and sharing of assets in several
1301 • It introduces as one of its core concepts the
1302 notion of visibility for services. The concept of
1303 visibility recognizes that potential consumers
1304 must be aware of the existence of services and,
1305 once aware of them, must have clear
1306 documentation regarding how to access them.
1307 • It includes service modeling guidelines, which
1308 establish clear, consistent rules for the
1309 information contained in a service description and
1310 how that information must be presented so that
1311 potential consumers understand what the service
1312 does and how to interact with it.
1313 • It introduces the concept of execution context
1314 and guidelines for how to share execution context
1315 infrastructure across a group of partners. Thus,
1316 instead of each project or pair of partners
1317 provisioning its own infrastructure, partners share
143Justice Reference Architecture Specification Version 1.7
1318 common infrastructure elements where it is
1319 possible to do so.
1320 • It introduces, as part of shared execution context,
1321 registries and repositories that store service
1322 descriptions and support searches that allow
1323 potential consumers to find the services they
1324 need quickly. The easier it is for consumers to
1325 find services, the more likely they are to reuse
1328The conceptual framework, standards, and guidelines within
1329the JRA apply to enterprises of varying sizes, from pairs of
1330partners with a handful of exchanges to large, multiagency
1331efforts with dozens of exchanges, to a national environment
1332with potentially hundreds of participants and thousands of
1334Itis possible to implement basic components of the JRA, such
1335as the conceptual framework, service interaction profiles,
1336service identification methodology, and service modeling
1337guidelines, without significant investments in infrastructure
1338(middleware, registries, etc.) Enterprises with a few services
1339representing point-to-point information exchanges can often
1340move forward with infrastructure already in place.
1341At the same time, the guidelines and standards in the JRA are
1342well-aligned with industry direction and product offerings, so
1343larger enterprises can also leverage the same standards within
1344the enhanced capabilities of sophisticated infrastructure.
1345Principle: Alignment With Best Practices and Experience
1346The JRA aligns with best practices and the experiences of
1347innovative organizations in the following ways:
1348 • It has been developed by a group of practitioners
1349 and technologists from the public sector, national
1350 associations, and industry who have gained
1351 experience working with service-oriented
1352 architecture. It is the result of this group of
1353 experienced individuals collaborating and
146Justice Reference Architecture Specification Version 1.7
1354 consolidating the lessons learned from SOA
1355 implementation projects.
1356 • It leverages accepted standards that have been
1357 developed by industry standards bodies,
1358 representing a diversity of technologies and
1359 vendors. The conceptual framework is based on
1360 (and conforms to) the OASIS SOA-RM. Individual
1361 JRA deliverables, such as service interaction
1362 profiles and service modeling guidelines, further
1363 leverage open industry standards such as the
1364 Web services stack and UML.
1365 • It builds on and provides linkages between
1366 national justice community standards such as
1367 NIEM, GFIPM, security, privacy guidelines, etc.
149Justice Reference Architecture Specification Version 1.7
1368 6.Elaboration of Service Interaction Requirements
1369The following is an initial list of candidate service interaction
1370requirements. Note that when these requirements refer to
1371SERVICE CONSUMER, this is not a human being but an information
1372system that interacts with a service. This is consistent with the
1373JRA usage of the term, as defined on page 15.
1374 • Service Consumer Authentication: Information provided
1375 with messages transmitted from service
1376 consumer to service that verifies the identity of
1377 the consumer.
1378 • Service Consumer Authorization: Information provided
1379 with messages transmitted from service
1380 consumer to service that documents the
1381 consumer’s authorization to perform certain
1382 actions on and/or access certain information via
1383 the service.
1384 • Identity and Attribute Assertion Transmission: Information
1385 provided with messages transmitted from service
1386 consumer to service that asserts the validity of
1387 information about a human or machine, including
1388 its identity.
1389 • Service Authentication: The ability of a service to
1390 provide a consumer with information that
1391 demonstrates the service’s identity to the
1392 consumer’s satisfaction.
1393 • Message Nonrepudiation: Information provided in a
1394 message to allow the recipient to prove that a
1395 particular authorized sender in fact sent the
1397 • Message Integrity: Information provided in a message
1398 to allow the recipient to verify that the message
1399 has not changed since it left the control of the
1401 • Message Confidentiality: Information provided in a
1402 message to prevent anyone except an authorized
1403 recipient from reading the message or parts of
1404 the message.
152Justice Reference Architecture Specification Version 1.7
1405 • Message Addressing: Information provided in a
1406 message that indicates where a message
1407 originated, the ultimate destination of the
1408 message (beyond physical end point), a specific
1409 recipient to whom the message should be
1410 delivered (this includes sophisticated metadata
1411 designed specifically to support routing), and a
1412 specific address or entity to which reply
1413 messages (if any) should be sent.
1414 • Reliability: Information provided with messages to
1415 permit message senders to receive notification of
1416 the success or failure of message transmissions
1417 and to permit messages sent with specific
1418 sequence-related rules either to arrive as
1419 intended or fail as a group.
1420 • Transaction Support: Information provided with
1421 messages to permit a sequence of messages to
1422 be treated as an atomic transaction by the
1424 • Service Metadata Availability: The ability of a service to
1425 capture and make available (via query) metadata
1426 about the service. Metadata is information that
1427 describes or categorizes the service and often
1428 assists consumers in interacting with the service
1429 in some way.
155Justice Reference Architecture Specification Version 1.7
1432 A set of artifacts (that is: principles, guidelines, policies,
1433 models, standards, and processes) and the relationships
1434 between these artifacts that guide the selection, creation,
1435 and implementation of solutions aligned with business
1438 A state whereby one party has knowledge of the
1439 existence of the other party. Awareness does not imply
1440 willingness or reachability.
1442 The characterization of, and responses to, temporal
1443 dependencies between the actions on a service.
1444Business Process Models
1445 A description (usually formal and often graphical) of a
1446 series of activities that culminate in the achievement of
1447 some outcome of business value. Some (but not
1448 necessarily all) of the steps in this series of activities
1449 involve producing a real-world effect provided by a
1450 capability, and some of the steps require a consumer to
1451 use a service. Each one of these steps, then, provides
1452 the contextual justification for service interaction between
1453 a particular consumer and a particular provider.
1455 Real-world effect(s) that service provider(s) are able to
1456 provide to a service consumer.
1458 A capability that coordinates interaction with multiple
1459 services. A collaboration is often implemented using an
1460 open industry standard implementation mechanism,
1461 which allows the implementation to be shared across
1462 tools and platforms.
158Justice Reference Architecture Specification Version 1.7
1464 The information system that gains access to another
1465 partner’s capability offered by means of a service.
1467 Includes canonical data models, data dictionaries, and
1468 markup languages that standardize the meaning and
1469 structure of information for a domain. Domain
1470 vocabularies can improve the interoperability between
1471 consumer and provider systems by providing a neutral,
1472 common basis for structuring and assigning semantic
1473 meaning to information exchanged as part of service
1474 interaction. Domain vocabularies can usually be
1475 extended to address information needs specific to the
1476 service interaction or to the business partners integrating
1477 their systems.
1478Enterprise Integration Patterns
1479 Enterprise integration has to deal with connecting multiple
1480 applications running on multiple platforms in different
1481 locations. Enterprise integration patterns help integration
1482 architects and developers design and implement
1483 integration solutions more rapidly and reliably. Most of
1484 the patterns assume a basic familiarity with messaging
1485 architectures. However, the patterns are not tied to a
1486 specific implementation.
1488 The set of technical and business elements that form a
1489 path between those with needs and those with
1490 capabilities and that permit service providers and
1491 consumers to interact.
1493 A set of assumptions, concepts, values, and practices
1494 that constitutes a way of viewing the current
1497 The characterization of the information that is associated
1498 with the use of a service. The scope of the information
1499 model includes the format of information that is
1500 exchanged, the structural relationships within the
1501 exchanged information, and the definition of terms used.
161Justice Reference Architecture Specification Version 1.7
1503 The activity involved in making use of a capability offered,
1504 usually across an ownership boundary, to achieve a
1505 particular desired real-world effect.
1506Interface Description Requirements
1507 Establishes common characteristics of service interface
1508 descriptions. These requirements address areas such as
1509 required interface contents, naming rules, documentation
1510 rules, and specification of a standard structure and
1511 format for descriptions.
1513 Interceptors are capabilities that receive a message and
1514 use the message content to trigger a secondary action;
1515 generally, the interceptors pass the message unaltered
1516 to the next step in a process.
1518 Routers and transformers are collectively called
1519 intermediaries. This term indicates that routers and
1520 transformers generally sit between other services and
1521 “mediate” the interaction by managing the transmission
1522 of messages between them or by reformatting messages
1523 in transit.
1524Justice Reference Architecture
1525 The JRA is an abstract framework for understanding
1526 significant components and relationships between them
1527 within a service-oriented environment. It lays out
1528 common concepts and definitions as the foundation for
1529 the development of consistent service-oriented
1530 architecture (SOA) implementations within the justice and
1531 public safety communities. The term refers to the
1532 modular architecture that clearly and appropriately
1533 identifies and separates technical and governance layers
1534 so that standards can be developed to improve
1535 interoperability. The JRA is being developed by Global; it
1536 leverages the work of others, such as the state of
1537 Washington, and builds upon the work of OASIS.
164Justice Reference Architecture Specification Version 1.7
1539 The entire “package” of information sent between
1540 service consumer and service (or vice versa), even if
1541 there is a logical partitioning of the message into
1542 segments or sections.
1543Message Definition Mechanisms
1544 Establishes a standard way of defining the structure and
1545 contents of a message; for example, Global JXDM- or
1546 NIEM-conformant schema sets. Note that since a
1547 message includes the concept of an “attachment,” the
1548 message definition mechanism must identify how
1549 different sections of a message (for example, the main
1550 section and any attachment sections) are separated and
1551 identified and how attachment sections are structured
1552 and formatted.
1553Message Exchange Patterns
1554 Identifies common sequences of message transmission
1555 between service consumers and services. They provide
1556 a label to a series of message transmissions that have
1557 some logical interrelationship.
1559 An intermediary that examines a message to ensure that
1560 the contents adhere to established business rules.
1562 A capability that coordinates interaction with multiple
1563 services. It is a declarative technique used to compose
1564 hierarchical and self-contained service-oriented business
1565 processes that are executed and coordinated by a single
1569 The characterization of the temporal relationships
1570 between and temporal properties of actions and events
1571 associated with interacting with the service.
1573 The information system that offers the use of capabilities
1574 by means of a service.
167Justice Reference Architecture Specification Version 1.7
1576 The responsibility/models for making a service available
1577 to customers in a manner consistent with formal (or
1578 occasionally informal) customer expectations.
1580 The ability of a service consumer and a service provider
1581 to interact. Reachability is an aspect of visibility.
1583 The actual result(s) of using a service, rather than merely
1584 the capability offered by a service provider.
1586 A reference architecture is an architectural design
1587 pattern that indicates how an abstract set of mechanisms
1588 and relationships realizes a predetermined set of
1591 A reference model is an abstract framework for
1592 understanding significant relationships among the entities
1593 of some environment that enables the development of
1594 specific reference or concrete architectures using
1595 consistent standards or specifications supporting that
1597 A reference model consists of a minimal set of unifying
1598 concepts, axioms, and relationships within a particular
1599 problem domain and is independent of specific
1600 standards, technologies, implementations, or other
1601 concrete details.
1603 Stores models and interface descriptions in a central
1604 location that is accessible to appropriate stakeholders. A
1605 repository will permit searching for models and interface
1606 descriptions based on a range of identifying criteria. A
1607 repository will also map logical service identifiers with
1608 physical addresses.
170Justice Reference Architecture Specification Version 1.7
1610 A capability that receives a message, examines it, and
1611 transmits it to one or more destinations based on the
1612 contents. In general, routers can be designed to operate
1613 on any of the information contained within the message;
1614 they may use information about the origin of the
1615 message, routing directive information contained within
1616 the message or the main content of the message itself.
1618 The means by which the needs of a consumer are
1619 brought together with the capabilities of a provider.
1621 A document that establishes policies and contractual
1622 elements for a given interaction or set of interactions
1623 (that is, for one or more services).
1625 An entity that seeks to satisfy a particular need through
1626 the use of capabilities offered by means of a service.
1628 An agreement by two or more parties regarding the
1629 conditions of use of a service.
1630Service Design Principles
1631 The documentation to provide consistent guidance
1632 regarding the overall partitioning of capabilities into
1633 services and the relationships between services.
1634Service Interaction Profiles
1635 Defines a family of industry standards or other
1636 technologies or techniques that together demonstrate
1637 implementation or satisfaction of:
1638 o Service interaction requirements
1639 o Interface description requirements
1640 o Message exchange patterns
1641 o Message definition mechanisms
1642 Service interaction profiles are included in the JRA to
1643 promote interoperability without forcing the organization
1644 to agree on a single way of enabling service interaction.
1645 Each service interface will support a single profile; a
173Justice Reference Architecture Specification Version 1.7
1646 service will have multiple interfaces if it supports multiple
1648Service Interaction Requirements
1649 Define common rules of service interaction. Typically,
1650 these requirements are nonfunctional in nature in that
1651 they are neither directly related to the capability used by
1652 the service consumer nor related to the real-world effect
1653 resulting from use of that capability. Rather, the
1654 requirements enforce (or support the enforcement of)
1655 policies or contracts or otherwise protect the interests of
1656 particular business partners or the business organization
1659 The means by which the underlying capabilities of a
1660 service are accessed.
1662 Interaction depends on two things. First, the designers of
1663 potential consumers need to be able to find services and,
1664 once found, establish a physical interaction mechanism
1665 with them. Second, the designers of potential consumers
1666 need a description of the actions that can be performed
1667 on a service, as well as the structure and meaning of
1668 information exchanged during the interaction. These
1669 needs are addressed by the concept of a service’s
1670 information model and behavioral model, collectively
1671 called service models in the JRA.
1672Service-Oriented Architecture (SOA)
1673 Service-Oriented Architecture is a paradigm for
1674 organizing and utilizing distributed capabilities that may
1675 be under the control of different ownership domains. It
1676 provides a uniform means to offer, discover, interact with,
1677 and use capabilities to produce desired effects
1678 consistent with measurable preconditions and
1681 A statement of obligations, constraints, or other
1682 conditions of use, deployment, or description of an
1683 owned entity as defined by any participant.
176Justice Reference Architecture Specification Version 1.7
1685 An entity (person or organization) that offers the use of
1686 capabilities by means of a service.
1688 A capability that receives a message and transforms it
1689 into another format before transmitting it on to another
1692 The capacity for those with needs and those with
1693 capabilities to be able to interact with each other.
1695 A predisposition of service providers and consumers to
179Justice Reference Architecture Specification Version 1.7
1699ebXMLSIP GISWG. The JRA ebXML Messaging Service
1700 Interaction Profile Version 1.0, October 1, 2007.
1703Erl Erl, Thomas. Service-Oriented Architecture: Concepts,
1704 Technology, and Design. Prentice-Hall, 2005.
1705GISWG GISWG. A Framework for Justice Information Sharing:
1706 Service-Oriented Architecture. Global, December 9,
1708JRA GISWG. http://it.ojp.gov/globaljra.
1709Patterns Hohpe, Gregor, and Woolf, Bobby. Enterprise
1710 Integration Patterns: Designing, Building, and Deploying
1711 Messaging Solutions. Addison Wesley, 2004. http://
1713Sholler Sholler, Daniel. Demystifying Service-Oriented Architecture,
1714 META Practice, June 9, 2004.
1715SOA-RA Reference Architecture for Service-Oriented Architecture 1.0, Public
1716 Review Draft 1. OASIS, April 23, 2008.
1719SOA-REC GISWG. A Framework for Justice Information Sharing:
1720 Service-Oriented Architecture. Global, December 9,
1724SOA-RM Reference Model for Service-Oriented Architecture 1.0, Oasis
1725 Standard. OASIS, October 12, 2006.
182Justice Reference Architecture Specification Version 1.7
1728WSSIP GISWG. The Global JRA Web Services Service
1729 Interaction Profile Version 1.1, August 1, 2007.
185Justice Reference Architecture Specification Version 1.7
1733 9.Document History
Date Versio Editor Change
March 25, 1.0 Scott Came Initial draft.
March 28, 1.0 Tish Editorial changes and
2006 Cunningham IIR Quality Control.
May 1, 2006 1.1 Monique La Integrated comments
Bare from EAC, glossary,
edited page numbers.
June 1, 2006 1.1 Tom Clarke Elaboration of
June 28, 2006 1.1 Reordered elaboration
of concepts, added
November 2, 1.2 Scott Came Consistency edits.
2006 Edits resulting from
of Iveta Topalova and
December 6, 1.3 Kim Geer Formatting.
2006 Dolores Editorial changes and
Parker IIR Quality Control.
February 14, 1.4 Scott Came EAC revisions.
188Justice Reference Architecture Specification Version 1.7
Date Versio Editor Change
February 11, 1.6 Scott Came EAC revisions.
July 6, 2008 1.7 Scott Came Added concepts of
candid relationships between
ate actions, messages,
models of a service.
October 30, 1.7 Monique La Verified references,
2008 candid Bare added service
November 18, 1.7 Scott Came New service interface
2008 language; Executive