source .DOC
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

source .DOC

on

  • 434 views

 

Statistics

Views

Total Views
434
Views on SlideShare
434
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

source .DOC Document Transcript

  • 1. 1 2 3 4 5 6 7 8 The Justice Reference 9 Architecture (JRA) 10 Specification 11 12 13 Working Draft V 1.3 14 15 by 16 The Global Infrastructure/Standards 17 Working Group 18
  • 2. 1Justice Reference Architecture DRAFT 2 19 20 21 December 4, 2006 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 3 4 2
  • 3. 5Justice Reference Architecture DRAFT 6 55 56 7 8 3
  • 4. 9Justice Reference Architecture DRAFT 10 57 Table of Contents 58 59Table of Contents.......................................................................... 60 The Justice Reference Architecture (JRA) ....................................................................................1 61 Specification..................................................................................................................................1 62 Working Draft V 1.3.......................................................................................................................1 63 by...................................................................................................................................................1 64 The Global Infrastructure/Standards Working Group.....................................................................1 65 Table of Contents..........................................................................................................................4 66 Acknowledgements........................................................................................................................7 67 The Justice Reference Architecture (JRA) was developed through a collaborative effort of the 68Global Justice Information Sharing Initiative (Global), Office of Justice Programs (OJP), U.S. 69Department of Justice (DOJ)..........................................................................................................7 70 Global aids its member organizations and the people they serve through a series of important 71initiatives. These include the facilitation of Global Working Groups. The Global 72Infrastructure/Standards Working Group (GISWG) is one of four Global Working Groups covering 73critical topics such as intelligence, privacy, security, and standards. The GISWG is under the 74direction of Tom Clarke, Ph.D., National Center for State Courts. The GISWG consists of three 75committees: Management and Policy, Services Interaction, and Services.....................................7 76 Although this document is the product of Global and its GISWG membership, it was adapted 77primarily from the technical reference architecture developed by the state of Washington, and 78sincere appreciation is expressed to Mr. Scott Came, State of Washington and SEARCH, The 79National Consortium for Justice Information and Statistics, for his guidance and leadership. In 80addition, parts of the architecture were derived from the Organization for the Advancement of 81Structured Information Standards (OASIS) Reference Model for Service-Oriented Architecture 1.0 82 83(SOA-RM). Other major contributors include the OASIS Court Filing Technical Committee, 84OASIS SOA-RM Technical Committee, and the Messaging Focus Group. ...................................7 85 Although each member of the GISWG is recognized for their contributions and for volunteering 86their time to the Justice Reference Architecture, Global would also like to recognize the members 87of the GISWG Executive Architecture Committee...........................................................................7 88 Mr. Scott Came—State of Washington and SEARCH, The National Consortium for Justice 89Information and Statistics, Services Interaction Committee............................................................7 90 Dr. Tom Clarke—National Center for State Courts, Chair, GISWG...............................................7 91 Mr. Scott Fairholm—National Center for State Courts, Chair, GISWG Services Committee.........8 92 Mr. Dale Good—CriMNet Program, Chair, GISWG Management and Policy Committee..............8 93 Mr. Kael Goodman—IJIS Institute, Chair, GISWG Services Interaction Committee......................8 94 Mr. Ron Hawley—SEARCH, The National Consortium for Justice Information and Statistics, 95GISWG Management and Policy Committee Chair (2005-2006)....................................................8 96 Mr. Eric Sweden—National Association for State Chief Information Officers, Vice Chair, GISWG 8 97 How to Use This Document...........................................................................................................9 11 12 4
  • 5. 13Justice Reference Architecture DRAFT 14 98 Executive Summary.....................................................................................................................11 99 Introduction..................................................................................................................................12 100 Global’s SOA Initiative..............................................................................................................12 101 An Interoperability Strategy......................................................................................................13 102 What Is Justice Reference Architecture?..................................................................................15 103 Architecture Requirements..........................................................................................................18 104 Requirement 7—JRA should leverage open industry standards where possible..................25 105 Requirement 8—JRA must support marketplace diversity....................................................25 106 Requirement 9—JRA should use a service-oriented design philosophy...............................26 107 Requirement 10—JRA should be driven by business need..................................................26 108 Requirement 11—JRA should derive service requirements from business process 109 requirements. ........................................................................................................................26 110 Requirement 12—JRA should preserve data control by the source organization.................26 111 Requirement 13—JRA should minimize dependencies among justice business processes 112 and supporting information systems......................................................................................27 113 Requirement 14—JRA should treat services as reusable assets to be shared beyond the 114 original context as required....................................................................................................27 115 Requirement 15—JRA should support business agility as the fundamental business 116 requirement............................................................................................................................27 117 Requirement 16—JRA should be developed in an iterative way..........................................27 118 Requirement 17—JRA should evolve indefinitely in response to changing business 119 requirements..........................................................................................................................27 120 Justice Reference Architecture....................................................................................................28 121 Graphical Overview..................................................................................................................28 122 Concepts and Relationships.....................................................................................................30 123 OASIS Reference Model for Service-Oriented Architecture for ...........................................30 124 Core Concepts—Services, Service Consumers, Capabilities, and Real-World Effects........31 125 Supporting Concepts............................................................................................................33 126 Business Process Models and the Service/Capability Hierarchy..........................................34 127 Interaction, Visibility, Service Models, and Service Interfaces..............................................35 128 Design and Description of Service Interfaces.......................................................................39 129 Capabilities in Detail.............................................................................................................41 130 Service Policies, Service Contracts, and Service Agreements.............................................43 131 Execution Context.................................................................................................................43 132 Services and Related Deliverables.......................................................................................46 133 The JRA deliverables related to services are documented in this section. To cross reference 134 the definitions of corresponding concepts in this section, see page 29. .................................46 135 Services ...................................................................................................................................46 136 Service Design Principles ........................................................................................................46 15 16 5
  • 6. 17Justice Reference Architecture DRAFT 18 137 Future Service Deliverables.....................................................................................................47 138 Business Process Models........................................................................................................47 139 Business Process Models are explained starting on page 32. ..............................................47 140 Interaction, Service Models, and Related Concepts.................................................................47 141 To cross reference the concepts and related deliverables in this section, please see page 33. 142 ..................................................................................................................................................47 143 Domain Vocabularies...............................................................................................................47 144 The domain vocabulary for JRA is the Global Justice XML Data Model (Global JXDM) Version 145 3.0.3. Information about the data model can be accessed at:..................................................47 146 Registries/Repositories.............................................................................................................48 147 Future Interaction and Service Model Deliverables..................................................................48 148 Design and Description of Service Interfaces.......................................................................48 149 As a cross reference, the concepts and related deliverables in this section correspond to the 150 concepts that are explained in the section starting on page 37. The JRA Work Plan includes 151 the following deliverables. ......................................................................................................48 152 Service Interaction Requirements............................................................................................48 153 Service Interaction Profiles.......................................................................................................50 154 Message Exchange Patterns....................................................................................................50 155 Capabilities in Detail and Related Components.......................................................................51 156 To cross reference the concepts and related deliverables in this section, please review page 157 39. The JRA Work Plan includes the following deliverables. ................................................51 158 Provisioning Models.................................................................................................................51 159 Enterprise Integration Patterns.................................................................................................51 160 Future Deliverables..................................................................................................................51 161 Model Policies and Contracts...................................................................................................52 162 Model Agreements...................................................................................................................52 163 Other Considerations................................................................................................................53 164 Governance..........................................................................................................................53 165 Investment Strategies ..........................................................................................................54 166 System Design .....................................................................................................................54 167 System Interfaces.................................................................................................................55 168Glossary....................................................................................42 169References...............................................................................48 170Document History.....................................................................48 19 20 6
  • 7. 21Justice Reference Architecture DRAFT 22 171 Acknowledgements 172 The Justice Reference Architecture (JRA) was developed 173 through a collaborative effort of the Global Justice 174 Information Sharing Initiative (Global), Office of Justice 175 Programs (OJP), U.S. Department of Justice (DOJ). 176 Global aids its member organizations and the people they 177 serve through a series of important initiatives. These 178 include the facilitation of Global Working Groups. The Global 179 Infrastructure/Standards Working Group (GISWG) is one of 180 four Global Working Groups covering critical topics such as 181 intelligence, privacy, security, and standards. The GISWG is 182 under the direction of Tom Clarke, Ph.D., National Center for 183 State Courts. The GISWG consists of three committees: 184 Management and Policy, Services Interaction, and Services. 185 Although this document is the product of Global and its 186 GISWG membership, it was adapted primarily from the 187 technical reference architecture developed by the state of 188 Washington, and sincere appreciation is expressed to Mr. 189 Scott Came, State of Washington and SEARCH, The National 190 Consortium for Justice Information and Statistics, for his 191 guidance and leadership. In addition, parts of the 192 architecture were derived from the Organization for the 193 Advancement of Structured Information Standards (OASIS) 194 Reference Model for Service-Oriented Architecture 1.0 195 (SOA-RM). Other major contributors include the OASIS 196 Court Filing Technical Committee, OASIS SOA-RM Technical 197 Committee, and the Messaging Focus Group. 198 Although each member of the GISWG is recognized for their 199 contributions and for volunteering their time to the Justice 200 Reference Architecture, Global would also like to recognize 201 the members of the GISWG Executive Architecture 202 Committee. 203 Mr. Scott Came—State of Washington and SEARCH, The 204 National Consortium for Justice Information and Statistics, 205 Services Interaction Committee 206 Dr. Tom Clarke—National Center for State Courts, Chair, 207 GISWG 23 24 7
  • 8. 25Justice Reference Architecture DRAFT 26 208 Mr. Scott Fairholm—National Center for State Courts, Chair, 209 GISWG Services Committee 210 Mr. Dale Good—CriMNet Program, Chair, GISWG 211 Management and Policy Committee 212 Mr. Kael Goodman—IJIS Institute, Chair, GISWG Services 213 Interaction Committee 214 Mr. Ron Hawley—SEARCH, The National Consortium for 215 Justice Information and Statistics, GISWG Management and 216 Policy Committee Chair (2005-2006) 217 Mr. Eric Sweden—National Association for State Chief 218 Information Officers, Vice Chair, GISWG 27 28 8
  • 9. 29Justice Reference Architecture DRAFT 30 219 How to Use This Document 220 Policymakers, Executives, and Decision Makers 221Global is committed to providing Service-Oriented Architecture 222(SOA) resources, such as this document, to local, state, 223regional, tribal, and federal justice and public safety 224organizations. As additional resources become available, 225these materials will demonstrate the value of the architecture 226to the stakeholders in a way that is targeted to their particular 227needs. Other planned resources include strategy, executive 228summary, case studies from early implementers, management 229and policy, and other planning briefings, which will be targeted 230towards managers, chiefs, and executives. 231For the purposes of this document, Global has selected a 232distinguished group of technical and domain representatives 233from a group of skilled peers who have volunteered to develop 234this material as a starting point in establishing the Justice 235Reference Architecture Specification for Service-Oriented 236Architecture. 237Keep in mind that the sections in this document referencing the 238conceptual diagram, high-level components, and relationships 239establish definitions that are intended for use by technical 240architects and project managers who are responsible for 241identifying all the elements necessary within their jurisdiction to 242implement SOA. This document is intended as a formal and complete 243architectural specification for people with previous knowledge of technical 244architecture, service-oriented architecture, and supporting industry standards 245(such as Web services). 246 247 Project Managers, Architects, and Technologists 248This report is intended as a resource for a technical audience, 249including Global Justice XML Data Model (Global JXDM) 250implementers, architects, developers, system integrators, and 251other justice and public safety technical practitioners. 252It provides the background and concepts—a strong foundation 253—required for the implementation of SOA. Justice Reference 254Architecture is a new term coined for the justice community, 255and it is derived from the OASIS Reference Model for Service- 31 32 9
  • 10. 33Justice Reference Architecture DRAFT 34 256Oriented Architecture 1.0 (SOA-RM1). The reader should refer 257to the SOA-RM for more detailed information about many of the 258concepts in this document. JRA is intended to facilitate your 259SOA implementation by establishing a common language that 260can be used to exchange data with partner organizations. 261 351 http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf 36 37 10
  • 11. 38Justice Reference Architecture DRAFT 39 262 Executive Summary 263This document states a set of requirements for justice 264interoperability and then describes the Justice Reference 265Architecture (concepts, relationships, and high-level 266components) Specification that satisfies those requirements. 267The document then illustrates the architecture through a set of 268actual scenarios. Finally, the document provides an initial 269elaboration of some of the concepts and components in the 270architecture. (This section will be significantly expanded in 271future versions.) 272 273 40 41 11
  • 12. 42Justice Reference Architecture DRAFT 43 274 Introduction 275 Global’s SOA Initiative 276On September 29, 2004, the Global Justice Information Sharing 277Initiative (Global) Advisory Committee (GAC) unanimously 278adopted SERVICE-ORIENTED ARCHITECTURE (SOA) and the 279recommendations in the report titled A Framework for Justice Information 280Sharing: Service-Oriented Architecture (SOA). 281 Global provides support for SOA by: 282 • Recognizing SOA as the recommended FRAMEWORK 283 for development of justice information sharing 284 systems; 285 • Promoting the utility of SOA for the justice 286 community; and 287 • Encouraging the members of the justice 288 community to take these recommended 289 incremental steps in the development of their own 290 systems. 291Global’s approval was based on the understanding that SOA is 292an approach that is most likely to result in an infrastructure that 293will support its vision of how information should be shared 294among the justice community. If SOA is to be used 295successfully as the framework for justice information sharing 296ARCHITECTURE, Global must play a proactive leadership role in 297several areas. The development of the JUSTICE REFERENCE ARCHITECTURE 298was based on the following actions recommended by Global. 299 • Incorporate SOA into the activities of all of the 300 Global Working Groups. SOA raises issues for 301 security, privacy and information quality, and 302 intelligence that will be given explicit attention and 303 treated as part of a broad initiative. 304 • Encourage the creation of a mechanism for 305 drawing together the experiences and lessons 306 from the field. 44 45 12
  • 13. 46Justice Reference Architecture DRAFT 47 307 • Reach out to existing national systems to 308 incorporate their efforts into the design of an 309 overall strategy. 310 • Address the following six issues as priorities— 311 services, standards, interagency agreements, 312 registries, security, and privacy and data quality— 313 because they will be a major part of the agenda 314 for the next set of Global activities. 315 • Develop a multitiered strategy for the public 316 sector to influence standards. It will include 317 encouraging the creation of a public process (as 318 it did with XML), taking part in industry groups that 319 are developing standards relevant to justice (e.g., 320 OASIS), and developing partnership processes 321 with industry and other public entities. 322 An Interoperability Strategy 323Solving interoperability challenges continues to be a significant 324problem and a high priority for the justice and public safety 325community. There are approximately 100,000 justice agencies 326that have the critical need to share information across their 327various information systems, and this variety creates multiple 328layers of interoperability problems because hardware, 329software, networks, and business rules for data exchange are 330different. The need for information sharing has led to this 331interoperability strategy and the Justice Reference 332Architecture (JRA). 333The strategy for developing JRA involves many steps. This 334paper details some highly technical and abstract concepts. 335Understanding these concepts may require significant effort 336from the reader. Though it may seem strategically 337questionable to place such a high hurdle at the beginning of a 338multistep process, doing so actually creates a flexible 339vocabulary and conceptual framework that will enable the 340desired interoperability to flourish. Additionally, subsequent 341steps that will build from this framework will be incrementally 342more concrete, and will ultimately lead to actual 343implementation specifications that can be used by 344practitioners in the field. Global believes that this dynamic 345interoperability strategy will help to prevent incompatibilities, 346guide vendors and organizations on how to fit components 347together, and facilitate communication and interoperability 48 49 13
  • 14. 50Justice Reference Architecture DRAFT 51 348among disparate communities. 349Global’s strategy for JRA, like other work that has preceded 350it, follows a five-step process: 351 Step One: Agree on common concepts 352 Step Two: Agree on the relationships and deliverables 353 Step Three: Assign the work 354 Step Four: Produce the deliverables 355 Step Five: Revise the deliverables 356As an example, when the Global JXDM project started it had a 357small set of limited solutions. Through much iteration, Global 358JXDM has been expanded and refined and addresses a 359successively larger set of justice domains. 360 Consensus on the OASIS Reference Model for SOA 361One of the justice requirements is to create a common 362language for talking about architecture across major domains. 363For instance, it is currently difficult for emergency 364management personnel to talk to justice personnel about how 365their respective systems might share data beyond the content 366standards issue because their ways of communicating about 367architecture are so different. 52 53 14
  • 15. 54Justice Reference Architecture DRAFT 55 368After considerable discussions among the stakeholders, Global 369adopted the Organization for the Advancement of Structured 370Information Standards (OASIS) Reference Model for Service- 371Oriented Architecture 1.0 (SOA-RM). OASIS has approved this 372standard reference model for describing different 373architectures using comparable, vendor-neutral language. 374Global is adopting the OASIS framework for describing its 375architecture and holding conversations with other domains. 376 Creating the Justice Reference Architecture 377Itis important to note that SOA-RM provides a conceptual 378foundation for not only the justice community, but for any 379domain to create a REFERENCE ARCHITECTURE. JRA builds on the SOA- 380RM concepts by specifying additional relationships and 381defining and specifying these adopted concepts. 382Although there is no perfect solution, and since there is a need 383to start somewhere, SOA-RM is recommended as the best 384place to start Global’s SOA work efforts. Global began by 385mapping the SOA components, documenting and leveraging 386the work that has been already done—like the Global JXDM— 387and, finally, identifying and filling the gaps. 388 Justice Reference Architecture is derived from the OASIS Reference 389 390 Model for Service-Oriented Architecture 1.0. The OASIS work was 391 developed to provide a conceptual foundation for creating a reference 392 architecture. As intended by OASIS, JRA builds on or expands from 393 394Specifically, Global is developing a modular architecture that 395cleanly and appropriately identifies and separates technical 396and governance layers so that standards can be developed to 397improve interoperability. 398 What Is Justice Reference Architecture? 399This section defines Justice Reference Architecture (JRA) for 400Service-Oriented Architecture (SOA) and explains why a 401reference architecture is useful. Keep in mind that there are 402potentially many justice reference architectures, but that this 403JRA focuses entirely on SOA for the justice and public safety 56 57 15
  • 16. 58Justice Reference Architecture DRAFT 59 404community. Out-of-scope components and other 405considerations are listed on page 53. 60 61 16
  • 17. 62Justice Reference Architecture DRAFT 63 406 JRA is an abstract framework for understanding significant 407 components and the relationships between them within a Service- 408 Oriented Architecture. It lays out common concepts and definitions 409 as the foundation for the development of consistent SOA implementations within the justice and public safety communities. 410 411JRA is a description of the important concepts in a justice 412information sharing architecture and the relationships between 413those concepts. JRA also identifies, at a high level, the kinds 414of “components” (software systems, hardware infrastructure, 415policies, practices, intersystem connections, and so on) 416necessary to bring those concepts to life in a particular 417context. JRA is generally not specific enough to govern the 418implementation of any individual software system 419implementation. Rather, it is a framework for guiding 420implementations in general, with the aim of standardizing or 421harmonizing certain key aspects of those implementations to 422support reusability or interoperability. 423Itis important to note that at this time JRA is not complete. 424Many sections of this document are still under development, 425but the document does attempt to identify the necessary 426concepts, relationships, and components that will require 427further elaboration and/or implementation. 64 65 17
  • 18. 66Justice Reference Architecture DRAFT 67 428 Architecture Requirements 429This section documents the business requirements to be 430addressed and satisfied by Justice Reference Architecture. In 431future revisions, this section will be changed from 432requirements to guiding principles and goals. 433As previously described in the Introduction, the justice world 434has close to 100,000 justice agencies, and most of these are 435very small and have few information technology resources. 436They use different applications, hardware, and networks that 437have diverse topologies and interoperability capabilities. 438Nonetheless, JRA must reflect the influence of the following 439factors, representing the key characteristics of the justice and 440public safety environment. 441 Requirement 1—Justice Reference Architecture must recognize 442 innumerable independent agencies and funding bodies from local, 443 state, tribal, and federal governments. 444 For anyone connected to the justice community, 445 this requirement is self-evident. One factor has 446 not changed throughout American history: the 447 business of justice is largely the province of local, 448 state, and tribal government. The independence 449 and number of entities that need to share justice 450 information is almost overwhelming. Certainly, it is 451 beyond the ability of existing conceptual 452 frameworks, computer models, financial 453 resources, or jurisdictional authority to create an 454 integrated network using traditional technology. 455 SOA, however, can be a meaningful bridge. A 456 quote from SOA literature makes this fit clear: 457 “Designing for SOA involves thinking of the parts 458 of a given system as a set of relatively 459 autonomous services, each of which is 460 (potentially) independently managed and 461 implemented, which are linked together with a set 462 of agreements and protocols into a federated 463 structure.” [Sholler] “Autonomous,” 464 “independent,” “agreements,” and “federated” 68 69 18
  • 19. 70Justice Reference Architecture DRAFT 71 465 capture the environment for justice information 466 sharing. 467 Requirement 2—JRA must accommodate information sharing 468 across agencies that represent divergent disciplines, branches of 469 government, and operating assumptions. 470It is difficult, if not impossible, to define precisely the 471boundaries of the justice community. The obvious list of 472participants—law enforcement, prosecution, courts, defense 473counsel, probation, and corrections—is only the beginning. 474Accurate, timely, and appropriate justice information sharing 475among the entities is necessary for effective apprehension, 476prosecution, adjudication, and punishment of an offender. 477However, these are only some of the objectives. 478This same information, or portions of it, are necessary to meet 479the business requirements of related justice, public safety, and 480homeland security agencies. For example, this information is 481required to regulate the sale of firearms; complete criminal 482background checks of employees at schools, child care 483services, and elder care facilities; identify aliens who have 484been convicted of crimes or have entered the country illegally; 485notify the local community of the release and location of sexual 486predators; prevent training in the operation of aircraft by aliens 487or other designated individuals who may present a risk to 488aviation and national security; do background checks of those 489transporting hazardous materials; or create information models 490to provide information and predict the spread of disease and 491its effects, and decide on countermeasures for potential health 492epidemics like the avian flu. 493The events of September 11, 2001, resulted in the creation of 494the 495U.S. Department of Homeland Security (DHS) with its 496constituent agencies, such as the U.S. Citizenship and 497Immigration Services, U.S. Customs and Border Protection, 498and the U.S. Coast Guard. September 11 also elevated the 499importance of information sharing between and among public 500safety agencies such as fire, emergency medical services, and 501other first-responder organizations. 502Thelist would not be complete without the recognition of the 503numerous entities outside of the justice and public safety 72 73 19
  • 20. 74Justice Reference Architecture DRAFT 75 504communities—such as schools, child care services, 505transportation, and licensing agencies—that need critical 506justice-related information to perform daily business activities, 507such as hiring new personnel, approving gun purchases, or 508granting professional licenses. 509Finally, the list of relevant constituencies also includes the 510public, who expect greater accountability and access to justice 511information that is considered sensitive or protected by privacy 512laws in some settings (e.g., state criminal history records in 513many state repositories and the FBI system), while viewed as 514public record in others (e.g., criminal history record information 515in the courts). Increasingly, the public also expects that this 516access be automated and online. 517The diversity of justice information consumers carries an 518attendant consideration: different types of users have different 519requirements. A judge making a sentencing decision has more 520time for their task—and a less expedited need for response to 521inquiry—than an officer on the scene requiring instant access to 522succinct information. 523The purposes also vary. For example, it is one thing if the 524primary objective is to validate the identity or status of an 525individual (e.g., a law enforcement officer communicating with 526the Department of Motor Vehicles to check on a driver’s 527license), but another when an exhaustive search for 528information is required (e.g., a probation officer conducting a 529pre-sentence investigation of a convicted offender). 530Different sources also mean differences in expectations about 531who can use what information. Privacy and data quality issues, 532which are demanding enough when dealing with a single 533information system, grow exponentially when dealing with 534different disciplines. It is one thing to share the records of a 535criminal sentencing hearing held in open court; it is quite 536another when dealing with health records or an ongoing 537criminal investigation. Incomplete or inaccurate data may be 538an annoyance if the task is to identify leads for subsequent 539investigations; they are a different issue entirely if they prohibit 540one from getting a job, traveling on an airplane, or lead to 541incarceration. Working documents in one setting can become 542dispositive evidence in another. 76 77 20
  • 21. 78Justice Reference Architecture DRAFT 79 543What this means is that the information system design cannot 544begin with a clear definition of the boundaries of the 545organization. Nor can we assume that all of those who 546participate share a common set of objectives or an 547understanding of the process. On the contrary, the information 548system design must assume diversity, even conflicts, in the 549operating procedures and objectives of the participating 550organizations. 551 Requirement 3—JRA must be able to accommodate an infinite 552 range of scales, from small operations with few participants in a 553 rural county to national processes that reach across local, state, 554 federal, and even international boundaries.2 555The context for information sharing is not the same 556everywhere, and the scale will depend upon the objectives and 557the geographical setting. It is one thing if the objective is to 558move cases quickly from investigation to arrest through 559adjudication in a rural county where all of the participants know 560each other and have ongoing contact on a personal level. It is 561quite another thing if the objective is to share information about 562warrants between law enforcement and the judiciary in a large 563state on a real-time basis. And it is different still if the context 564moves to a national level, and the objective is to share 565information among many local, state, tribal, and federal law 566enforcement and health agencies about a reported health 567epidemic. 568 The resources required to implement advanced 569 justice information sharing architectures will come 570 from many independent sources, the largest body 571 of which will be local. It is safe to assume that the 572 funds will be spent to meet the immediate needs 573 of the entities within the funding source’s 574 jurisdiction and not as a result of priorities that are 575 provided by a state or national plan. An approach 576 to infrastructure design that cannot be adapted to 802 For clarity, we have changed the original language in the documents to fit 81the current terminology that is based on the OASIS and JRA work efforts. 82This current work is based on the requirements from the document titled, A 83Framework for Justice Information Sharing: Service-Oriented Architecture 84(SOA), December 9, 2004, which was written by The Global 85Infrastructure/Standards Working Group. 86 87 21
  • 22. 88Justice Reference Architecture DRAFT 89 577 the different scales without losing its internal 578 integrity will quickly be marginalized. 90 91 22
  • 23. 92Justice Reference Architecture DRAFT 93 579 Requirement 4—JRA must be able to accommodate data sources 580 that differ widely in software, hardware, structure, and design. 581The history of efforts to develop integrated information 582systems among local criminal justice agencies around a single 583hardware and software platform is large and filled with many 584disappointments. When the focus shifts to the state and 585national level, the success rate becomes even smaller and is 586largely populated by single-purpose efforts. The explanation 587for this phenomenon is relatively simple: technology 588investment decisions are made by funding sources with their 589own tax base, budget cycle, and spending priorities. The result 590is that information system development among local, state, 591tribal, or federal justice community entities rarely occurs in 592concert. 593The reality is that no infrastructure development strategy can 594assume that all participants will be at the same point in the 595technology cycle. To paraphrase: new technologies are 596important, but legacy systems will always be with us. 597 Requirement 5—JRA must reflect and incorporate the lessons and 598 developments of the private sector. 599Itoften surprises the justice community to learn how much of 600the technology needed to share information is common to the 601private sector as well. When you think about it, only parts of 602the data and the transaction definitions are unique to the 603justice world. The several other technical layers in a 604transaction that provides a service are driven by open 605standards defined by private industry and implemented in their 606tool sets and products. The justice community must learn how 607to incorporate and leverage private industry. 608The Global process and the projects sponsored by it must take 609these powerful trends in the private sector into account. The 610justice community can have some influence on such decisions, 611even in the private sector, by more fully participating in the 612open standards bodies that decide what will be proposed to 613the market for implementation; continuing collaboration with 614industry partners such as the IJIS Institute will be necessary to 615succeed. Often, such participation and collaboration will 616educate us on how to develop and/or reuse the standards 94 95 23
  • 24. 96Justice Reference Architecture DRAFT 97 617without needing to invent something new and unique for our 618business problems. And, as Global puts together an agenda 619for progress, lessons learned are provided from initiatives that 620have failed as well as succeeded. These discoveries and 621lessons learned from the private sector will save us money and 622facilitate the sharing of critical data in ways that increase public 623safety. 98 99 24
  • 25. 100Justice Reference Architecture DRAFT 101 624 Requirement 6—JRA must be dynamic and capable of evolving as 625 the information sharing requirements change and the technology 626 is transformed. 627The operational requirements of members of the justice 628community are in constant change. The events of September 62911 have elevated intelligence information to a leading priority for 630law enforcement; the rise of domestic violence cases has 631expanded the judiciary’s need to reach out to the family 632services community; the increased mobility of the population 633has complicated probation’s efforts to monitor offenders; and 634the spread of AIDS has put a premium on health management 635by corrections administrators. An infrastructure design that 636cannot adapt to an evolving definition of the boundaries and 637critical components of the justice community will, before long, 638become irrelevant. 639 Requirement 7—JRA should leverage open industry standards where 640 possible. 641The justice environment will benefit from the stabilization of 642standards as the basis for an overall approach to 643interoperability among large and diverse organizations. The 644evolution of open industry standards for systems integration 645has reached a point where these standards will facilitate 646interoperability. Many prominent programming languages, 647software development environments, packaged applications, 648and integration platforms/tools support the standards. 649Although some common integration needs are met by 650competing standards, the number and significance of 651competing standards continue to shrink. 652 Requirement 8—JRA must support marketplace diversity. 653The marketplace for integration products is highly diverse and 654is likely to remain so for the foreseeable future. Support for 655Web services standards, key integration capabilities (such as 656transformation, content-based routing, and orchestration), and 657off-the-shelf adapters for applications (such as Enterprise 658Resource Planning [ERP] packaged applications) exist from a 659variety of vendors. 102 103 25
  • 26. 104Justice Reference Architecture DRAFT 105 660 Requirement 9—JRA should use a service-oriented design philosophy. 661 Requirement 10—JRA should be driven by business need. 662 Requirement 11—JRA should derive service requirements from business 663 process requirements. 664 Requirement 12—JRA should preserve data control by the source 665 organization. 106 107 26
  • 27. 108Justice Reference Architecture DRAFT 109 666 Requirement 13—JRA should minimize dependencies among justice business 667 processes and supporting information systems. 668 Requirement 14—JRA should treat services as reusable assets to be shared 669 beyond the original context as required. 670 Requirement 15—JRA should support business agility as the fundamental 671 business requirement. 672 Requirement 16—JRA should be developed in an iterative way. 673 Requirement 17—JRA should evolve indefinitely in response to changing 674 business requirements. 675 110 111 27
  • 28. 112Justice Reference Architecture DRAFT 113 676 Justice Reference Architecture 677 Graphical Overview 678The following diagram depicts the concepts, high-level 679components, and relationships in the Justice Reference 680Architecture Specification V 1.3. These elements are described 681in detail in the following sections. 114 115 28
  • 29. 116Justice Reference Architecture DRAFT 117 Orchestrations act as Routers consist of identify common Message Validators Intermediaries types of Transformers Provisioning can be supported by Models Interceptors define Enterprise leverage information contained in Integration Patterns implement Service Providers provider systems implement Capabilities provide Real-World Effects Domain Vocabularies produce Business Process Models conforms to, Behavior Model provide access to seek uses Information Model define context of use contains Services Service Consumers contains defines semantics of Service Model are composed of act as can contain some provide access to constrain use of or hosts Repository expected result assists hosts is described by of using conform to, are assembled from consumer systems depends on Visibility are aspects of Agreements can be specified in structure and content determined by Willingness Awareness described by Policies and Reachability can constrain can be Interaction Service Interfaces Contracts are the means of accomplished by exchange of enables Execution Context establish some requirements for guide design and Service Interaction description of Profiles Service Interaction define common rules of Requirements Interface Description Define interoperable implementations of Requirements Message Exchange describe ways of exchanging Patterns Messages Message Definition define structure of Mechanisms enables and determines essential aspects of Justice Reference Architecture Legend Concept Map November 3, 2006 Concepts from OASIS SOA-RM Concepts particular to the JRA 682 683 118 119 29
  • 30. 120Justice Reference Architecture DRAFT 121 684 Concepts and Relationships 685The following sections describe the concepts, components, 686and relationships depicted in the diagram on the previous 687page. 688 OASIS Reference Model for Service-Oriented Architecture for 689The Justice Reference Architecture depicted in the diagram 690above (and defined in this document) adopts and builds on the 691OASIS 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 700 unifying concepts, axioms, and relationships within 701 a 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 711 will impact SOA.” (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 reference architecture. OASIS lays out a 716roadmap for the creation of such reference architecture. 717Specifically, OASIS recommends that the reference model guide the development 718of an architecture; that protocols, profiles, specifications, and standards are 122 123 30
  • 31. 124Justice Reference Architecture DRAFT 125 719considered; and that requirements, motivations, and goals are taken into account. 720(SOA-RM, p. 5)3 721JRA does just this. It takes the reference model and adds the protocols, profiles, 722specifications, standards, requirements, motivations, and goals appropriate for the 723justice community. 724In the JRA diagram, OASIS SOA-RM concepts are shaded 725yellow with a dashed line as the border. Concepts and 726components particular to the conceptual JRA defined by this 727document are shaded light blue with a 728solid border. Relationships between 729concepts (indicated by arrows) are 730defined in the SOA-RM if the arrows 731connect concepts shaded yellow. 732Relationships between cyan-shaded 733concepts or between cyan-shaded and 734yellow-shaded concepts are particular 735to JRA. 736The descriptions of SOA-RM concepts 737provided in the following sections are 738intended to be brief summaries; 739consequently, they omit certain details 740that appear in the SOA-RM. Concepts 741listed in bold, blue caps are listed in the 742glossary at the end of this document, 743and the glossary contains definitions of 744the SOA-RM concepts, which are 745repeated from the SOA-RM glossary for 746convenience. The SOA-RM itself is the primary source for full 747exposition of 748SOA-RM concepts and the relationships between them. 749 Core Concepts—Services, Service Consumers, Capabilities, and Real-World 750 Effects 751These four concepts make up the core of the Global JRA. All other concepts support these 752concepts. It is strongly advised that these concepts be clearly grasped before reading the 753section called Supporting Concepts. 1263 Note: In the next version of the JRA specification, this paragraph will be 127clarified to identify where the SOA-RM stops, and where JRA begins. 128 129 31
  • 32. 130Justice Reference Architecture DRAFT 131 754JRA begins from the premise that a group of justice partners 755have CAPABILITIES that they provide to one another. These 756capabilities“solve or support a solution for the problems 757[businesses] face in the course of their business.” ( SOA-RM, p. 7588) That is, capabilities are the things organizations have to 759solve problems and therefore add value, directly or indirectly, 760to their stakeholders. 761Note that JRA is generic enough to support virtually any kind of 762capability. However, the purpose of JRA is to describe an 763approach to achieving interoperability among automated, 764computer software-based information systems. Therefore, 765JRA considers only those business capabilities that are 766provided by (or implemented by) information systems. JRA 767calls these systems PROVIDER SYSTEMS and establishes that provider 768systems implement capabilities. 769Each capability produces one or more REAL-WORLD EFFECTS, each of 770which is an outcome of the business value sought by one of 771the partners. A real-world effect can be either the obtaining of 772information, the changing of something of business relevance 773to the participating partners, or both. Because JRA 774establishes that capabilities are implemented by provider 775systems, real-world effects consist of the functional business 776requirements of provider systems. That is, real-world effects 777in JRA are essentially the information made available by 778provider systems or the outcomes resulting from business 779processes and workflows automated by provider systems, or 780both. 781In a service-oriented architecture, a SERVICE is the way in which 782one partner gains access to a capability offered by another 783partner. A partner that uses a service to gain access to 784another partner’s capability is called a SERVICE CONSUMER. As with 785capabilities, the architecture is generic enough to support 786virtually any kind of service consumer. However, since the 787purpose of JRA is to describe an approach to information 788systems interoperability, JRA narrows the SOA-RM definition of 789service consumer to information systems that interact with 790services directly through an interface that conforms to a 791service interaction profile (as defined below). JRA calls such 792systems CONSUMER SYSTEMS. 132 133 32
  • 33. 134Justice Reference Architecture DRAFT 135 793One of the most important features of JRA is the separation of 794consumer systems from provider systems by services in the 795middle. This is the defining characteristic of a service-oriented 796architecture and is the key to decoupling systems as called for 797in many of the Architecture Requirements listed in the section 798on page 18. 799The fact that information sharing is one kind of real-world 800effect allows the architecture to support the traditional view of 801system integration as “data exchange” or “information 802sharing.” JRA improves this view by encouraging systems to 803share information in a way that minimizes the dependencies of 804each system on the implementation of other systems. 805 Supporting Concepts 806A PROVISIONING MODEL determines the organizational (perhaps 807contractual or legal) responsibility for providing a capability, via 808services, to achieve consumers’ desired real-world effect. 809The entity identified in a provisioning model as responsible for 810providing a capability is called a SERVICE PROVIDER. 811SERVICE DESIGN PRINCIPLES 4 provide consistent guidance regarding the 812overall partitioning of capabilities into services and the 813relationships between services. For instance, service design 814principles may call for services to represent one concise, self- 815contained function and may also suggest that services should 816completely hide the implementation details of the capabilities 817to which they provide access. 818There is a wide variety of ways in which a service can provide 819access to a capability. In some cases, the provider system 820that implements the capability may already expose all or some 821of its functionality as services (through one or more service 822interfaces, described on page 39). In other cases, the 823business partner that provisions the capability can purchase an 824off-the-shelf adapter from the provider system vendor (or a 825third party) that exposes the system’s functionality as a set of 826services. Finally, the provider system may require 827reimplementation or custom adaptation to expose functionality 828as services. This is often expensive and risky, and the desire 1364 Principles and guidelines are important components of the conceptual 137JRA; however, these principles and guidelines are not illustrated on the 138diagram because they will exist for most of the components. 139 140 33
  • 34. 141Justice Reference Architecture DRAFT 142 829toavoid this situation should be addressed in the Service 830Design Guidelines. 831In general, a given information system can be both a provider 832system and a consumer system. Similarly, a particular 833business organization may offer capabilities to its partners and, 834at the same time, be a consumer of the capabilities offered by 835others. This has important implications for how the 836organization should conceive and describe its information 837systems assets and how it assigns responsibilities for the 838maintenance and support of those assets. For example, in the 839past it was common to think of systems as having “client” and 840“server” components (or “browser” and “server” 841components), which in turn influenced thinking about systems 842deployment, networking, security, support, and a range of 843other issues. These issues deserve reconsideration in an 844architecture in which a system or system component can be 845both a “client” (consumer of services) and “server” (provider 846of services) at the same time. The discussion of service 847interaction on page 36, and the subsequent elaboration of 848interaction mechanisms in future iterations of JRA, will reflect 849the impact of these issues. 850Note that the concept of a service in JRA does not equate to a 851“Web service.” The term “Web services” is a label for a 852family of standards and an associated technical approach to 853communicating between service consumers and services. The 854architecture supports flexibility in how this communication 855happens through the notion of service interaction profiles 856(discussed on page 40). A Web service profile will be 857developed for the Web services family of standards; however, 858JRA will include additional profiles that adopt other 859communication mechanisms, such as MQ, JMS, and ebXML 860(discussed on page 50). 861 Business Process Models and the Service/Capability Hierarchy 862The previous section described the basic concepts involved in 863the integration of provider systems and consumer systems. In 864short, consumer systems seek a real-world effect provided by 865a capability, and they produce that effect by accessing a 866service that provides access to the capability. However, these 867concepts by themselves do not provide the context for the 868integration of a particular consumer and particular provider. 869That is, the concepts do not provide a way of describing why a 143 144 34
  • 35. 145Justice Reference Architecture DRAFT 146 870consumer seeks the effect made available by a provider 871through a service. 872A BUSINESS PROCESS MODEL provides this contextual justification. A 873business process model is a description (usually formal and 874often graphical) of a series of activities that culminate in the 875achievement of some outcome of business value. Some (but 876not necessarily all) of the steps in this series of activities 877involve producing a real-world effect provided by a capability, 878and some of the steps require a consumer to use a service. 879Each one of these steps, then, provide the contextual 880justification for service interaction between a particular 881consumer and particular provider. 882The execution of the steps described in a business process 883model can be considered a capability in and of itself. In 884addition, each of the steps in a business process model can 885unfold into yet another business process model at a more 886focused level of detail. In this way, each step in a series of 887service interactions can itself be a series of service 888interactions. And, in theory, this recursion of models can go on 889forever, though in practice it rarely exceeds three or four levels 890of containment. So, services and capabilities form a hierarchy, 891where a service provides access to a capability whose real- 892world effect is to accomplish the coordination of multiple 893services at a lower level of detail. 894JRA supports this hierarchy through orchestrations and 895intermediaries, discussed on page 41. 896Itis important to note that a given service may play a role in 897multiple business processes. In fact, reuse of services across 898business processes is an important part of the value of a 899service-oriented architecture. 900 Interaction, Visibility, Service Models, and Service Interfaces 901Servicesdefine what features of a provider system the system 902owner makes accessible to business partners. Services also 903provide a logical description of the information exchanged 904between consumer and provider systems as the consumer 905accesses the capability. 147 148 35
  • 36. 149Justice Reference Architecture DRAFT 150 906 Interaction 907JRA refers to a consumer’s accessing the features of a 908capability through a service as INTERACTION, defined as “the 909performing [of] actions against a service.” (SOA-RM, p. 15) 910Service interaction generally involves the exchange of 911information between the consumer and the service. 912Interactiondepends on two things. First, the designers of 913potentialconsumers need to be able to find services and, once 914found, establish a physical interaction mechanism with them. 915These needs are addressed by the concept of VISIBILITY. Second, 916the designers of potential consumers need a description of the 917actions that can be performed on a service, as well as the 918structure and meaning of information exchanged during the 919interaction. These needs are addressed by the concept of a 920service’s INFORMATION MODEL and BEHAVIOR MODEL, collectively called 921SERVICE MODELS in the JRA. 922 Visibility 923Visibility, as the name implies, defines how service consumers 924and the providers of capabilities “see” each other in a way 925that enables interaction between them. JRA identifies three 926aspects of visibility. 927 • A service consumer must have information that 928 makes it aware of the existence of a service; the 929 possession of this information is called AWARENESS. 930 • The service (or capability accessed through the 931 service) must be willing to interact with the 932 consumer; this is called WILLINGNESS. 933 • The consumer and service must be able to 934 communicate with one another through some 935 kind of communication path or channel; the 936 existence of such a communication path is called 937 REACHABILITY. 938In JRA, a REPOSITORY will support awareness by hosting service 939models and service interfaces. “Hosting” in this context 940means storing models and interface descriptions in a central 941location that is accessible to appropriate stakeholders. A 151 152 36
  • 37. 153Justice Reference Architecture DRAFT 154 942repository will permit searching for models and interface 943descriptions based on a range of identifying criteria. A 944repository will also map logical service identifiers with physical 945addresses. When a consumer wishes to communicate with a 946service (identified by a logical identifier), the consumer queries 947the repository for the physical address associated with the 948service’s logical identifier. This decouples the consumer from 949the physical location of a service at any point in time, thereby 950permitting the physical relocation of the service without 951impacting the implementation of the consumer. 952The concept of willingness is related to authorization and 953access control policies, in that a common reason for lack of 954willingness to interact is that the consumer is not authorized to 955conduct the requested interaction. Willingness often manifests 956in service descriptions, as well as policies, contracts, and 957agreements (discussed on page 43). A SERVICE MODEL is defined 958as the information needed in order to use, or consider using, a 959service. 960The concept of reachability is closely related to the concept of 961execution context (discussed on page 43). 962 Service Models 963Service models, consisting of a service’s information and 964behavior models, define the semantics of interaction with the 965service. The behavior model defines the actions that can be 966performed on the service; that is, it defines what the service 967“does.” The information model describes the information that 968consumers exchange with the service in the course of 969performing those actions. 970Note that the SOA-RM considers the orchestration and 971choreography of multiple services to be “part of the PROCESS MODEL 972ofa given architecture.” Yet the SOA-RM also indicates that a 973process model (part of the behavior model) applies to a single 974service. (SOA-RM, p. 15) Because of this lack of clarity in the 975SOA-RM, this JRA defines orchestration as a type of capability 976that leverages other services; it is described on page 41. 977In general, service models will be described at conceptual and 978logicallevels of detail. (Service models have a physical 979manifestation as well, in the form of the service interface 155 156 37
  • 38. 157Justice Reference Architecture DRAFT 158 980discussed in the next section.) A conceptual description of a 981service model will typically describe, in prose text form, the 982capability to which the service provides access, a listing and 983brief textual description of each action, and a brief textual 984description of the information model (e.g., key information 985entities, key properties on those entities, and brief definitions). 986A logical description of a service model will describe the 987actions and information structures in detail but independent of 988any physical implementation mechanism. Often this 989description will be graphical and follow a standard 990diagramming or modeling technique, such as Uniform Modeling 991Language (UML). 992A MESSAGE is defined as the entire “package” of information sent 993between service consumer and service (or vice versa), even if 994there is a logical partitioning of the message into segments or 995sections. For instance, if an interface expresses actions as 996operations or functions that take arguments, and a particular 997operation has two arguments, both arguments would be 998considered part of the same message, even though they may 999be logically separated within the message structure. A 1000message also includes the concept of an “attachment,” in 1001which there are several additional sections (attachments) that 1002relate to a distinct, “primary” section. 1003In JRA, the exchange of messages is the only way in which 1004consumers and services can communicate. This establishes a 1005linkage between the Federal Enterprise Architecture Data 1006Reference Model (FEA DRM) and JRA: a message in JRA 1007equates to an Information Exchange Package (IEP) in the DRM. 1008The concept of DOMAIN VOCABULARIES in JRA includes canonical data 1009models, data dictionaries, and markup languages that 1010standardize the meaning and structure of information for a 1011topical or business domain. Domain vocabularies can improve 1012the interoperability between consumer and provider systems 1013by providing a neutral, common basis for structuring and 1014assigning semantic meaning to information exchanged as part 1015of service interaction. Domain vocabularies can usually be 1016extended to address information needs specific to the service 1017interaction or to the business partners integrating their 1018systems. 159 160 38
  • 39. 161Justice Reference Architecture DRAFT 162 1019SERVICE MODELING GUIDELINES govern the style, structure, and 1020description of service models. 1021As previously stated, a repository should contain service model 1022description artifacts for each level of detail. The availability of 1023service model descriptions to consumer system designers, 1024implementers, and purchasers is a key factor in establishing 1025visibility and the reuse of services. 1026 Service Interface 1027Service models describe the actions available from a service 1028and the information exchanged between a consumer and the 1029service during the performance of those actions. In this way, 1030the service models describe the “what” of interaction. 1031A SERVICE INTERFACE “is the means for interacting with a service. It 1032includes the specific protocols, commands, and information 1033exchange by which actions are initiated [on the service].” 1034(SOA-RM, p. 22) A service interface is what a system designer 1035or implementer (programmer) uses to design or build 1036executable software that interacts with the service. That is, 1037the service interface represents the “how” of interaction. 1038JRA considers the service interface to be the physical 1039manifestation of the service models. Best practices call for a 1040service interface to be described in an open-standard, 1041referenceable format (that is, a format whose contents are 1042capable of automated processing by a computer). 1043Note that at least some policies and contracts can be 1044described in a service’s interface. 1045The format, structure, and allowable contents of a service 1046interface are established by INTERFACE DESCRIPTION REQUIREMENTS, 1047described in the following section. 1048 Design and Description of Service Interfaces 1049JRA identifies four architectural elements that guide the design 1050and description of service interfaces. 1051SERVICE INTERACTION REQUIREMENTS define common rules of service 1052interaction. Typically, these requirements are not directly 163 164 39
  • 40. 165Justice Reference Architecture DRAFT 166 1053related to the capability used by the service consumer, nor are 1054they related to the real-world effect resulting from use of that 1055capability. Rather, the requirements enforce (or support the 1056enforcement of) policies or contracts or otherwise protect the 1057interests of particular business partners or the business 1058organization overall. 1059Common service interaction requirements address areas such 1060as security, reliability, and availability. An initial elaboration of 1061service interaction requirements appears on page 48. 1062INTERFACE DESCRIPTION REQUIREMENTS establish common characteristics of 1063service interface descriptions. These requirements address 1064areas such as required interface contents, naming rules, 1065documentation rules, and specification of a standard structure 1066and format for descriptions. 1067MESSAGE EXCHANGE PATTERNS identify common sequences of message 1068transmission between service consumers and services. They 1069provide a label to a series of message transmissions that have 1070some logical interrelationship. An initial elaboration of 1071message exchange patterns appears on page 50. 1072MESSAGE DEFINITION MECHANISMS are closely related to interface 1073description requirements, described above. Unlike interface 1074description requirements, message definition mechanisms 1075establish a standard way of defining the structure and contents 1076of a message. Note that since a message includes the 1077concept of an “attachment,” the message definition 1078mechanism must identify how different sections of a message 1079(for example, the main section and any “attachment” 1080sections) are separated and identified and how attachment 1081sections are structured and formatted. 1082 Service Interaction Profiles 1083A SERVICE INTERACTION PROFILE defines a family of industry standards or 1084other technologies or techniques that together demonstrate 1085implementation or satisfaction of: 1086 • Service interaction requirements. 1087 • Interface description requirements. 1088 • Message exchange patterns. 1089 • Message definition mechanisms. 167 168 40
  • 41. 169Justice Reference Architecture DRAFT 170 1090Service interaction profiles are included in JRA to promote 1091interoperability without forcing the organization to agree on a 1092single way of enabling service interaction. Each service 1093interface will support a single profile; a service will have 1094multiple interfaces if it supports multiple profiles. By supporting 1095a profile, an interface establishes the mode of interoperation it 1096allows from service consumers; any consumer that also 1097supports that profile can “reach” the service. 1098JRA explicitly recognizes that a service interaction profile may 1099be further constrained by an implementer to require specific 1100techniques, technologies, or mechanisms, as long as the 1101additional constraints remain consistent with the original 1102profile. 1103 Capabilities in Detail 1104JRA identifies several types of capabilities to assist decision 1105makers in understanding where certain capabilities should be 1106deployed in the organization and what relationships they may 1107have to other capabilities and services. 1108 Orchestrations and Intermediaries 1109An ORCHESTRATION is a capability that coordinates interaction with 5 1110multiple services. An orchestration is often implemented using 1111an open industry standard implementation mechanism 1112(referred to as an ORCHESTRATION MECHANISM in JRA), which allows the 1113implementation to be shared across tools and platforms. Also, 1114it is often possible to implement orchestrations using a 1115graphical, model-driven approach, in which the implementer 1116diagrams business processes and work flows, the steps of 1117which are services that already exist. After the diagram is 1118complete, the implementer generates a standards-based 1119artifact that is deployed into a software component that 1120exposes the work flow as a service through a service 1121interface. The promise of this model-driven approach is that 1122less technical implementers with greater business expertise 1123can be responsible for the implementation of orchestrated 1124capabilities. 1715 In version 1.4 of the JRA, we will change the name of the orchestration 172concept to something more generic that encompasses orchestration, 173choreography, and collaboration. 174 175 41
  • 42. 176Justice Reference Architecture DRAFT 177 1125ROUTERS are capabilities that receive a message, examine it, and 1126transmit it to one or more destinations based on the contents. 1127In general, routers can be designed to operate on any of the 1128information contained within the message; they may use 1129information about the origin of the message, routing directive 1130information contained within the message or the main content 1131of the message itself. 1132TRANSFORMERS are capabilities that receive a message and 1133transform it into another format before transmitting it on to 1134another destination. 1135INTERCEPTORS are capabilities that receive a message and use the 1136message content to trigger a secondary action; generally, the 1137interceptors pass the message unaltered to the next step in a 1138process. Most interceptors capture information from the 1139message for reporting or analytical purposes. 6 1140Routers, transformers, and interceptors are collectively called 1141INTERMEDIARIES. An intermediary is any capability that receives 1142messages from a consumer and subsequently, as a service 1143consumer itself, interacts with another service. The term 1144“intermediary” indicates that these capabilities sit between 1145other services and “mediate” the interaction by managing, 1146controlling, brokering, or facilitating the transmission of 1147messages between them. 1148Routers and transformers are useful mechanisms for 1149decoupling the senders and recipients of messages. They 1150tend to centralize and share certain kinds of logic so that the 1151logic can be maintained independently of the provider and 1152consumer capabilities at the edges; sharing also improves the 1153likelihood of reuse, since it is easier to reuse functionality if it 1154encapsulates a single task. 1155Support for router, transformer, and orchestration capabilities 1156is a common feature in many integration platforms, and 1157therefore support for these capabilities is a consideration in 1158choice of execution context (discussed on page 32). 1786 The concept of interceptor defined here is similar to, but separate and 179distinct from, the notion of an interceptor as defined in the SOAP protocol 180[reference needed to SOAP standard]. The definition of this concept in JRA 181is not intended to imply any implementation technique or technology. 182 183 42
  • 43. 184Justice Reference Architecture DRAFT 185 1159Routing, transformation, and orchestration capabilities are well 1160understood and well documented in the integration 1161architecture literature. The most common flavors of these 1162capabilities have been collected into pattern form as ENTERPRISE 1163INTEGRATION PATTERNS. (Patterns web site) JRA incorporates these 1164patterns by reference. 1165Orchestrations and intermediaries are a key component in 1166implementing business process models and also lead to the 1167formation of service/capability hierarchies. 1168 Service Policies, Service Contracts, and Service Agreements 1169SERVICE POLICIES and SERVICE CONTRACTS express rules that govern the 1170interaction between a service consumer and a service. A 1171policy is an assertion by either a consumer or service provider 1172of that participant’s requirements for willingness to interact. A 1173policy also has an enforcement aspect and must be stated in 1174such a way as to permit enforcement. A SERVICE CONTRACT is an 1175agreement by the parties involved, and there is a process 1176associated with the agreement action. Whereas a policy is an 1177assertion by one participant in the interaction, a contract is an 1178agreement between the participants that expresses some 1179expectation or requirement of the interaction. And whereas 1180policy enforcement is generally the responsibility of the 1181participant who asserts the policy, contract enforcement may 1182involve resolution of disputes that arise between the parties. 1183A SERVICE AGREEMENT is a document that establishes policies and 1184contractual elements for a given interaction or set of 1185interactions (that is, for one or more services). 1186 Execution Context 1187EXECUTION CONTEXT is “the set of infrastructure elements, process 1188entities, policy assertions, and agreements that are identified 1189as part of an instantiated service interaction.” (SOA-RM, p. 24) 1190Execution context is the primary enabler of the reachability 1191aspect of visibility. Execution context includes the set of 1192infrastructure elements that provide a physical communication 1193path between service consumers and services. 186 187 43
  • 44. 188Justice Reference Architecture DRAFT 189 1194JRA considers execution context to be primarily the supporting 1195infrastructure elements that permit service consumers and 1196services to interact. These infrastructure elements consist of: 1197 • Data networks used by service consumers and 1198 services to exchange information. 1199 • Integration infrastructure (hardware and 1200 software) that makes service interfaces available 1201 and handles higher-level message routing, 1202 transformation, and orchestration. 1203 • Common capabilities that support service 1204 interaction; examples include access control 1205 services, policy decision services, public key 1206 infrastructure (PKI), and metering services. 1207Execution context can implement (or support the 1208implementation of) some service interaction requirements, 1209such as reliability and availability. Service interaction profiles, 1210contracts, and policies can constrain the behavior of execution 1211context elements by requiring particular technologies or 1212techniques or establishing service level policies, for example. 1213Finally, execution context can support intermediary capabilities 1214(as defined above) directly in the integration infrastructure, 1215such as routers, transformers, interceptors, and 1216orchestrations. 190 191 44
  • 45. 192Justice Reference Architecture DRAFT 193 1217 Illustration Scenarios 1218In version 1.4 of the JRA, this section will include scenarios that 1219illustrate the concepts in the architecture. 194 195 45
  • 46. 196Justice Reference Architecture DRAFT 197 1220 Elaboration of JRA Concepts 1221The purpose of this section is to establish a direction and initial 1222“straw model” for the components to be defined in detail 1223within JRA. Note that many of these components are currently 1224deliverables within the JRA Work Plan for the 2006 time frame. 1225The GISWG will develop these concepts in incremental steps 1226over time as noted in the Plan. The components that are future 1227deliverables and the other concepts that are more mature are 1228also listed below. 1229Inversion 1.4 of JRA, this section will change to be a list of 1230pointersto additional documents that fully elaborate and define 1231some of the concepts in JRA. 1232 Services and Related Deliverables 1233 The JRA deliverables related to services are documented in 1234 this section. To cross reference the definitions of 1235 corresponding concepts in this section, see page 31. 1236 Services 1237The SEARCH Justice Information Exchange Model (JIEM) 1238Reference Model 1.1 will be used as the starting point to define 1239services in JRA. The list of key Information Exchange Package 1240Documentation (IEPD) that have already been developed will 1241be used to further narrow the initial list of services to define. 1242(See http://it.ojp.gov/iepd/.) 1243 Service Design Principles 1244Note: In version 1.4 of JRA, this list of principles will be 1245removed and replaced (in a separate document) with the 1246service design principles developed by the Services 1247Committee. 1248The following initial list of service design principles is 1249summarized from the text by Thomas Erl. (Erl) 1250 • Services should be designed for reuse. 1251 • Services should be designed so that they may 1252 participate in a composition with other services to 1253 form a higher-level service. 198 199 46
  • 47. 200Justice Reference Architecture DRAFT 201 1254 • Services should share only a formal contract with 1255 their consumers. Consumers are dependent only 1256 on the service’s interface, not the 1257 implementation details of the capability to which 1258 the service provides access. 1259 • Services are stateless, meaning that during an 1260 interaction with a service, a service consumer 1261 supplies all information necessary to conduct the 1262 interaction and makes no assumptions about 1263 information retained from prior interactions. 1264 Future Service Deliverables 1265 • Identification of Service Definitions 1266 • Service Specification Guidelines 1267 Business Process Models 1268 Business Process Models are explained starting on page 34. 1269Although not part of the normative JRA, these business 1270process models may be drawn from normative guidance within 1271specific communities for specific services, such as fusion 1272centers or the exchange of classified intelligence data. They 1273are also useful as guides to more complex orchestrated 1274services that support core business processes within the 1275justice community. 1276 Interaction, Service Models, and Related Concepts 1277 To cross reference the concepts and related deliverables in 1278 this section, please see page 35. 1279 Domain Vocabularies 1280 The domain vocabulary for JRA is the Global Justice XML Data 1281 Model (Global JXDM) Version 3.0.3. Information about the 1282 data model can be accessed at: 1283 http://it.ojp.gov/jxdm 1284An expanded data model drawing on parts of the National 1285Information Exchange Model (NIEM) may be incorporated. 1286Information on its status may be obtained at: 202 203 47
  • 48. 204Justice Reference Architecture DRAFT 205 1287 http://www.niem.gov 1288 Registries/Repositories 1289Several SOA registries are now under pilot development in the 1290justice community and could potentially be used to host JRA. 1291Further research is being compiled, and the documentation 1292listed below is currently under development. 1293 Future Interaction and Service Model Deliverables 1294The GISWG is currently evaluating various approaches to best 1295elaborate the following components. These components will 1296be completed as part of the JRA Work Plan, and will be 1297documented once the deliverables have been solidified. 1298 • Registries/Repositories Principles 1299 • Registries/Repositories Requirements 1300 • Registries/Repositories Guidelines 1301 • Service Description 1302 • Service Modeling Guidelines 1303 Design and Description of Service Interfaces 1304 As a cross reference, the concepts and related deliverables in 1305 this section correspond to the concepts that are explained in 1306 the section starting on page 39. The JRA Work Plan includes 1307 the following deliverables. 1308 Service Interaction Requirements 1309The following is an initial list of candidate service interaction 1310requirements. Note that when these requirements refer to 1311“Service Consumer,” this is not a human being, but an 1312information system that interacts with a service. This is 1313consistent with the JRA usage of the term, as defined on page 131422. 1315 • Service Consumer Authentication: Information provided 1316 with messages transmitted from service 1317 consumer to service that verifies the identity of 1318 the consumer. 206 207 48
  • 49. 208Justice Reference Architecture DRAFT 209 1319 • Service Consumer Authorization: Information provided 1320 with messages transmitted from service 1321 consumer to service that documents the 1322 consumer’s authorization to perform certain 1323 actions on and/or access certain information via 1324 the service. 1325 • Identity and Attribute Assertion Transmission: Information 1326 provided with messages transmitted from service 1327 consumer to service that asserts the validity of 1328 information about a human or machine, including 1329 its identity. 1330 • Service Authentication: The ability of a service to 1331 provide a consumer with information that 1332 demonstrates the service’s identity to the 1333 consumer’s satisfaction. 1334 • Message Nonrepudiation: Information provided in a 1335 message to allow the recipient to prove that a 1336 particular authorized sender in fact sent the 1337 message. 1338 • Message Integrity: Information provided in a message 1339 to allow the recipient to verify that the message 1340 has not changed since it left the control of the 1341 sender. 1342 • Message Confidentiality: Information provided in a 1343 message to prevent anyone except an authorized 1344 recipient from reading the message or parts of 1345 the message. 1346 • Message Addressing: Information provided in a 1347 message that indicates where a message 1348 originated, the ultimate destination of the 1349 message (beyond physical end point), a specific 1350 recipient to whom the message should be 1351 delivered (this includes sophisticated metadata 1352 designed specifically to support routing), and a 1353 specific address or entity to which reply 1354 messages (if any) should be sent. 1355 • Reliability: Information provided with messages to 1356 permit message senders to receive notification of 1357 the success or failure of message transmissions, 1358 and to permit messages sent with specific 210 211 49
  • 50. 212Justice Reference Architecture DRAFT 213 1359 sequence-related rules either to arrive as 1360 intended, or fail as a group. 1361 • Transaction Support: Information provided with 1362 messages to permit a sequence of messages to 1363 be treated as an atomic transaction by the 1364 recipient. 1365 • Service Metadata Availability: The ability of a service to 1366 capture and make available (via query) metadata 1367 about the service. Metadata is information that 1368 describes or categorizes the service and often 1369 assists consumers in interacting with the service 1370 in some way. 1371 Service Interaction Profiles 1372Several service interaction profiles have already been 1373prioritized for development: Web services, MQ, JMS, ebXML, 1374fixed wireless, and mobile wireless. A draft of the Web 1375services service interaction profile is available as part of the 1376OASIS Legal XML Electronic Court Filing 3.0 committee draft 1377specification. 1378 Message Exchange Patterns 1379JRA will identify the following message exchange patterns: 1380The FIRE-AND-FORGET pattern calls for the sender of a message 1381(which could be the service consumer or service) to send the 1382message and not expect a reply message back from the 1383recipient. This pattern is useful for one-way transmission of 1384information, such as notification that an event has occurred. 1385The REQUEST-REPLY pattern calls for the sender of a message to 1386send the message and expect a reply back from the recipient. 1387These two patterns are considered “primitive” patterns, in 1388that they are the fundamental building blocks of more complex 1389information exchange scenarios. For instance, the complex 1390PUBLISH-SUBSCRIBE pattern involves an initial request-reply exchange 1391inwhich the subscriber subscribes to a service, followed by 1392the service using the fire-and-forget pattern to notify 1393subscribers of an event. 214 215 50
  • 51. 216Justice Reference Architecture DRAFT 217 1394Future Service Interaction Deliverables 1395 • Service Interaction Profile Guidelines 1396 • Interface Description Requirements 1397 • Message Definition Mechanisms 1398 Capabilities in Detail and Related Components 1399 To cross reference the concepts and related deliverables in 1400 this section, please review page 41. The JRA Work Plan 1401 includes the following deliverables. 1402 Provisioning Models 1403Although not part of the normative JRA, best practices for 1404PROVISIONING MODELS provide guidance on how best to implement key 1405facilitationservices like message validation, orchestration, 1406routing, and transformation using intermediaries or other 1407means. The GISWG plans on documenting Provisioning Model 1408Guidelines and Principles. 1409 Enterprise Integration Patterns 1410Although not part of the normative JRA, the existing best 1411practices can be combined with the provisioning models to 1412indicate preferred approaches to the implementation of key 1413services within a community. The GISWG will adopt existing 1414best practices by reference. (Patterns) 1415 Future Deliverables 1416 • Orchestration Guidelines 1417 • Orchestration Principles 1418 • Orchestration Mechanisms 1419 Policies, Contracts, and Agreements 218 219 51
  • 52. 220Justice Reference Architecture DRAFT 221 1420 Model Policies and Contracts 1421It is possible for every JRA service provider to establish a 1422unique set of policies and business requirements for each 1423service. This approach would create almost insurmountable 1424barriers to the widespread consumption of services for cost 1425reasons alone. The definition of model policies and contracts 1426will provide reusable policies across common services and 1427sets of related services, based on national policies on security, 1428privacy, and other policy requirements. Given the current local 1429and state variations in policy based on statute and court rule, 1430these model policies must necessarily be aspirational initially. 1431The GISWG will develop and recommend potential model 1432policies and contracts. 1433 Model Agreements 1434These model agreements (termed memorandum of 1435understanding [MOUs], etc.), together with model contracts, 1436lay out standard provisions for consuming JRA services. The 1437GISWG will develop and recommend potential model 1438agreements. 1439 Execution Context 1440Version 1.4 of the JRA specification will reference an initial 1441elaboration of the Execution Context concept. 222 223 52
  • 53. 224Justice Reference Architecture DRAFT 225 1442 Other Considerations 1443This document does not identify everything necessary for a 1444successful approach to interoperability among various justice 1445information systems. Other essential factors that need to be 1446addressed but that are not addressed in this document are 1447governance, detailed systems designs, infrastructure 1448specification, or specification of interfaces between justice 1449systems. These other factors will likely relate to concepts and 1450components in JRA, so as companion documents that address 1451these other factors are developed, they should reference JRA 1452when appropriate. 1453 Governance 1454The issue of interoperability among justice and public safety 1455informationsystems raises a set of governance and decision- 1456making questions, such as: 1457 • Under what circumstances and through what 1458 process is a shared interface to an information 1459 system allowed to change? 1460 • Through what process does the organization 1461 assess the compliance of system interfaces with 1462 architectural standards? 1463 • Through what process does the organization 1464 adopt new architectural standards or change 1465 existing ones? 1466 • How does the organization reach agreement on 1467 the meaning of information exchanged between 1468 interoperable systems? 1469 • How do partners enforce agreements and 1470 resolve disputes? 1471Governance business processes and standards will be 1472delivered as a companion document to JRA. Governance 1473areas of particular concern include registries, intermediaries, 1474orchestration, and the execution context. JRA currently does 1475not include these and other aspects of political governance 1476that underpin or support the technical architecture. 1477Technical governance is another area that remains to be 1478specified. Issues like change control and version management 226 227 53
  • 54. 228Justice Reference Architecture DRAFT 229 1479go beyond political decisions to practical administration when 1480operational systems implement a set of technical standards. 1481The governance document will include at least the following 1482deliverables: 1483 • Model policies, agreements, and contracts 1484 • IEPD and Service Interaction Profile (SIP) 1485 governance processes 1486 • Principles for registries, orchestration, services, 1487 and provisioning models 1488 Investment Strategies 1489JRA does not offer guidance on how to fund the 1490implementation of execution context (in particular, 1491infrastructure to support service interaction via messages) or 1492the design and implementation of individual services. 1493Identifying high-value and modest-risk services for initial 1494implementation is an important success factor in the 1495establishment of an SOA, borne out by experiences in many 1496domains. The reader is advised to consult material from other 1497sources on technology investment strategies and the 1498provisioning of shared and consolidated services. In particular, 1499the National Association of State Chief Information Officers 1500(NASCIO) has published useful guidance in this area, including 1501the NASCIO Enterprise Architecture Toolkit. 1502 System Design 1503JRA does not include actual applications nor does it propose a 1504design of any information system. The requirements addressed 1505by JRA focus on the interoperability of systems, not the 1506systems themselves. JRA does identify the need for a set of 1507design guidelines that should impact information system design 1508choices. But these guidelines will address only the integration 1509aspects of systems in support of business processes that 1510involve the sharing of justice information. 1511JRA is a set of reference standards and guidelines that such 1512systems may implement to improve interoperability and 1513information sharing. Global will reach out to existing local, 1514state, tribal, and national systems to incorporate the JRA 1515specification into their technical strategies. 230 231 54
  • 55. 232Justice Reference Architecture DRAFT 233 1516 Infrastructure Specifications 1517Though the concept of execution context defined above 1518includes the physical infrastructure necessary to support 1519service interaction, JRA does not identify specific networks nor 1520does it propose a detailed design for an infrastructure to 1521support systems integration. Requirements for integration 1522infrastructure could be derived from further elaboration and 1523specification of some of the concepts and components 1524documented in JRA. 1525 System Interfaces 1526JRA does not identify specific interfaces between systems. It 1527is intended to provide a framework or road map for the 1528definition of these interfaces. Specific services based on the 1529JRA set of policies, guidelines, and standards may be 1530implemented by any system that finds it useful as a guide. The 1531governance document may separately recommend that certain 1532systems implement certain services or that certain types of 1533organizations consume services from particular systems, but 1534that is beyond the scope of JRA. 234 235 55
  • 56. 236Justice Reference Architecture DRAFT 237 1535 Glossary 1536Architecture 1537 A set of artifacts (that is: principles, guidelines, policies, 1538 models, standards, and processes) and the relationships 1539 between these artifacts that guide the selection creation 1540 and implementation of solutions aligned with business 1541 goals. 1542Awareness 1543 A state whereby one party has knowledge of the 1544 existence of the other party. Awareness does not imply 1545 willingness or reachability. 1546Behavior Model 1547 The characterization of, and responses to, temporal 1548 dependencies between the actions on a service. 1549Business Process Models 1550 A description (usually formal and often graphical) of a 1551 series of activities that culminate in the achievement of 1552 some outcome of business value. Some (but not 1553 necessarily all) of the steps in this series of activities 1554 involve producing a real-world effect provided by a 1555 capability, and some of the steps require a consumer to 1556 use a service. Each one of these steps, then, provides 1557 the contextual justification for service interaction between 1558 a particular consumer and particular provider. 1559Capabilities 1560 Real-world effect(s) that service provider(s) are able to 1561 provide to a service consumer. 1562Consumer Systems 1563 The information system that gains access to another 1564 partner’s capability offered by means of a service. 1565Domain Vocabularies 1566 Includes canonical data models, data dictionaries, and 1567 markup languages that standardize the meaning and 1568 structure of information for a domain. Domain 1569 vocabularies can improve the interoperability between 238 239 56
  • 57. 240Justice Reference Architecture DRAFT 241 1570 consumer and provider systems by providing a neutral, 1571 common basis for structuring and assigning semantic 1572 meaning to information exchanged as part of service 1573 interaction. Domain vocabularies can usually be 1574 extended to address information needs specific to the 1575 service interaction or to the business partners integrating 1576 their systems. 242 243 57
  • 58. 244Justice Reference Architecture DRAFT 245 1577Enterprise Integration Patterns 1578 Enterprise integration has to deal with connecting multiple 1579 applications running on multiple platforms in different 1580 locations. Enterprise Integration Patterns help integration 1581 architects and developers design and implement 1582 integration solutions more rapidly and reliably. Most of 1583 the patterns assume a basic familiarity with messaging 1584 architectures. However, the patterns are not tied to a 1585 specific implementation. 1586Execution Context 1587 The set of technical and business elements that form a 1588 path between those with needs and those with 1589 capabilities and that permit service providers and 1590 consumers to interact. 1591Framework 1592 A set of assumptions, concepts, values, and practices 1593 that constitutes a way of viewing the current 1594 environment. 1595Information Model 1596 The characterization of the information that is associated 1597 with the use of a service. The scope of the information 1598 model includes the format of information that is 1599 exchanged, the structural relationships within the 1600 exchanged information, and the definition of terms used. 1601Interaction 1602 The activity involved in making use of a capability offered, 1603 usually across an ownership boundary, in order to 1604 achieve a particular desired real-world effect. 1605Interface Description Requirements 1606 Establishes common characteristics of service interface 1607 descriptions. These requirements address areas such as 1608 required interface contents, naming rules, documentation 1609 rules, and specification of a standard structure and 1610 format for descriptions. 1611Interceptors 246 247 58
  • 59. 248Justice Reference Architecture DRAFT 249 1612 Interceptors are capabilities that receive a message and 1613 use the message content to trigger a secondary action; 1614 generally, the interceptors pass the message unaltered 1615 to the next step in a process. 1616Intermediaries 1617 Routers and transformers are collectively called 1618 intermediaries. This term indicates that routers and 1619 transformers generally sit between other services and 1620 “mediate” the interaction by managing the transmission 1621 of messages between them or by reformatting messages 1622 in transit. 1623Justice Reference Architecture 1624 JRA is an abstract framework for understanding 1625 significant components and relationships between them 1626 within a service-oriented environment. It lays out 1627 common concepts and definitions as the foundation for 1628 the development of consistent service-oriented 1629 architecture (SOA) implementations within the justice and 1630 public safety communities. The term refers to the 1631 modular architecture that cleanly and appropriately 1632 identifies and separates technical and governance layers 1633 so that standards can be developed to improve 1634 interoperability. JRA is being developed by Global; it 1635 leverages the work of others, such as the state of 1636 Washington, and builds upon the work of OASIS. 1637Messages 1638 The entire “package” of information sent between 1639 service consumer and service (or vice versa), even if 1640 there is a logical partitioning of the message into 1641 segments or sections. 1642Message Definition Mechanisms 1643 Establishes a standard way of defining the structure and 1644 contents of a message; for example, Global JXDM- or 1645 NIEM-conformant schema sets. Note that since a 1646 message includes the concept of an “attachment,” the 1647 message definition mechanism must identify how 1648 different sections of a message (for example, the main 1649 section and any “attachment” sections) are separated 1650 and identified and how attachment sections are 1651 structured and formatted. 250 251 59
  • 60. 252Justice Reference Architecture DRAFT 253 1652Message Exchange Patterns 1653 Identifies common sequences of message transmission 1654 between service consumers and services. They provide 1655 a label to a series of message transmissions that have 1656 some logical interrelationship. 1657Message Validators 1658 An intermediary that examines a message to ensure that 1659 the contents adhere to established business rules. 1660Orchestrations 1661 A capability that coordinates interaction with multiple 1662 services. An orchestration is often implemented using an 1663 open industry standard implementation mechanism 1664 (referred to as an orchestration mechanism in JRA), 1665 which allows the implementation to be shared across 1666 tools and platforms. 1667Process Model 1668 The characterization of the temporal relationships 1669 between and temporal properties of actions and events 1670 associated with interacting with the service. 254 255 60
  • 61. 256Justice Reference Architecture DRAFT 257 1671Provider Systems 1672 The information system that offers the use of capabilities 1673 by means of a service. 1674Provisioning Models 1675 The responsibility/models for making a service available 1676 to customers in a manner consistent with formal (or 1677 occasionally informal) customer expectations. 1678Reachability 1679 The ability of a service consumer and service provider to 1680 interact. Reachability is an aspect of visibility. 1681Real-World Effects 1682 The actual result(s) of using a service, rather than merely 1683 the capability offered by a service provider. 1684Reference Architecture 1685 A reference architecture is an architectural design 1686 pattern that indicates how an abstract set of mechanisms 1687 and relationships realizes a predetermined set of 1688 requirements. 1689Reference Model 1690 A reference model is an abstract framework for 1691 understanding significant relationships among the entities 1692 of some environment that enables the development of 1693 specific reference or concrete architectures using 1694 consistent standards or specifications supporting that 1695 environment. 1696 A reference model consists of a minimal set of unifying 1697 concepts, axioms, and relationships within a particular 1698 problem domain, and is independent of specific 1699 standards, technologies, implementations, or other 1700 concrete details. 1701Repository 1702 Stores models and interface descriptions in a central 1703 location that is accessible to appropriate stakeholders. A 1704 repository will permit searching for models and interface 1705 descriptions based on a range of identifying criteria. A 258 259 61
  • 62. 260Justice Reference Architecture DRAFT 261 1706 repository will also map logical service identifiers with 1707 physical addresses. 1708Routers 1709 A capability that receives a message, examines it, and 1710 transmits it to one or more destinations based on the 1711 contents. In general, routers can be designed to operate 1712 on any of the information contained within the message; 1713 they may use information about the origin of the 1714 message, routing directive information contained within 1715 the message or the main content of the message itself. 262 263 62
  • 63. 264Justice Reference Architecture DRAFT 265 1716Services 1717 The means by which the needs of a consumer are 1718 brought together with the capabilities of a provider. 1719Service Agreements 1720 A document that establishes policies and contractual 1721 elements for a given interaction or set of interactions 1722 (that is, for one or more services). 1723Service Consumers 1724 An entity that seeks to satisfy a particular need through 1725 the use of capabilities offered by means of a service. 1726Service Contracts 1727 An agreement by two or more parties regarding the 1728 conditions of use of a service. 1729Service Design Principles 1730 The documentation to provide consistent guidance 1731 regarding the overall partitioning of capabilities into 1732 services and the relationships between services. 1733Service Interaction Profiles 1734 Defines a family of industry standards or other 1735 technologies or techniques that together demonstrate 1736 implementation or satisfaction of: 1737 o Service interaction requirements. 1738 o Interface description requirements. 1739 o Message exchange patterns. 1740 o Message definition mechanisms. 1741 Service interaction profiles are included in JRA to promote 1742 interoperability without forcing the organization to agree 1743 on a single way of enabling service interaction. Each 1744 service interface will support a single profile; a service 1745 will have multiple interfaces if it supports multiple profiles. 1746Service Interaction Requirements 1747 Define common rules of service interaction. Typically, 1748 these requirements are nonfunctional in nature, in that 1749 they are not directly related to the capability used by the 1750 service consumer, nor are they related to the real-world 1751 effect resulting from use of that capability. Rather, the 266 267 63
  • 64. 268Justice Reference Architecture DRAFT 269 1752 requirements enforce (or support the enforcement of) 1753 policies or contracts or otherwise protect the interests of 1754 particular business partners or the business organization 1755 overall. 1756Service Interfaces 1757 The means by which the underlying capabilities of a 1758 service are accessed. 270 271 64
  • 65. 272Justice Reference Architecture DRAFT 273 1759Service Model 1760 Interaction depends on two things. First, the designers of 1761 potential consumers need to be able to find services and, 1762 once found, establish a physical interaction mechanism 1763 with them. Second, the designers of potential consumers 1764 need a description of the actions that can be performed 1765 on a service, as well as the structure and meaning of 1766 information exchanged during the interaction. These 1767 needs are addressed by the concept of a service’s 1768 information model and behavioral model, collectively 1769 called service models in JRA. 1770Service Modeling Guidelines 1771 Documents guidelines for services provided and 1772 consumed among partners. It provides guidance as well 1773 as compliance information regarding the modeling and 1774 description of services to promote consistency. 1775Service-Oriented Architecture (SOA) 1776 Service-Oriented Architecture is a paradigm for 1777 organizing and utilizing distributed capabilities that may 1778 be under the control of different ownership domains. It 1779 provides a uniform means to offer, discover, interact with, 1780 and use capabilities to produce desired effects 1781 consistent with measurable preconditions and 1782 expectations. 1783Service Policies 1784 A statement of obligations, constraints, or other 1785 conditions of use, deployment, or description of an 1786 owned entity as defined by any participant. 1787Service Providers 1788 An entity (person or organization) that offers the use of 1789 capabilities by means of a service. 1790Transformers 1791 A capability that receives a message and transforms it 1792 into another format before transmitting it on to another 1793 destination. 1794Visibility 274 275 65
  • 66. 276Justice Reference Architecture DRAFT 277 1795 The capacity for those with needs and those with 1796 capabilities to be able to interact with each other. 1797Willingness 1798 A predisposition of service providers and consumers to 1799 interact. 1800 278 279 66
  • 67. 280Justice Reference Architecture DRAFT 281 1801 References 1802 1803Erl Erl, Thomas. Service-Oriented Architecture: 1804 Concepts, Technology, and Design. Prentice- 1805 Hall, 2005 1806GISWG GISWG. A Framework for Justice 1807 Information Sharing: Service-Oriented 1808 Architecture. Global, December 9, 1809 2004. 1810Patterns Hohpe, Gregor, and Woolf, Bobby. 1811 Enterprise Integration Patterns: Designing, 1812 Building, and Deploying Messaging Solutions. 1813 Addison Wesley, 2004. 1814 http://www.eaipatterns.com 1815Sholler Sholler, Daniel. Demystifying Service- 1816 Oriented Architecture, META Practice, 1817 June 9, 2004. 1818SOA-RM Reference Model for Service-Oriented Architecture 1819 1.0, Committee Specification 1. OASIS, July 1820 19, 2006. http://www.oasis- 1821 open.org/ 1822 1823 1824 1825 1826 Document History 1827 Date Versi Editor Change on March 25, 1.0 Scott Came Initial Draft 2006 282 283 67
  • 68. 284Justice Reference Architecture DRAFT 285 Date Versi Editor Change on March 28, 1.0 Tish Editorial changes and 2006 Cunningham IIR QC Kim Geer May 1, 2006 1.1 Monique La Integrate comments Bare from EAC, glossary, introduction, acknowledgements, insert scenario, editing page numbers June 1, 2006 1.1 Tom Clarke Elaboration of concepts and principles. June 28, 1.1 Reordered elaboration 2006 of concepts, added warrant scenario November 2, 1.? Scott Came Consistency edits 2006 Edits resulting from October GISWG meetings Reflect comments of Iveta Topalova and Martin Smith December 6, 1.3 Kim Geer Formatting 2006 Dolores Editorial changes and Parker IIR quality control 1828 1829 286 287 68