Conceptual Integration Technical Reference Architecture

1,465 views
1,331 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
1,465
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
108
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Conceptual Integration Technical Reference Architecture

  1. 1. Contributors: Scott Came Department of Information Services Laura Parma Department of Information Services Enterprise Architecture Committee Steward Conceptual Integration Technical Reference Architecture EA Committee Document Version 2.0 March 17, 2006 Information Services Board Enterprise Architecture Committee Sue Fleener, Washington State Patrol Cathy Munson, Legislative Service Center Co-Chairs Scott Came, Department of Information Services Chief Enterprise Architect 1110 Jefferson Street SE P.O. Box 42445 Olympia, WA 98504-2445 Phone 360/902.3519 Fax 360/902.2982 ScottCa@dis.wa.gov
  2. 2. Washington State Enterprise Architecture Program March 17, 2006 Conceptual Integration Technical Reference Architecture EA Committee Document—Version 2.0 Table of Contents 1. Document History ........................................................................................................................ 3 2. Document Context ....................................................................................................................... 3 3. Description and Purpose ............................................................................................................. 4 3.1. What is a Reference Architecture? ....................................................................................... 4 3.2. What is Outside the Reference Architecture? ....................................................................... 4 3.2.1. Governance .................................................................................................................... 4 3.2.2. Detailed System Designs ............................................................................................... 5 3.2.3. Infrastructure Specifications or Designs......................................................................... 5 3.2.4. Specification of Interfaces between Systems ................................................................ 5 4. Requirements .............................................................................................................................. 5 4.1. Recognize Integration Domain Business Drivers ................................................................. 5 4.1.1. Enterprise Systems will Evolve over Time ..................................................................... 5 4.1.2. Common Solutions with Agency-Unique Elements where Justified .............................. 5 4.1.3. Enter and Maintain Information in One Place ................................................................ 6 4.2. Recognize Integration Domain Environmental Trends ......................................................... 6 4.2.1. Stabilization of Open Industry Integration Standards..................................................... 6 4.2.2. Continued Integration Product Market Diversity ............................................................ 6 4.2.3. Diversity in External Business Partners’ System Platforms ........................................... 6 4.3. Promote Integration Domain Principles ................................................................................ 6 4.3.1. Minimize Dependencies between Integrated Information Systems ............................... 6 4.3.2. Favor Integration Techniques that Leverage Open Industry Standards ........................ 7 4.3.3. Treat Integration Interfaces as Shared Enterprise Assets ............................................. 7 5. Conceptual Architecture .............................................................................................................. 7 5.1. Graphical Overview ............................................................................................................... 7 5.2. Concepts and Relationships ................................................................................................. 8 5.2.1. OASIS Service-Oriented Architecture Reference Model ............................................... 9 5.2.2. Services, Service Consumers, Capabilities, and Real-World Effects ............................ 9 5.2.3. Business Process Models and the Service/Capability Hierarchy ................................ 11 5.2.4. Interaction, Visibility, Service Models, and Service Interfaces ..................................... 11 5.2.5. Design and Description of Service Interfaces .............................................................. 13 5.2.6. Capabilities in Detail ..................................................................................................... 14 5.2.7. Policies, Contracts, and Agreements ........................................................................... 16 5.2.8. Execution Context ........................................................................................................ 16 6. Mapping of Architecture to Requirements ................................................................................. 17 7. Illustration Scenarios ................................................................................................................. 17 7.1. Scenario A........................................................................................................................... 17 Page 2 of 21
  3. 3. Washington Enterprise Architecture Program March 17, 2006 Conceptual Integration Technical Reference Architecture EA Committee Document—Version 2.0 7.2. Scenario B........................................................................................................................... 17 8. Initial Elaboration of Concepts ................................................................................................... 17 8.1. Service Modeling Guidelines .............................................................................................. 17 8.2. Service Design Principles ................................................................................................... 17 8.3. Service Interaction Requirements ....................................................................................... 17 8.4. Message Exchange Patterns .............................................................................................. 18 9. Glossary..................................................................................................................................... 19 10. References .............................................................................................................................. 19 Appendix A: Documenter Team .................................................................................................... 20 Appendix B: Review Log ............................................................................................................... 21 1. Document History Date Version Editor Change February 17, 2006 1.0 Scott Came Initial Draft March 17, 2006 1.1 Scott Came Documenter Team edits (see Appendix B) March 30, 2006 2.0 Trina Regan Endorsed by EAC 2. Document Context This document currently has EA Committee Document status. This status signifies that the document has been adopted by a vote of the ISB Enterprise Architecture Committee. For more information about the Enterprise Architecture Program or the ISB Enterprise Architecture Committee and its initiative, please visit the EA Committee website at: http://isb.wa.gov/committees/enterprise/index.aspx. Page 3 of 21
  4. 4. Washington Enterprise Architecture Program March 17, 2006 Conceptual Integration Technical Reference Architecture EA Committee Document—Version 2.0 1 3. Description and Purpose 2 This section briefly describes the Conceptual Integration Technical Reference Architecture, and 3 explains why a reference architecture is useful. It also identifies what is not in the scope of the 4 reference architecture. 5 3.1. What is a Reference Architecture? 6 A reference architecture is a description of the important concepts in a subject area, and the 7 relationships between those concepts. A reference architecture also identifies, at a high level, the 8 kinds of “components” (software systems, hardware infrastructure, policies, practices, inter- 9 system connections, and so on) necessary to bring those concepts to life in a particular context. 10 A reference architecture is generally not specific enough to govern the implementation of any 11 individual software system implementation. Rather, it is a framework for guiding implementations 12 in general, with the aim of standardizing or harmonizing certain key aspects of those 13 implementations to support reusability or interoperability. 14 A reference architecture should be driven by written requirements and should demonstrate its 15 satisfaction of those requirements. Requirements traceability is the way in which the architect 16 guarantees the relevance and correctness of the reference architecture. Without requirements 17 traceability, an architecture can easily become detached from the business needs it is intended to 18 support. 19 This document states a set of requirements for information systems integration, and then 20 describes a conceptual reference architecture (concepts, relationships, and high-level 21 components) that satisfies those requirements. The document then illustrates the architecture 22 through a set of actual system integration scenarios. Finally, the document provides an initial 23 elaboration of some of the concepts and components in the architecture. 24 The reference architecture described in this document can serve as a starting point for 25 establishing design and implementation guidelines, standards, and shared infrastructure to 26 support the integration of information systems across the enterprise. It will identify concepts, 27 relationships, and components that require further elaboration and/or implementation. Because 28 the elaboration and implementation start from a single, cohesive reference architecture, the 29 resulting guidelines, standards, and infrastructure are more likely to fit together in a way that 30 maximizes interoperability and the treatment of information systems as reusable, sharable assets. 31 3.2. What is Outside the Reference Architecture? 32 The reference architecture described in this document does not identify everything necessary for 33 a successful approach to systems integration across the enterprise. This section describes other 34 essential factors that need to be addressed, but that are not addressed in this document. These 35 other factors will likely relate to concepts and components in the reference architecture, so 36 documents that address these other factors should reference this document. 37 3.2.1. Governance 38 The integration of information systems raises a set of governance and decision-making issues, 39 such as: 40 Under what circumstances and through what process is a shared interface to an 41 information system allowed to change? 42 Through what process does the enterprise assess the compliance of system interfaces 43 with architectural standards? Page 4 of 21
  5. 5. Washington Enterprise Architecture Program March 17, 2006 Conceptual Integration Technical Reference Architecture EA Committee Document—Version 2.0 44 Through what process does the enterprise adopt new architectural standards (or change 45 existing ones)? 46 How does the enterprise reach agreement on the meaning of information exchanged 47 between integrated systems? 48 Governance business processes and standards should be developed outside of this architecture, 49 but in a way that utilizes the concepts and components defined in this architecture. 50 3.2.2. Detailed System Designs 51 The conceptual reference architecture in this document does not propose a design of any 52 information system. The requirements addressed by the architecture focus on the integration of 53 systems, not the systems themselves. 54 The architecture does identify the need for a set of design guidelines that should impact 55 information system design choices. But these guidelines will address only the integration aspects 56 of systems, not their primary business requirements. 57 3.2.3. Infrastructure Specifications or Designs 58 The conceptual reference architecture in this document does not propose a detailed design for an 59 infrastructure to support systems integration. Requirements for integration infrastructure could be 60 derived from further elaboration and specification of some of the concepts and components 61 documented in the architecture. 62 3.2.4. Specification of Interfaces between Systems 63 The conceptual reference architecture in this document does not identify specific interfaces 64 between systems in the current or future state enterprise. This architecture is intended to provide 65 a framework or roadmap for the definition of these interfaces. Individual projects or initiatives will 66 specify system interfaces (or update specifications of existing interfaces) as needed to 67 accomplish their objectives, and will do so in accordance with the guidance of this architecture. 68 4. Requirements 69 This section documents the requirements to be addressed and satisfied by the conceptual 70 integration reference architecture. 71 4.1. Recognize Integration Domain Business Drivers 72 The integration reference architecture must reflect the influence of the following factors, 73 representing key characteristics of the state enterprise business environment. 74 4.1.1. Enterprise Systems will Evolve over Time 75 The state enterprise will continue to implement new systems (and update current systems) over 76 time. It is expected that, at any point in time, capabilities somewhere in the enterprise will be 77 transitioning from their current implementation to a future implementation. 78 4.1.2. Common Solutions with Agency-Unique Elements where Justified 79 One of the state’s over-arching Enterprise Architecture principles (the Commonality principle) 80 calls for technology solutions and services to be designated as common where justified by a 81 business case, and indicates that once a service or solution is designated as common, a 82 business case is required for an agency-unique approach to that service or solution. (Such a Page 5 of 21
  6. 6. Washington Enterprise Architecture Program March 17, 2006 Conceptual Integration Technical Reference Architecture EA Committee Document—Version 2.0 83 business case for agency-uniqueness may rest, for example, on Federal or other external 84 business partner requirements.) 85 Integration architecture has an important role to play in maximizing the amount of functionality 86 implemented in common systems. A proper integration strategy will permit the enterprise to 87 isolate agency-unique elements of a workflow, allowing the other elements of that workflow to be 88 implemented with a common system. 89 4.1.3. Enter and Maintain Information in One Place 90 If the state enterprise stores a single information item in multiple information systems, then users 91 should need to use only one editing mechanism to update the information in all systems. The job 92 of synchronizing multiple copies of the same information item should be the responsibility of the 93 enterprise’s integrated information systems, not system users. 94 4.2. Recognize Integration Domain Environmental Trends 95 The integration reference architecture must reflect the influence of the following environmental 96 factors. 97 4.2.1. Stabilization of Open Industry Integration Standards 98 The evolution of open industry standards for systems integration has reached a point where these 99 standards can serve as the basis for an overall approach to integration across a large, diverse 100 enterprise. Many prominent programming languages, software development environments, 101 packaged applications, and integration platforms/tools support the standards. While some 102 common integration needs are met by competing standards, the number and significance of 103 competing standards continues to shrink. 104 4.2.2. Continued Integration Product Market Diversity 105 The marketplace for integration products is highly diverse and is likely to remain so for the 106 foreseeable future. Support for web services standards, key integration capabilities (such as 107 transformation, content-based routing, and orchestration), and off-the-shelf adapters for 108 enterprise applications (such as enterprise resource planning (ERP) packaged applications) 109 exists from a variety of vendors. 110 4.2.3. Diversity in External Business Partners’ System Platforms 111 The state enterprise interacts with external business partners, such as private industry service 112 providers, Federal government agencies, local governments, and the governments of other 113 states. These external business partners will continue to maintain a wide diversity of platforms 114 and technologies; consequently, integration with these partners’ systems will require the state 115 enterprise to accommodate diversity and regular change in the way those systems have been 116 implemented. 117 4.3. Promote Integration Domain Principles 118 4.3.1. Minimize Dependencies between Integrated Information Systems 119 The integration of one information system with another information system should be designed 120 and implemented in such a way as to minimize the dependency of either system on the 121 implementation details of the other. For purposes of this principle, “integration” means any direct 122 use of the functionality of one information system by another system. Page 6 of 21
  7. 7. Washington Enterprise Architecture Program March 17, 2006 Conceptual Integration Technical Reference Architecture EA Committee Document—Version 2.0 123 4.3.2. Favor Integration Techniques that Leverage Open Industry Standards 124 Design and investment decisions should favor technologies (products, designs, approaches) that 125 are based on open industry standards. Open standards improve system interoperability, position 126 the state to utilize commodity (widely available) products and services, and may reduce product 127 and service costs. 128 4.3.3. Treat Integration Interfaces as Shared Enterprise Assets 129 The points at which information systems integrate should be viewed as enterprise assets 130 intended to be reused and shared beyond the context of the initial integration effort or project. 131 5. Conceptual Architecture 132 5.1. Graphical Overview 133 The following diagram depicts the concepts, high-level components, and relationships in the 134 reference architecture. These elements are described in detail in the following sections. Page 7 of 21
  8. 8. Washington Enterprise Architecture Program March 17, 2006 Conceptual Integration Technical Reference Architecture EA Committee Document—Version 2.0 consist of Routers Orchestrations Message Validators Intermediaries Transformers identify common act as types of Functional Non-Functional are types of define can be supported by Edge Capabilities Common Capabilities Enterprise Integration Patterns Business Process Models are types of implement produce Domain Capabilities Real-World Effects implement Vocabularies conforms to, Behavior Model uses provide access to seek provider systems leverage information contained in Information Model use Services Service Consumers contains contains defines semantics of act as Service Model are composed of can contain some provide access to hosts Repository constrain use of or assists hosts is described by expected result of using consumer conform to, are assembled from systems depends on Visibility are aspects of can be specified in Agreements structure and content determined by Willingness can be described by Awareness Policies and Reachability can constrain Interaction Service Interfaces Contracts are the means of accomplished by exchange of enables Execution Context can be implemented by guide design and description of establish some requirements for Service Interaction require support for define common rules of Requirements Service Interaction Interface Profile Guidelines Description Requirements govern content of define interoperable implementations of Message Exchange describe ways of exchanging Patterns Service Interaction Messages Profiles Message Definition define structure of Mechanisms enables and determines essential aspects of Conceptual Integration Technical Reference Architecture Legend Concept Map Scott Came Washington Enterprise Architecture Program Concepts from OASIS SOA-RM March 17, 2006 Version 1.2 DOCUMENTER TEAM DRAFT Concepts particular to the TRA 135 136 5.2. Concepts and Relationships 137 The following sections describe the concepts, components, and relationships depicted on the 138 diagram in the previous section. Page 8 of 21
  9. 9. Washington Enterprise Architecture Program March 17, 2006 Conceptual Integration Technical Reference Architecture EA Committee Document—Version 2.0 139 5.2.1. OASIS Service-Oriented Architecture Reference Model 140 The conceptual reference architecture depicted in the diagram above (and defined in this 141 document) adopts the Service-Oriented Architecture Reference Model (SOA-RM) developed by 142 the Organization for the Advancement of Structured Information Standards (OASIS). 143 The SOA-RM defines its purpose as follows: 144 “A reference model is an abstract framework for understanding significant relationships among 145 the entities of some environment. It enables the development of specific architectures using 146 consistent standards or specifications supporting that environment. A reference model consists of 147 a minimal set of unifying concepts, axioms and relationships within a particular problem domain, 148 and is independent of specific standards, technologies, implementations, or other concrete 149 details.” ([SOA-RM], p. 4). 150 “The goal of this reference model is to define the essence of service oriented architecture, and 151 emerge with a vocabulary and a common understanding of SOA. It provides a normative 152 reference that remains relevant for SOA as an abstract and powerful model, irrespective of the 153 various and inevitable technology evolutions that will impact SOA.” ([SOA-RM], p. 4). 154 While the SOA-RM is a powerful model that provides the first vendor-neutral, open-standard 155 definition of the service-oriented approach to integration, its abstract nature means that it is not 156 capable of providing the architectural guidance needed for the actual design of integration 157 solutions (or integrated software systems). That guidance comes from the definition of a 158 reference architecture that rests on the foundation of the reference model’s concepts. The 159 reference architecture builds on those concepts by specifying additional relationships, further 160 defining and specifying some of the concepts, and adding key (high-level) software components 161 necessary for integration solutions. 162 In the diagram above, SOA-RM concepts are shaded yellow. Concepts and components 163 particular to the conceptual reference architecture defined by this document are shaded cyan. 164 Relationships between concepts (indicated by arrows) are defined in the SOA-RM if the arrows 165 connect concepts shaded yellow. Relationships between cyan-shaded concepts or between 166 cyan-shaded and yellow-shaded concepts are particular to the reference architecture. 167 The descriptions of SOA-RM concepts provided in the following sections are intended to be brief 168 summaries; consequently, they omit certain details that appear in the SOA-RM. The glossary at 169 the end of this document contains the full, formal definitions of the SOA-RM concepts (repeated 170 from the SOA-RM glossary for convenience.) The SOA-RM itself is the primary source for full 171 exposition of SOA-RM concepts and the relationships between them. 172 5.2.2. Services, Service Consumers, Capabilities, and Real-World Effects 173 The reference architecture begins from the premise that a group of business partners have 174 CAPABILITIES that they provide to one another. These capabilities “solve or support a solution for 175 the problems [businesses] face in the course of their business” ([SOA-RM], p. 7). That is, 176 capabilities are the things businesses do to solve problems and therefore add value, directly or 177 indirectly, to their stakeholders. 178 Note that the architecture is generic enough to support virtually any kind of capability. However, 179 the purpose of the reference architecture defined in this document is to describe an approach to 180 integrating automated, computer software-based information systems. Therefore, the reference 181 architecture only considers those business capabilities that are provided by (or implemented by) 182 information systems. The reference architecture calls these systems PROVIDER SYSTEMS, and 183 establishes that provider systems implement capabilities. 184 Each capability produces one or more REAL-WORLD EFFECTS, each of which is an outcome of 185 business value sought by one of the partners. A real-world effect can be either the obtaining of 186 information, the changing of something of business relevance to the participating partners, or 187 both. Because the reference architecture establishes that capabilities are implemented by Page 9 of 21
  10. 10. Washington Enterprise Architecture Program March 17, 2006 Conceptual Integration Technical Reference Architecture EA Committee Document—Version 2.0 188 provider systems, real-world effects in the reference architecture context consist of the functional 189 business requirements of provider systems. That is, real-world effects in the reference 190 architecture are essentially the information made available by provider systems, or the outcomes 191 resulting from business processes and workflows automated by provider systems, or both. 192 In a service-oriented architecture, a SERVICE is the way in which one partner gains access to a 193 capability offered by another partner. A partner that uses a service to gain access to another 194 partner’s capability is called a SERVICE CONSUMER. As with capabilities, the architecture is generic 195 enough to support virtually any kind of service consumer. However, since the purpose of the 196 reference architecture in this document is to describe an approach to integrating information 197 systems, the reference architecture only considers those service consumers implemented by 198 information systems. The reference architecture calls such systems CONSUMER SYSTEMS. 199 One of the most important features of this reference architecture is the separation of consumer 200 systems from provider systems by services in the middle. This is the defining characteristic of a 201 service-oriented architecture, and is the key to de-coupling integrated systems as called for in 202 many of the requirements listed in section 4 above. 203 The fact that information sharing is one kind of real-world effect allows the architecture to support 204 the traditional view of system integration as “data exchange” or “information sharing”. The 205 architecture improves this view by encouraging systems to share information in a way that 206 minimizes the dependencies of each system on the implementation details of the other systems. 207 There are some characteristics of consumer and provider systems that can improve their fitness 208 as service consumers and capabilities, respectively. SOLUTION DESIGN GUIDELINES capture these 209 characteristics, and inform system design and specification decisions for consumer and provider 210 systems. For instance, design guidelines may encourage systems to separate the user interface 211 and business logic layers, so that the business logic can be made directly available through 212 services. 213 SERVICE DESIGN PRINCIPLES provide consistent guidance regarding the overall partitioning of 214 capabilities into services, and the relationships between services. For instance, service design 215 principles may call for services to represent one concise, self-contained function, and may also 216 suggest that services should completely hide the implementation details of the capabilities to 217 which they provide access. 218 There is a wide variety of ways in which a service can provide access to a capability. In some 219 cases, the provider system that implements the capability may already expose all or some of its 220 functionality as services (through one or more service interfaces, described in section 5.2.4 221 below.) In other cases, the business partner that provisions the capability can purchase an off- 222 the-shelf adapter from the provider system vendor (or a third party) that exposes the system’s 223 functionality as a set of services. Finally, the provider system may require re-implementation or 224 custom adaptation to expose functionality as services; this is often expensive and risky, and the 225 desire to avoid this situation should be addressed in the design guidelines discussed in this 226 section above. 227 In general, a given information system can be both a provider system and a consumer system. 228 Similarly, a particular business organization may offer capabilities to its partners and, at the same 229 time, be a consumer of the capabilities offered by others. This has important implications for how 230 the enterprise should conceive and describe its information systems assets, and how it assigns 231 responsibilities for the maintenance and support of those assets. For example, in the past it was 232 common to think of systems having “client” and “server” components (or “browser” and “server” 233 components), which in turn influenced thinking about systems deployment, networking, security, 234 support, and a range of other issues. These issues deserve reconsideration in an architecture in 235 which a system or system component can be both a “client” (consumer of services) and “server” 236 (provider of services) at the same time. The discussion of service interaction in section 5.2.4 237 below, and the subsequent elaboration of interaction mechanisms in future iterations of the 238 integration architecture, will reflect the impact of these issues. Page 10 of 21
  11. 11. Washington Enterprise Architecture Program March 17, 2006 Conceptual Integration Technical Reference Architecture EA Committee Document—Version 2.0 239 Note that the concept of a service in the architecture does not equate to a “web service”. The 240 term “web services” is a label for a family of standards and an associated technical approach to 241 communicating between service consumers and services. The architecture supports flexibility in 242 how this communication happens through the notion of service interaction profiles (discussed in 243 section 5.2.4 below.) It is very likely that one of these profiles will adopt the web services family 244 of standards; however, it is also likely that the architecture will include additional profiles that 245 adopt other communication mechanisms. 246 5.2.3. Business Process Models and the Service/Capability Hierarchy 247 The previous section described the basic concepts involved in the integration of provider systems 248 and consumer systems. In short, consumer systems seek a real-world effect provided by a 249 capability, and they produce that effect by accessing a service that provides access to the 250 capability. However, these concepts by themselves do not provide the context for the integration 251 of a particular consumer and particular provider. That is, the concepts do not provide a way of 252 describing why a consumer seeks the effect made available by a provider through a service. 253 A BUSINESS PROCESS MODEL provides this contextual justification. A business process model is a 254 description (usually formal and often graphical) of a series of activities that culminate in the 255 achievement of some outcome of business value. Some (but not necessarily all) of the steps in 256 this series of activities involve producing a real-world effect provided by a capability, and so some 257 of the steps require a consumer to use a service. Each one of these steps, then, provide the 258 contextual justification for service interaction between a particular consumer and particular 259 provider. 260 The execution of the steps described in a business process model can be considered a capability 261 in and of itself. In addition, each of the steps in a business process model can unfold into yet 262 another business process model at a more focused level of detail. In this way, each step in a 263 series of service interactions can itself be a series of service interactions. (And in theory this 264 recursion of models can go on forever, though in practice it rarely exceeds three or four levels of 265 containment.) So, services and capabilities form a hierarchy, where a service provides access to 266 a capability whose real-world effect is to accomplish the coordination of multiple services at a 267 lower level of detail. 268 The architecture supports this hierarchy through orchestrations and intermediaries, discussed in 269 section 5.2.6 below. 270 5.2.4. Interaction, Visibility, Service Models, and Service Interfaces 271 Services, described in section 5.2.2 above, define what features of a provider system the system 272 owner makes accessible to business partners. Services also provide a logical description of the 273 information exchanged between consumer and provider systems as the consumer accesses the 274 capability. 275 The architecture refers to a consumer’s accessing the features of a capability through a service 276 as INTERACTION, defined as “the performing [of] actions against a service” ([SOA-RM], p. 13). 277 Service interaction generally involves the exchange of information between the consumer and the 278 service. 279 Interaction depends on two things. First, the designers of potential consumers need to be able to 280 find services, and once found establish a physical interaction mechanism with them. These 281 needs are addressed by the concept of VISIBILITY. Second, the designers of potential consumers 282 need a description of the actions that can be performed on a service, as well as the structure and 283 meaning of information exchanged during the interaction. These needs are addressed by the 284 concept of a service’s INFORMATION MODEL and BEHAVIOR MODEL, collectively called SERVICE 285 MODELS in the reference architecture. Page 11 of 21
  12. 12. Washington Enterprise Architecture Program March 17, 2006 Conceptual Integration Technical Reference Architecture EA Committee Document—Version 2.0 286 5.2.4.1. Visibility 287 Visibility, as the name implies, defines how service consumers and the providers of capabilities 288 “see” each other in a way that enables interaction between them. The architecture identifies 289 three aspects of visibility (note that to simplify the diagram above, these three concepts have 290 been omitted): 291 A service consumer must have information that makes it aware of the existence of a 292 service; the possession of this information is called AWARENESS 293 The service (or capability accessed through the service) must be willing to interact with 294 the consumer; this is called WILLINGNESS 295 The consumer and service must be able to communicate with one another, through some 296 kind of communication path or channel; the existence of such a communication path is 297 called REACHABILITY 298 In the reference architecture, a REPOSITORY will support awareness by hosting service models 299 and service interfaces. “Hosting” in this context means storing models and interface descriptions 300 in a central location that is accessible to appropriate stakeholders. A repository will permit 301 searching for models and interface descriptions based on a range of identifying criteria. A 302 repository will also map logical service identifiers with physical addresses. When a consumer 303 wishes to communicate with a service (identified by a logical identifier), the consumer queries the 304 repository for the physical address associated with the service’s logical identifier. This de- 305 couples the consumer from the physical location of a service at any point in time, thereby 306 permitting the physical relocation of the service without impacting the implementation of the 307 consumer. 308 The concept of willingness is related to authorization and access control policies, in that a 309 common reason for lack of willingness to interact is that the consumer is not authorized to 310 conduct the requested interaction. Willingness often manifests in service descriptions (discussed 311 in section 5.2.5 below) as well as policies, contracts, and agreements (discussed in section 5.2.7 312 below). 313 The concept of reachability is closely related to the concept of execution context (discussed in 314 section 5.2.8 below). 315 5.2.4.2. Service Models 316 Service models, consisting of a service’s information and behavior models, define the semantics 317 of interaction with the service. The behavior model defines the actions that can be performed on 318 the service; that is, it defines what the service “does”. The information model describes the 319 information that consumers exchange with the service in the course of performing those actions. 320 Note that the SOA-RM considers the orchestration and choreography of multiple services to be 321 “part of the process model of a given architecture”. Yet the SOA-RM also indicates that a 322 process model (part of the behavior model) applies to a single service. ([SOA-RM], p. 15). 323 Because of this lack of clarity in the SOA-RM, this reference architecture identifies orchestration 324 as a type of capability that leverages other services; it is described in section 5.2.6 below. 325 In general, service models will be described at conceptual and logical levels of detail. (Service 326 models have a physical manifestation as well, in the form of the service interface discussed in the 327 next section.) A conceptual description of a service model will typically describe, in prose text 328 form, the capability to which the service provides access, a listing and brief textual description of 329 each action, and a brief textual description of the information model (e.g., key information entities, 330 key properties on those entities, and brief definitions.) A logical description of a service model will 331 describe the actions and information structures in detail, but independent of any physical 332 implementation mechanism. Often this description will be graphical and follow a standard 333 diagramming or modeling technique. Page 12 of 21
  13. 13. Washington Enterprise Architecture Program March 17, 2006 Conceptual Integration Technical Reference Architecture EA Committee Document—Version 2.0 334 A MESSAGE is defined as the entire “package” of information sent between service consumer and 335 service (or vice versa), even if there is a logical partitioning of the message into segments or 336 sections. For instance, if an interface expresses actions as operations or functions that take 337 arguments, and a particular operation has two arguments, both arguments would be considered 338 part of the same message, even though they may be logically separated within the message 339 structure. In this reference architecture, the exchange of messages is the only way in which 340 consumers and services can communicate. A message also includes the concept of an 341 “attachment”, in which there are several additional sections (attachments) that relate to a distinct, 342 “primary” section. 343 The concept of DOMAIN VOCABULARIES in the reference architecture includes canonical data 344 models, data dictionaries, and markup languages that standardize the meaning and structure of 345 information for a topical or business domain. Domain vocabularies can improve the 346 interoperability between consumer and provider systems by providing a neutral, common basis 347 for structuring and assigning semantic meaning to information exchanged as part of service 348 interaction. Domain vocabularies can usually be extended to address information needs specific 349 to the service interaction or to the business partners integrating their systems. The choice of 350 domain vocabularies, like the design of particular services, is outside the scope of the reference 351 architecture. 352 SERVICE MODELING GUIDELINES govern the style, structure, and description of service models; an 353 initial elaboration of these guidelines appears in section 8.1 below. 354 As stated in section 5.2.4.1 above, a repository should contain service model description artifacts 355 for each level of detail. The availability of service model descriptions to consumer system 356 designers, implementers, and purchasers is a key factor in establishing visibility and the reuse of 357 services. 358 5.2.4.3. Service Interface 359 Service models describe the actions available from a service, and the information exchanged 360 between a consumer and the service during the performance of those actions. In this way, the 361 service models describe the “what” of interaction. 362 A SERVICE INTERFACE “is the means for interacting with a service. It includes the specific 363 protocols, commands, and information exchange by which actions are initiated [on the service]” 364 ([SOA-RM], p. 19). A service interface is what a system designer or implementer (programmer) 365 uses to design or build executable software that interacts with the service. That is, the service 366 interface represents the “how” of interaction. 367 The reference architecture considers the service interface to be the physical manifestation of the 368 service models. Best practices call for a service interface to be described in an open-standard, 369 referenceable format (that is, a format whose contents are capable of automated processing by a 370 computer.) 371 Note that at least some policies and contracts can be described in a service’s interface. 372 The format, structure, and allowable contents of a service interface are established by INTERFACE 373 DESCRIPTION REQUIREMENTS, described in section 5.2.5 below. 374 5.2.5. Design and Description of Service Interfaces 375 The reference architecture identifies four architectural elements that guide the design and 376 description of service interfaces. 377 SERVICE INTERACTION REQUIREMENTS define common rules of service interaction. Typically these 378 requirements are non-functional in nature, in that they are not directly related to the capability 379 used by the service consumer, nor are they related to the real-world effect resulting from use of 380 that capability. Rather, the requirements enforce (or support the enforcement of) policies or Page 13 of 21
  14. 14. Washington Enterprise Architecture Program March 17, 2006 Conceptual Integration Technical Reference Architecture EA Committee Document—Version 2.0 381 contracts, or otherwise protect the interests of particular business partners or the business 382 enterprise overall. 383 Common service interaction requirements address areas such as security, reliability, and 384 availability. An initial elaboration of service interaction requirements appears in section 8.3 385 below. 386 INTERFACE DESCRIPTION REQUIREMENTS establish common characteristics of service interface 387 descriptions. These requirements address areas such as required interface contents, naming 388 rules, documentation rules, and specification of a standard structure and format for descriptions. 389 MESSAGE EXCHANGE PATTERNS identify common sequences of message transmission between 390 service consumers and services. They provide a label to a series of message transmissions that 391 have some logical inter-relationship. An initial elaboration of message exchange patterns 392 appears in section 8.4 below. 393 MESSAGE DEFINITION MECHANISMS are closely related to interface description requirements, 394 described above. Unlike interface description requirements, message definition mechanisms 395 establish a standard way of defining the structure and contents of a message. Note that since a 396 message includes the concept of an “attachment”, the message definition mechanism must 397 identify how different sections of a message (for example, the main section and any “attachment” 398 sections) are separated and identified, and how attachment sections are structured and 399 formatted. 400 5.2.5.1. Service Interaction Profiles 401 A SERVICE INTERACTION PROFILE defines a family of industry standards or other technologies or 402 techniques that together demonstrate implementation or satisfaction of: 403 Service interaction requirements 404 Interface description requirements 405 Message exchange patterns 406 Message definition mechanisms 407 Service interaction profiles are included in the reference architecture to promote interoperability 408 without forcing the state enterprise to agree on a single way of enabling service interaction. Each 409 service interface will support a single profile; a service will have multiple interfaces if it supports 410 multiple profiles. By supporting a profile, an interface establishes the mode of inter-operation it 411 allows from service consumers; any consumer that also supports that profile can “reach” the 412 service (the concept of reachability is defined under visibility, in section 5.2.3.1 above). 413 SERVICE INTERACTION PROFILE GUIDELINES define precisely what is required of a service interaction 414 profile, and therefore provides guidance and clear requirements for developers of potential 415 profiles. 416 5.2.6. Capabilities in Detail 417 The reference architecture identifies several types of capabilities, to assist decision-makers in 418 understanding where certain capabilities should be deployed in the enterprise, who should 419 provision them, and what relationships they may have to other capabilities and services. 420 5.2.6.1. Common and Edge Capabilities 421 A COMMON CAPABILITY is a capability for which a business case exists to suggest common, 422 shared, enterprise provisioning. That is, a common capability has no natural “owner” or 423 provisioner among the enterprise business partners, because the nature of the capability is that it 424 is best shared across partners. Page 14 of 21
  15. 15. Washington Enterprise Architecture Program March 17, 2006 Conceptual Integration Technical Reference Architecture EA Committee Document—Version 2.0 425 Most common capabilities are non-functional in nature, in that their function supports the proper, 426 safe, or reliable functioning of other capabilities. Examples of non-functional common capabilities 427 are: directory services to support authentication, authorization, and access control; logging 428 services; message structure/format validation services; and metering/billing services. In addition, 429 a capability that translates messages from one format to another without adding or enhancing the 430 information in the message would be non-functional in nature. Also, operational management 431 capabilities monitor and record information about service interaction, which permits analysis of 432 service performance and an understanding of where services are being used throughout the 433 enterprise. 434 Some common capabilities could be functional in nature. A typical example is a data-enrichment 435 service, that receives a message (ultimately destined for a service or consumer elsewhere) and 436 enhances the message by adding relevant data to it. A second typical example is an aggregated 437 query service, that receives a set of query parameters, examines them, and interacts with several 438 other services to compile the response. Yet another example is a portal service that coordinates 439 the interaction of several services across the enterprise, to aggregate information or provide a 440 seamless workflow to a human user. (Strictly speaking, such a “portal service” would consist only 441 of the capability to perform the coordination; a portal human-interaction interface would use the 442 portal service to present the aggregated information or coordinated workflow to a human user.) 443 Common capabilities are often designed, implemented, and provisioned by a central service 444 provider or consortium of the enterprise business partners. 445 An EDGE CAPABILITY is a capability whose design and provisioning is the responsibility of a single, 446 well-identified enterprise business partner. Usually an edge capability is implemented by an 447 information system wholly owned and maintained by that single partner. The partner has control 448 over the implementation of an edge capability, and the freedom to alter that implementation as 449 long as the terms of any services that provide access to that capability are satisfied. 450 Note that while responsibility for provisioning an edge capability rests with a single business 451 partner, the services that access that capability (and the service interfaces that provide the 452 means of interacting with those services) should be viewed as shared assets with some 453 appropriate degree of shared control. 454 5.2.6.2. Orchestrations and Intermediaries 455 An ORCHESTRATION is a capability that coordinates interaction with multiple services. An 456 orchestration is often implemented using an open industry standard implementation mechanism 457 (referred to as an ORCHESTRATION MECHANISM in the reference architecture), which allows the 458 implementation to be shared across tools and platforms. Also, it is often possible to implement 459 orchestrations using a graphical, model-driven approach, in which the implementer diagrams 460 business processes and workflows, the steps of which are services that already exist. After the 461 diagram is complete, the implementer generates a standards-based artifact that is deployed into 462 a software component that exposes the workflow as a service through a service interface. The 463 promise of this model-driven approach is that less technical implementers with greater business 464 expertise can be responsible for the implementation of orchestrated capabilities. 465 A ROUTER is a capability that receives a message, examines it, and transmits it to one or more 466 destinations based on the contents. In general, routers can be designed to operate on any of the 467 information contained within the message; they may use information about the origin of the 468 message, routing directive information contained within the message, or the main content of the 469 message itself. 470 A TRANSFORMER is a capability that receives a message and transforms it into another format 471 before transmitting it on to another destination. 472 Routers and transformers are collectively called INTERMEDIARIES. This term indicates that routers 473 and transformers generally sit between other services and “mediate” the interaction by managing 474 the transmission of messages between them, or by reformatting messages in transit. Page 15 of 21
  16. 16. Washington Enterprise Architecture Program March 17, 2006 Conceptual Integration Technical Reference Architecture EA Committee Document—Version 2.0 475 Routers and transformers are useful mechanisms for de-coupling the senders and recipients of 476 messages. They tend to centralize and share certain kinds of logic so that the logic can be 477 maintained independently of the provider and consumer capabilities at the edges; sharing also 478 improves the likelihood of reuse, since it is easier to reuse functionality if it encapsulates a single 479 task. 480 Support for router, transformer, and orchestration capabilities is a common feature in many 481 integration platforms, and therefore support for these capabilities is a consideration in choice of 482 execution context (discussed in section 5.2.8 below). 483 Routing, transformation, and orchestration capabilities are well understood and well documented 484 in the integration architecture literature. The most common flavors of these capabilities have 485 been collected into pattern form as ENTERPRISE INTEGRATION PATTERNS, in [Patterns]. The 486 reference architecture should incorporate these patterns by reference. 487 Orchestrations and intermediaries are a key component in implementing business process 488 models, and also lead to the formation of service/capability hierarchies. This topic is discussed in 489 more detail in section 5.2.3 above. 490 5.2.7. Policies, Contracts, and Agreements 491 POLICIES and CONTRACTS express rules that govern the interaction between a service consumer 492 and a service. A policy is an assertion by either a consumer or service provider of that 493 participant’s requirements for willingness to interact. A policy also has an enforcement aspect, 494 and must be stated in such a way as to permit enforcement. Whereas a policy is an assertion by 495 one participant in the interaction, a contract is an agreement between the participants that 496 expresses some expectation or requirement of the interaction. And whereas policy enforcement 497 is generally the responsibility of the participant who asserts the policy, contract enforcement may 498 involve resolution of disputes that arise between the parties. 499 An AGREEMENT is a document that establishes policies and contractual elements for a given 500 interaction or set of interaction (that is, for one or more services). 501 5.2.8. Execution Context 502 EXECUTION CONTEXT is “the set of infrastructure elements, process entities, policy assertions, and 503 agreements that are identified as part of an instantiated service interaction” ([SOA-RM], p. 21.) 504 Execution context is the primary enabler of the reachability aspect of visibility, as defined in 505 section 5.2.4.1 above. Execution context includes the set of infrastructure elements that provide 506 a physical communication path between service consumers and services. 507 The reference architecture considers execution context to be primarily the supporting 508 infrastructure elements that permit service consumers and services to interact. These 509 infrastructure elements consist of: 510 Data networks used by service consumers and services to exchange information 511 Integration infrastructure (hardware and software) that makes service interfaces available 512 and handles higher-level message routing, transformation, and orchestration 513 Consumers of certain common capabilities (via services) that support service interaction; 514 examples include directory services and metering services 515 Execution context can implement (or support the implementation of) some service interaction 516 requirements, such as reliability and availability. Service interaction profiles, contracts, and 517 policies can constrain the behavior of execution context elements, by requiring particular 518 technologies or techniques, or establishing service level policies (for example.) Page 16 of 21
  17. 17. Washington Enterprise Architecture Program March 17, 2006 Conceptual Integration Technical Reference Architecture EA Committee Document—Version 2.0 519 Finally, as discussed in section 5.2.6 above, execution context can support certain kinds of 520 capabilities directly in the integration infrastructure, such as routing, transformation, and 521 orchestration. 522 6. Mapping of Architecture to Requirements 523 The Documenter Team will complete this section after Integration Domain (principles, drivers, and 524 trends) stabilize. 525 7. Illustration Scenarios 526 Note that this section is illustrative only, and is not intended to establish these scenarios as 527 standards or intended approaches to specific projects. This section will grow over time as the 528 Documenter Team identifies additional illustrative scenarios. 529 7.1. Scenario A 530 Waiting on scenario submissions from the team. 531 7.2. Scenario B 532 Waiting on scenario submissions from the team. 533 8. Initial Elaboration of Concepts 534 The purpose of this section is to establish a direction and initial “straw model” for those concepts 535 to be elaborated and defined in detail within the architecture. (Note that some concepts will 536 remain conceptual, and will be defined in detail over time). 537 8.1. Service Modeling Guidelines 538 A sub-group of the Documenter Team will elaborate this concept starting in the April 14 iteration. 539 8.2. Service Design Principles 540 The following initial list of service design principles is summarized from [Erl]. 541 Services should be designed for reuse 542 Services should be designed so that they may participate in a composition with other 543 services to form a higher-level service 544 Services should share only a formal contract with their consumers (consumers are 545 dependent only on the service’s interface, not the implementation details of the capability 546 to which the service provides access) 547 Services are stateless, meaning that during an interaction with a service, a service 548 consumer supplies all information necessary to conduct the interaction, and makes no 549 assumptions about information retained from prior interactions 550 8.3. Service Interaction Requirements 551 The following is an initial list of candidate service interaction requirements. Page 17 of 21
  18. 18. Washington Enterprise Architecture Program March 17, 2006 Conceptual Integration Technical Reference Architecture EA Committee Document—Version 2.0 552 Service Consumer Authentication: Information provided with messages transmitted 553 from service consumer to service, that verify the identity of the consumer 554 Service Consumer Authorization: Information provided with messages transmitted 555 from service consumer to service, that document the consumer’s authorization to perform 556 certain actions on and/or access certain information via the service 557 Service Authentication: The ability of a service to provide a consumer with information 558 that demonstrates the service’s identity to the consumer’s satisfaction 559 Message Non-Repudiation: Information provided in a message to allow the recipient to 560 prove that a particular, authorized sender in fact sent the message 561 Message Integrity: Information provided in a message to allow the recipient to verify that 562 the message has not changed since it left the control of the sender 563 Message Confidentiality: Information provided in a message to protect anyone except 564 an authorized recipient from reading the message or parts of the message 565 Message Addressing: Information provided in a message that indicates where a 566 message originated, the ultimate destination of the message (beyond physical endpoint), 567 a specific recipient to whom the message should be delivered (this includes sophisticated 568 metadata designed specifically to support routing), and a specific address or entity to 569 which reply messages (if any) should be sent 570 Reliability: Information provided with messages to permit message senders to receive 571 notification of the success or failure of message transmissions, and to permit messages 572 sent with specific sequence-related rules either to arrive as intended, or fail as a group 573 Transaction Support: Information provided with messages to permit a sequence of 574 messages to be treated as an atomic transaction by the recipient 575 Service Metadata Availability: The ability of a service to capture and make available 576 (via query) metadata about the service (metadata is information that describes or 577 categorizes the service, and often assists consumers in interacting with the service in 578 some way) 579 Service Availability: A commitment of a service to be reachable at a stated percent of 580 the time with specified conditions 581 Service Responsiveness: A commitment of a service to return a response 582 (synchronous or asynchronous) within a specified period of time 583 8.4. Message Exchange Patterns 584 The reference architecture will identify the following message exchange patterns: 585 The FIRE-AND-FORGET pattern calls for the sender of a message (which could be the service 586 consumer or service) to send the message, and not expect a reply message back from the 587 recipient. This pattern is useful for one-way transmission of information, such as notification that 588 an event has occurred. 589 The REQUEST-REPLY pattern calls for the sender of a message to send the message and expect a 590 reply back from the recipient. 591 These two patterns are considered “primitive” patterns, in that they are the fundamental building 592 blocks of more complex information exchange scenarios. For instance, the complex PUBLISH- 593 SUBSCRIBE pattern involves an initial request-reply exchange in which the subscriber subscribes 594 to a service, followed by the service using the fire-and-forget pattern to notify subscribers of an 595 event. Page 18 of 21
  19. 19. Washington Enterprise Architecture Program March 17, 2006 Conceptual Integration Technical Reference Architecture EA Committee Document—Version 2.0 596 9. Glossary 597 10. References 598 SOA-RM Reference Model for Service Oriented Architectures, 599 Working Draft 11. OASIS, 2005. 600 Patterns Hohpe, Gregor and Woolf, Bobby. Enterprise Integration 601 Patterns: Designing, Building, and Deploying Messaging 602 Solutions. Addison Wesley, 2004. 603 Erl Erl, Thomas. Service-Oriented Architecture: Concepts, 604 Technology, and Design. Prentice-Hall, 2005. Page 19 of 21
  20. 20. Washington Enterprise Architecture Program March 17, 2006 Conceptual Integration Technical Reference Architecture EA Committee Document—Version 2.0 605 Appendix A: Documenter Team 606 This document was developed through the Integration Architecture enterprise architecture 607 initiative, chartered December 14, 2005. The following individuals were members of the 608 Documenter Team for this initiative, and participated in review of this document. 609 Kent Andrus, Office of Financial Management 610 Lori Bame, LEAP Committee 611 Jerry Britcher, Department of Social and Health Services 612 Scott Came, Department of Information Services 613 Gary Dubuque, Department of Revenue 614 Jim Eby, Department of Fish and Wildlife 615 Brian Everson, Washington State Patrol 616 Laura Graham, Legislative Service Center 617 Robin Griggs, Department of Licensing 618 John Hanson, Commission on Trade and Economic Development 619 Tom Henderson, Department of Labor & Industries 620 Paul Hubert, Department of Information Services 621 Debbie Johnson, The Higher Education Coordinating Board 622 Lorraine Louderback, Department of Corrections 623 Dan Mercer, Department of Labor & Industries 624 Miles Neale, Department of Ecology 625 Bill Norris, Department of Health 626 Laura Parma, Department of Information Services 627 Mike Rohrbach, Administrative Office of the Courts 628 Jeff Sharp, Office of the State Treasurer 629 Matt Stevens, Department of Information Services 630 Lyle Tillett, Department of Retirement Systems Page 20 of 21
  21. 21. Washington Enterprise Architecture Program March 17, 2006 Conceptual Integration Technical Reference Architecture EA Committee Document—Version 2.0 631 Appendix B: Review Log 632 The following feedback on this document was received by the Enterprise Architecture Program; 633 the response to each contribution is noted below. Review by whom Contribution Response and when Documenter Team New Service Interaction Incorporated into document Requirements: Service February 22, 2006 Authentication; Service Metadata Availability Remove confusing references to SOA-RM throughout Re-label “core capabilities” to “common capabilities” Recognize that “service” does not mean “web service” Add notion of business process models and service/capability hierarchy 634 635 Page 21 of 21

×