source .DOC

338 views
291 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
338
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

source .DOC

  1. 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. 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. 3. 5Justice Reference Architecture DRAFT 6 55 56 7 8 3
  4. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 16. 58Justice Reference Architecture DRAFT 59 404community. Out-of-scope components and other 405considerations are listed on page 53. 60 61 16
  17. 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. 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. 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. 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. 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. 22. 88Justice Reference Architecture DRAFT 89 577 the different scales without losing its internal 578 integrity will quickly be marginalized. 90 91 22
  23. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×