MJISA

444 views
391 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
444
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

MJISA

  1. 1. Maine Justice Information Sharing Architecture Version 1.0 October 15, 2007
  2. 2. Table of Contents Purpose...........................................................................................................................................1 Scope..............................................................................................................................................1 Document Conventions...................................................................................................................1 Executive Summary........................................................................................................................2 Motivation and Objectives...............................................................................................................3 Motivation....................................................................................................................................3 Objectives....................................................................................................................................3 Foundation Concepts......................................................................................................................5 Service, Capability, Real-World Effect, and Service Consumer..................................................5 Consumer System.......................................................................................................................5 Service Provider..........................................................................................................................6 Provider System..........................................................................................................................6 Interaction....................................................................................................................................6 Visibility and Closely Related Concepts......................................................................................7 Service Description.....................................................................................................................7 Information Model........................................................................................................................8 Behavior, Action, and Process Models........................................................................................8 Message......................................................................................................................................9 Domain Vocabulary.....................................................................................................................9 Service Interface.........................................................................................................................9 Service Interaction Profile and Closely Related Concepts.........................................................10 Adapter......................................................................................................................................10 Intermediaries and Closely Related Concepts...........................................................................11 Execution Context.....................................................................................................................11 Repository.................................................................................................................................12 Policy and Contract...................................................................................................................12 Service Identification Methodology...............................................................................................14 Usage........................................................................................................................................14 Naming Services.......................................................................................................................14 Principles of Service Design: What makes a good service?......................................................14 Boundaries Between Services...................................................................................................15 How to Identify Services............................................................................................................15 Justice Information Exchange Modeling (JIEM) Methodology...................................................15 Service Specification Standards...................................................................................................17 Usage........................................................................................................................................17 Structure of Service Description................................................................................................17 Maine Justice Information Sharing Architecture Version 1.0 October 15, 2007
  3. 3. Table of Contents Service Interaction Standards.......................................................................................................20 Usage........................................................................................................................................20 Service Interaction Requirements.............................................................................................20 Message Exchange Pattern Requirements...............................................................................21 Interface Description Requirements..........................................................................................21 Standards..................................................................................................................................21 Web Services Service Interaction Profile......................................................................................23 Usage........................................................................................................................................23 Profile........................................................................................................................................23 Intermediary Service Guidelines...................................................................................................24 Usage........................................................................................................................................24 Guidelines.................................................................................................................................24 Shared Execution Context Requirements.....................................................................................25 Usage........................................................................................................................................25 Requirements............................................................................................................................25 Incremental Implementation Strategy........................................................................................27 Repository Requirements..............................................................................................................29 Usage........................................................................................................................................29 Requirements............................................................................................................................29 Provider and Consumer System Guidelines.................................................................................31 Usage........................................................................................................................................31 Guidelines for Existing Systems................................................................................................31 Guidelines for Future Systems..................................................................................................34 Governance Guidelines.................................................................................................................36 Near-term Issues.......................................................................................................................36 Long-term Issues.......................................................................................................................36 Alignment with Objectives.............................................................................................................38 References....................................................................................................................................41 Appendix: Illustrative Examples...................................................................................................42 Statute Information Service.......................................................................................................42 Process-Oriented Example: Disposition Reporting....................................................................43 Maine Justice Information Sharing Architecture Version 1.0 October 15, 2007
  4. 4. Purpose The purpose of this document is to establish an architecture for the sharing of information between criminal justice partner organizations in the State of Maine. Scope The standards and guidelines in this document apply to Maine criminal justice partner organizations that exchange information using the shared infrastructure described herein. The intent of this document is to establish standards and guidelines for information exchanges implemented after its adoption; the intent is not to suggest or require that partner agencies “retrofit” or rebuild working exchanges to conform to the architecture. Document Conventions The following formatting and terminology conventions apply to this document. The first time a foundation concept is used in this document, and at other points where it is important to emphasize that a term is a foundation concept, the name of the concept will be formatted in bold italics. Foundation concepts are defined in the first substantive section of the document below, entitled “Foundation Concepts”. Sources of information external to this document are listed in the “References” section below, and are indicated in the text with a bold font in square brackets, as in [SOA-RM]. The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC 2119]. Document version numbers mean the following. A version number will have three numbers separated by periods. The first number indicates a version that is published by Maine State Police as a “major” version of the architecture. The second number indicates a draft, based on the last major version, that incorporates the review and comments of the Advisory Committee. The third number indicates a draft, based on the last committee-reviewed draft, that is internal to Maine State Police. For example, version 1.2.3 means the third “MSP internal” version of the second “Advisory Committee reviewed” version of major version 1 of the architecture. Maine Justice Information Sharing Architecture Page 1 of 49 Version 1.0 October 15, 2007
  5. 5. Executive Summary The purpose of this document is to define an architecture for the sharing of information among criminal justice partners in Maine. As with any architecture, this document provides decision- making guidance; in this case, the architecture supports more consistent, efficient, and effective decision making regarding the planning, design, acquisition, and implementation of technology to enable the sharing of justice information. Moreover, the architecture guides the partners to exchange information in a way that minimizes unnecessary dependencies between systems, maintains agency autonomy to govern internal business processes, and improves the partners’ collective ability to respond rapidly to new business needs and opportunities. In order to accomplish this, the architecture defines a set of standards, guidelines, and requirements around a small set of key decisions typically encountered in information sharing projects: • At what points should we exchange information? • How do we describe information exchange points to reduce development costs and promote reuse? • What format should be used for information exchanged between agencies? • How should systems communicate (what protocols and technologies)? • What infrastructure capabilities do we need to share, in order to maximize the return on our infrastructure investments? • What must we do to ready our existing (or near-future planned) systems to participate in the architecture? • How do we manage and control change to our information exchange points and shared infrastructure? The following responses to the questions listed above represent a brief summary of the decision- making guidance contained in the architecture: • View information exchange points as services, through which one partner makes business capabilities (functionality) available to another • Systems interact through services, not by directly communicating with one another, thus keeping their implementations separate • Drive identification of services from business processes and strategic business objectives • Use industry-standard and national justice community-standard formats and protocols for exchanging information between agencies, to enable maximum interoperability and solution choice • Separate the business rules and logic of information sharing from the partner systems that provide and consume information, thus promoting agility and responsiveness • Share infrastructure that supports all of the above and facilitates secure, reliable transmission of information among partners and systems The partners have developed this architecture with assistance from SEARCH—The National Consortium for Justice and Statistics, and have aligned it with emerging guidance on service- oriented architecture from the US Department of Justice, Global Justice Information Sharing Initiative. As with any technology architecture, this document should be considered a living document, and the partners should plan to update it as requirements and industry standards change. Maine Justice Information Sharing Architecture Page 2 of 49 Version 1.0 October 15, 2007
  6. 6. Motivation and Objectives This section identifies describes why the justice community in Maine needs this architecture, and identifies the community’s objectives for the architecture. Motivation The sharing of information between agencies and organizations involved in the criminal justice process is essential to the effectiveness and efficiency of that process. Accurate, timely information in the hands of the right decision-makers at the right time is a necessary component of reducing crime and improving public safety. The integration of systems and the automated, electronic sharing of information eliminate error-prone redundant data entry, leading to improved information quality and security and better-informed decisions. Integration speeds decision- makers’ access to records and information, improving the efficiency of the justice process and increasing officer and public safety.1 The State of Maine recognized the potential benefit of justice information sharing in 1993 by creating the Maine Criminal Justice Information System (MCJUSTIS) to “provide criminal justice agencies and authorized private users ready access to shared uniform information on criminal offenders and crime data”.2 The benefits of system integration and automated information sharing do not happen by accident. Effective integrated justice requires a sound strategy that includes two key elements: • A strategic plan that identifies strategic business objectives and the ways in which automated information sharing can help achieve those objectives3 • An information sharing architecture that guides the planning, acquisition, and implementation of technology to ensure that systems can share information at minimum cost and maximum flexibility The goal of this document is to provide an information sharing architecture for the Maine criminal justice community. This architecture provides concrete, objective, formal guidance to justice information sharing partners in Maine regarding how their information systems should share data and functionality. It is expected that the partners will use the architecture to guide the planning, design, acquisition, and implementation of systems within their own agencies, wherever those systems provide information to or consume information from other partners. It is also expected that the architecture will guide and inform the design and acquisition of shared, common infrastructure to support the inter-system (inter-partner) exchange of information. Objectives In pursuit of the goal of information sharing at minimum cost and with maximum flexibility, the objectives of this architecture are as follows4: 1. Drive selection and implementation of justice information sharing initiatives and projects from strategic business objectives. 1 These benefits of system integration and automated information sharing have long been recognized as national best practices; see [IntegrationLibrary] for more information. 2 Maine Revised Statutes, Title 16, Section 631. 3 While a strategic plan is a critical element of an effective overall integrated justice strategy, it is not a goal of this document to provide a strategic plan. This document will make linkages to a strategic plan where appropriate, to ensure that implementation of integration points is driven by business objectives. 4 These objectives are adapted from the principles identified in the forthcoming (version 1.5) release of the Global Justice Reference Architecture ([JRA]), and also align with principles of information sharing identified in [NASCIO ConOps] and referenced in Lt. Col. Robert Williams’ presentations on the vision for information sharing in Maine. Maine Justice Information Sharing Architecture Page 3 of 49 Version 1.0 October 15, 2007
  7. 7. 2. Integrate systems in such a way as to minimize the implementation dependencies between them. 3. Allow partners to make information and functionality available from existing systems; leverage existing assets to the greatest extent possible. 4. Support the reuse of system integration points in new contexts. 5. Support the autonomy of each partner agency, and maintain each agency’s control over its own line-of-business systems. 6. Support diversity in line-of-business system architecture, vendor platforms, programming languages, and agency technology infrastructure. Accomplish this through adoption of open industry standards5 wherever possible. 7. Support an investment in shared, common infrastructure to support inter-system communication, and reuse that infrastructure to support all information exchange between the partners. 8. Ensure that the points at which systems integrate and share information are clearly documented in a consistent fashion across agencies 9. Provide effective, industry-standard mechanisms for implementing security and privacy requirements. 10. Support incremental adoption of the architecture, with the immediate goal of completing the cycle of capturing criminal history information in Maine. 11. In providing for the objectives listed above, select an overall approach to information sharing and system integration that is within the mainstream, is well-supported by skill sets and products available from industry, is accepted by the national criminal justice community, and is in use by other state/local integrated justice initiatives. 5 A standard is an “open industry standard” if it was developed by and/or subsequently endorsed or supported by more than one implementing organization (vendor), is available separately from any implementing product at low or minimal cost with minimal licensing restrictions, and is implemented in or depended upon by at least two products generally available in the marketplace. This meaning of the term “open industry standard” is intended wherever this term appears in this document. Maine Justice Information Sharing Architecture Page 4 of 49 Version 1.0 October 15, 2007
  8. 8. Foundation Concepts This section identifies and defines the concepts on which the rest of the architecture relies, and the relationships between those concepts. When concepts defined in this section appear elsewhere in the architecture, those concepts are intended to have the meaning established here. It is the intent of this architecture to adopt the concepts defined in [SOA-RM] and [JRA]. The concept definitions below summarize and adapt the SOA-RM and Global JRA concepts as appropriate to add context for Maine. Service, Capability, Real-World Effect, and Service Consumer Definitions A service is a mechanism that enables access to one or more capabilities. A capability is an asset that a business organization owns or maintains, that provides direct or indirect value to the organization’s partners by the production or creation of a real-world effect. A real-world effect is a change in the state of the world that meets some need or provides something of business value to one or more of the organization’s partners. A service consumer is a business partner who meets some need or derives some value by accessing a capability through a service to achieve some real-world effect.6 Relationships to Other Concepts The real-world effects that can be achieved through use of a service, and the information that must be exchanged with the service to achieve these effects, are defined by a service model. In a justice information sharing architecture that is focused on the electronic or automated exchange of justice information, service consumers are often represented by and often act through consumer systems. Policies and contracts define rules and constraints on the use of services. A service is accessed by means of a service interface. Related Architectural Mechanisms The service identification methodology defined in the architecture (below) determines what constitutes a “good” service, and how Maine’s justice partners will go about identifying what services are necessary to accomplish stated business objectives. Notes/Comments Real-world effects typically consist of one or both of the following: • Information returned in response to a request for that information • A change in the shared business context of the partner organizations Consumer System Definition A consumer system is a computer software system that exchanges information with or uses a partner’s capability through a service.7 Relationships to Other Concepts In a justice information sharing architecture that is focused on the electronic or automated exchange of justice information, service consumers are often represented by and often act through consumer systems. 6 Definitions adapted from [SOA-RM] and [JRA]. 7 Definition adapted from [JRA]. Maine Justice Information Sharing Architecture Page 5 of 49 Version 1.0 October 15, 2007
  9. 9. Related Architectural Mechanisms Guidance regarding the implementation of consumer systems appears in the Adapter and Consumer System Guidelines defined below. Notes/Comments None. Service Provider Definition A service provider is a business partner whose capabilities it chooses to make available through services. Relationships to Other Concepts In a justice information sharing architecture that is focused on the electronic or automated exchange of justice information, the capabilities made available by a service provider are generally provider systems. Related Architectural Mechanisms The Governance Guidelines defined in the architecture below provide guidance on the assignment of responsibility and provisioning of funding to service providers. Notes/Comments None. Provider System Definition A provider system is a computer software system owned and/or maintained by a business partner, and that has functionality or information of actual or potential business value to other business partners. Relationships to Other Concepts A provider system is a kind of capability made available through one or more services. The business partner that owns and/or maintains a provider system is a service provider. Service consumers interact with provider systems via a service interface. Related Architectural Mechanisms Guidance regarding the implementation of provider systems and their conformance to service interfaces appears in the Adapter and Consumer System Guidelines defined below. Notes/Comments None. Interaction Definition Interaction with a service consists of performing actions against a service. Relationships to Other Concepts Service interaction is accomplished by exchange of messages between the service consumer and the service via the service interface. Interaction depends on two things. Maine Justice Information Sharing Architecture Page 6 of 49 Version 1.0 October 15, 2007
  10. 10. • The designers of potential consumers need to be able to find services and, once found, establish a physical interaction mechanism with them. These needs are addressed by the concept of visibility. • The designers of potential consumers need a description of the actions that can be performed on a service, as well as the structure and meaning of information exchanged during the interaction. These needs are addressed by the concept of service model. Related Architectural Mechanisms Service Interaction Standards, defined in the architecture below, establish the standard way(s) in which service interaction occurs. Notes/Comments None. Visibility and Closely Related Concepts Definitions Visibility is the relationship between service consumers and providers that is satisfied when they are able to interact with each other. Preconditions to visibility are awareness, willingness and reachability. Awareness is a state whereby a service consumer (more properly, the designer of a consumer system) has knowledge of the existence of a service that meets some business need. Willingness is a predisposition or intent on the part of a service consumer or service provider (or both) to interact through a service. Reachability is the ability of a service consumer and service to communicate with each other by exchanging messages. Relationships to Other Concepts Awareness is generally the result of effective use of a repository. Service interaction cannot take place without visibility. Reachability is achieved mostly through effective provisioning of execution context. Willingness is often expressed through policy and contract mechanisms. Related Architectural Mechanisms None. Notes/Comments None. Service Description Definition A service description is the set of information needed in order to use the service. Relationships to Other Concepts A service description consists of the information model and behavior model of the service. Service descriptions are stored, maintained, and found in a repository. Service descriptions consist of the specifications for the various messages that are exchanged with the service. Maine Justice Information Sharing Architecture Page 7 of 49 Version 1.0 October 15, 2007
  11. 11. Related Architectural Mechanisms Service Specification Standards defined in the architecture below determine the standard structure and content of service descriptions. Notes/Comments None. Information Model Definition The information model of a service is a characterization of the information that may be exchanged with the service. Only information and data that are potentially exchanged with a service are generally included within that service's information model. The scope of the information model includes the format of information that is exchanged, the structural relationships within the exchanged information and also the definition of terms used. Relationships to Other Concepts The information model of a service is part of the service description. The information model of a service should be constructed from semantic concepts defined in domain vocabularies, wherever appropriate. Related Architectural Mechanisms Service Specification Standards defined in the architecture below determine the standard structure and content of the information model. Notes/Comments The information model of a service represents the explicit, formal agreement among the partners regarding the structure and meaning of information within the scope of that service. It does not necessarily represent a single, standard meaning for a term or concept across all services, nor does it govern how individual organizations within the justice system name or define terms/concepts within their environment or systems. Behavior, Action, and Process Models Definitions The behavior model of a service is a description of the actions that may be invoked against the service and the process or temporal aspects of interaction with the service. These parts of the service description are called the action model and process model, respectively. That is, the behavior model is the union of the action and process models. The action model is the set of functions performed by a service, and so defines what a service “does”. The action model defines the methods by which a service consumer achieves one or more real-world effects through the service. The process model describes the contextual relationship between a service’s actions and the actions defined on other services. It defines business processes or workflows in which a service plays a role. Relationships to Other Concepts The behavior model of a service is part of the service description. The process model can specify intermediaries—in particular, orchestration services. Maine Justice Information Sharing Architecture Page 8 of 49 Version 1.0 October 15, 2007
  12. 12. Related Architectural Mechanisms Service Specification Standards defined in the architecture below determine the standard structure and content of the behavior model. Notes/Comments The action model specifies only the aspects of the action that are visible to and have impact on the service consumer. That is, state change or triggered functionality that is only visible within the provider system should not be described in the action model. The process model defines how a service can be made to work in concert with other services to achieve higher-level effects. Message Definition A message is the entire package of information (sequence of bytes) that flow between a service consumer and a service during interaction. Relationships to Other Concepts The structure and content of the messages related to a service are described in the service description. A message should conform, where appropriate, to domain vocabularies. Related Architectural Mechanisms None. Notes/Comments None. Domain Vocabulary Definition A domain vocabulary is a formal, structured definition of a set of concepts, their meaning, and their interrelationships that compose a topical or business domain (or part of a domain). Relationships to Other Concepts The information model of a service is constructed from one or more domain vocabularies, where appropriate. Messages should conform, where appropriate, to domain vocabularies. Related Architectural Mechanisms None. Notes/Comments None. Service Interface Definition The service interface is the means for interacting with a service. It includes the specific protocols, commands, and information exchange by which actions are initiated that result in the service's advertised real-world effects. Maine Justice Information Sharing Architecture Page 9 of 49 Version 1.0 October 15, 2007
  13. 13. A service interface is a computer software component with which other components communicate to accomplish interaction with the service. Relationships to Other Concepts A service interface is described within the service description. Related Architectural Mechanisms A service interaction profile determines the protocols, commands, and nature of the information exchange reflected in a service interface. Notes/Comments None. Service Interaction Profile and Closely Related Concepts Definitions A service interaction profile defines a family of industry standards or other technologies or techniques that together demonstrate implementation or satisfaction of: • Service interaction requirements, which define the protocols, commands, and information structures necessary to communicate between service consumer and service in a way that adheres to certain defined rules • Interface description requirements, which define the required structure and content of a service interface • Message exchange patterns, which define how specific sequences of related messages are transmitted between service consumer and service Relationships to Other Concepts Each service interface conforms to one and only one service interaction profile. Related Architectural Mechanisms Service interaction standards determine the standard set of requirements for service interaction that must be addressed by every service interaction profile, and determine how to select the service interaction profile that applies in any given situation. Notes/Comments By supporting a service interaction profile, an interface establishes the mode of interoperation it allows from service consumers; any consumer that also supports that profile can “reach” the service. Adapter Definition An adapter is a software component (or set of components) that enable(s) a provider system to implement a service interface. Relationships to Other Concepts None. Related Architectural Mechanisms Guidance regarding the implementation of adapters appears in the Adapter and Consumer System Guidelines defined below. Maine Justice Information Sharing Architecture Page 10 of 49 Version 1.0 October 15, 2007
  14. 14. Notes/Comments Depending on the type of provider system, adapters may be available from the system vendor or a different vendor; in other cases, the service provider may need to build a custom adapter. Intermediaries and Closely Related Concepts Definitions An intermediary is any capability that receives messages from a consumer and subsequently, as a service consumer itself, interacts with another service. The term “intermediary” indicates that these capabilities sit between other services and “mediate” the interaction by managing, controlling, brokering, or facilitating the transmission of messages between them. An orchestration is a capability that controls and manages interaction with multiple services. A router is a capability that receives a message, examines it, and transmits it to one or more destinations based on the contents. A transformer is a capability that receives a message and transforms it into another format before transmitting it on to another destination. A message validator is a capability that examines a message to ensure that the contents adhere to established business rules. An interceptor is a capability that receives a message and uses the message content to trigger a secondary action; generally, interceptors pass the message unaltered to the next step in a process. Most interceptors capture information from the message for reporting or analytical purposes. Relationships to Other Concepts None. Related Architectural Mechanisms Guidance regarding the specification, design, and implementation of intermediary services appears in the Intermediary Service Guidelines defined below. Notes/Comments An orchestration is often implemented using an open industry standard implementation mechanism such as Business Process Execution Language (BPEL), which allows the implementation to be shared across tools and platforms. In general, routers can be designed to operate on any of the information contained within the message; they may use information about the origin of the message, routing directive information contained within the message or the main content of the message itself. Intermediaries provide for one of the key benefits of a service-oriented architecture, which is the separation of information-sharing or integration logic from the logic of line-of-business systems. Without intermediaries, integration logic would be mixed with line-of-business system logic, creating undesired dependencies and coupling between the two. When either line-of-business or integration functionality or implementation changed, the other would have to change also, even if there was no specific business reason for the change. The separation of line-of-business logic and integration logic is a key factor in enabling the agility that drives the business case for adopting SOA. Execution Context Definition Execution context is the set of infrastructure elements, process entities, policy assertions, and agreements that are identified as part of a specific, real interaction between a service consumer Maine Justice Information Sharing Architecture Page 11 of 49 Version 1.0 October 15, 2007
  15. 15. and a service. Execution context forms a communication and policy path between a service consumer with needs and a service that provides access to a capability that meets that need. Relationships to Other Concepts Execution context is a crucial element of enabling interaction. Related Architectural Mechanisms Shared Execution Context Requirements, defined in the architecture below, identify the infrastructure necessary to support general execution context across all interactions supported by the architecture. Notes/Comments There are general execution context aspects that are present for any service interaction that conforms to the standards and guidelines defined in the architecture. These aspects can be stated as requirements for shared infrastructure that Maine must acquire in order to support architecture-conformant interactions. This infrastructure will likely include the hardware and software components that form the path between senders and receivers of information, and will include shared/enterprise data networks, “middleware” or “broker” functionality that routes and transforms messages, and other integration-support infrastructure. Repository Definition A repository is a shared storage and discovery mechanism for service descriptions. It allows the designers and implementers of service consumers (consumer systems) to find services that meet their needs, and then to obtain the descriptions of those services. It allows service providers to maintain and disseminate descriptions of the services they provide. Relationships to Other Concepts The existence of a repository is necessary for effective and efficient visibility. Related Architectural Mechanisms Repository Requirements, defined in the architecture below, identify the necessary features of a repository. Notes/Comments None. Policy and Contract Definition A policy is an assertion by either a consumer or service provider of that participant’s requirements for willingness to interact. A policy also has an enforcement aspect and must be stated in such a way as to permit enforcement. A contract is an agreement by the parties involved, and there is a process associated with the agreement action. Whereas a policy is an assertion by one participant in the interaction, a contract is an agreement between the participants that expresses some expectation or requirement of the interaction. Relationships to Other Concepts None. Related Architectural Mechanisms None. Maine Justice Information Sharing Architecture Page 12 of 49 Version 1.0 October 15, 2007
  16. 16. Notes/Comments Whereas policy enforcement is generally the responsibility of the participant who asserts the policy, contract enforcement may involve resolution of disputes that arise between the parties. Policy and contract is where the traditional subjects of Memoranda of Understanding (MOUs) would be addressed within this architecture. Topics such as how information may be used, how long it may be retained, the credentials required to gain access to information, and other issues commonly addressed in an MOU, would be stated as part of the policy or contract for a service that provides access to the information. Maine Justice Information Sharing Architecture Page 13 of 49 Version 1.0 October 15, 2007
  17. 17. Service Identification Methodology This section of the architecture provides a set of standards for the identification of services. It is the intent of this document to conform to service identification methodology guidelines developed and endorsed by the Global Justice Information Sharing Initiative as part of the Justice Reference Architecture ([JRA]). As of June 2007, the JRA does not yet include formal guidelines; however, this section incorporates initial versions of guidelines being considered internally by Global committees. Usage These standards will be used by justice partner organizations in Maine to govern the manner in which partners identify points of interaction between their information systems. Naming Services The name8 of a service SHOULD encapsulate the set of actions in the service’s action model. That is, the name should reflect the set of goals that a consumer can accomplish, or the real- world effects that a consumer may achieve, by using a service. Principles of Service Design: What makes a good service? A service SHOULD reflect the following principles. Note that principles are not rules or standards, in that it is generally not objectively true whether a service conforms to or complies with a principle. Principles express general characteristics of services, not objective facts about services. Service Abstractness A service’s models and name SHOULD reflect what the service does or what it accomplishes and SHOULD NOT describe how the service works or how it is implemented. Service Autonomy There SHOULD be one and only one service that produces a given real-world effect. Once a service is available to provide access to a capability, consumers SHOULD NOT access that capability except through the service. Service Reusability A service SHOULD NOT preclude usage by consumers or in contexts not explicitly prohibited by the service’s stated policy or contract. Service Loose-Coupling A service SHOULD have minimal dependencies on other services, the execution context, and the business organization responsible for providing it. Separable real-world effects SHOULD be achieved through use of separate services.9 Service Statelessness All information necessary for a service to perform an action in its action model SHOULD be provided by the consumer during interaction, or obtained by the service implementation during performance of the action. A service SHOULD NOT rely upon information retained from a previous interaction with a consumer. 8 While the name of a service may seem to be appropriately governed by the architecture’s Service Specification Standards, it is included here because choosing a name for a service is the primary result of identifying it. 9 A common example of this principle is that separate services should handle the reporting of an event in the justice process, and the policy response to that event. Maine Justice Information Sharing Architecture Page 14 of 49 Version 1.0 October 15, 2007
  18. 18. Boundaries Between Services An important aspect of identifying a service is determining which actions belong in its action model. Often the question arises whether a new action belongs with a new service or an existing service, and if an existing service, then which one. Actions SHOULD be grouped together if they are likely to change together (in terms of their interface). How to Identify Services The process of identifying services begins with establishing strategic intent for a specified planning period (e.g., a biennium or a year). Strategic intent is best represented by a strategic plan that does the following: • Restates and confirms the long-term mission and vision of justice information sharing in Maine • Identifies specific business goals and objectives to be achieved during the planning period, in pursuit of the mission and vision • Identifies organizational and technology capabilities necessary to achieve the goals and objectives • Identifies projects to provide for or implement the necessary capabilities • Establishes a strategy for measuring and reporting performance After establishing strategic intent, the next step is to charter and execute the identified projects. Some projects will likely require the sharing of information or functionality between systems across organizational boundaries (i.e., between partner agencies). There is a service at every point where systems need to share information or functionality. When such a point of required sharing is discovered, the project MUST do the following: 1. The project MUST search the service repository to determine if a service already exists that implements all or part of the required sharing. 2. If an existing service completely implements the required sharing, then the project MUST use it rather than re-implementing a second service. 3. If an existing service partially implements the required sharing, then the project MUST propose new process, action, and information models for the service as necessary to meet its requirements, and initiate the Change Management Process defined under Governance Guidelines below. 4. If no existing service either partially or completely implements the required sharing, then the project MUST follow the Service Specification Standards below to specify a new service. In selecting the scope boundaries for a service, the project MUST apply the Principles of Service Design identified in this section above. Justice Information Exchange Modeling (JIEM) Methodology The Justice Information Exchange Modeling (JIEM) Methodology has become a de-facto standard in the national justice information sharing community for the identification and documentation of the contextual requirements of information exchange. The JIEM Methodology is defined in [JIEM] and [JIEM Framework]. The Service Specification Standards below define the JIEM Methodology’s role in service specification—in particular, that JIEM SHOULD be used to define the process model of the service. This section links JIEM Methodology concepts to the concepts defined in this architecture, with the goal of ensuring that requirements captured in JIEM lead to properly identified and specified services. Maine Justice Information Sharing Architecture Page 15 of 49 Version 1.0 October 15, 2007
  19. 19. In using JIEM to define the process model for a service, projects SHOULD do the following: 1. Exchanges in JIEM equate to individual actions in the action model of a service. JIEM does not currently provide a mechanism for grouping exchanges into a concept equivalent to a service. Thus, the name of an exchange in JIEM should consist of two parts. The first part should name the service for which the exchange represents an action in the action model. The second part should name the action itself. A separator should be used between the two parts of the name.10 2. JIEM exchanges should adhere to the Principles of Service Design identified in this section above, and should follow the guidance on service naming defined above. 3. Agencies captured in JIEM should reflect business capabilities, not necessarily organizations or organizational units. 4. The receiving agency for an exchange should encapsulate the real-world effect (business value) provided by the capability to which the service provides access. The notes attribute of the agency object should be used to capture further details or key information about the capability and its real-world effects. 5. The sending agency for an exchange should represent the service consumer. If the expectation is that only one consumer will ever interact with a capability, identify the consumer as the sending agency. If the interaction will not be limited to one consumer, then create an “undefined sending agency” in JIEM and assign that as the sending agency. 6. Identify events that trigger interaction between consumers and capabilities. Use the JIEM Adult Felony Reference Model as a guide when identifying events. Identify separate capabilities (receiving agencies) and exchanges for event reporting and response. 7. Reflect service policy issues (willingness) in JIEM conditions. Note that JIEM exchanges are “one-way”, analogous to the Fire-And-Forget message exchange pattern defined under Service Interaction Standards below. 10 It is expected that a future version of JIEM will allow for the grouping of exchanges into services. Should JIEM offer this functionality at some point in the future, the methodology described here will be changed to remove the two-part exchange naming approach. Maine Justice Information Sharing Architecture Page 16 of 49 Version 1.0 October 15, 2007
  20. 20. Service Specification Standards This section of the architecture provides a set of standards for the specification or description of services. It is the intent of this document to conform to service specification guidelines developed and endorsed by the Global Justice Information Sharing Initiative as part of the Justice Reference Architecture ([JRA]). As of June 2007, the JRA does not yet include formal guidelines; however, this section incorporates initial versions of guidelines being considered internally by Global committees. Usage These standards will be used by justice partner organizations in Maine to govern the structure and content of service descriptions. These standards can be referenced in design documents for projects involving inter-agency information exchange, and in requests for proposals, to ensure that staff and contract implementers engaged for different partner agencies on different projects produce consistent service descriptions. Structure of Service Description A service description MUST be structured as follows. Service Name This section defines the name for the service. The name MUST indicate what the service does, not how it works. The name should not indicate anything about the internal implementation of the service. Motivation This section describes the business need addressed by the service by describing the business value of the real-world effect produced by the service. It MUST consist of one or more paragraphs of prose text that describes the business need. The business need SHOULD trace back to one or more elements of a project plan or strategic plan, through the service identification methodology described above. Process Model This section describes the business processes in which this service plays a role. The process model description MUST consist of one or both of the following: • The name(s) of one or more processes defined in a Justice Information Exchange Modeling (JIEM) site model, corresponding to the business processes in which the service plays a role • One or more Business Process Modeling Notation (BPMN) diagrams describing the business processes in which the service plays a role Action Model This section describes the functions performed by the service. It MUST consist of conceptual, logical, and physical descriptions, as follows. The conceptual description MUST consist of one or more paragraphs of prose text that describe these functions. The description SHOULD describe each function in terms of the purpose, intent, or value of a consumer performing that function. The description SHOULD identify the principal information entities from the information model involved in performing each action. The description SHOULD identify any conditions that cause exceptional termination of each action, and information entities from the information model used to inform the consumer of such termination. Maine Justice Information Sharing Architecture Page 17 of 49 Version 1.0 October 15, 2007
  21. 21. The logical description MUST consist of a Unified Modeling Language (UML) static structure diagram11, in which the service appears as a class, and each function in the action model appears as an operation on that class. The operation signature MUST identify input and output parameters of the appropriate types from the logical information model description. The physical description of a service’s action model will depend on the service interaction profile chosen to govern interaction with the service. Reference the interface description requirements and each profile’s mechanism for implementing those requirements for the normative definition of a service’s physical action model. Information Model This section describes the structure of information passed into, and returned from, the service during interaction. It MUST consist of conceptual, logical, and physical descriptions, as follows. The conceptual description MUST list all the information entities involved in interaction with the service, and MUST provide one or more paragraphs of prose text that defines each entity. The conceptual description MAY be represented by the information dimension defined in a Justice Information Exchange Modeling (JIEM) site model. The logical description MUST consist of a Unified Modeling Language (UML) static structure diagram defining the information entities/structures in terms of classes, associations between classes, and attributes of classes. The physical description of a service’s information model will depend on the service interaction profile chosen to govern interaction with the service. Reference the interface description requirements, message definition mechanisms, and each profile’s mechanism for implementing these requirements for the normative definition of a service’s physical information model. Service Taxonomy This section identifies metadata to be captured about each service. It is anticipated that this list of metadata will grow as Maine stakeholders identify additional useful categorizations of services and additional information necessary to support common searches for service descriptions. The service description MUST contain a table (or equivalent mechanism) that associates values with the following metadata items: • service-provider: The name of the organization providing this service • service-provider-contact-name: The name of a contact person at the service provider organization who can provide information about the service • service-usage-category: Is this an infrastructure service or line-of-business service? A line-of-business service is one whose real-world effect is of primary value to a strategic business objective. An infrastructure service is one that supports line-of-business services and whose real-world effect is of secondary, supporting, or enabling value to a strategic business objective. Service Interaction Requirements This section identifies those requirements from the standard list of service interaction requirements that apply to this service. This section MUST list each of the requirements defined in section “Service Interaction Requirements” below, and MUST indicate whether that requirement is a requirement of this service. If any parameterization of a service interaction requirement is necessary, this section MUST fully describe any parameters and their values. This section MUST designate which service interaction profile governs interaction with this service. 11 To do: reference UML specification. Maine Justice Information Sharing Architecture Page 18 of 49 Version 1.0 October 15, 2007
  22. 22. Policy or Contract This section defines or references the service provider’s policy governing use of the service, or the contract(s) between the service provider and each consumer. The governance guidelines defined below identify common issues to be addressed in the policy or contract for a service. Maine Justice Information Sharing Architecture Page 19 of 49 Version 1.0 October 15, 2007
  23. 23. Service Interaction Standards This section of the architecture provides a set of standards for the interaction between service consumers and services. The intent of these standards is to conform as closely as possible to the relevant guidance in the Justice Reference Architecture ([JRA]). As of June 2007, the JRA does not define service interaction standards, but it does define several service interaction profiles, including the Web Services Service Interaction Profile (referenced below, and see [JRA WS SIP].) The service interaction requirements identified below are taken directly from the JRA, and are repeated here for reader convenience. Usage The standards defined in this section will be used by the Maine justice partners to govern the interaction between consumers and services. No information exchange or sharing of functionality between organizations or systems is considered conformant with this architecture unless that exchange/sharing occurs in a manner conformant with the standards in this section. These standards provide staff and contract implementers with the guidance necessary to implement interoperable information exchange points. As such, these standards SHOULD be referenced by project/system design documentation and requests for proposals (RFPs) as necessary to provide this guidance. Service Interaction Requirements The following are the service interaction requirements defined in this architecture.12 Service Consumer Authentication Information provided with messages transmitted from service consumer to service that verifies the identity of the consumer. Service Consumer Authorization Information provided with messages transmitted from service consumer to service that documents the consumer’s authorization to perform certain actions on and/or access certain information via the service. Identity and Attribute Assertion Transmission Information provided with messages transmitted from service consumer to service that asserts the validity of information about a human or machine, including its identity. Service Authentication The ability of a service to provide a consumer with information that demonstrates the service’s identity to the consumer’s satisfaction. Message Non-Repudiation Information provided in a message to allow the recipient to prove that a particular authorized sender in fact sent the message. Message Integrity Information provided in a message to allow the recipient to verify that the message has not changed since it left the control of the sender. Message Confidentiality Information provided in a message to prevent anyone except an authorized recipient from reading the message or parts of the message. 12 These requirements are copied verbatim from [JRA] and are repeated here for reader convenience. Maine Justice Information Sharing Architecture Page 20 of 49 Version 1.0 October 15, 2007
  24. 24. Message Addressing Information provided in a message that indicates where a message originated, the ultimate destination of the message (beyond physical end point), a specific recipient to whom the message should be delivered (this includes sophisticated metadata designed specifically to support routing), and a specific address or entity to which reply messages (if any) should be sent. Reliability Information provided with messages to permit message senders to receive notification of the success or failure of message transmissions, and to permit messages sent with specific sequence-related rules either to arrive as intended, or fail as a group. Transaction Support Information provided with messages to permit a sequence of messages to be treated as an atomic transaction by the recipient. Service Metadata Availability The ability of a service to capture and make available (via query) metadata about the service. Metadata is information that describes or categorizes the service and often assists consumers in interacting with the service in some way. Message Exchange Pattern Requirements Three patterns of message exchange between service consumers and services are supported by this architecture.13 The “fire-and-forget” pattern calls for the sender of a message (which could be the service consumer or service) to send the message and not expect a reply message back from the recipient. This pattern is useful for one-way transmission of information, such as notification that an event has occurred. The “request-reply” pattern calls for the sender of a message to send the message and expect a reply back from the recipient. These two patterns are considered “primitive” patterns, in that they are the fundamental building blocks of more complex information exchange scenarios. For instance, the complex “publish- subscribe” pattern involves an initial request-reply exchange in which the subscriber subscribes to a service, followed by the service using the fire-and-forget pattern to notify subscribers of an event. Interface Description Requirements Interface description requirements14 establish common characteristics of service interface descriptions. These requirements address areas such as required interface contents, naming rules, documentation rules, and specification of a standard structure and format for descriptions. Standards Standards for Service Interaction Profiles Each service interaction profile MUST demonstrate a mechanism for implementing each of the Service Interaction, Message Exchange Pattern, and Interface Description Requirements defined in this section. 13 These requirements correspond to the standard Message Exchange Patterns defined in [JRA], which are copied here verbatim and for reader convenience. 14 These requirements are copied verbatim from [JRA] and are repeated here for reader convenience. Maine Justice Information Sharing Architecture Page 21 of 49 Version 1.0 October 15, 2007
  25. 25. Standards for Services, Service Consumers, and Service Descriptions To be considered conformant with this architecture, each interaction between a service consumer and a service MUST conform to one and only one service interaction profile. Individual service descriptions MUST specify which of these requirements apply to each service. A service MAY require only a subset of these requirements. However, if a requirement does apply to a service, then that requirement MUST be implemented (by both the service and the consumer) in a manner that conforms to the service interaction profile designated by the service description. Maine Justice Information Sharing Architecture Page 22 of 49 Version 1.0 October 15, 2007
  26. 26. Web Services Service Interaction Profile This section of the architecture identifies a set of mechanisms, based on the Web Services family of industry standards, for implementing the requirements defined in section “Service Interaction Requirements” above. Usage This profile is will be used by the Maine justice partners to govern interactions between service consumers and services based on the Web Services family of industry standards. Profile In order to conform to this architecture, all service interfaces, service consumers, and messages involved in the sharing of information or functionality between Maine justice partner systems MUST conform to the guidance of the Global Justice Reference Architecture Web Services Service Interaction Profile, version 1.0, as defined in [JRA WS-SIP]. The Domain Vocabulary to be used in message definitions and interface descriptions that conform to this architecture is the Global Justice XML Data Model (GJXDM) version 3.0.3. Maine Justice Information Sharing Architecture Page 23 of 49 Version 1.0 October 15, 2007
  27. 27. Intermediary Service Guidelines This section of the architecture identifies guidelines for the implementation of intermediary services. This section identifies guidelines (“SHOULD” directives) rather than standards (“MUST” directives) because mature, widely-implemented industry standards in this area do not exist. For that reason, it is likely that Maine will need to remain flexible in this area and willing to adapt to the mechanisms and techniques are made available by the selected shared execution context infrastructure, as discussed below. Usage The guidelines in this section will be used by the Maine justice partners to: • Inform the selection of shared execution context infrastructure • Provide technical direction on the implementation of integration logic, and promote the separation of that logic from the logic of individual agency line-of-business systems • Guide staff skills development and inform Maine’s vendor partners of the techniques used to implement integration logic Guidelines An information exchange among two or more justice partners SHOULD implement the following functionality as an intermediary, rather than within the line-of-business systems that produce or consume the information being exchanged: • Functionality that determines the destination or distribution of the information (router) • Functionality that transforms or reformats information to suit the needs of the recipient (transformer) • Functionality that controls, manages, or orchestrates a logic flow, or governs interactions between several services to provide a composite capability (orchestration) • Functionality that records “meta” information about an information exchange, such as the time at which it occurred and its status (interceptor) • Functionality that validates messages involved in an information exchange (validator) The behavior of intermediary services SHOULD be specified using open industry standards whenever possible. Orchestrations SHOULD be specified in [BPEL]. Transformers SHOULD be specified, to the extent practicable, in [XSLT]. Validators SHOULD be specified, to the extent practicable, in terms of sets of GJXDM- conformant schemas (Information Exchange Package Documentation (IEPD)). Maine Justice Information Sharing Architecture Page 24 of 49 Version 1.0 October 15, 2007
  28. 28. Shared Execution Context Requirements This section of the architecture identifies the necessary features of shared execution context to support reachability of services, and interaction that conforms to the service interaction profiles within the architecture. Usage The requirements in this section will be used by the Maine justice partners to: • Plan for the acquisition of shared/common information sharing infrastructure • Discriminate between effective and non-effective infrastructure solutions in the marketplace • Form the basis of a Request for Proposals (RFP) to acquire shared/common information sharing infrastructure at a future time Requirements The following requirements are organized into three sections. The first section addresses infrastructure that supports reachability in general, and support for service interaction profiles in particular. The second section addresses support for intermediaries. The third section addresses desired characteristics of the infrastructure itself. Reachability and Service Interaction Profile Support Shared execution context must provide an effective and efficient path along which service consumers and service providers can interact through message exchange. In addition, this architecture identifies specific common requirements of service interaction, and a service interaction profile that identifies specific standards (from the Web Services family) to satisfy these requirements. Data Transport Layer Shared execution context requires a network that supports data transport via TCP/IP between the Maine justice partner locations at which consumer and provider systems will be deployed. The network must provide adequate bandwidth to support message exchange that complies with response times specified in service policies and contracts. To the extent that service interaction requirements are implemented through reliance on network reliability and security, the network must satisfy reliability/availability and security requirements specified in service policies and contracts. The network must permit the transmission of HTTP and HTTP/S traffic (on TCP ports 80 or 443) between the partner locations. A review of the Maine state government network in June 2007 indicates that the network currently satisfies the above requirements, at a level necessary to support current justice information exchanges between the partners. As information exchanges are redefined as services in the future, and as service policies and contracts may change the requirements, the Maine partners must continue to evaluate the network’s satisfaction of these requirements. The Office of Information Technology (OIT) should be included in future strategic planning sessions and efforts to identify/plan services, so that it may properly plan adequate network bandwidth, protocols, and capabilities necessary to support those services. Partner agencies acting as service providers will establish formal network requirements through service-level agreements (or equivalent, formal, written mechanisms) with OIT far enough in advance to allow OIT to adjust network capabilities as required. It is expected that, for the foreseeable future, local law enforcement agencies in Maine will continue to reach services provisioned by state agencies through the Metro switch. The switch will therefore act as both a consumer system and provider system; this is described in more detail in the “Provider and Consumer System Guidelines” section below. Maine Justice Information Sharing Architecture Page 25 of 49 Version 1.0 October 15, 2007
  29. 29. Message Transport Layer The shared execution context must allow service providers to deploy and manage components called service containers15, which are defined as follows. A service container: • Receives messages and, based on the service action being invoked, interacts with one or more adapters to accomplish the service’s real-world effect • Manages the lifecycle of adapters (including configuration/initiation, disposal, and threading/concurrency issues) A service container must be capable of receiving and properly handling any message that conforms to a service interaction profile defined within this architecture. A service container consists of both hardware and software components. The hardware components (including operating systems installed on them) must conform to existing standards or common practices for web servers prevalent among the Maine justice partners, and/or standards prescribed by the Maine Office of Information Technology. The shared execution context must specify and/or provide software components or application programming interfaces (APIs) that service consumer systems will use or invoke in order to send messages. These components or APIs must support the sending of any message that conforms to a service interaction profile defined within this architecture. Web Services Service Interaction Profile Support The shared execution context must provide components that conform to the RM Source and RM Destination concepts in [WS-ReliableMessaging]. The hardware on which these components are deployed (including operating systems) must conform to existing standards or common practices for web servers prevalent among the Maine justice partners, and/or standards prescribed by the Maine Office of Information Technology. To the extent the components rely on a relational database for message persistence, the hardware (including storage), operating systems, and database software must conform to existing standards or common practices for databases prevalent among the Maine justice partners, and/or standards prescribed by the Maine Office of Information Technology. To the extent service interaction requirements are implemented at the network layer (e.g., authentication, authorization, confidentiality), the shared execution context requires a network that satisfies those requirements. To the extent these requirements are implemented by mechanisms identified in [WS-I BSP], the shared execution context must contain the following: • A mechanism for issuing and revoking digital certificates • A mechanism for obtaining the public key for any consumer or provider system that signs or encrypts message contents Intermediary Support Shared execution context must provide support for intermediary services, as defined in the Intermediary Service Guidelines section above. Specific requirements follow for particular intermediary service types. Router Support Shared execution context must support the definition and configuration of components that route messages to their destination based upon rules applied to the contents of messages. By “contents”, this requirement means either metadata attached to the message (as envisioned by 15 While the term “service container” is often associated with an enterprise service bus (see [ESB] for example), it is not the intent of this section to prescribe any particular product label or category. Any product or software solution that satisfies the requirements in this section is deemed conformant with this architecture, regardless of the label applied to that product/solution by its vendor. Maine Justice Information Sharing Architecture Page 26 of 49 Version 1.0 October 15, 2007
  30. 30. the Message Addressing service interaction requirement defined above) or the “main” message contents as defined in the service’s information model.16 The definition of router components should be accomplished by sophisticated, robust tooling that gives the user adequate power to define arbitrary routing rules from arbitrary message contents. The shared execution context infrastructure must provide a way for deploying router components once developed. Orchestration Support The shared execution context must support deployment, management, maintenance, and execution of orchestrated business processes defined in [BPEL]. Transformer Support The shared execution context must support deployment, management, maintenance, and execution of components that transform messages from one format/structure to another. The shared execution context should support transformers defined in terms of [XSLT] stylesheets. Infrastructure Characteristics The shared execution context must support the following: • Availability: The infrastructure must be available as necessary to support the most stringent availability requirements specified in service policies and contracts. Based on existing implementations of information exchanges to be deployed on the infrastructure in the future, the infrastructure must at a minimum be available seven days per week, 24 hours per day, with a 99.99% probability of availability. • Scalability: The infrastructure must be capable of a limited initial deployment (consisting of perhaps no more than one service and one consumer), while being capable of scaling to hundreds of services and consumers. • Configurability and Usability: The infrastructure must provide administrators with intuitive interfaces for configuration, deployment/management of service interfaces and service containers, and maintenance. • Security: The infrastructure must provide appropriate safeguards against unauthorized access to configuration, service and service container deployment/management, and maintenance capabilities. The infrastructure must provide the capability to log administrative activities in a manner that permits auditing of those activities. • Monitoring: The infrastructure must allow administrators to monitor the following: o The flow of information among the Maine partners (between consumers and services) o The status and current/recent usage of services o The status and number of pending/undelivered messages at each RM Source and RM Destination component, as defined in [WS-ReliableMessaging]. Incremental Implementation Strategy It is the intent of the Maine partners to implement this architecture, and therefore the supporting shared execution context, in an incremental fashion. Shared execution context will be acquired and deployed as required by actual operational services and consumers. Implications of this strategy are as follows: 16 These two scenarios are commonly labeled “metadata-based routing” and “content-based routing” in vendors’ integration product literature. Maine Justice Information Sharing Architecture Page 27 of 49 Version 1.0 October 15, 2007
  31. 31. • The shared execution context need not support RM Source and RM Destination components until the first service policy/contract requires reliable messaging (as defined in the service interaction requirements above) • The shared execution context need not support digital certificate issuance, revocation, and provisioning until the first service policy/contract requires message-level authentication, authorization, confidentiality, integrity, or non-repudiation. To the extent security requirements can be met at the transport level (i.e., by relying solely on network security), the shared execution context does not require digital certificate infrastructure. • The shared execution context need not support intermediaries until the first instance of significant integration logic implementation outside of line-of-business applications • Shared execution context solutions (hardware/software) will best support the strategy if they permit relatively modest initial investments that can scale over time to meet new requirements. Maine’s goal is to commit to a shared execution context platform that has all the capabilities identified in these requirements, but that supports incremental investment in and deployment of components to address those requirements. Maine Justice Information Sharing Architecture Page 28 of 49 Version 1.0 October 15, 2007
  32. 32. Repository Requirements This section of the architecture identifies necessary features of a repository to support awareness and visibility of services. Usage The requirements in this section will be used by the Maine justice partners to: • Plan for the acquisition of shared repository infrastructure • Discriminate between effective and non-effective repository infrastructure solutions in the marketplace • Form the basis of a Request for Proposals (RFP) to acquire shared repository infrastructure at a future time Requirements The overall goal of a repository is to support visibility in general, and awareness in particular. It is critical that the owners, designers, and implementers of consumer systems are aware of services that can be used to produce real-world effects within their scope. It is also critical that system implementers understand a service’s models (behavior and information) thoroughly, so they are able to implement the consumer system side of service interaction properly. Finally, it is critical that policies and contracts associated with a service be known to consumer system owners and designers, in order for them to “play by the rules.” A repository is a software solution, generally deployed using web technologies (i.e., browser-web server web application), that provides some or all of the following capabilities: • A Life Cycle Management interface that manages service models and associated artifacts: o Submission of models/artifacts and editing metadata about each artifact o Approval of submitted content o Deprecation of submitted content o Deletion of submitted content • A Query Interface that supports the discovery and retrieval of models/artifacts. • Content Management o Cataloging (dynamically creating metadata based on artifact content) o Validation of content upon submission • Security (Authentication, Authorization) • Auditing (submission, queries) • Event Notification o Users are notified (e.g., via email) when new content is submitted or existing content is edited o Users are able to choose which notifications to receive, e.g., via filtering mechanisms Near-term Requirements In the near term (designated as the time period during which the Maine justice partners manage fewer than 20 services), a simple and inexpensive repository solution consisting of a static Maine Justice Information Sharing Architecture Page 29 of 49 Version 1.0 October 15, 2007
  33. 33. website will be sufficient to support the needs of the Maine stakeholders. Submission, editing, and removal of service models and associated artifacts would occur by interacting manually (e.g., via email) with a designated repository administrator. Querying the repository will consist of the user manually scanning the list of (fewer than 20) service specifications. Auditing, cataloging and validation of content, as necessary, will be performed by the repository administrator. Security (e.g., permission to submit content) will be applied by the administrator at submission time, and the repository website will be hosted on a network that ensures only authorized users have access. If stronger authentication is required, the website can implement simple HTTP authentication. Event notification will occur via email distributed by the repository administrator. Long-term Requirements In the long term (when the partners manage 20 or more services), a set of manual processes in which a single human repository administrator updates a static website will likely no longer be sufficient. When the Maine justice partners reach this point, they should transition to a repository solution that conforms to [ebXML Registry].17 17 The ebXML Registry standard was selected for the following reasons. It is the leading open industry standard for registry/repository solutions, and includes as a subset the secondary standard (Universal Description, Discovery, and Integration). It has wide industry adoption (the leading “SOA Governance” vendors implement the standard, and also has an open source implementation (freebxml). It effectively addresses the general requirements listed in this section. Maine Justice Information Sharing Architecture Page 30 of 49 Version 1.0 October 15, 2007
  34. 34. Provider and Consumer System Guidelines This section of the architecture provides guidance on the implementation of provider and consumer systems so that these systems may participate effectively in the architecture. As stated in the Foundation Concepts section above, provider systems implement service interfaces through adapters. This section provides a strategy for creating adapters for the following line-of-business systems in use within the Maine justice community: • Criminal History Records Information (CHRI) System • State Police Metro Switch • Corrections Information System (CORIS) • JustWare Prosecutor • Maine Judicial Information System (MEJIS) The focus on these four systems is not intended as an indicator that only these four will be able to participate in the architecture. Rather, the intent is to focus attention and effort on those systems expected to participate in the initial phases of completing the criminal history information cycle. Similar analysis and guidelines will be necessary as future partners seek to participate. Usage The guidelines in this section will be used by the Maine justice partners to: • Understand how existing systems will exchange information using the architecture • Assess approach, and required resources and effort, necessary to participate in the architecture Guidelines for Existing Systems The guidelines associated with each participating system follow. Criminal History Records Information (CHRI) System18 The CHRI system has been developed on the Java 2 platform, and runs in the JBoss Application Server. It is currently (July 2007) supporting a small number of web services transactions (approximately ten percent of the total number of transaction types), leveraging the Apache Axis web services toolkit built in to JBoss. The strategic direction is to support web services for new transaction interfaces, so the future of CHRI is already well-aligned with the requirements of the Web Services Service Interaction Profile defined in this architecture. The cost and effort of implementing additional service interfaces will be a factor primarily of developing Java components that are deployed in the JBoss application server environment to interact with existing CHRI components and/or the backend Oracle database. It is anticipated that CHRI will not be a significant consumer system. However, should CHRI need to consume services offered by other partners, it would leverage the Java 2 platform’s robust support for forming and sending web services messages that conform to the Web Services Service Interaction Profile defined in this architecture, such as the Java API for XML Web Services (JAX-WS). 18 Information gathered from telephone interview of Mike Naseem 12 July 2007. Needs to be re-written because of migration to Sun Solaris (Glenda 2008)… Maine Justice Information Sharing Architecture Page 31 of 49 Version 1.0 October 15, 2007
  35. 35. State Police Metro Switch19 The Metro switch is a Java 2 platform application, allowing it to consume services offered by other partners by leveraging the Java 2 platform’s robust web services capabilities. The Metro switch already supports the receipt of web services messages. This capability will be leveraged in an upcoming project through which the Administrative Office of the Courts will send the switch information about disqualifying factors for firearm purchases. In the statement of work for this project, CPI (the Metro switch vendor) has attested that switch server technologies (Java 2, Tomcat, Xerces, Xalan) are capable of parsing and processing SOAP messages. More specifically, the current version of the switch uses a version of the Java Web Services Development Pack (JWSDP) from Sun Microsystems that does not support WS-I conformant web services, but updating the switch implementation to support WS-I conformance should be relatively simple.20 The cost and effort involved in implementing service provider or consumer functionality in the Metro switch will largely be a function of the effort required to implement the sending or receiving logic in the switch itself, not in processing or parsing web services messages. In most cases, this would require modification of the software by the vendor, CPI. Corrections Information System (CORIS)21 CORIS is built on the Microsoft .NET platform, which has strong support for standards- conformant sending and receiving of web services messages. CORIS has recently added an “integration platform” that supports web services for CORIS interactions with InforME, case management (MEJIS), and the new corrections telephone system. The CORIS integration platform makes available the capabilities necessary to read and write data to/from the CORIS database. The .NET platform, through the Windows Communication Foundation (WCF) libraries, provides the capability to parse WS-I conformant SOAP messages, and also to form and send messages. The cost and effort involved in implementing service provider or consumer functionality in CORIS will largely be a function of the effort required to implement the sending or receiving logic in the application, not in processing or parsing web services messages. In most most cases, this would require modification of the software by the vendor, X-Wave. JustWare Prosecutor22 The JustWare Prosecutor system alone does not include information sharing capabilities, except as a “shared database” architecture with other JustWare products (Court, Defender, etc.) To implement information exchanges with non-JustWare systems, New Dawn Technologies offers a product called JusticeBroker. JusticeBroker acts as an adapter that interacts with JustWare applications and translates (or “brokers”) application interactions to and from a variety of formats and protocols, including web services that conform to [WS-I BP]. JusticeBroker offers a web- based application for configuring data exchanges and performing mapping from JustWare data structures to message structures. For most data exchanges, New Dawn Technologies must develop custom components that are deployed within JusticeBroker to interact with JustWare Prosecutor. While the current version of JustWare deployed by the Maine prosecutors is supported by JusticeBroker, New Dawn has stated that newer versions of JustWare are better supported (JusticeBroker is able to interface with JustWare in a more cost-effective manner). This is important, given that the prosecutors are planning a future upgrade to JustWare. 19 Information gathered from interview of Jack Parkin 27 August 2007. 20 Information gathered from Jack Parkin conversation with CPI 19 September 2007. 21 Information provided by Barry Hansen of X-Wave via email 14 August 2007. 22 Information gathered from Tom Jewett presentation 28 June 2007, and JustWare / JusticeBroker product information provided by Gordon Jeppson of New Dawn Technologies. Maine Justice Information Sharing Architecture Page 32 of 49 Version 1.0 October 15, 2007
  36. 36. The cost and effort to form and send web services messages from JustWare Prosecutor will be a function of: • The cost of licensing and deploying JusticeBroker • The cost of engaging New Dawn Technologies to develop JusticeBroker components to interact with JustWare Prosecutor Maine Judicial Information System (MEJIS)23 Guidelines for MEJIS participation in the architecture are as follows. MEJIS as Provider System MEJIS has already adopted a service-oriented architecture to guide the connectivity of MEJIS client software to the MEJIS server components. All MEJIS functionality is currently exposed as web services. Most commercial implementations of shared execution context contain built-in adapters for web services, so making MEJIS functionality available as services as defined in this architecture should be straightforward. If existing MEJIS services are not able to implement services identified as appropriate for the court case management capability, then intermediary services (e.g., transformers) or a more sophisticated adapter may be necessary. Whether this is a factor will be determined when specific services are identified and modeled. MEJIS as Consumer System It is anticipated that MEJIS consumption of services offered by other justice partners would take place within MEJIS server components. These components have been developed at and are maintained by the Administrative Office of the Courts, using the Java 2 platform. This platform has robust support for forming and sending web services messages that conform to the Web Services Service Interaction Profile defined in this architecture, such as through the Java API for XML Web Services (JAX-WS). Therefore the technology barriers to MEJIS acting as a consumer system are minimal. The cost and effort required to form and send web services messages from MEJIS will be a function primarily of the complexity of the messages and the availability of required information within MEJIS. 23 Information gathered from Doug Birgfeld presentation 28 June 2007, and MEJIS 2 Developer Handbook. Maine Justice Information Sharing Architecture Page 33 of 49 Version 1.0 October 15, 2007
  37. 37. Illustration of Provider/Consumer Systems and Execution Context CHRI CORIS .NET CLR (C#, VB) WCF Java 2 JAX-WS Java 2 .NET CLR (C#, VB) JBoss/Axis ? Adapter/ Connector Criminal Corrections History Offender Future Services Mgmt Services Enterprise Networks Intermediaries Services Transport Shared Service Execution Context Management/ Reliable Court Case Monitoring Prosecution Messaging Mgmt Case Mgmt Future Services Services Services Adapter/ Web Objects JusticeBroker Connector Java 2 .NET CLR (C#, VB) Java 2 JAX-WS MEJIS 2 JustWare Prosecutor Guidelines for Future Systems Information sharing partners in Maine should consider the following factors when building or acquiring systems intended to participate in this architecture: • System functionality should be accessible through APIs rather than solely through the application’s user interface • APIs that expose system functionality should (ideally) conform to open industry standards, such as [WS-I BP] or the Java Connector Architecture, or (secondarily) should conform to modern industry standard component architectures, such as the Java 2 or Microsoft .NET/CLR platforms. • If APIs are not available, then systems should as a last resort provide access to application data in the database • System components should be acquired under a licensing model favorable to information sharing and integration • Line-of-business system functionality should not include integration or information sharing logic (or, if included, it should be possible to bypass this functionality) • Maine partners should avoid having applications in separate organizations share a common database Maine Justice Information Sharing Architecture Page 34 of 49 Version 1.0 October 15, 2007
  38. 38. • Systems should be extensible at key expected information exchange points, allowing the Maine partners to form and send web services messages to other systems at these points Maine Justice Information Sharing Architecture Page 35 of 49 Version 1.0 October 15, 2007

×