The Justice Reference Architecture (JRA) was developed ...

510 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
510
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
15
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

The Justice Reference Architecture (JRA) was developed ...

  1. 1. 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35
  2. 2. 1Justice Reference Architecture Specification Version 1.7 2 36 Table of Contents 37 Table of Contents............................................................................................................................i 38 Acknowledgements........................................................................................................................ii 39 The Justice Reference Architecture (JRA) was developed through a collaborative effort of the 40Global Justice Information Sharing Initiative (Global), Office of Justice Programs (OJP), U.S. 41Department of Justice (DOJ)...........................................................................................................ii 42 Global aids its member organizations and the people they serve through a series of important 43initiatives. These include the facilitation of Global Working Groups. The Global 44Infrastructure/Standards Working Group (GISWG) is one of five Global Working Groups covering 45critical topics such as intelligence, privacy, security, outreach, and standards. The GISWG is 46under the direction of Tom Clarke, Ph.D., National Center for State Courts. The GISWG consists 47of three committees—Management and Policy, Services Implementation, and Enterprise 48Architecture.....................................................................................................................................ii 49 Although this document is the product of Global and its GISWG membership, 50it was adapted primarily from the technical reference architecture developed by 51the state of Washington, and sincere appreciation is expressed to Mr. Scott Came, state of 52Washington and SEARCH, The National Consortium for Justice Information and Statistics, for his 53guidance and leadership. In addition, parts of the architecture were derived from the 54Organization for the Advancement of Structured Information Standards (OASIS) Reference Model 55for Service-Oriented Architecture 1.0 56(SOA-RM). Other major contributors include the OASIS Court Filing Technical Committee, 57OASIS SOA-RM Technical Committee, and the Messaging Focus Group. ....................................ii 58 Although all members of the GISWG are recognized for their contributions and for volunteering 59their time to the development of the architecture, Global would also like to recognize the 60members of the GISWG Executive Architecture Committee..........................................................iii 61 How to Use This Document...........................................................................................................iv 62 Policymakers, Executives, and Decision Makers..............................................................iv 63 Project Managers, Architects, and Technologists.............................................................iv 64 Document Conventions.................................................................................................................vi 65 Executive Summary.........................................................................................................vii 661. Introduction.................................................................................................................................1 67 1.1. Global’s SOA Initiative................................................................................................1 68 1.2. An Interoperability Strategy.........................................................................................2 69 1.3. Consensus on the OASIS Reference Model for SOA.................................................4 70 1.4. Creating the JRA.........................................................................................................5 71 1.5. What Is the JRA?........................................................................................................6 72 1.6. What the JRA Is Not....................................................................................................6 732. Architecture Requirements.........................................................................................................8 74 This section documents the business requirements to be addressed and satisfied by the 75 JRA. These requirements are stated in the form of principles, the intent of which is to guide 76 and constrain the choices made in developing the architecture...............................................8 773. The JRA....................................................................................................................................15 3 i
  3. 3. 4Justice Reference Architecture Specification Version 1.7 5 78 3.1. Graphical Overview...................................................................................................15 794. Concepts and Relationships.....................................................................................................17 80 OASIS Reference Model for Service-Oriented Architecture .................................................17 81 Core Concepts—Services, Service Consumers, Capabilities, and Real-World Effects.........18 82 Supporting Concepts.............................................................................................................20 83 Interaction, Visibility, Service Models, and Service Interfaces...............................................20 84 Design and Description of Service Interfaces........................................................................26 85 Capabilities in Detail..............................................................................................................28 86 Service Policy, Service Contract, and Service Agreement....................................................31 87 Execution Context.................................................................................................................31 88 Provisioning Model................................................................................................................32 895. Reconciliation of Architecture With Principles...........................................................................33 906. Elaboration of Service Interaction Requirements......................................................................37 917. Glossary....................................................................................................................................39 928. References...............................................................................................................................47 939. Document History.....................................................................................................................49 94 Acknowledgements 95 The Justice Reference Architecture (JRA) was developed 96 through a collaborative effort of the Global Justice 97 Information Sharing Initiative (Global), Office of Justice 98 Programs (OJP), U.S. Department of Justice (DOJ). 99 Global aids its member organizations and the people they 100 serve through a series of important initiatives. These 101 include the facilitation of Global Working Groups. The Global 102 Infrastructure/Standards Working Group (GISWG) is one of 103 five Global Working Groups covering critical topics such as 104 intelligence, privacy, security, outreach, and standards. The 105 GISWG is under the direction of Tom Clarke, Ph.D., National 106 Center for State Courts. The GISWG consists of three 107 committees—Management and Policy, Services 108 Implementation, and Enterprise Architecture. 109 Although this document is the product of Global and its 110 GISWG membership, 111 it was adapted primarily from the technical reference 112 architecture developed by 113 the state of Washington, and sincere appreciation is 114 expressed to Mr. Scott Came, state of Washington and 6 ii
  4. 4. 7Justice Reference Architecture Specification Version 1.7 8 115 SEARCH, The National Consortium for Justice Information 116 and Statistics, for his guidance and leadership. In addition, 117 parts of the architecture were derived from the Organization 118 for the Advancement of Structured Information Standards 119 (OASIS) Reference Model for Service-Oriented Architecture 120 1.0 121 (SOA-RM). Other major contributors include the OASIS 122 Court Filing Technical Committee, OASIS SOA-RM Technical 123 Committee, and the Messaging Focus Group. 124 Although all members of the GISWG are recognized for their 125 contributions and for volunteering their time to the 126 development of the architecture, Global would also like to 127 recognize the members of the GISWG Executive 128 Architecture Committee. 129Mr. Scott Came—State of Washington and SEARCH, The 130NationalConsortium for Justice Information and Statistics, 131GISWG Services Implementation Committee 132Dr. Tom Clarke—National Center for State Courts, Chair, 133GISWG 134Mr. Scott Fairholm—National Center for State Courts, Chair, 135GISWG Services Committee (2005–2008) 136Mr. Dale Good—Judicial Council of California, Chair, GISWG 137Management and Policy Committee 138Mr. Kael Goodman—IJIS Institute, Chair, GISWG Services 139Interaction Committee (2005–2007) 140Mr. Ron Hawley—SEARCH, The National Consortium for Justice 141Information and Statistics, GISWG Management and Policy 142Committee Chair (2005–2006) 143Mr. Eric Sweden—National Association for State Chief 144Information Officers, Vice Chair, GISWG (2005–2008) 9 iii
  5. 5. 10Justice Reference Architecture Specification Version 1.7 11 145 How to Use This Document 146 Policymakers, Executives, and Decision Makers 147Global is committed to providing Service-Oriented Architecture 148(SOA) resources, such as this document, to local, state, 149regional, tribal, and federal justice and public safety 150organizations. As additional resources become available, 151these materials will demonstrate the value of the architecture 152to the stakeholders in a way that is targeted to their particular 153needs. Other planned resources include strategy, executive 154summary, case studies from early implementers, management 155and policy, and other planning briefings, which will target 156managers, chiefs, and executives. 157For the purposes of this document, Global has selected a 158distinguished group of technical and domain representatives 159from a group of skilled peers who have volunteered to develop 160this material as a starting point in establishing the Justice 161Reference Architecture (JRA). 162Keep in mind that the sections in this document referencing the 163conceptual diagram, high-level components, and relationships 164establish definitions that are intended for use by technical 165architects and project managers who are responsible for 166identifying all the elements necessary within their jurisdictions 167to implement SOA. This document is intended as a formal and complete 168architectural specification for people with previous knowledge of technical 169architecture, service-oriented architecture, and supporting industry standards 170(such as Web services). 171 Project Managers, Architects, and Technologists 172This report is intended as a resource for a technical audience, 173including Global Justice XML Data Model (Global JXDM) and 174National Information Exchange Model (NIEM) implementers, 175architects, developers, system integrators, and other justice 176and public safety technical practitioners. 177 178Itprovides the background and concepts—a strong foundation 179—required for the implementation of SOA. The JRA is a new 12 iv
  6. 6. 13Justice Reference Architecture Specification Version 1.7 14 180term coined for the justice community, and it is derived from 181the OASIS Reference Model for Service-Oriented Architecture 1821.0 [SOA-RM]. The reader should refer to the SOA-RM for more 183detailed information about many of the concepts in this 184document. JRA is intended to facilitate your SOA 185implementation by establishing a common language that can 186be used to exchange data with partner organizations. 15 v
  7. 7. 16Justice Reference Architecture Specification Version 1.7 17 187 Document Conventions 188In this document, use of a bold small-caps typeface, as in this 189EXAMPLE, indicates an important concept or a term defined either 190inthe glossary or in the body of the text at the point where the 191term or concept is first used. 192 193In this document, use of a bold caps typeface, as in this 194[EXAMPLE], indicates an important resource document noted in the 195Reference Section of this document. 18 vi
  8. 8. 19Justice Reference Architecture Specification Version 1.7 20 196 Executive Summary 197In2004, Global endorsed service-oriented architecture (SOA) 198as a recommended strategy for integrating justice information 199systems. This document—the Justice Reference Architecture 200Specification—is a first step towards achieving this vision. 201SOA promises many benefits to state, local, and tribal justice 202partners. It promotes the sharing of information in a manner 203that maximizes agility—the ability of partners to change 204business processes and technology solutions rapidly at 205minimum cost. In today’s dynamic justice business 206environment, this is more important than ever. It also gives 207justice partners a set of tools that allow them to share 208infrastructure by identifying where interoperability is important, 209thus enabling them to make smart investments that stretch 210every dollar. Finally, SOA offers the promise of an over-arching 211umbrella framework that demonstrates how all of Global’s 212work products fit together as a cohesive approach to 213improving information sharing. 214While recognizing these benefits, it is also important to 215recognize that SOA is not trivial to implement, especially if 216practitioners do not share lessons learned and best practices 217across jurisdictions. The cost of reimplementing SOA from 218scratch in every state, county, municipality, and tribal 219organization in the United States would be overwhelming. The 220JRA aims to solve this problem by providing practitioners with a 221set of documents that represent the national justice 222community’s very best practices, experiences, and lessons 223learned from implementing SOA. A state, local, or tribal 224integration architect or project manager can start with these 225documents rather than starting from nothing, dramatically 226accelerating his or her jurisdiction’s path to SOA. Along the 227way, the JRA will lead the jurisdiction to adoption of the other 228products that Global and its partners have developed. 229This document—the JRA Specification—is a conceptual 230framework for SOA that is based on an industry standard, the 231OASIS SOA Reference Model, which was developed by a 232committee of industry and government SOA experts, including 233some of the GISWG members who authored the JRA. The 234Specification defines a set of key concepts in a standard way, 235so that across the country, justice practitioners and their 236industry partners can adopt a consistent vocabulary for 21 vii
  9. 9. 22Justice Reference Architecture Specification Version 1.7 23 237communicating about SOA. The framework also provides a 238jumping-off point for the rest of the broader reference 239architecture, by identifying areas where the community needs 240more thorough standards and guidelines. Separate documents 241within the JRA elaborate these concepts, which include: 242 • A methodology for identifying what services— 243 exchange points—a jurisdiction should develop to 244 solve some identified business problem 245 • A standard for describing services so they can be 246 used, understood, and consumed across 247 jurisdictions 248 • Recommended requirements for infrastructure 249 necessary to support SOA 250 • Technical communications protocols, based on 251 industry standards such as Web services and 252 XML, for transmitting information as messages 253 between justice partners and their systems 254 • Guidelines for governing and managing an SOA in 255 a jurisdiction—how to assign decision rights and 256 responsibilities for implementing elements of an 257 SOA 258If you are an executive-level decision-maker without direct 259day-to-day management responsibilities over technology, you 260should view this document (and the remainder of the JRA) as 261important guidance for your technology staff to follow as you 262plan (or participate in planning) information sharing in your 263jurisdiction. Even if you are not technically oriented, you still 264have ultimate accountability for the wise investment of public 265funds in your community, and you should be aware of the 266JRA’s power to lead you and your partners to an agile, 267standards-based, shared approach to information sharing. 268Ifyou are a chief information officer, architect, senior project 269manager, or other technology leader responsible for 270implementation of information sharing solutions, the JRA holds 271the promise of saving you a great deal of time, effort, and 272money in implementing the best practices inherent in SOA. 273This document is primarily for you. 274 24 viii
  10. 10. 25Justice Reference Architecture Specification Version 1.7 26 275 276 277 278 279 280 281 282 283 284 285 27 ix
  11. 11. 28Justice Reference Architecture Specification Version 1.7 29 286 1.Introduction 2871.1.Global’s SOA Initiative 288On September 29, 2004, the Global Justice Information Sharing 289Initiative (Global) Advisory Committee (GAC) unanimously 290adopted SERVICE-ORIENTED ARCHITECTURE (SOA) and the 291recommendations in the report titled A Framework for Justice Information 292Sharing: Service-Oriented Architecture (SOA). [SOA-REC] 293 Global provides support for SOA by: 294 295 • Recognizing SOA as the recommended FRAMEWORK 296 for development of justice information sharing 297 systems 298 • Promoting the utility of SOA for the justice 299 community 300 • Encouraging the members of the justice 301 community to take these recommended 302 incremental steps in the development of their own 303 systems 304 305Global’s approval was based on the understanding that SOA is 306the approach most likely to result in an infrastructure that will 307support its vision of how information should be shared within 308the justice community. If SOA is to be used successfully as the 309framework for justice information sharing ARCHITECTURE, Global 310must play a proactive leadership role in several areas. The 311development of the JUSTICE REFERENCE ARCHITECTURE was based on the 312following actions recommended by Global: 313 314 • Incorporate SOA into the activities of all Global 315 Working Groups. SOA raises issues for security, 316 privacy and information quality, and intelligence 317 that will be given explicit attention and treated as 318 part of a broad initiative. 319 • Encourage the creation of a mechanism for 320 drawing together the experiences and lessons 321 from the field. 30 1
  12. 12. 31Justice Reference Architecture Specification Version 1.7 32 322 • Reach out to existing national systems to 323 incorporate their efforts into the design of an 324 overall strategy. 325 • Address the following six issues as priorities— 326 services, standards, interagency agreements, 327 registries, security, and privacy and data quality— 328 because they will be a major part of the agenda 329 for the next set of Global activities. 330 • Develop a multitiered strategy for the public 331 sector to influence standards. It will include 332 encouraging the creation of a public process (as 333 it did with XML), taking part in industry groups that 334 are developing standards relevant to justice (e.g., 335 OASIS), and developing partnership processes 336 with industry and other public entities. 3371.2.An Interoperability Strategy 338Solving interoperability challenges continues to be a significant 339problem and a high priority for the justice and public safety 340community. Approximately 100,000 justice agencies have the 341critical need to share information across their various 342information systems, and this variety creates multiple layers of 343interoperability problems because hardware, software, 344networks, and business rules for data exchange are different. 345The need for information sharing has led to this interoperability 346strategy and the JRA. 347The strategy for developing JRA involves many steps. This 348paper details some highly technical and abstract concepts. 349Understanding these concepts may require significant effort 350from the reader. Though it may seem strategically 351questionable to place such a high hurdle at the beginning of a 352multistep process, doing so actually creates a flexible 353vocabulary and a conceptual framework that will enable the 354desired interoperability to flourish. Additionally, subsequent 355steps that will build from this framework will be incrementally 356more concrete and will ultimately lead to actual 357implementation specifications that can be used by 358practitioners in the field. Global believes that this dynamic 359interoperability strategy will help to prevent incompatibilities, 360guide vendors and organizations on how to fit components 361together, and facilitate communication and interoperability 362among disparate communities. 33 2
  13. 13. 34Justice Reference Architecture Specification Version 1.7 35 363Global’s strategy for JRA, like other work that has preceded 364it, follows a five-step process: 365 Step One: Agree on common concepts 366 Step Two: Agree on the relationships and 367 deliverables 368 Step Three: Assign the work 369 Step Four: Produce the deliverables 370 Step Five: Revise the deliverables 371As an example, when the Global JXDM project started, it had a 372small set of limited solutions. Through much iteration, Global 373JXDM has been expanded and refined and addresses a 374successively larger set of justice domains. 36 3
  14. 14. 37Justice Reference Architecture Specification Version 1.7 38 3751.3.Consensus on the OASIS Reference Model for SOA 376One of the justice requirements is to create a common 377language for talking about architecture across major domains. 378For instance, it is currently difficult for emergency 379management personnel to talk to justice personnel about how 380their respective systems might share data beyond the content 381standards issue because their ways of communicating about 382architecture are so different. 383After considerable discussions among the stakeholders, Global 384adopted the Organization for the Advancement of Structured 385Information Standards (OASIS) Reference Model for Service- 386Oriented Architecture 1.0 [SOA-RM]. OASIS has approved this 387standard reference model for describing different 388architectures using comparable, vendor-neutral language. 389Global is adopting the OASIS framework for describing its 390architecture and holding conversations with other domains. 39 4
  15. 15. 40Justice Reference Architecture Specification Version 1.7 41 3911.4.Creating the JRA 392Itis important to note that SOA-RM provides a conceptual 393foundation not only for the justice community but also for any 394other domain to create a REFERENCE ARCHITECTURE. JRA builds on the 395SOA-RM concepts by specifying additional relationships and 396defining and specifying these adopted concepts. 397Although there is no perfect solution and since there is a need 398to start somewhere, SOA-RM is recommended as the best 399place to start Global’s SOA work efforts. Global began by 400mapping the SOA components, documenting, and leveraging 401the work that has been done already—like the Global JXDM— 402and finally, worked to identify and fill the gaps. 403 404 Justice Reference Architecture is derived from the OASIS Reference 405 Model for Service-Oriented Architecture 1.0. The OASIS work was 406 developed to provide a conceptual foundation for creating a reference 407 architecture. As intended by OASIS, the JRA builds on or expands 408 409 from the OASIS model. 410Specifically, Global is developing a modular architecture that 411clearly and appropriately identifies and separates technical 412and governance layers so that standards can be developed to 413improve interoperability. 42 5
  16. 16. 43Justice Reference Architecture Specification Version 1.7 44 4141.5.What Is the JRA? 415This section defines the JRA and explains why a reference 416architecture is useful. Keep in mind that there are many 417potential justice reference architectures but that the JRA 418focuses entirely on SOA for the justice and public safety 419community. 420 JRA is an abstract framework for understanding significant 421 components and the relationships between them within a Service- 422 Oriented Architecture. It lays out common concepts and definitions 423 as the foundation for the development of consistent SOA implementations within the justice and public safety communities. 424 425The JRA is a description of the important concepts in a justice 426information sharing architecture and of the relationships 427between those concepts. The JRA also identifies, at a high 428level, the kinds of components (software systems, hardware 429infrastructure, policies, practices, intersystem connections, 430and so on) necessary to bring those concepts to life in a 431particular context. The JRA is generally not specific enough to 432govern the implementation of any individual software system 433implementation. Rather, it is a framework for guiding 434implementations in general, with the aim of standardizing or 435harmonizing certain key aspects of those implementations to 436support reusability or interoperability. 437Itis important to note that at this time, the JRA is not complete. 438Many sections of this document are still under development, 439but the document does attempt to identify the necessary 440concepts, relationships, and components that will require 441further elaboration and/or implementation. 4421.6.What the JRA Is Not 443The JRA is a reference architecture for information sharing 444and, as such, does not address the following: 445 • Detailed specifications for justice agencies’ 446 operational systems (e.g., police records 447 management systems, court case management 448 systems) 45 6
  17. 17. 46Justice Reference Architecture Specification Version 1.7 47 449 • Detailed specifications of information exchanges 450 or services 451 • Recommendations or standards for integration 452 infrastructure products 48 7
  18. 18. 49Justice Reference Architecture Specification Version 1.7 50 453 2.Architecture Requirements 454 This section documents the business requirements to be 455 addressed and satisfied by the JRA. These requirements 456 are stated in the form of principles, the intent of which is to 457 guide and constrain the choices made in developing the 458 architecture. 459Principle: Independence of Information Sharing Partners 460A reference architecture for justice information sharing should 461accommodate a large number of independent information 462sharing partners at the federal, state, local, and tribal levels of 463government. 464Rationale 465It is a plain fact that organizations responsible for functions in 466the criminal justice process are independent and autonomous 467from other organizations playing roles in that process. In 468general, it is not possible for one partner or set of partners to 469dictate to others how they conduct their business, what 470information systems they use, how they store information, and 471so on. 472It is also true—especially at the state, regional, and national 473levels—that the number of partners that need to share 474information is large and growing. To make agreement on 475information sharing possible, it is necessary to reduce or 476eliminate the need to agree on how partners’ systems and 477business processes function and to move towards open 478industry standards instead of proprietary approaches. 479While partners may readily agree on the need to share 480information, their individual objectives and incentives for doing 481so may differ. 482Any information sharing architecture that does not 483accommodate these facts will face difficulty in its adoption and 484implementation by the community. Where adopted and 485implemented, an architecture that does not accommodate 486these facts will likely fail to scale to include the large number of 487involved partners. 51 8
  19. 19. 52Justice Reference Architecture Specification Version 1.7 53 488Note: This principle also summarizes the first two 489requirements for SOA established by the Global Infrastructure/ 490Standards Working Group in its 2004 paper, A Framework for Justice 491Information Sharing: Service-Oriented Architecture [SOA-REC, pages 2–5]. 492Implications 493This principle implies the following about the JRA: 494 • The JRA should encourage the definition of 495 system interfaces that focus only on what system 496 functionality or information is to be shared, not on 497 how organizations design, deploy, or operate 498 their systems 499 • The JRA should encourage information sharing 500 mechanisms and approaches based on open 501 industry standards rather than on approaches 502 proprietary to one vendor, one domain, one level 503 of government, or one specific partner 504 • The JRA should identify issues on which justice 505 information sharing partners will typically need to 506 reach and enforce agreement, which conversely 507 will identify issues on which they can continue to 508 take independent approaches 509Principle: Scalability 510A reference architecture for justice information sharing should 511provide useful guidance to integrated justice enterprises of all 512sizes, from small operations with a few participants, to national 513processes that reach across local, state, tribal, federal, and 514even international boundaries. 515Rationale 516The national justice community consists of enterprises large 517and small, from the smallest rural county to the largest 518metropolitan areas and most populous states. To enable 519sharing of justice information within and among these 520jurisdictions, a consistent set of technical standards, 521guidelines, and infrastructure requirements is necessary. An 522information sharing architecture that addresses only one size 523of jurisdiction will fall short of the goal of fulfilling a truly national 524scope. 54 9
  20. 20. 55Justice Reference Architecture Specification Version 1.7 56 525In addition, experience and practical considerations indicate 526that information sharing architecture is most often 527implemented in an incremental fashion. Jurisdictions should be 528able to implement modest standards and infrastructure at first, 529with confidence that as their scope and capabilities grow, 530there will be minimal rework and reinvestment. This principle 531promotes an architecture that will satisfy the needs of an initial 532implementation and that will retain its relevance as the 533implementation expands. 534Note: This principle also summarizes the third requirement for 535SOA established by the Global Infrastructure/Standards 536Working Group [SOA-REC, pages 5–6]. 537Implications 538This principle implies the following about the JRA: 539 • The JRA should adopt a modular approach that 540 allows jurisdictions to implement a subset of the 541 full architecture, achieving some initial benefit 542 while retaining the option of adopting more of the 543 architecture later 544 • The JRA should encourage the adoption of 545 industry standards with a broad range of 546 implementations available in the marketplace, 547 from less expensive implementations with modest 548 capabilities, to larger investments that support an 549 increased volume of information sharing 550 • The JRA should encourage the clear description, 551 the straightforward discovery, and ultimately the 552 reuse of services across jurisdictions to provide 553 information more economically (particularly to 554 smaller jurisdictions) 555Principle: Diversity of Data Source Architectures 556A reference architecture for justice information sharing should 557accommodate data sources and partner systems that differ 558widely in software, hardware, structure, and design. 559Rationale 57 10
  21. 21. 58Justice Reference Architecture Specification Version 1.7 59 560There is not now—nor will there be in the foreseeable future—a 561single solution or system for any particular domain within 562criminal justice. Because of the independence and autonomy 563of jurisdictions (and organizations within jurisdictions), it will in 564general be impossible for the sharing of justice information to 565rely on a single vendor system, application platform, or 566database. Even if it were possible to achieve, implementing a 567single vendor’s solution across all the partners within a 568jurisdiction introduces interdependencies that reduce agility 569and impede technical and policy innovation. 570In addition, today’s optimal choice of systems and platforms 571will likely be different than tomorrow’s. When a partner 572wishes to swap out old software or hardware for a new 573solution, that ought not to cause chaos for its information 574sharing partners. 575Note: This principle also summarizes the fourth requirement 576for SOA established by the Global Infrastructure/Standards 577Working Group [SOA-REC, page 6]. 578Implications 579This principle implies the following about the JRA: 580 • The JRA should encourage the sharing of 581 information and functionality between systems in 582 a way that minimizes the implementation 583 dependencies between them 584 • The JRA should encourage communication 585 between systems using open industry standards 586 rather than proprietary approaches 587 • The JRA should use vendor-neutral terminology 588 and concepts in defining the architecture 589 • The JRA should adopt a modular approach to 590 intersystem communication mechanisms and 591 protocols so that the entire architecture need not 592 change when improved protocols are developed 593 in the future 594Principle: Agility 595A reference architecture for justice information sharing should 596accommodate changes in policy, information flow, and partner 60 11
  22. 22. 61Justice Reference Architecture Specification Version 1.7 62 597system implementation without forcing investments or changes 598in unrelated systems or exchanges. 599Rationale 600While the events in the justice community that trigger 601information exchange remain fairly constant (arrests, bookings, 602charging decisions, case filing, disposition, supervision, etc.), 603the policy responses and the flow of information following 604these events are in constant change. This principle promotes 605an architecture that allows information sharing practitioners to 606respond to—and even to thrive in—this dynamic environment. 607Technologies within partner organizations change frequently as 608well. The days of purchasing a line of business system, such 609as a records system or a case management system, and 610leaving it untouched for years at a time are long past. New 611capabilities available from vendors and improvements in 612internal operations both compel a more rapid rate of change. 613This principle promotes an architecture that separates 614partners’ system implementations from one another, reducing 615the impact of change to one on the others. 616Note: This principle also reflects the sixth requirement for SOA 617established by the Global Infrastructure/Standards Working 618Group [SOA-REC, pages 7–8]. 619Implications 620This principle implies the following about the JRA: 621 • The JRA should encourage the sharing of 622 information and functionality between systems in 623 a way that minimizes the implementation 624 dependencies between them 625 • The JRA should encourage the definition of 626 system interfaces that reflect what the interfaces 627 do, as opposed to how they work 628 • The JRA should provide mechanisms to separate 629 the logic of information exchange (e.g., the 630 routing and transforming of messages that flow 631 between partners) from the logic of line-of- 632 business systems 63 12
  23. 23. 64Justice Reference Architecture Specification Version 1.7 65 633Principle: Reuse and Sharing of Assets 634A reference architecture for justice information sharing should 635promote the use of existing system interfaces, information 636exchanges, and infrastructure to support new business 637requirements. 638Rationale 639Organizations responsible for criminal justice are, like many 640public sector organizations, being asked by citizens to do more 641with less. In addition, reusing system interfaces and 642information exchange implementations can improve 643consistency and reliability of information by having all 644information consumers draw from the same source. This 645principle reflects these factors by encouraging an architecture 646that supports reuse of interfaces and infrastructure. 647Implications 648This principle implies the following about the JRA: 649 • The JRA should encourage the definition of 650 system interfaces that do not require usage in 651 particular contexts 652 • The JRA should provide mechanisms to separate 653 the logic of information exchange (e.g., the 654 routing and transforming of messages that flow 655 between partners) from the logic of line-of- 656 business systems 657Principle: Alignment With Best Practices and Experience 658A reference architecture for justice information sharing should 659reflect concepts and mechanisms that have proven viable in 660actual, real-world information exchange scenarios; the 661architecture should reflect the experiences of both public- and 662private-sector information exchange implementation projects. 663Rationale 664There is considerable experience, both in the private and 665public sectors, with implementing information sharing 666architecture. This principle encourages the JRA to help future 66 13
  24. 24. 67Justice Reference Architecture Specification Version 1.7 68 667implementers avoid the pitfalls of the past, while adopting 668those practices that have proven effective. 669Note: This principle also reflects the fifth requirement for SOA 670established by the Global Infrastructure/Standards Working 671Group [SOA-REC, pages 6–7]. 672Implications 673This principle implies the following about the JRA: 674 • The JRA should base proposed standards and 675 infrastructure requirements on practices that 676 have proven effective 677 69 14
  25. 25. 70Justice Reference Architecture Specification Version 1.7 71 678 3.The JRA 6793.1.Graphical Overview 680The following diagram depicts the concepts, high-level 681components, and relationships in the JRA specification Version 6821.7. These elements are described in detail in the following 683sections. 72 15
  26. 26. 73Justice Reference Architecture Specification Version 1.7 74 can be supported by Collaboration act as Routers identify common Message Validators Intermediaries types of Transformers Provisioning Interceptors Models can specify implement define Enterprise Process Model Integration Patterns provide Service Providers interface of transforms Action Model provider systems contains provide contains Capabilities Real-World Effects leverage information contained in Domain Adapter produce Vocabularies conform provider conforms to, Behavior Model provide access to seek systems to uses Information Model 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 Agreement can be specified in structure and content determined by Willingness Awareness described by Reachability Policy and Contract can constrain can be Interaction Service Interfaces 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 Requirements implementations of describe ways of exchanging Message Exchange Patterns Messages Message Definition define structure of Mechanisms enables and determines essential aspects of G lobal JRA version 1.5 Legend Concept Map May 1, 2007 Concepts from OASIS SOA-RM Concepts particular to the JRA 684 75 16
  27. 27. 76Justice Reference Architecture Specification Version 1.7 77 685 4.Concepts and Relationships 686The following sections describe the concepts, components, 687and relationships depicted in the diagram on the previous 688page. 689 OASIS Reference Model for Service-Oriented Architecture 690The JRA depicted in the diagram above (and defined in this 691document) adopts and builds on the OASIS SOA-RM. 692The SOA-RM defines its purpose as follows: 693 “A REFERENCE MODEL is an abstract framework for 694 understanding significant relationships among the 695 entities of some environment. It enables the 696 development of specific reference or concrete 697 architectures using consistent standards or 698 specifications supporting that environment. A 699 reference model consists of a minimal set of unifying 700 concepts, axioms and relationships within a 701 particular problem domain, and is independent of 702 specific standards, technologies, implementations, 703 or other concrete details.” [SOA-RM, p. 4] 704 “The goal of this reference model is to define the 705 essence of service-oriented architecture, and 706 emerge with a vocabulary and a common 707 understanding of SOA. It provides a normative 708 reference that remains relevant for SOA as an 709 abstract and powerful model, irrespective of the 710 various and inevitable technology evolutions that will 711 influence SOA deployment.” [SOA-RM, p. 4] 712While the SOA-RM is a powerful model that provides a vendor- 713neutral, open-standard definition of service-oriented 714architecture, its abstract nature means that further work must 715be done to create a reference architecture. This work should 716include the definition of specific standards and guidelines for 717information sharing and should define minimum requirements 718for infrastructure necessary to enable information sharing while 719supporting those standards and guidelines. It should do this in 78 17
  28. 28. 79Justice Reference Architecture Specification Version 1.7 80 720a way that satisfies the goals and requirements of the 721enterprise creating the reference architecture. 722The JRA is just such a reference architecture, intended to 723satisfy the goals and requirements of justice information 724sharing by identifying specific standards, guidelines, and 725infrastructure requirements for any group of justice partners 726interested in sharing information among themselves. 727In the JRA diagram, OASIS SOA-RM concepts are shaded 728yellow. Concepts and components particular to the conceptual 729architecture defined by this document are shaded cyan. 730Relationships between concepts (indicated by arrows) are 731defined in the SOA-RM if the arrows connect concepts shaded 732yellow. Relationships between cyan-shaded concepts or 733between cyan-shaded and yellow-shaded concepts are 734particular to the JRA. 735The descriptions of SOA-RM concepts provided in the following 736sections are intended to be brief summaries; consequently, 737they omit certain details that appear in the SOA-RM. The SOA- 738RM itself is the primary source for full exposition of 739SOA-RM concepts and the relationships between them. 740 Core Concepts— Services, Service Consumers, Capabilities, and 741 Real-World Effects 742These four concepts make up the core of the JRA. All other concepts support these 743concepts. 744The JRA begins from the premise that a group of justice 745partners have CAPABILITIES that they provide to one another. 746These capabilities “solve or support a solution for the 747problems [businesses] face in the course of their business.” 748[SOA-RM, p. 8] That is, capabilities are the things organizations 749have to solve problems and therefore add value, directly or 750indirectly, to their stakeholders. 751Note that the JRA is generic enough to support virtually any 752kind of capability. However, the purpose of the JRA is to 753describe an approach to achieving interoperability among 754automated, computer software-based information systems. 755Therefore, the JRA considers only those business capabilities 81 18
  29. 29. 82Justice Reference Architecture Specification Version 1.7 83 756thatare provided by information systems. The JRA calls these 757systems PROVIDER SYSTEMS. 758Each capability produces one or more REAL-WORLD EFFECTS, each of 759which is an outcome of the business value sought by one of 760the partners. A real-world effect can be either the obtaining of 761information, the changing of something of business relevance 762to the participating partners, or both. Because the JRA 763establishes that capabilities are implemented by provider 764systems, real-world effects consist of the functional business 765requirements of provider systems. That is, real-world effects 766in the JRA are essentially the information made available by 767provider systems or the outcomes resulting from business 768processes and workflows automated by provider systems, or 769both. 770In a service-oriented architecture, a SERVICE is the way in which 771one partner gains access to a capability offered by another 772partner. A partner that uses a service to gain access to 773another partner’s capability is called a SERVICE CONSUMER. As with 774capabilities, the architecture is generic enough to support 775virtually any kind of service consumer. However, since the 776purpose of the JRA is to describe an approach to information 777systems interoperability, the JRA narrows the SOA-RM 778definition of service consumer to information systems that 779interact with services directly through an interface that 780conforms to a service interaction profile (as defined below). 781The JRA calls such systems CONSUMER SYSTEMS. 782One of the most important features of the JRA is the 783separation of consumer systems from provider systems by 784services in the middle. This is the defining characteristic of a 785service-oriented architecture and is the key to minimizing the 786implementation dependencies between systems, which is 787identified as part of the rationale of several of the JRA 788principles listed above. 789The fact that information sharing is one kind of real-world 790effect allows the architecture to support the traditional view of 791system integration as “data exchange” or “information 792sharing.” The JRA improves this view by encouraging systems 793to share information in a way that minimizes the dependencies 794of each system on the implementation of other systems. 84 19
  30. 30. 85Justice Reference Architecture Specification Version 1.7 86 795 Supporting Concepts 796Beyond the four core concepts of real-world effects, 797capabilities,services, and service consumers, the remainder of 798the concepts in the JRA deal with the following three important 799concerns: 800 • How consumers may find out that a service exists 801 • Once they find the service, how consumers may 802 understand what the service does and what 803 information flows in and out of it 804 • How a consumer may reach and interact or 805 communicate with the service 806The remaining concepts that address these concerns are 807called “supporting concepts” and are defined in this section. 808 Interaction, Visibility, Service Models, and Service Interfaces 809Servicesdefine what features of a provider system the system 810owner makes accessible to business partners. Services also 811provide a logical description of the information exchanged 812between consumer and provider systems as the consumer 813accesses the capability. 814Interaction 815The JRA refers to a consumer’s accessing the features of a 816capability through a service as INTERACTION, defined as “the 817performing [of] actions against a service.” [SOA-RM, p. 15] 818Service interaction generally involves the exchange of 819information between the consumer and the service. 820Interaction depends on two things. First, the designers of 821potential consumers need to be able to find services and, once 822found, establish a physical interaction mechanism with them. 823These needs are addressed by the concept of VISIBILITY. Second, 824the designers of potential consumers need a description of the 825actions that can be performed on a service, as well as the 826structure and meaning of information exchanged during the 827interaction. These needs are addressed by the concept of a 87 20
  31. 31. 88Justice Reference Architecture Specification Version 1.7 89 828service’s INFORMATION MODEL and BEHAVIOR MODEL, collectively called 829SERVICE MODELS in the JRA. 830Visibility 831Visibility, as the name implies, defines how service consumers 832and the providers of capabilities “see” each other in a way 833that enables interaction between them. The JRA identifies 834three aspects of visibility. 835 • A service consumer must have information that 836 makes it aware of the existence of a service; the 837 possession of this information is called AWARENESS. 838 • The service (or capability accessed through the 839 service) must be willing to interact with the 840 consumer; this is called WILLINGNESS. 841 • The consumer and service must be able to 842 communicate with one another through some 843 kind of communication path or channel; the 844 existence of such a communication path is called 845 REACHABILITY. 846In the JRA, a REPOSITORY will support awareness by hosting service 847models and service interfaces. “Hosting” in this context 848means storing models and interface descriptions in a central 849location that is accessible to appropriate stakeholders. A 850repository will permit searching for models and interface 851descriptions based on a range of identifying criteria. A 852repository will also map logical service identifiers with physical 853addresses. When a consumer wishes to communicate with a 854service (identified by a logical identifier), the consumer queries 855the repository for the physical address associated with the 856service’s logical identifier. This decouples the consumer from 857the physical location of a service at any point in time, thereby 858permitting the physical relocation of the service without 859affecting the implementation of the consumer. 860The concept of willingness is related to authorization and 861access control policies, in that a common reason for lack of 862willingness to interact is that the consumer is not authorized to 863conduct the requested interaction. Willingness often manifests 864in service descriptions, as well as policies, contracts, and 90 21
  32. 32. 91Justice Reference Architecture Specification Version 1.7 92 865agreements (discussed on page 31). A SERVICE MODEL is defined as 866the information needed in order to use, or consider using, a 867service. 868The concept of reachability is closely related to the concept of 869execution context (discussed on page 31). 870Service Models 871Service models, consisting of a service’s behavior and 872information models, define the semantics of interaction with 873the service. 874The behavior model of a service consists of two parts—the 875action model, which defines the operations available to 876consumers (in effect, what the service does) and the process 877model, which defines how consumers may invoke the 878service’s actions together or in sequence to accomplish some 1 879larger business process. 880The information model of a service describes the structure and 881meaning of data that consumers send to and receive from the 882service in the course of interaction. 883In general, service models will be described at conceptual and 884logical levels of detail. (Service models have a physical 885manifestation as well, in the form of the service interface 886discussed in the next section.) A conceptual description of a 887service model will typically describe, in prose text form, the 888capability to which the service provides access, a listing and 889brief textual description of each action, and a brief textual 890description of the information model (e.g., key information 891entities, key properties on those entities, and brief definitions). 892A logical description of a service model will describe the 893actions and information structures in detail but independent of 894any physical implementation mechanism. Often this 895description will be graphical and follow a standard 896diagramming or modeling technique, such as Uniform Modeling 897Language (UML). 931The OASIS SOA-RM term “process model” is consistent with the JRA 94definition given here; however, it is somewhat at odds with the popular 95notion of “Business Process Modeling,” which generally refers to 96documenting/modeling the interactions between many services or 97capabilities. The JRA remains consistent with the OASIS SOA-RM, but 98readers are cautioned not to confuse the two definitions of this term. 99 22
  33. 33. 100Justice Reference Architecture Specification Version 1.7 101 898A MESSAGE is defined as the entire “package” of information sent 899between service consumer and service (or vice versa), even if 900there is a logical partitioning of the message into segments or 901sections. For instance, if an interface expresses actions as 902operations or functions that take arguments, and a particular 903operation has two arguments, both arguments would be 904considered part of the same message, even though they may 905be logically separated within the message structure. A 906message also includes the concept of an “attachment,” in 907which there are several additional sections (attachments) that 908relate to a distinct, “primary” section. 909In the JRA, the exchange of messages is the only way in which 910consumers and services can communicate. This establishes a 911linkage between the Federal Enterprise Architecture Data 912Reference Model (FEA DRM) and the JRA—a message in the 913JRA equates to an Information Exchange Package (IEP) in the 914FEA DRM. In the JRA, all service interaction is accomplished 915via message (information) exchange, and each message 916triggers the invocation of an action in the service’s action 917model. 918The concept of DOMAIN VOCABULARIES in the JRA includes canonical 919data models, data dictionaries, and markup languages that 920standardize the meaning and structure of information for a 921topical or business domain. Domain vocabularies can improve 922the interoperability between consumer and provider systems 923by providing a neutral, common basis for structuring and 924assigning semantic meaning to information exchanged as part 925of service interaction. Domain vocabularies can usually be 926extended to address information needs specific to the service 927interaction or to the business partners integrating their 928systems. 929The information model for a service generally should be built 930from components in one or more domain vocabularies to 931promote semantic interoperability. In the justice domain, the 932information model for services should be built from 933components in the National Information Exchange Model 934(NIEM) when NIEM components exist that satisfy the semantic 935requirements of the model. 102 23
  34. 34. 103Justice Reference Architecture Specification Version 1.7 104 2 936SERVICE DESIGN PRINCIPLES provide consistent guidance regarding the 937overall partitioning of capabilities into services and the 938relationships between services. For instance, service design 939principles may call for services to represent one concise, self- 940contained function and may also suggest that services should 941completely hide the implementation details of the capabilities 942to which they provide access. 943There is a wide variety of ways in which a service can provide 944access to a capability. In some cases, the provider system 945that implements the capability may already expose all or some 946of its functionality as services (through one or more service 947interfaces, described on page 25). In other cases, the 948business partner that provisions the capability can purchase an 949off-the-shelf adapter from the provider system vendor (or a 950third party) that exposes the system’s functionality as a set of 951services. Finally, the provider system may require 952reimplementation or custom adaptation to expose functionality 953as services. This is often expensive and risky, and the desire 954to avoid this situation should be addressed in the service 955design guidelines. 956In general, a given information system can be both a provider 957system and a consumer system. Similarly, a particular 958business organization may offer capabilities to its partners and, 959at the same time, be a consumer of the capabilities offered by 960others. This has important implications for how the 961organization should conceive and describe its information 962systems assets and how it assigns responsibilities for the 963maintenance and support of those assets. For example, in the 964past, it was common to think of systems as having “client” 965and “server” components (or “browser” and “server” 966components), which in turn influenced thinking about systems 967deployment, networking, security, support, and a range of 968other issues. These issues deserve reconsideration in an 969architecture in which a system or system component can be 970both a “client” (consumer of services) and a “server” 971(provider of services) at the same time. The discussion of 972service interaction on page 20, and the subsequent 973elaboration of interaction mechanisms in future iterations of the 974JRA, will reflect the impact of these issues. 1052Principles and guidelines are important components of the conceptual JRA; 106however, these principles and guidelines are not illustrated on the diagram 107because they will exist for most of the components. 108 24
  35. 35. 109Justice Reference Architecture Specification Version 1.7 110 975Note that the concept of a service in the JRA does not equate 976to a Web service. The term “Web services” is a label for a 977family of standards and an associated technical approach to 978communicating between service consumers and services. The 979architecture supports flexibility in how this communication 980happens through the notion of service interaction profiles 981(discussed on page 27). A Web service profile has been 982developed for the Web services family of standards; however, 983the JRA will include additional profiles that adopt other 984communication mechanisms, such as MQ, JMS, and ebXML. 985[WSSIP AND ebXMLSIP] 986As previously stated, a repository should contain service model 987description artifacts for each level of detail. The availability of 988service model descriptions to consumer system designers, 989implementers, and purchasers is a key factor in establishing 990visibility and the reuse of services. 991Service Interface 992Service models describe the actions available from a service 993and the information exchanged between a consumer and the 994service during the performance of those actions. In this way, 995the service models describe the “what” of interaction. 996A SERVICE INTERFACE “is the means for interacting with a service. It 997includesthe specific protocols, commands, and information 998exchange by which actions are initiated [on the service].” [SOA- 999RM, p. 22] A service interface is what a system designer or 1000implementer (programmer) uses to design or build executable 1001software that interacts with the service. That is, the service 1002interface represents the “how” of interaction. 1003In many cases, the capability to which a service provides 1004access is some kind of information system. The JRA calls such 1005a system a provider system, as discussed above on page 15. 1006However, in general, a provider system will not conform to or 1007satisfy the constraints imposed by the service interface 1008through which consumers access the capability. A software 1009component called an ADAPTER is required to transform 1010interactions with the provider system into interactions that 1011conform to the service interface. Depending on the type of 1012provider system, adapters may be available from the system 111 25
  36. 36. 112Justice Reference Architecture Specification Version 1.7 113 1013vendor or a different vendor; in other cases, the service 1014provider may need to build a custom adapter. 1015The JRA considers the service interface to be the physical 1016manifestation of the service models. Best practices call for a 1017service interface to be described in an open-standard, 1018referenceable format (that is, a format whose contents are 1019capable of automated processing by a computer). 1020Many service interaction profiles use the term “endpoint” or 1021“endpoint interface” to refer to the physical point that 1022receives a message sent by a consumer. There is a one-to- 1023one correspondence between a service interface and an 1024endpoint interface, and the JRA considers the two terms to be 1025synonymous. 1026A given service may have multiple interfaces that conform to 1027the same service interaction profile, where the multiple 1028interfaces expose different sets of the service’s actions. For 1029instance, a service may have one “query” action and three 1030“update” actions; the query action may be exposed by one 1031Web services interface, while the three update actions may be 1032exposed by a separate Web services interface. These 1033interfaces would reside at separate endpoints. 1034Note that at least some policies and contracts can be 1035described in a service’s interface. 1036The format, structure, and allowable contents of a service 1037interface are established by INTERFACE DESCRIPTION REQUIREMENTS, 1038described in the following section. 1039 Design and Description of Service Interfaces 1040The JRA identifies four architectural elements that guide the 1041design and description of service interfaces. 1042SERVICE INTERACTION REQUIREMENTS define common rules of service 1043interaction. Typically, these requirements are not directly 1044related to the capability used by the service consumer, nor are 1045they related to the real-world effect resulting from use of that 1046capability. Rather, the requirements enforce (or support the 1047enforcement of) policies or contracts or otherwise protect the 1048interests of particular business partners or the business 1049organization overall. 114 26
  37. 37. 115Justice Reference Architecture Specification Version 1.7 116 1050Common service interaction requirements address areas such 1051as security, reliability, and availability. An initial elaboration of 1052service interaction requirements appears on page 29. 1053INTERFACE DESCRIPTION REQUIREMENTS establish common characteristics of 1054service interface descriptions. These requirements address 1055areas such as required interface contents, naming rules, 1056documentation rules, and specification of a standard structure 1057and format for descriptions. 1058MESSAGE EXCHANGE PATTERNS identify common sequences of message 1059transmission between service consumers and services. They 1060providea label to a series of message transmissions that have 1061some logical interrelationship. 1062MESSAGE DEFINITION MECHANISMS are closely related to interface 1063description requirements, described above. Unlike interface 1064description requirements, message definition mechanisms 1065establish a standard way of defining the structure and contents 1066of a message. Note that since a message includes the 1067concept of an “attachment,” the message definition 1068mechanism must identify how different sections of a message 1069(for example, the main section and any attachment sections) 1070are separated and identified and how attachment sections are 1071structured and formatted. 1072Service Interaction Profiles 1073A SERVICE INTERACTION PROFILE defines a family of industry standards or 1074other technologies or techniques that together demonstrate 1075implementation or satisfaction of: 1076 • Service interaction requirements 1077 • Interface description requirements 1078 • Message exchange patterns 1079 • Message definition mechanisms 1080Service interaction profiles are included in the JRA to promote 1081interoperability without forcing the organization to agree on a 1082single way of enabling service interaction. Each service 1083interface will support a single profile; a service will have 1084multiple interfaces if it supports multiple profiles. By supporting 1085a profile, an interface establishes the mode of interoperation it 117 27
  38. 38. 118Justice Reference Architecture Specification Version 1.7 119 1086allows from service consumers; any consumer that also 1087supports that profile can “reach” the service. 1088The JRA explicitly recognizes that a service interaction profile 1089may be further constrained by an implementer to require 1090specific techniques, technologies, or mechanisms, as long as 1091the additional constraints remain consistent with the original 1092profile. 1093 Capabilities in Detail 1094The JRA identifies several types of capabilities to assist 1095decision makers in understanding where certain capabilities 1096should be deployed in the organization and what relationships 1097they may have to other capabilities and services. 1098Intermediaries 1099An INTERMEDIARY is any capability that receives messages from a 1100consumer and subsequently, as a service consumer itself, 1101interacts with another service. The term “intermediary” 1102indicates that these capabilities sit between other services and 1103“mediate” the interaction by managing, controlling, brokering, 1104or facilitating the transmission of messages between them. An 1105intermediary is the mechanism by which the JRA separates the 1106logic of integration from the logic of line-of-business systems, 1107which is a key feature of SOA. 1108The JRA identifies five types of intermediary but recognizes 1109that other types are possible. The five identified types are 1110orchestrations, routers, message validators, transformers, and 1111interceptors. 1112An ORCHESTRATION is a capability that coordinates interaction with 1113multiple services. It is a declarative technique used to 1114compose hierarchical and self-contained service-oriented 1115business processes that are executed and coordinated by a 1116single conductor [SOA-RA, p. 69]. An orchestration is often 1117implemented using an open industry standard implementation 1118mechanism such as Business Process Execution Language 1119(BPEL) that allows the implementation to be shared across 1120tools and platforms. 120 28
  39. 39. 121Justice Reference Architecture Specification Version 1.7 122 1121It is often possible to design and model orchestrations using a 1122graphical approach, in which the implementer diagrams 1123business processes and work flows, the steps of which are 1124services that already exist. After the diagram is complete, the 1125implementer generates a standards-based artifact that is 1126deployed into a software component that exposes the work 1127flow as a service through a service interface. The promise of 1128this approach is that less technical implementers with greater 1129business expertise can be responsible for the implementation 1130of orchestrated capabilities. 1131Note that the execution of the steps described in a business 1132process model can be considered a capability in and of itself. 1133In addition, each of the steps in a business process model can 1134unfold into yet another business process model at a more 1135focused level of detail. In this way, each step in a series of 1136service interactions can itself be a series of service 1137interactions. And, in theory, this recursion of models can go on 1138forever, though in practice it rarely exceeds three or four levels 1139of containment. So, services and capabilities form a hierarchy, 1140where a service provides access to a capability whose real- 1141world effect is to accomplish the coordination of multiple 1142services at a lower level of detail. 1143As a side effect, each of the steps in a business process model 1144provides a contextual justification for service interaction 1145between a particular consumer and a particular provider. It is 1146often useful to capture this information in a taxonomy to 1147promote a better understanding of where services are being 1148used and to add value. 1149Note that an orchestration is different from a choreography, in 1150that a choreography is a description of how a group of 1151business peers coordinate a service-oriented business 1152process without the direction of a controller. 1153ROUTERS are capabilities that receive a message, examine it, and 1154transmit it to one or more destinations based on the contents. 1155In general, routers can be designed to operate on any of the 1156information contained within the message; they may use 1157information about the origin of the message, routing directive 1158information contained within the message or the main content 1159of the message itself. 123 29
  40. 40. 124Justice Reference Architecture Specification Version 1.7 125 1160TRANSFORMERS are capabilities that receive a message and 1161transform it into another format before transmitting it to 1162another destination. 1163MESSAGE VALIDATORS are capabilities that examine a message to 1164ensure that the contents adhere to established business rules. 1165INTERCEPTORS are capabilities that receive a message and use the 1166message content to trigger a secondary action; generally, the 1167interceptors pass the message unaltered to the next step in a 1168process. Most interceptors capture information from the 1169message for reporting or analytical purposes. 3 1170Routers and transformers are useful mechanisms for 1171decoupling the senders and recipients of messages. They 1172tend to centralize and share certain kinds of logic so that the 1173logic can be maintained independently of the provider and 1174consumer capabilities at the edges; sharing also improves the 1175likelihood of reuse, since it is easier to reuse functionality if it 1176encapsulates a single task. 1177Support for router, transformer, and collaboration capabilities 1178isa common feature in many integration platforms; therefore, 1179support for these capabilities is a consideration in choice of 1180execution context (discussed on page 25). 1181Routing, transformation, and collaboration capabilities are well 1182understood and well documented in the integration 1183architecture literature. The most common flavors of these 1184capabilities have been collected into pattern form as ENTERPRISE 1185INTEGRATION PATTERNS. [PATTERNS] The JRA incorporates these patterns 1186by reference. 1187Intermediaries are a key component in implementing business 1188process models and also lead to the formation of 1189service/capability hierarchies. 1263The concept of interceptor defined here is similar to, but separate and 127distinct from, the notion of an interceptor as defined in the SOAP protocol 128[reference needed to SOAP standard]. The definition of this concept in JRA 129is not intended to imply any implementation technique or technology. 130 30

×