conceptual integration technical reference architecture

Conceptual Integration TechnicalReference Architecture

EA Committee Document

Version 2.02.0

March 17, 2006

Information Services BoardEnterprise Architecture Committee

Sue Fleener, Washington State PatrolCathy Munson, Legislative Service Center

Co-Chairs

Scott Came, Department of Information ServicesChief Enterprise Architect

1110 Jefferson Street SEP.O. Box 42445

Olympia, WA 98504-2445Phone 360/902.3519

Fax 360/[email protected]

Contributors:

Scott CameDepartment of Information Services

Laura ParmaDepartment of Information Services

Enterprise Architecture Committee Steward

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

1

mailto:[email protected]

Washington State Enterprise Architecture Program March 17, 2006Conceptual 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

of 21

234

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

5

Washington Enterprise Architecture Program March 17, 2006Conceptual 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.

of 21

67

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

8

http://isb.wa.gov/committees/enterprise/index.aspx


3. Description and Purpose

This section briefly describes the Conceptual Integration Technical Reference Architecture, and explains why a reference architecture is useful. It also identifies what is not in the scope of the reference architecture.

3.1. What is a Reference Architecture?

A reference architecture is a description of the important concepts in a subject area, and the relationships between those concepts. A reference architecture also identifies, at a high level, the kinds of “components” (software systems, hardware infrastructure, policies, practices, inter-system connections, and so on) necessary to bring those concepts to life in a particular context. A reference architecture is generally not specific enough to govern the implementation of any individual software system implementation. Rather, it is a framework for guiding implementations in general, with the aim of standardizing or harmonizing certain key aspects of those implementations to support reusability or interoperability.

A reference architecture should be driven by written requirements and should demonstrate its satisfaction of those requirements. Requirements traceability is the way in which the architect guarantees the relevance and correctness of the reference architecture. Without requirements traceability, an architecture can easily become detached from the business needs it is intended to support.

This document states a set of requirements for information systems integration, and then describes a conceptual reference architecture (concepts, relationships, and high-level components) that satisfies those requirements. The document then illustrates the architecture through a set of actual system integration scenarios. Finally, the document provides an initial elaboration of some of the concepts and components in the architecture.

The reference architecture described in this document can serve as a starting point for establishing design and implementation guidelines, standards, and shared infrastructure to support the integration of information systems across the enterprise. It will identify concepts, relationships, and components that require further elaboration and/or implementation. Because the elaboration and implementation start from a single, cohesive reference architecture, the resulting guidelines, standards, and infrastructure are more likely to fit together in a way that maximizes interoperability and the treatment of information systems as reusable, sharable assets.

3.2. What is Outside the Reference Architecture?

The reference architecture described in this document does not identify everything necessary for a successful approach to systems integration across the enterprise. This section describes other essential factors that need to be addressed, but that are not addressed in this document. These other factors will likely relate to concepts and components in the reference architecture, so documents that address these other factors should reference this document.

3.2.1. Governance

The integration of information systems raises a set of governance and decision-making issues, such as:

Under what circumstances and through what process is a shared interface to an information system allowed to change?

Through what process does the enterprise assess the compliance of system interfaces with architectural standards?

of 21

910

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

11


Through what process does the enterprise adopt new architectural standards (or change existing ones)?

How does the enterprise reach agreement on the meaning of information exchanged between integrated systems?

Governance business processes and standards should be developed outside of this architecture, but in a way that utilizes the concepts and components defined in this architecture.

3.2.2. Detailed System Designs

The conceptual reference architecture in this document does not propose a design of any information system. The requirements addressed by the architecture focus on the integration of systems, not the systems themselves.

The architecture does identify the need for a set of design guidelines that should impact information system design choices. But these guidelines will address only the integration aspects of systems, not their primary business requirements.

3.2.3. Infrastructure Specifications or Designs

The conceptual reference architecture in this document does not propose a detailed design for an infrastructure to support systems integration. Requirements for integration infrastructure could be derived from further elaboration and specification of some of the concepts and components documented in the architecture.

3.2.4. Specification of Interfaces between Systems

The conceptual reference architecture in this document does not identify specific interfaces between systems in the current or future state enterprise. This architecture is intended to provide a framework or roadmap for the definition of these interfaces. Individual projects or initiatives will specify system interfaces (or update specifications of existing interfaces) as needed to accomplish their objectives, and will do so in accordance with the guidance of this architecture.

4. Requirements

This section documents the requirements to be addressed and satisfied by the conceptual integration reference architecture.

4.1. Recognize Integration Domain Business Drivers

The integration reference architecture must reflect the influence of the following factors, representing key characteristics of the state enterprise business environment.

4.1.1. Enterprise Systems will Evolve over Time

The state enterprise will continue to implement new systems (and update current systems) over time. It is expected that, at any point in time, capabilities somewhere in the enterprise will be transitioning from their current implementation to a future implementation.

4.1.2. Common Solutions with Agency-Unique Elements where Justified

One of the state’s over-arching Enterprise Architecture principles (the Commonality principle) calls for technology solutions and services to be designated as common where justified by a business case, and indicates that once a service or solution is designated as common, a business case is required for an agency-unique approach to that service or solution. (Such a

of 21

1213

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

14


business case for agency-uniqueness may rest, for example, on Federal or other external business partner requirements.)

Integration architecture has an important role to play in maximizing the amount of functionality implemented in common systems. A proper integration strategy will permit the enterprise to isolate agency-unique elements of a workflow, allowing the other elements of that workflow to be implemented with a common system.

4.1.3. Enter and Maintain Information in One Place

If the state enterprise stores a single information item in multiple information systems, then users should need to use only one editing mechanism to update the information in all systems. The job of synchronizing multiple copies of the same information item should be the responsibility of the enterprise’s integrated information systems, not system users.

4.2. Recognize Integration Domain Environmental Trends

The integration reference architecture must reflect the influence of the following environmental factors.

4.2.1. Stabilization of Open Industry Integration Standards

The evolution of open industry standards for systems integration has reached a point where these standards can serve as the basis for an overall approach to integration across a large, diverse enterprise. Many prominent programming languages, software development environments, packaged applications, and integration platforms/tools support the standards. While some common integration needs are met by competing standards, the number and significance of competing standards continues to shrink.

4.2.2. Continued Integration Product Market Diversity

The marketplace for integration products is highly diverse and is likely to remain so for the foreseeable future. Support for web services standards, key integration capabilities (such as transformation, content-based routing, and orchestration), and off-the-shelf adapters for enterprise applications (such as enterprise resource planning (ERP) packaged applications) exists from a variety of vendors.

4.2.3. Diversity in External Business Partners’ System Platforms

The state enterprise interacts with external business partners, such as private industry service providers, Federal government agencies, local governments, and the governments of other states. These external business partners will continue to maintain a wide diversity of platforms and technologies; consequently, integration with these partners’ systems will require the state enterprise to accommodate diversity and regular change in the way those systems have been implemented.

4.3. Promote Integration Domain Principles

4.3.1. Minimize Dependencies between Integrated Information Systems

The integration of one information system with another information system should be designed and implemented in such a way as to minimize the dependency of either system on the implementation details of the other. For purposes of this principle, “integration” means any direct use of the functionality of one information system by another system.

of 21

1516

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

17


4.3.2. Favor Integration Techniques that Leverage Open Industry Standards

Design and investment decisions should favor technologies (products, designs, approaches) that are based on open industry standards. Open standards improve system interoperability, position the state to utilize commodity (widely available) products and services, and may reduce product and service costs.

4.3.3. Treat Integration Interfaces as Shared Enterprise Assets

The points at which information systems integrate should be viewed as enterprise assets intended to be reused and shared beyond the context of the initial integration effort or project.

5. Conceptual Architecture

5.1. Graphical Overview

The following diagram depicts the concepts, high-level components, and relationships in the reference architecture. These elements are described in detail in the following sections.

of 21

1819

204

205

206

207

208

209

210

211

212

213

214

215

20


5.2. Concepts and Relationships

The following sections describe the concepts, components, and relationships depicted on the diagram in the previous section.

of 21

2122

216

217

218

219

23


5.2.1. OASIS Service-Oriented Architecture Reference Model

The conceptual reference architecture depicted in the diagram above (and defined in this document) adopts the Service-Oriented Architecture Reference Model (SOA-RM) developed by the Organization for the Advancement of Structured Information Standards (OASIS).

The SOA-RM defines its purpose as follows:

“A reference model is an abstract framework for understanding significant relationships among the entities of some environment. It enables the development of specific architectures using consistent standards or specifications supporting that environment. A reference model consists of a minimal set of unifying concepts, axioms and relationships within a particular problem domain, and is independent of specific standards, technologies, implementations, or other concrete details.” ([SOA-RM], p. 4).

“The goal of this reference model is to define the essence of service oriented architecture, and emerge with a vocabulary and a common understanding of SOA. It provides a normative reference that remains relevant for SOA as an abstract and powerful model, irrespective of the various and inevitable technology evolutions that will impact SOA.” ([SOA-RM], p. 4).

While the SOA-RM is a powerful model that provides the first vendor-neutral, open-standard definition of the service-oriented approach to integration, its abstract nature means that it is not capable of providing the architectural guidance needed for the actual design of integration solutions (or integrated software systems). That guidance comes from the definition of a reference architecture that rests on the foundation of the reference model’s concepts. The reference architecture builds on those concepts by specifying additional relationships, further defining and specifying some of the concepts, and adding key (high-level) software components necessary for integration solutions.

In the diagram above, SOA-RM concepts are shaded yellow. Concepts and components particular to the conceptual reference architecture defined by this document are shaded cyan. Relationships between concepts (indicated by arrows) are defined in the SOA-RM if the arrows connect concepts shaded yellow. Relationships between cyan-shaded concepts or between cyan-shaded and yellow-shaded concepts are particular to the reference architecture.

The descriptions of SOA-RM concepts provided in the following sections are intended to be brief summaries; consequently, they omit certain details that appear in the SOA-RM. The glossary at the end of this document contains the full, formal definitions of the SOA-RM concepts (repeated from the SOA-RM glossary for convenience.) The SOA-RM itself is the primary source for full exposition of SOA-RM concepts and the relationships between them.

5.2.2. Services, Service Consumers, Capabilities, and Real-World Effects

The reference architecture begins from the premise that a group of business partners have CAPABILITIES that they provide to one another. These capabilities “solve or support a solution for the problems [businesses] face in the course of their business” ([SOA-RM], p. 7). That is, capabilities are the things businesses do to solve problems and therefore add value, directly or indirectly, to their stakeholders.

Note that the architecture is generic enough to support virtually any kind of capability. However, the purpose of the reference architecture defined in this document is to describe an approach to integrating automated, computer software-based information systems. Therefore, the reference architecture only considers those business capabilities that are provided by (or implemented by) information systems. The reference architecture calls these systems PROVIDER SYSTEMS, and establishes that provider systems implement capabilities.

Each capability produces one or more REAL-WORLD EFFECTS, each of which is an outcome of business value sought by one of the partners. A real-world effect can be either the obtaining of information, the changing of something of business relevance to the participating partners, or both. Because the reference architecture establishes that capabilities are implemented by

of 21

2425

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

261

262

263

264

265

266

267

268

26


provider systems, real-world effects in the reference architecture context consist of the functional business requirements of provider systems. That is, real-world effects in the reference architecture are essentially the information made available by provider systems, or the outcomes resulting from business processes and workflows automated by provider systems, or both.

In a service-oriented architecture, a SERVICE is the way in which one partner gains access to a capability offered by another partner. A partner that uses a service to gain access to another partner’s capability is called a SERVICE CONSUMER. As with capabilities, the architecture is generic enough to support virtually any kind of service consumer. However, since the purpose of the reference architecture in this document is to describe an approach to integrating information systems, the reference architecture only considers those service consumers implemented by information systems. The reference architecture calls such systems CONSUMER SYSTEMS.

One of the most important features of this reference architecture is the separation of consumer systems from provider systems by services in the middle. This is the defining characteristic of a service-oriented architecture, and is the key to de-coupling integrated systems as called for in many of the requirements listed in section 4.

The fact that information sharing is one kind of real-world effect allows the architecture to support the traditional view of system integration as “data exchange” or “information sharing”. The architecture improves this view by encouraging systems to share information in a way that minimizes the dependencies of each system on the implementation details of the other systems.

There are some characteristics of consumer and provider systems that can improve their fitness as service consumers and capabilities, respectively. SOLUTION DESIGN GUIDELINES capture these characteristics, and inform system design and specification decisions for consumer and provider systems. For instance, design guidelines may encourage systems to separate the user interface and business logic layers, so that the business logic can be made directly available through services.

SERVICE DESIGN PRINCIPLES provide consistent guidance regarding the overall partitioning of capabilities into services, and the relationships between services. For instance, service design principles may call for services to represent one concise, self-contained function, and may also suggest that services should completely hide the implementation details of the capabilities to which they provide access.

There is a wide variety of ways in which a service can provide access to a capability. In some cases, the provider system that implements the capability may already expose all or some of its functionality as services (through one or more service interfaces, described in section 5.2.4.) In other cases, the business partner that provisions the capability can purchase an off-the-shelf adapter from the provider system vendor (or a third party) that exposes the system’s functionality as a set of services. Finally, the provider system may require re-implementation or custom adaptation to expose functionality as services; this is often expensive and risky, and the desire to avoid this situation should be addressed in the design guidelines discussed in this section above.

In general, a given information system can be both a provider system and a consumer system. Similarly, a particular business organization may offer capabilities to its partners and, at the same time, be a consumer of the capabilities offered by others. This has important implications for how the enterprise should conceive and describe its information systems assets, and how it assigns responsibilities for the maintenance and support of those assets. For example, in the past it was common to think of systems having “client” and “server” components (or “browser” and “server” components), which in turn influenced thinking about systems deployment, networking, security, support, and a range of other issues. These issues deserve reconsideration in an architecture in which a system or system component can be both a “client” (consumer of services) and “server” (provider of services) at the same time. The discussion of service interaction in section below, and the subsequent elaboration of interaction mechanisms in future iterations of the integration architecture, will reflect the impact of these issues.

Note that the concept of a service in the architecture does not equate to a “web service”. The term “web services” is a label for a family of standards and an associated technical approach to

of 21

2728

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

288

289

290

291

292

293

294

295

296

297

298

299

300

301

302

303

304

305

306

307

308

309

310

311

312

313

314

315

316

317

318

319

320

29


communicating between service consumers and services. The architecture supports flexibility in how this communication happens through the notion of service interaction profiles (discussed in section 5.2.4 below.) It is very likely that one of these profiles will adopt the web services family of standards; however, it is also likely that the architecture will include additional profiles that adopt other communication mechanisms.

5.2.3. Business Process Models and the Service/Capability Hierarchy

The previous section described the basic concepts involved in the integration of provider systems and consumer systems. In short, consumer systems seek a real-world effect provided by a capability, and they produce that effect by accessing a service that provides access to the capability. However, these concepts by themselves do not provide the context for the integration of a particular consumer and particular provider. That is, the concepts do not provide a way of describing why a consumer seeks the effect made available by a provider through a service.

A BUSINESS PROCESS MODEL provides this contextual justification. A business process model is a description (usually formal and often graphical) of a series of activities that culminate in the achievement of some outcome of business value. Some (but not necessarily all) of the steps in this series of activities involve producing a real-world effect provided by a capability, and so some of the steps require a consumer to use a service. Each one of these steps, then, provide the contextual justification for service interaction between a particular consumer and particular provider.

The execution of the steps described in a business process model can be considered a capability in and of itself. In addition, each of the steps in a business process model can unfold into yet another business process model at a more focused level of detail. In this way, each step in a series of service interactions can itself be a series of service interactions. (And in theory this recursion of models can go on forever, though in practice it rarely exceeds three or four levels of containment.) So, services and capabilities form a hierarchy, where a service provides access to a capability whose real-world effect is to accomplish the coordination of multiple services at a lower level of detail.

The architecture supports this hierarchy through orchestrations and intermediaries, discussed in section 5.2.6 below.

5.2.4. Interaction, Visibility, Service Models, and Service Interfaces

Services, described in section above, define what features of a provider system the system owner makes accessible to business partners. Services also provide a logical description of the information exchanged between consumer and provider systems as the consumer accesses the capability.

The architecture refers to a consumer’s accessing the features of a capability through a service as INTERACTION, defined as “the performing [of] actions against a service” ([SOA-RM], p. 13). Service interaction generally involves the exchange of information between the consumer and the service.

Interaction depends on two things. First, 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. Second, 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 a service’s INFORMATION MODEL and BEHAVIOR MODEL, collectively called SERVICE MODELS in the reference architecture.

of 21

3031

321

322

323

324

325

326

327

328

329

330

331

332

333

334

335

336

337

338

339

340

341

342

343

344

345

346

347

348

349

350

351

352

353

354

355

356

357

358

359

360

361

362

363

364

365

32


5.2.4.1. Visibility

Visibility, as the name implies, defines how service consumers and the providers of capabilities “see” each other in a way that enables interaction between them. The architecture identifies three aspects of visibility (note that to simplify the diagram above, these three concepts have been omitted):

A service consumer must have information that makes it aware of the existence of a service; the possession of this information is called AWARENESS

The service (or capability accessed through the service) must be willing to interact with the consumer; this is called WILLINGNESS

The consumer and service must be able to communicate with one another, through some kind of communication path or channel; the existence of such a communication path is called REACHABILITY

In the reference architecture, a REPOSITORY will support awareness by hosting service models and service interfaces. “Hosting” in this context means storing models and interface descriptions in a central location that is accessible to appropriate stakeholders. A repository will permit searching for models and interface descriptions based on a range of identifying criteria. A repository will also map logical service identifiers with physical addresses. When a consumer wishes to communicate with a service (identified by a logical identifier), the consumer queries the repository for the physical address associated with the service’s logical identifier. This de-couples the consumer from the physical location of a service at any point in time, thereby permitting the physical relocation of the service without impacting the implementation of the consumer.

The concept of willingness is related to authorization and access control policies, in that a common reason for lack of willingness to interact is that the consumer is not authorized to conduct the requested interaction. Willingness often manifests in service descriptions (discussed in section 5.2.5) as well as policies, contracts, and agreements (discussed in section 5.2.7).

The concept of reachability is closely related to the concept of execution context (discussed in section 5.2.8).

5.2.4.2. Service Models

Service models, consisting of a service’s information and behavior models, define the semantics of interaction with the service. The behavior model defines the actions that can be performed on the service; that is, it defines what the service “does”. The information model describes the information that consumers exchange with the service in the course of performing those actions.

Note that the SOA-RM considers the orchestration and choreography of multiple services to be “part of the process model of a given architecture”. Yet the SOA-RM also indicates that a process model (part of the behavior model) applies to a single service. ([SOA-RM], p. 15). Because of this lack of clarity in the SOA-RM, this reference architecture identifies orchestration as a type of capability that leverages other services; it is described in section below.

In general, service models will be described at conceptual and logical levels of detail. (Service models have a physical manifestation as well, in the form of the service interface discussed in the next section.) A conceptual description of a service model will typically describe, in prose text form, the capability to which the service provides access, a listing and brief textual description of each action, and a brief textual description of the information model (e.g., key information entities, key properties on those entities, and brief definitions.) A logical description of a service model will describe the actions and information structures in detail, but independent of any physical implementation mechanism. Often this description will be graphical and follow a standard diagramming or modeling technique.

of 21

3334

366

367

368

369

370

371

372

373

374

375

376

377

378

379

380

381

382

383

384

385

386

387

388

389

390

391

392

393

394

395

396

397

398

399

400

401

402

403

404

405

406

407

408

409

410

411

412

35


A MESSAGE is defined as the entire “package” of information sent between service consumer and service (or vice versa), even if there is a logical partitioning of the message into segments or sections. For instance, if an interface expresses actions as operations or functions that take arguments, and a particular operation has two arguments, both arguments would be considered part of the same message, even though they may be logically separated within the message structure. In this reference architecture, the exchange of messages is the only way in which consumers and services can communicate. A message also includes the concept of an “attachment”, in which there are several additional sections (attachments) that relate to a distinct, “primary” section.

The concept of DOMAIN VOCABULARIES in the reference architecture includes canonical data models, data dictionaries, and markup languages that standardize the meaning and structure of information for a topical or business domain. Domain vocabularies can improve the interoperability between consumer and provider systems by providing a neutral, common basis for structuring and assigning semantic meaning to information exchanged as part of service interaction. Domain vocabularies can usually be extended to address information needs specific to the service interaction or to the business partners integrating their systems. The choice of domain vocabularies, like the design of particular services, is outside the scope of the reference architecture.

SERVICE MODELING GUIDELINES govern the style, structure, and description of service models; an initial elaboration of these guidelines appears in section below.

As stated in section above, a repository should contain service model description artifacts for each level of detail. The availability of service model descriptions to consumer system designers, implementers, and purchasers is a key factor in establishing visibility and the reuse of services.

5.2.4.3. Service Interface

Service models describe the actions available from a service, and the information exchanged between a consumer and the service during the performance of those actions. In this way, the service models describe the “what” of interaction.

A SERVICE INTERFACE “is the means for interacting with a service. It includes the specific protocols, commands, and information exchange by which actions are initiated [on the service]” ([SOA-RM], p. 19). A service interface is what a system designer or implementer (programmer) uses to design or build executable software that interacts with the service. That is, the service interface represents the “how” of interaction.

The reference architecture considers the service interface to be the physical manifestation of the service models. Best practices call for a service interface to be described in an open-standard, referenceable format (that is, a format whose contents are capable of automated processing by a computer.)

Note that at least some policies and contracts can be described in a service’s interface.

The format, structure, and allowable contents of a service interface are established by INTERFACE DESCRIPTION REQUIREMENTS, described in section 5.2.5.

5.2.5. Design and Description of Service Interfaces

The reference architecture identifies four architectural elements that guide the design and description of service interfaces.

SERVICE INTERACTION REQUIREMENTS define common rules of service interaction. Typically these requirements are non-functional in nature, in that they are not directly related to the capability used by the service consumer, nor are they related to the real-world effect resulting from use of that capability. Rather, the requirements enforce (or support the enforcement of) policies or

of 21

3637

413

414

415

416

417

418

419

420

421

422

423

424

425

426

427

428

429

430

431

432

433

434

435

436

437

438

439

440

441

442

443

444

445

446

447

448

449

450

451

452

453

454

455

456

457

458

38


contracts, or otherwise protect the interests of particular business partners or the business enterprise overall.

Common service interaction requirements address areas such as security, reliability, and availability. An initial elaboration of service interaction requirements appears in section below.

INTERFACE DESCRIPTION REQUIREMENTS 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.

MESSAGE EXCHANGE PATTERNS identify common sequences of message transmission between service consumers and services. They provide a label to a series of message transmissions that have some logical inter-relationship. An initial elaboration of message exchange patterns appears in section 8.4 below.

MESSAGE DEFINITION MECHANISMS are closely related to interface description requirements, described above. Unlike interface description requirements, message definition mechanisms establish a standard way of defining the structure and contents of a message. Note that since a message includes the concept of an “attachment”, the message definition mechanism must identify how different sections of a message (for example, the main section and any “attachment” sections) are separated and identified, and how attachment sections are structured and formatted.

5.2.5.1. Service Interaction Profiles

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

Interface description requirements

Message exchange patterns

Message definition mechanisms

Service interaction profiles are included in the reference architecture to promote interoperability without forcing the state enterprise to agree on a single way of enabling service interaction. Each service interface will support a single profile; a service will have multiple interfaces if it supports multiple profiles. By supporting a profile, an interface establishes the mode of inter-operation it allows from service consumers; any consumer that also supports that profile can “reach” the service (the concept of reachability is defined under visibility, in section 5.2.3.1 above).

SERVICE INTERACTION PROFILE GUIDELINES define precisely what is required of a service interaction profile, and therefore provides guidance and clear requirements for developers of potential profiles.

5.2.6. Capabilities in Detail

The reference architecture identifies several types of capabilities, to assist decision-makers in understanding where certain capabilities should be deployed in the enterprise, who should provision them, and what relationships they may have to other capabilities and services.

5.2.6.1. Common and Edge Capabilities

A COMMON CAPABILITY is a capability for which a business case exists to suggest common, shared, enterprise provisioning. That is, a common capability has no natural “owner” or provisioner among the enterprise business partners, because the nature of the capability is that it is best shared across partners.

of 21

3940

459

460

461

462

463

464

465

466

467

468

469

470

471

472

473

474

475

476

477

478

479

480

481

482

483

484

485

486

487

488

489

490

491

492

493

494

495

496

497

498

499

500

501

41


Most common capabilities are non-functional in nature, in that their function supports the proper, safe, or reliable functioning of other capabilities. Examples of non-functional common capabilities are: directory services to support authentication, authorization, and access control; logging services; message structure/format validation services; and metering/billing services. In addition, a capability that translates messages from one format to another without adding or enhancing the information in the message would be non-functional in nature. Also, operational management capabilities monitor and record information about service interaction, which permits analysis of service performance and an understanding of where services are being used throughout the enterprise.

Some common capabilities could be functional in nature. A typical example is a data-enrichment service, that receives a message (ultimately destined for a service or consumer elsewhere) and enhances the message by adding relevant data to it. A second typical example is an aggregated query service, that receives a set of query parameters, examines them, and interacts with several other services to compile the response. Yet another example is a portal service that coordinates the interaction of several services across the enterprise, to aggregate information or provide a seamless workflow to a human user. (Strictly speaking, such a “portal service” would consist only of the capability to perform the coordination; a portal human-interaction interface would use the portal service to present the aggregated information or coordinated workflow to a human user.)

Common capabilities are often designed, implemented, and provisioned by a central service provider or consortium of the enterprise business partners.

An EDGE CAPABILITY is a capability whose design and provisioning is the responsibility of a single, well-identified enterprise business partner. Usually an edge capability is implemented by an information system wholly owned and maintained by that single partner. The partner has control over the implementation of an edge capability, and the freedom to alter that implementation as long as the terms of any services that provide access to that capability are satisfied.

Note that while responsibility for provisioning an edge capability rests with a single business partner, the services that access that capability (and the service interfaces that provide the means of interacting with those services) should be viewed as shared assets with some appropriate degree of shared control.

5.2.6.2. Orchestrations and Intermediaries

An ORCHESTRATION is a capability that coordinates interaction with multiple services. An orchestration is often implemented using an open industry standard implementation mechanism (referred to as an ORCHESTRATION MECHANISM in the reference architecture), which allows the implementation to be shared across tools and platforms. Also, it is often possible to implement orchestrations using a graphical, model-driven approach, in which the implementer diagrams business processes and workflows, the steps of which are services that already exist. After the diagram is complete, the implementer generates a standards-based artifact that is deployed into a software component that exposes the workflow as a service through a service interface. The promise of this model-driven approach is that less technical implementers with greater business expertise can be responsible for the implementation of orchestrated capabilities.

A ROUTER is a capability that receives a message, examines it, and transmits it to one or more destinations based on the contents. 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.

A TRANSFORMER is a capability that receives a message and transforms it into another format before transmitting it on to another destination.

Routers and transformers are collectively called INTERMEDIARIES. This term indicates that routers and transformers generally sit between other services and “mediate” the interaction by managing the transmission of messages between them, or by reformatting messages in transit.

of 21

4243

502

503

504

505

506

507

508

509

510

511

512

513

514

515

516

517

518

519

520

521

522

523

524

525

526

527

528

529

530

531

532

533

534

535

536

537

538

539

540

541

542

543

544

545

546

547

548

549

550

551

44


Routers and transformers are useful mechanisms for de-coupling the senders and recipients of messages. They tend to centralize and share certain kinds of logic so that the logic can be maintained independently of the provider and consumer capabilities at the edges; sharing also improves the likelihood of reuse, since it is easier to reuse functionality if it encapsulates a single task.

Support for router, transformer, and orchestration capabilities is a common feature in many integration platforms, and therefore support for these capabilities is a consideration in choice of execution context (discussed in section below).

Routing, transformation, and orchestration capabilities are well understood and well documented in the integration architecture literature. The most common flavors of these capabilities have been collected into pattern form as ENTERPRISE INTEGRATION PATTERNS, in [Patterns]. The reference architecture should incorporate these patterns by reference.

Orchestrations and intermediaries are a key component in implementing business process models, and also lead to the formation of service/capability hierarchies. This topic is discussed in more detail in section 5.2.3 above.

5.2.7. Policies, Contracts, and Agreements

POLICIES and CONTRACTS express rules that govern the interaction between a service consumer and a service. 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. 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. And 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.

An AGREEMENT is a document that establishes policies and contractual elements for a given interaction or set of interaction (that is, for one or more services).

5.2.8. Execution Context

EXECUTION CONTEXT is “the set of infrastructure elements, process entities, policy assertions, and agreements that are identified as part of an instantiated service interaction” ([SOA-RM], p. 21.)

Execution context is the primary enabler of the reachability aspect of visibility, as defined in section 5.2.4.1 above. Execution context includes the set of infrastructure elements that provide a physical communication path between service consumers and services.

The reference architecture considers execution context to be primarily the supporting infrastructure elements that permit service consumers and services to interact. These infrastructure elements consist of:

Data networks used by service consumers and services to exchange information

Integration infrastructure (hardware and software) that makes service interfaces available and handles higher-level message routing, transformation, and orchestration

Consumers of certain common capabilities (via services) that support service interaction; examples include directory services and metering services

Execution context can implement (or support the implementation of) some service interaction requirements, such as reliability and availability. Service interaction profiles, contracts, and policies can constrain the behavior of execution context elements, by requiring particular technologies or techniques, or establishing service level policies (for example.)

Finally, as discussed in section above, execution context can support certain kinds of capabilities directly in the integration infrastructure, such as routing, transformation, and orchestration.

of 21

4546

552

553

554

555

556

557

558

559

560

561

562

563

564

565

566

567

568

569

570

571

572

573

574

575

576

577

578

579

580

581

582

583

584

585

586

587

588

589

590

591

592

593

594

595

596

597

47


6. Mapping of Architecture to Requirements

The Documenter Team will complete this section after Integration Domain (principles, drivers, and trends) stabilize.

7. Illustration Scenarios

Note that this section is illustrative only, and is not intended to establish these scenarios as standards or intended approaches to specific projects. This section will grow over time as the Documenter Team identifies additional illustrative scenarios.

7.1. Scenario A

Waiting on scenario submissions from the team.

7.2. Scenario B

Waiting on scenario submissions from the team.

8. Initial Elaboration of Concepts

The purpose of this section is to establish a direction and initial “straw model” for those concepts to be elaborated and defined in detail within the architecture. (Note that some concepts will remain conceptual, and will be defined in detail over time).

8.1. Service Modeling Guidelines

A sub-group of the Documenter Team will elaborate this concept starting in the April 14 iteration.

8.2. Service Design Principles

The following initial list of service design principles is summarized from [Erl].

Services should be designed for reuse

Services should be designed so that they may participate in a composition with other services to form a higher-level service

Services should share only a formal contract with their consumers (consumers are dependent only on the service’s interface, not the implementation details of the capability to which the service provides access)

Services are stateless, meaning that during an interaction with a service, a service consumer supplies all information necessary to conduct the interaction, and makes no assumptions about information retained from prior interactions

8.3. Service Interaction Requirements

The following is an initial list of candidate service interaction requirements.

Service Consumer Authentication: Information provided with messages transmitted from service consumer to service, that verify the identity of the consumer

Service Consumer Authorization: Information provided with messages transmitted from service consumer to service, that document the consumer’s authorization to perform certain actions on and/or access certain information via the service

of 21

4849

598

599

600

601

602

603

604

605

606

607

608

609

610

611

612

613

614

615

616

617

618

619

620

621

622

623

624

625

626

627

628

629

630

631

632

50


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 protect anyone except an authorized recipient from reading the message or parts of the message

Message Addressing: Information provided in a message that indicates where a message originated, the ultimate destination of the message (beyond physical endpoint), 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)

Service Availability: A commitment of a service to be reachable at a stated percent of the time with specified conditions

Service Responsiveness: A commitment of a service to return a response (synchronous or asynchronous) within a specified period of time

8.4. Message Exchange Patterns

The reference architecture will identify the following message exchange patterns:

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.

9. Glossary

10. References

SOA-RM Reference Model for Service Oriented Architectures, Working Draft 11. OASIS, 2005.

of 21

5152

633

634

635

636

637

638

639

640

641

642

643

644

645

646

647

648

649

650

651

652

653

654

655

656

657

658

659

660

661

662

663

664

665

666

667

668

669

670

671

672

673

674

675

53


Patterns Hohpe, Gregor and Woolf, Bobby. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison Wesley, 2004.

Erl Erl, Thomas. Service-Oriented Architecture: Concepts, Technology, and Design. Prentice-Hall, 2005.

of 21

5455

676

677

678

679

680

56


Appendix A: Documenter Team

This document was developed through the Integration Architecture enterprise architecture initiative, chartered December 14, 2005. The following individuals were members of the Documenter Team for this initiative, and participated in review of this document.

Kent Andrus, Office of Financial Management

Lori Bame, LEAP Committee

Jerry Britcher, Department of Social and Health Services

Scott Came, Department of Information Services

Gary Dubuque, Department of Revenue

Jim Eby, Department of Fish and Wildlife

Brian Everson, Washington State Patrol

Laura Graham, Legislative Service Center

Robin Griggs, Department of Licensing

John Hanson, Commission on Trade and Economic Development

Tom Henderson, Department of Labor & Industries

Paul Hubert, Department of Information Services

Debbie Johnson, The Higher Education Coordinating Board

Lorraine Louderback, Department of Corrections

Dan Mercer, Department of Labor & Industries

Miles Neale, Department of Ecology

Bill Norris, Department of Health

Laura Parma, Department of Information Services

Mike Rohrbach, Administrative Office of the Courts

Jeff Sharp, Office of the State Treasurer

Matt Stevens, Department of Information Services

Lyle Tillett, Department of Retirement Systems

of 21

5758

681

682

683

684

685

686

687

688

689

690

691

692

693

694

695

696

697

698

699

700

701

702

703

704

705

706

59


Appendix B: Review Log

The following feedback on this document was received by the Enterprise Architecture Program; the response to each contribution is noted below.

Review by whom and when

Contribution Response

Documenter Team

February 22, 2006

New Service Interaction Requirements: Service 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

Incorporated into document

of 21

6061

707

708

709

710

711

62

conceptual integration technical reference architecture

Documents