27 0132344823 Index.qxd 6/14/07 1:17 PM Page 539...

A

absolute isolation, 309, 317abstract classes (OOAD), 461

designing service-oriented classes, 474

Abstract Syntax Notation 1 (ASN.1), 128

abstraction (OOAD), 463. See alsoService Abstraction (principle)

access control levels, 232-234accessor methods (OOAD), 454active state (state management), 335aggregates of services. See service

compositionsaggregation (OOAD), 471-472agile development, 87, 521

organizational agility versus, 63service-orientation and, 87Service Reusability design

risks, 287agility. See organizational agilityagnostic capability candidates, 523agnostic service references, 63agnostic services, 62, 82, 91, 407

reusable services versus, 268-269service contracts, 144Service Reusability, 268-269

agnostic solution logic, increasing, 82alignment of business and technology.

See business and technology domainalignment in service-orientedcomputing

analysis phase, measuring servicereusability in, 265-266

analysis scope, defining, 522AOP (aspect-oriented programming),

as an influence of service-orientation, 99, 448

API (application programminginterface), 48, 128, 174, 177, 213, 313

functional abstraction, 221service contracts and, 129

application architectures, 95-96application programming interface.

See APIapplication services. See utility servicesapplication-specific solution logic,

reducing, 82-83applications

composite, 91-92service compositions versus, 91-92service-orientation and, 91-92technology architectures, 95-96

architects. See enterprise architects (role)

Index

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 539

architecture. See also SOA (service-oriented architecture)

application, 95-96client-server, 128, 165

state management, 328defining, 520distributed, 128, 166

state management, 329, 331enterprise, 80, 95-96integration, 81, 92-96, 182-184mainframe, 166point-to-point, 80, 405-406service composition, 96Service Statelessness design risks,

349-350of Web services, 48-49, 166

ASN.1 (Abstract Syntax Notation 1),128

aspect-oriented programming. See AOPassertions. See policy assertionsassociation (OOAD)

comparison of object-orientationand service-orientation, 469-470

designing service-oriented classes,474

attachments (SOAP), 334attributes (objects), explained, 454attributes (OOAD), 473auditors. See enterprise design

standards custodians (role)auto-generation (of service contracts),

175, 178autonomy. See also Service Autonomy

(principle)composition autonomy, 430data models and, 308-310databases and, 308-310governance and, 298-299service compositions and, 298, 314

B

base classes (OOAD), 461benefits of service-oriented computing.

See service-oriented computing,goals and benefits

best practicesarchitecture dependency, 350building Web services, 151controlled access, 234discoverability meta

information, 382Domain Inventory design

pattern, 275encapsulated legacy

environments, 318example of, 34explained, 34-35measuring consumer coupling, 192service composition performance

limitations, 437service contract design risks, 150for service-orientation, 87

bidirectional coupling, 165black box concept, 213, 227books, related, 4-5

Web site, 16bottom-up processes, 518-519BPM (business process management),

as an influence of service-orientation, 98, 448

bridging products, 142business agility. See organizational

agilitybusiness analysts, 522

discoverability meta informationand, 377

role of, 53business and technology domain

alignment in service-orientedcomputing, 60-61

540 Index

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 540

business data (state management), 338business entity services. See entity

servicesbusiness logic. See core service logic in

Web sitesbusiness models. See enterprise

business modelsbusiness process definition,

explained, 397business process instance,

explained, 397business process management.

See BPMbusiness process services. See

orchestrated task services;task services

business requirements fulfillment, asgoal of object-orientation, 450-451

business service candidates, 377business services. See entity services;

task services

C

candidates. See service candidatescapabilities

granularity and, 116operations and methods

versus, 115service compositions, 399-400services and, 69-70

capability candidates. See servicecapability candidates

capability granularity, 486explained, 116Service Composability and, 428service contracts, 143Service Loose Coupling principle

and, 195-196Service Reusability and, 277

Capability Name (service profile field), 481

capability profiles, structure of, 481-482case study

background, 20-22, 66, 100-101,119-121

business process description,119-121

conclusion of, 514-515coupling in, 202-209preliminary planning, 101service abstraction levels, 244-252Service Autonomy in, 319-323Service Composability in, 439-441Service Discoverability in, 382-386Service Reusability in, 288-292Service Statelessness in, 351-359services in, 154Standardized Service Contract

principle example, 154-161style, 20

centralizationContract Centralization design

pattern, 185, 195, 473, 530example of, 216-217Logic Centralization and,

272-273measuring consumer coupling,

191-192standardized coupling and, 185technology coupling, 189-190

Logic Centralization designpattern, 185, 465, 468, 531

Contract Centralization and,272-273

difficulty in achieving, 274-275as enterprise design

standard, 272explained, 271standardized coupling and, 185Web services and, 274

Index 541

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 541

of policy assertions, 138-139Schema Centralization design

pattern, 135-137, 531characteristics. See design

characteristicschorded circle symbol, explained, 13,

15-16classes (OOAD)

compared to service contracts, 453service-oriented classes, 472-474

client-server architectures, 165, 128state management, 328

coarse-grained design. See granularitycode examples

capability expressed in IDL, 129capability expressed in WSDL, 129constraint granularity, 117fine-grained XML schema simple

type, 143skeleton (coarse- and fine-grained)

operation definitions, 143skeleton WSDL definition for

coarse-grained service, 142SOAP and WS-Addressing headers

for state management, 337standardized and non-

standardized WSDL messagedefinitions, 133

UDDI discoveryURL construct, 372WS-BPEL composition logic, 431WS-Coordination headers for state

management, 338WS-MetadataExchange and WS-

Addressing, 373cohesion

comparison of object-orientationand service-orientation, 467

service granularity and, 467collective composability, explained,

400-401

color, in symbols, 13commercial product design, 62, 276

abstraction and, 214coupling and, 166gold-plating versus, 267meta abstraction types in, 227measuring service reusability, 262,

264-265risks associated with, 286-287

communications quality, 365communications specialists. See

technical communicationsspecialists (role)

complete reusability, 266, 487complex compositions. See complex

service compositionscomplex service activities, 402complex service compositions,

406-407, 487characteristics of, 410-411preparation for, 411service inventory evolution, 407,

409-410complexity, in traditional solution

delivery, 80components, coupling and, 176-177composability. See Service

Composability (principle)composition (OOAD), 470-471. See also

service compositions; ServiceComposability (principle)

composition autonomy, 430Service Composability and, 430

composition candidates. See servicecomposition candidates

composition controller capabilities,394, 400

composition controllers, 435, 487explained, 398-401service consumers as, 404

542 Index

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 542

composition initiators, 487explained, 403-405service consumers as, 404

composition instances, 397composition member capabilities,

393, 400Composition Member Capabilities

(service profile field), 481composition members, 487

design of. See ServiceComposability (principle)

explained, 398-401Web service region of influence

for, 395Composition Role (service profile

field), 481composition sub-controllers, 487concise contract abstraction, 232, 487conflict symbol, 13constraint granularity, 486

explained, 117-118Service Abstraction and, 239Service Composability and, 428service contracts, 143Service Loose Coupling principle


consumer couplingmeasuring, 191-192Service Abstraction and, 192Service Composability and, 191service consumers, 48-49

as composition initiators andcontrollers, 404

coupling and, 167coupling types, 181-192policy dependencies, 138

consumer-specific functional coupling, 180

consumer-to-contract coupling, 185-191, 473, 486

risks with, 214Web services and, 186

consumer-to-implementation coupling,182, 184, 486

integration architectures and,182-184

containers, objects as, 458content abstraction, 246context data (state management), 337-

338context rules (state management), 337Contract Centralization design pattern,

185, 195, 473, 530example of, 216-217Logic Centralization and, 272-273measuring consumer coupling,


contract content abstraction levels,231-232

Contract Denormalization designpattern, 242, 305, 312, 530

service contract autonomy and,304-305

contract first design, 53, 131, 173, 194contract-to-functional coupling,

180, 486indirect consumer coupling and,

188contract-to-implementation coupling,

177-179, 486examples of, 177indirect consumer coupling

and, 189service composability, 200

Index 543

27_0132344823_Index.qxd 6/14/07 1:17 PM 43

contract-to-logic coupling, 174-175, 486policies and, 179Service Composability and, 199

contract-to-technology coupling,176-177, 486

direct consumer coupling and, 188Service Composability and, 199

contracts. See service contractscontrolled access (access control level),

233-234, 487controller capabilities, 400controllers. See composition controllerscore service logic in Web services, 48coupling. See also Service Loose

Coupling (principle)architectural, 168auto-generation and, 175in case study, 202-209in client-service architectures, 165commercial product design

and, 166compared to dependency, 165data models and, 175database tables and, 175design principles, relationship

with, 197-200design risks, 200

logic-to-contract coupling,200-201

performance problems, 201-202design-time autonomy and, 181,

315-316in distributed architectures, 166explained, 164-165integration architectures and,

182-184mainframe and, 166multi-consumer coupling

requirements (ServiceAbstraction principle), 242

negative types, 193, 195in object-orientation, 166origins of, 165-166performance, 202policies and, 179positive types, 193, 195proprietary components and,

176-177risks with, 214Service Composability and, 191service consumer coupling types,

181-182consumer-to-contract coupling,

185-191consumer-to-implementation

coupling, 182, 184Contract Centralization design

pattern, 185measuring consumer coupling,

191-192service contract coupling types,

169-173contract-to-functional

coupling, 180contract-to-implementation

coupling, 177-179contract-to-logic coupling,

174-175contract-to-technology coupling,

176-177logic-to-contract coupling,

173-174service granularity and, 195-196service models and, 196-197service-orientation and, 193-195symbols for, 165Web services and, 166

coupling quality, 146cross-cutting functions, 313, 347CRUD, 44, 464

544 Index

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 544

cultural issues, Service Reusabilitydesign risks, 281-283

Custodian (service profile field), 482Cutit Saws case study. See case study

D

data granularity, 486explained, 116Service Composability and, 428service contracts, 143Service Loose Coupling principle


data modelsautonomy and, 308-310contract-to-implementation

coupling and, 177-178coupling and, 175data granularity and, 116example of coupling, 206global, 136logical, 52service contracts and, 134-137standardization, 50, 89, 134-137

data representation standardization,134-137

case study, 155data transformation, avoiding,

140-142sample design standards, 155

data transformationavoidance, 135-136, 140-142design standards and, 135-136performance issues, 140problems, 140standardization and, 140-142Standardized Service Contract

principle and, 135-136, 140-142

databasesautonomy and, 308-310contract-to-implementation

coupling and, 177-178coupling and, 175for state management, 329, 331,

339-343dedicated controllers, 487deferral. See state deferraldelegation (OOAD), 468-469. See also

state delegationdelivery processes. See processesdelivery strategies. See processesdenormalization. See also normalization

service contracts and, 301-305dependency, coupling compared to,

165design characteristics

example of, 27explained, 27-28implementation of, 111-114importance of, 69list of, 81loose coupling, 166regulation of, 111-114

design framework, 35-36design granularity. See granularitydesign paradigm

example of, 29explained, 29-30relationships with design

framework, 36service-orientation as, 70-71

design pattern languageexample of, 32explained, 31-32

Index 545

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 545

design patternsContract Centralization design

pattern, 185, 195, 242, 473, 530example of, 216-217Logic Centralization and,

272-273measuring consumer coupling,


Contract Denormalization, 242,305, 312


Domain Inventory, 136, 275example of, 31explained, 30-31how they are referenced, 111Logic Centralization, 185, 465, 468

Contract Centralization and,272-273

difficulty in achieving, 274-275as enterprise design

standard, 272explained, 271Web services and, 274

referenced in design principles, 530relationships with design

framework, 36Schema Centralization, 135-137Service Normalization, 272,

305, 465service contract autonomy and,

302-304design phase (service composition), 413

assessment, 413, 415design principles

application levels, vocabulariesfor, 487-488

best practices versus, 34

business and technologyalignment in, 502-503

compared to object-orienteddesign principles, 457-472

design pattern references, 111, 530design standards and, 33, 107-108documentation for, 109-110example of, 28explained in abstract, 28-29extent of implementation, 108federation in, 501in formal service design processes,

106-107granularity, types of, 115-118guidelines for working with,

104-110, 115-121implementation mediums and,

114-115implementation of design

characteristics, 111-114interoperability and, 74-75intrinsic interoperability in,

498, 500list of, 71-73mapping to strategic goals, 498-509organizational agility in, 505, 507principle profiles, explained,

109-110reduced IT burden in, 507, 509regulation of design

characteristics, 111-114ROI in, 504Service Abstraction, relationship

with, 239-241. See also ServiceAbstraction (principle)

Service Autonomy, relationshipwith, 314-317. See also ServiceAutonomy (principle)

546 Index

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 546

Service Composability,relationship with, 432-436. Seealso Service Composability(principle)

service contracts. See servicecontracts

Service Coupling (principle),relationship with, 197-200

Service Discoverability,relationship with, 378-380. Seealso Service Discoverability(principle)

Service Reusability (principle),relationship with, 278, 280-281

Service Statelessness, relationshipwith, 347-349. See also ServiceStatelessness (principle)

in service-oriented analysis,105-106

service-oriented computingelements, relationship with, 41

SOA goals and benefits,relationship with, 498-499

standard structure, 109-110standardization of service

contracts, relationship with,144-148

vendor diversification in, 501-502vocabularies for, 486-487

design standardsdata representation design

standard samples, 155design principles and, 107-108example of, 33explained, 32-33functional expression design

standard samples, 155granularity and, 144importance of, 86industry standards versus, 34level required, 89

naming conventions, 147in service-orientation, 86Standardized Service Contract

principle and, 132design taxonomy, 35design-time autonomy, 486

coupling and, 315-316explained, 298-299logic-to-contract coupling and, 181service contracts and, 301-305

design-time discovery, 371-373, 486design-time isolation, 309designated controllers, explained, 400detailed contract abstraction level,

231, 487development tool deficiencies, 151-152direct consumer coupling

example of, 188indirect consumer coupling versus,

186, 188-189discoverability, explained, 364. See also

Service Discoverability (principle)discovery. See also Service

Discoverability (principle)explained, 364-366meta information and, 362origins of, 367-368processes, 363-367of resources, 362-368types of, 371-373

distributed architectures, 128, 166state management, 329, 331

DLL (dynamic link library), 390document-centric messages, 117Domain Inventory design pattern, 136,

275, 531don’t repeat yourself. See DRY (OOAD)DRY (OOAD), 465-466dynamic link library. See DLL

Index 547

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 547

E

EAI, 213, 448as an influence of service-

orientation, 98-99, 448encapsulation

of legacy logic, 318Service Abstraction versus, 235service encapsulation, 235-237

encapsulation (OOAD), 458Endpoint References, 345enterprise application integration.

See EAIenterprise architects (role), 494-495enterprise architectures, 80, 95-96enterprise business models,

defining, 520enterprise design standards custodians

(role), 495entity schemas, 136entity services

coupling and, 196design processes, 526example of, 44explained, 44Service Abstraction principle, 239Service Autonomy and, 312-313service contracts, 144Service Statelessness and, 346

entity-centric business services. Seeentity services

entity-centric schemas, 137errata, 16event-driven, 48examples. See case study; code

examples; For Example sectionsextends attribute, 460extensibility, as goal of object-

orientation, 450-451

F

façade classes (OOAD), designingservice-oriented classes, 474

federated service architecture, 59federation

in service-oriented computing,58-59

with services, 58Web services and, 59

fine-grained design. See granularityfirst-generation Web services platform,

47. See also Web servicesflexibility, as goal of object-orientation,

450, 452For Example sections

composition initiators, 404-405contract-to-implementation

coupling, 179contract-to-logic coupling, 175contract-to-technology

coupling, 177design standards, 108formal service design

processes, 107logic-to-contract coupling, 174messaging, 344Service Abstraction principle,

216-217service contract autonomy, 303service modeling process, 106Service Reusability, 284-285XML schema standardization, 137

fully deferred state management,measuring service statelessness,342-343

functional abstraction, 221-222, 225, 486example of, 246

functional context, 70, 312, 468service granularity and, 116

548 Index

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 548

functional coupling. See contract-to-functional coupling

functional expression standardization, 155

functional isolation, 308functional meta data, 374, 486

example of, 383-386functional scope, Service Autonomy

design risks, 317functional service expression,

standardization of, 133-134case study, 155

fundamental concepts, comparison ofobject-orientation and service-orientation, 453-454, 456-457

G

generalization (OOAD), 461-462global data models, 136glossary Web site, 16, 533goals


mapping to design principles,498-509

goals of service-oriented computing.See service-oriented computing,goals and benefits

gold-plating, 267governance

autonomy and, 298-299, 316design-time autonomy and,

298-299pure autonomy, 308reuse and, 316Service Composability design

risks, 438Service Reusability design risks,

283-285of service-orientation, 88

governance phase (servicecomposition), 413

assessment, 417, 419granularity. See also capability

granularity; constraint granularity;data granularity; service granularity

design standards and, 144levels, 118types of, 115-118

Guidelines for Policy Assertion Authors(W3C), 493

H

hardware accelerators, 334has-a relationships (OOAD),

469-471, 474hidden compositions, 402, 434hiding information. See Service

Abstraction (principle)high statelessness, 342-343history. See origins

I

IDL (Interface Definition Language), 128

implementation coupling, example of,206-207

implementation mediums, designprinciples and, 114-115

implementation phase, measuringservice reusability in, 267

implementation principles, 111-114implementation requirement, service

contracts, 131increased intrinsic interoperability, 75indirect consumer coupling

direct consumer coupling versus,186, 188-189

example of, 188-189, 207

Index 549

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 549

industry standards, design standardsversus, 34. See also Web services

information architecture models, 52information hiding. See Service

Abstraction (principle)infrastructure services. See utility

servicesinheritance (OOAD), 166



service granularity and, 473Input/Output (service profile field), 481integration

of architectures, 81consumer-to-implementation

coupling, 182-184coupling and, 182-184EAI (enterprise application

integration), 98-99service compositions and, 92-94service-orientation and, 84, 92-94in traditional solution delivery,

80-81integration architectures, 95-96Interface Definition Language. See IDLinterface element, 456interfaces (OOAD)

compared to service contracts,456-457

compared to WSDL portType andinterface elements, 456


measuring service statelessness, 342

interoperabilityof services, 84service-orientation and, 74-75, 84in service-oriented computing,

56-57interpretability. See also Service

Discoverability (principle)defined, 365explained, 365

interpretation process, 364-367explained, 365

intrinsic interoperability. Seeinteroperability

inventory analysis, 520-521, 523is-a relationships (OOAD), 459is-a-kind-of relationships (OOAD), 461isolation

levels of, 308-310partially isolated services, 306-308of services, 308-310

IT roles. See organizational roles

J–K

JDBC, 166

Keywords (service profile field), 481

L

LDAP directories, 367legacy systems

effect on, 523mainframe architectures, 166Service Autonomy design

risks, 318service encapsulation, 236

lifecycle phases of servicecomposability, 412-413

logic abstraction. See programmaticlogic abstraction

550 Index

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 550

Logic Centralization design pattern,185, 465, 468, 531

Contract Centralization and, 272-273

difficulty in achieving, 274-275as enterprise design standard, 272explained, 271standardized coupling and, 185Web services and, 274

Logic Description (service profile field), 481

logic-to-contract coupling, 173-174, 486design-time autonomy and, 181example of, 174limitations, 200-201Web services and, 201

logic-to-implementation coupling, 178logical data models, 52loose coupling. See Service Loose

Coupling (principle)low-to-no statelessness, 340

M

mainframe architectures, 166measuring

consumer coupling, 191-192Service Abstraction, 231

access control abstraction levels,232-234

contract content abstractionlevels, 231-232

quality of service metainformation, 234

Service Autonomy, 300-301mixed autonomy, 310pure autonomy, 308-310service contract autonomy,

301-305service logic autonomy, 306-308shared autonomy, 305-306

Service Composability, 412checklists, 419-420, 426-427design phase assessment,

413, 415governance phase assessment,

417, 419lifecycle phases, 412-413runtime phase assessment,

415, 417Service Discoverability

baseline measures checklist,375-376

custom measures, 376Service Reusability, 262-263

in analysis/design phase,265-266

commercial design approach,262, 264-265

gold-plating, 267in implementation phase, 267

Service Statelessness, 339fully deferred state management,

342-343internally deferred state

management, 342non-deferred state

management, 340partially deferred memory,

340-341partially deferred state

management, 341-342message correlation, 337message processing logic for Web

services, 48messages. See also SOAP


data granularity and, 116document-centric, 117RPC-style, 117as state deferral option, 343-344

Index 551

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 551

meta abstraction types, 218-219in commercial software, 227in custom-developed software,

228-229functional abstraction, 221-222in open source software, 227-228programmatic logic abstraction,

222-223quality of service abstraction, 224technology information

abstraction, 219-221Web service design and, 225-226in Web services, 229-230

meta information types. See ServiceDiscoverability (principle)

methods (objects), explained, 454mixed autonomy, 310, 313mixed detailed contract abstraction

level, 232, 487moderate statelessness, 341-342modularization of policy assertions,

138-139monolithic executables, 390multi-consumer coupling

requirements (Service Abstractionprinciple), 242

multi-purpose logic, 268multi-purpose programs, 255-256multi-purpose services, 468

N

naming conventions. See vocabulariesnegative types of coupling, 193, 195nested policy assertions, 138.NET, 177, 216-217no access (access control level), 234, 487non-agnostic capability candidates, 523non-deferred state management, 340

non-technical service contracts,152-153. See also SLA

Service Abstraction and, 237-238normalization

Contract Denormalization designpattern, 305, 312, 530


entity services, 313service contracts and, 301-305Service Normalization design

pattern, 272, 305, 465, 531service contract autonomy and,

302-304of services, 65, 83utility services, 313

notification service for updates toPrentice Hall Service-OrientedComputing Series from Thomas Erlbooks, 17, 533

O

object-orientation, 129abstract classes, 461

designing service-orientedclasses, 474

abstraction, 213, 463. See alsoService Abstraction (principle)

accessor methods, 454aggregation, 471-472association

comparison of object-orientationand service-orientation,469-470


attributes, 473base classes, 461

552 Index

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 552

classescompared to service

contracts, 453service-oriented classes, 472-474

composition, 470-471. See alsoservice compositions; ServiceComposability (principle)

coupling, 166delegation, 468-469. See also state

delegationas design paradigm, 30DRY, 465-466encapsulation, 458façade classes, designing service-

oriented classes, 474generalization, 461-462has-a relationships, 469-471, 474as influence of Service

Composability, 391as influence of service-

orientation, 97inheritance, 166

comparison of object-orientationand service-orientation,459-460


service granularity and, 473interfaces

compared to service contracts,456-457

compared to WSDL portType andinterface elements, 456


measuring service statelessness, 342

is-a relationships, 459is-a-kind-of relationships, 461

OCP, 465polymorphism, 463-464reuse and, 257RPC, 448service-orientation compared, 97,

446-475common goals, 449-452design principles, 457-472fundamental concepts, 453-457

specialization, 461-462SRP, 466-468sub-classes, 459, 461, 463super-classes, 459uses-a relationships, 469, 471, 474

object-oriented design principles,compared to service-orientationdesign principles, 457-458, 460-471

objectscompared to services, 453as containers, 458

OCP (OOAD), 465ODBC, 166ontologies, 52OOAD (object-oriented analysis and

design). See object-orientationopen access (access control level),

233, 487open source software, meta abstraction

types in, 227-228open-closed principle. See OCPoptimized contract abstrction level,

232, 487orchestrated task services

coupling and, 197defined, 45Service Abstraction principle, 239Service Autonomy and, 313-314

Index 553

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 553

Service Composability and,430, 432

Service Statelessness and, 347orchestration. See orchestracted task

services; WS-BPELorchestration services. See orchestrated

task servicesorganizational agility

agile development versus, 63project delivery timelines and, 64responsiveness and, 63Service Abstraction principle

support for, 506service compositions and, 64Service Loose Coupling principle

support for, 506Service Reusability principle

support for, 64, 506service-orientation and, 63in service-oriented computing,

63-64organizational culture. See cultural

issuesorganizational roles, 488-490

enterprise architects, 494-495enterprise design standards

custodians, 495policy custodians, 493schema custodians, 492service analysts, 491service architects, 491service custodians, 492service registry custodians, 493-494technical communications

specialists, 494origins

of autonomy, 295of composition, 390-392of coupling, 165-166

of discovery, 367-368of information hiding, 213of reuse, 257-258of service-orientation, 96-99

AOP (aspect-orientedprogramming), 99

BPM (business processmanagement), 98

EAI (enterprise applicationintegration), 98-99

object-orientation, 97Web services, 98

of service contracts, 127-129of state management, 328-331

overestimating service usagerequirements, 318

P

paradigm. See design paradigmparameters in policy assertions, 138parent process coupling, 180partially deferred memory, 340-341partially deferred state management,

341-342partially isolated services, 306-308passive state (state management), 335pattern languages. See design pattern

languagespatterns. See design patternsperformance

data transformation, 140schema coupling and, 202Service Composability design

risks, 437-438service loose coupling, 201-202state management and, 334

Plain Old XML. See POXplanned reuse, measures of, 265-266

554 Index

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 554

point-to-point data exchanges,explained, 80, 405-406

policies, 48, 137-139, 274, 493centralization and, 138contract-to-logic coupling, 179editors, 152processors, 138Service Abstraction and, 238service consumer dependencies

and, 138service profiles and, 483structural standards, 139

policy alternatives, 378policy assertions, 146, 493

centralization, 138-139modularization, 138-139nested policy assertions, 138parameters, 138proprietary vocabularies for

discoverability, 378Service Discoverability and, 378structural design, 139structural standards and, 139vocabularies for, 137-138

policy custodians (role), 493policy parameters, 378policy vocabularies, 493polymorphism (OOAD), 463-464portType element, 456positive types of coupling, 193, 195post-implementation application of

service discoverability, 381poster Web site, 16, 534POX (Plain Old XML), 50Prentice Hall Service-Oriented Computing

Series from Thomas Erl, 4, 111, 284,495, 531

Web site, 16, 533

primitive compositions, 406, 487primitive service activities, 402, 405principle profiles

explained, 109-110Service Abstraction, 214-217Service Autonomy, 296-297Service Composability, 392,

395-396Service Discoverability, 368, 370Service Loose Coupling, 167, 169service profiles versus, 110Service Reusability, 259-261Service Statelessness, 331-332, 334Standardized Service Contract,

130-132principles. See design principlesprivacy concerns, Service Abstraction

principle, 243process services. See orchestrated task

servicesprocess-specific services, service

contracts for, 144processes

bottom-up, 518-519choosing, 521-522discovery, 363-367interpretation, 364-367inventory analysis cycle, 520-521service delivery, 518, 521-528service modeling, 105-106, 523service-oriented analysis,

105-106, 521service-oriented design, 106-107SOA delivery, 518, 521-528top-down, 518-519

productivity, as goal of object-orientation, 450, 452

profiles. See principle profiles; serviceprofiles

Index 555

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 555

programmatic logic abstraction,222-223, 226, 486

proprietary assertion vocabularies, 378proprietary vocabularies, 137-138proxies, 128pure autonomy, 308-310, 317, 488Purpose Description (service profile

field), 481

Q

QoS Requirements (service profilefield), 481

quality of service abstraction, 224,226, 486

quality of service meta information,374, 486

abstraction levels and, 234example of, 386

R

reduced IT burden, as supported byService Composability principle, 509

reduced statefulness, 340-341redundancy

avoidance of, 64, 465-466reducing, 83in silo-based applications, 78in traditional solution delivery,

78-79registries. See service registriesregulatory presence, 241regulatory principles, 111-114reliability, 317

Service Reusability design risks, 286

repository versus registry, 367REST (Representational State

Transfer), 50

return on investment. See ROIreusability, 69. See also Service

Reusability (principle)as goal of object-orientation,

450, 452level required, 90reuse versus, 256

reusable components (StandardizedService Contract principle), 129

reuse, 62-63, 69, 82, 90. See also ServiceReusability (principle)

explained in abstract, 254-256governance rigidity and, 438origins of, 257-258reusability versus, 256traditional approaches, 258traditional problems with, 257-258Web services and, 258

riskswith consumer-to-contract

coupling, 214of gold-plating, 267Service Abstraction design, 242

human misjudgment, 242-243multi-consumer coupling

requirements, 242security and privacy

concerns, 243Service Autonomy design

functional scope, 317overestimating service usage

requirements, 318wrapper services, 318

Service Composability designgovernance rigidity, 438performance limitations,

437-438single points of failure, 437

556 Index

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 556

Service Contract design, 149development tool deficiencies,

151-152technology dependencies, 150versioning, 149-150

Service Discoverability designcommunication limitations,

381-382post-implementation

application, 381Service Loose Coupling design,

200logic-to-contract coupling,

200-201performance problems, 201-202

Service Reusability design, 281agile delivery, 287commercial design, 286-287governance structure, 283-285organizational culture, 281-283reliability, 286security, 286

Service Statelessness designarchitecture dependency, 349-

350runtime performance, 350underestimating effort

requirements, 350robustness, as goal of object-

orientation, 450-451ROI (return on investment)

Service Composability principlesupport for, 505

Service Discoverability principlesupport for, 505

Service Statelessness principlesupport for, 505

in service-oriented computing,61-62

roles. See organizational rolesRPC, 150, 448, 455RPC-style messages, 117runtime autonomy, 486

explained, 298normalization design patterns, 305service contracts and, 301-305

runtime discovery, 371-373, 486runtime performance (Service

Statelessness design risks), 350

S

scalability, 326, 333, 340, 348Schema Centralization design pattern,

135-137, 531schema custodians (role), 492scope

of analysis, defining, 522comparison of object-orientation

and service-orientation, 447second-generation Web services

platform, 47. See also Web servicessecurity

Service Abstraction principle, 243Service Reusability design

risks, 286separation of concerns, 70

in relation to service compositions, 390

Service Abstraction (principle), 72, 212-251, 402

application level terminology, 487associated terminology, 486in case study, 244-252commercial product design

and, 214

Index 557

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 557

compared to abstraction (OOAD), 463

considerations when designingservice-oriented classes, 473

constraint granularity and, 239consumer coupling and, 192contribution to realizing

organizational agility, 506design principles, relationship

with, 239-241design risks, 242

human misjudgment, 242-243multi-consumer coupling

requirements, 242security and privacy

concerns, 243effect on other design principles,

239-241encapsulation versus, 235-237explained, 212goals, 215impact on composition design

process, 418implementation requirements, 216interoperability and, 74measuring, 231

access control abstraction levels,232-234

contract content abstractionlevels, 231-232

quality of service metainformation, 234

meta abstraction types, 218-219in commercial software, 227in custom-developed software,

228-229functional abstraction, 221-222in open source software, 227-228programmatic logic abstraction,

222-223

quality of service abstraction, 224

technology informationabstraction, 219-221

Web service design and, 225-226in Web services, 229-230

non-technical contract documentsand, 237-238

origins of, 213policies and, 238policy assertions, 238principle profile, 214-217Service Autonomy and, 316Service Composability and, 241,

433-435Service Discoverability and,

241, 379service granularity and, 238-239Service Loose Coupling and, 114,

198, 241service models and, 239Service Reusability and, 241, 279Standardized Service Contract

principle and, 146, 240Web services and, 50WS-Policy definitions, 238

service activities, explained,402-403, 487

service adapters, 142, 174, 213service agents, 114

in message processing logic, 48service analysts (role), 491service architects (role), 491Service Autonomy (principle), 72, 276,

294-323application level terminology, 488associated terminology, 486in case study, 319-323composition autonomy and, 430

558 Index

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 558

considerations when designingservice-oriented classes, 473

coupling and, 178design principles, relationship

with, 314-317design risks

functional scope, 317overestimating service usage

requirements, 318wrapper services, 318

design-time autonomy, explained,298-299

effect on other design principles,314-317

explained, 294-295interoperability and, 74measuring, 300-301

mixed autonomy, 310pure autonomy, 308-310service contract autonomy,

301-305service logic autonomy, 306-308shared autonomy, 305-306

origins of, 295principle profile, 296-297runtime autonomy, explained, 298scalability, 261Service Abstraction and, 316Service Composability and, 317,

435-436service contracts, 301-305service granularity and, 311-312Service Loose Coupling and, 178,

199, 315-316service models and, 105, 311-314,

525Service Reusability and, 280, 316Service Statelessness and, 316, 348service-oriented analysis processes

and, 105

Standardized Service Contractand, 301-305, 315

service candidates, 269, 276. See alsoservice modeling

explained, 52Service Discoverability and, 377service inventory blueprint

definition, 520service modeling and, 52service-oriented design and, 53services versus, 52

service capabilitiescomposition design support,

assessment for, 422composition governance support,

assessment for, 426composition runtime support,

assessment for, 424explained, 115granularity and, 116operations and methods

versus, 115service capability candidates, 523, 525.

See also service candidatesservice catalogs, service profiles

and, 483Service Composability (principle), 73,

388-441. See also composition(OOAD)

associated terminology, 487in case study, 439-441composition autonomy and, 430composition controllers, explained,

398-401composition initiators, explained,

403-405composition members, explained,

398-401considerations when designing

service-oriented classes, 473-474

Index 559

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 559

consumer coupling and, 191contract-to-implementation

coupling and, 200contract-to-logic coupling and, 199contract-to-technology coupling

and, 199contribution to realizing reduced

IT burden, 509contribution to realizing ROI, 505design principles, relationship


governance rigidity, 438performance limitations, 437-

438single points of failure, 437


explained, 388interoperability and, 75measuring, 412

checklists, 419-420, 426-427design phase assessment,

413, 415governance phase assessment,

417, 419lifecycle phases, 412-413runtime phase assessment,

415, 417orchestration and, 430, 432point-to-point data exchanges,

explained, 405-406principle profile, 392, 395-396Service Abstraction and, 241,

433-435service activities, explained,

402-403Service Autonomy and, 317,

435-436

service composition instances,explained, 397

service compositionscapabilities, 399-400explained, 397

Service Discoverability and,380, 436

service granularity and, 427-428Service Loose Coupling and,

199-200, 433service models and, 428-430Service Reusability and, 280, 435Service Statelessness and, 436Standardized Service Contract

and, 148, 432Web service region of influence,

395-396Web services and, 50, 401

service composition candidates, 523service composition instances,

explained, 397service composition references, 63service compositions, 82

agnostic services, 62applications versus, 91-92architecture of, 95-96autonomy and, 298, 314capabilities, 399-400compared to applications and

integrated applications, 94-95complex service compositions, 407

characteristics of, 410-411preparation for, 411service inventory evolution, 407,

409-410composition autonomy, 430consumer coupling and, 191defined, 39design assessment, 413

560 Index

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 560

evolutionary cycles, 412-413design phase, 413governance phase, 413runtime phase, 413

explained, 39-40, 94-95,388-390, 397

governance assessment, 417governance considerations, 438hidden, 434implementation, 42integrated applications versus,

92-94naming, 96origins of, 390-392as related to service

inventories, 407relationship with service-oriented

computing elements, 40roles

composition controllers, 398-399composition initiators, 403-404composition members, 398-399designated controllers, 400examples of, 404-405

runtime assessment, 415, 417scope of, 405-406service contracts and, 148state management and, 340types of, 406

service consumers, 48-49as composition initiators and

controllers, 404coupling and, 167coupling types, 181-182

consumer-to-contract coupling,185-191

consumer-to-implementationcoupling, 182, 184

Contract Centralization designpattern, 185

measuring consumer coupling,191-192

policy dependencies, 138service contract autonomy, 301-305, 488service contracts, 126, 393. See also

Standardized Service Contracts(principle)

APIs and, 129auto-generation, 54, 152in client-service applications, 128content abstraction levels, 231-232data models and, 134-137defined, 126denormalization and, 301-305dependencies on, 165design-time autonomy and,

301-305discoverability, 364-367in distributed applications, 128explained, 126-127interpretability, 364-367naming conventions, 133non-technical contract documents,

Service Abstraction and, 237-238normalization and, 301-305runtime autonomy and, 301-305Service Autonomy and, 301-305service compositions and, 148technical versus non-technical, 127validation coupling and, 190-191versions, 150Web services architecture, 48

service coupling. See couplingservice custodians (role), 492service description documents,

explained, 126service design

capability granularity and, 116

Index 561

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 561

constraint granularity and, 117-118data granularity and, 116formal processes, design principles

in, 106-107granularity levels, 118granularity types, 118normalization and, 65separation of concerns and, 70service granularity and, 116Service Reusability principle

design principles, relationshipwith, 278, 280-281

service granularity, 277-278service models, 276-278

service-orientation principles and,106-107

Service Discoverability (principle), 73,243, 272, 276, 362-386. See alsodiscovery

associated terminology, 486in case study, 382-386contribution to realizing ROI, 505design principles, relationship


communication limitations,381-382

post-implementation application, 381

discovery types, design-time andruntime discovery, 371-373


explained, 362-364implementation requirements, 370interoperability and, 75measuring

baseline measures checklist,375-376

custom measures, 376

meta information types, 373functional meta data, 374quality of service meta data, 374

policy assertions and, 378principle profile, 368, 370Service Abstraction and, 241, 379Service Composability and,

380, 436service granularity and, 378Service Loose Coupling and, 199service modeling and, 106,

377-378, 525Service Reusability and, 280, 380service-oriented analysis processes

and, 106Standardized Service Contract

and, 147-148, 379support for service capability

composition design process, 426Web service region of

influence, 370service encapsulation, 235-237, 306service enterprise models. See service

inventory blueprintsservice granularity, 486

cohesion and, 467coupling and, 195-196explained, 116functional context and, 116inheritance (OOAD) and, 473Service Abstraction and, 238-239Service Autonomy and, 311-312Service Composability and,

427-428Service Discoverability and, 378Service Reusability, 277-278Service Statelessness and, 346standardization of service

contracts, 142-144

562 Index

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 562

service instances, 344-346Service Statelessness and, 344-346

service inventory. See also serviceinventory blueprints

analysis process, 521defined, 40delivery processes, 520-521evolutionary stages, 407, 409-410modeling, 520-521example of, 270explained, 40implementation, 42as related to service

compositions, 407relationship with service-oriented

computing elements, 41service inventory blueprints, 53, 313,

320. See also service inventoryarchitecture definition, 520case study, 66defining, 520explained, 51-52selecting processes, 521Service Reusability, 269-270

service inventory models. See serviceinventory blueprints

service layers, 60, 82service level agreement. See SLAservice logic autonomy, 306-308, 488Service Loose Coupling (principle), 71,

164-209, 299. See also couplingassociated terminology, 486association with Service

Autonomy principle, 299capability granularity and, 195-196considerations when designing

service-oriented classes, 473constraint granularity and, 195-196contribution to realizing

organizational agility, 506

data granularity and, 195-196effect on other design principles,

197-200interoperability and, 74performance, 202principle profile, 167, 169Service Abstraction principle and,

114, 198, 241Service Autonomy and, 178, 199,

315-316Service Composability and,

199-200, 433Service Discoverability principle

and, 199Service Reusability and, 199, 279Standardized Service Contract

principle and, 145-146, 173, 198technology abstraction and, 221Web services and, 50

service methods, explained, 115service modeling, 60, 522-525. See also

service-oriented analysisalternative terms for, 485business analysists and, 53business-centric, 45classification, 485coupling and, 196-197entity services, 44explained, 43-46, 52non-business-centric, 46orchestrated task services, 45process, 523Service Abstraction and, 239Service Autonomy and, 105,

311-314, 525service candidates, 52Service Composability and,

428-430Service Discoverability and, 106,

377-378, 525

Index 563

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 563

Service Reusability and, 105,276-278, 525

Service Statelessness and, 346-347service-orientation principles and,

105-106service-oriented design processes

and, 526-527standardization of service

contracts, 144task services, 44-45technology architects and, 53utility services, 46wrapper service model, 306

Service Normalization design pattern,272, 305, 465, 531


service operations, explained, 115service policies, standardization of,

137-139service profiles, 155

capability profiles, structure of,481-482

case study, 155, 157customizing, 482example of, 383-386explained, 478-479policies and, 483principle profiles versus, 110service catalogs and, 483service registries and, 482structure of, 480

service providers, 48-49service registries

explained, 366service profiles and, 482

service registry custodians (role),493-494

Service Reusability (principle), 62, 72,

254-292, 343, 393, 465, 468agnostic services, 268-269application level terminology, 487in case study, 288-292contribution to realizing

organizational agility, 506cultural issues, 281-283design principles, relationship

with, 278, 280-281design risks, 281

agile delivery, 287commercial design, 286-287governance structure, 283-285organizational culture, 281-283reliability, 286security, 286

Domain Inventory design patternand, 275


explained, 254governance issues, 283-285interoperability and, 74Logic Centralization design

patternContract Centralization and,

272-273difficulty in achieving, 274-275as enterprise design

standard, 272explained, 271Web services and, 274

measuring, 262-263in analysis/design phase,

265-266commercial design approach,

262, 264-265gold-plating, 267in implementation phase, 267

principle profile, 259-261

564 Index

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 564

reduced IT burden, 64Service Abstraction and, 241, 279Service Autonomy and, 280, 316Service Composability and,

280, 435service contracts and, 147Service Discoverability and,

280, 380service granularity, 277-278service inventory blueprints,

269-270Service Loose Coupling and,

199, 279service modeling and, 105,

276-278, 525Service Statelessness and, 280, 348service-oriented analysis processes

and, 105Standardized Service Contract

and, 147, 278Web services and, 50

Service Statelessness (principle), 73,326-359. See also state management

in case study, 351-359considerations when designing

service-oriented classes, 473contribution to realizing ROI, 505design principles, relationship


architecture dependency, 349-350

runtime performance, 350underestimating effort

requirements, 350effect on other design principles,

347-349explained, 326granularity and, 346interoperability and, 74

measuring, 339fully deferred state management,

342-343internally deferred state

management, 342non-deferred state

management, 340partially deferred memory,

340-341partially deferred state

management, 341-342messaging as deferral option,

343-344principle profile, 331-332, 334scalability, 261Service Autonomy and, 316, 348Service Composability and, 436service instances and, 344-346service models and, 346-347Service Reusability and, 280, 348state, types of, 335

active, 335business data, 338context data, 337-338passive, 335session data, 336-337stateful, 336stateless, 336

state deferralexplained, 329messaging as, 343-344state delegation versus, 331

state delegationexplained, 329state deferral versus, 331

state managementin client-server architectures, 328databases and, 329, 331,

339-343in distributed architectures,

329, 331

Index 565

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 565

explained, 327-328origins of, 328-331performance and, 334service compositions and, 340SOAP attachments and, 334

service symbol, explained, 13, 15-16service-orientation

advantages of, 81-84applications and, 82, 91-92applications versus service

compositions, 91-92challenges introduced by, 85-88comparison with object-

orientation, 446-475counter-agile delivery and, 87coupling types and, 193-195defined, 39design characteristics, importance

of, 69as design paradigm, 30, 70-71design standards and, 86, 89evolution of, 89explained, 68-101governance demands, 88integration and, 84, 92-94interoperability and, 74-75, 84meta abstraction types in, 229-230object-orientation compared, 97,

446-449common goals, 449-452design principles, 457-472fundamental concepts, 453-457

origins of, 96-99AOP (aspect-oriented

programming), 99BPM (business process

management), 98EAI (enterprise application

integration), 98-99

object-orientation, 97Web services, 98

problems solved by, 75-84relationship with service-oriented

computing elements, 40reusability, level required, 90service compositions, explained,

94-95standardization and, 89technology architectures and, 95-96top-down delivery, 86-87

service-orientation principles. See alsodesign principles

service modeling processes and,105-106

service-oriented analysis processesand, 105-106

service-oriented design processesand, 106-107

service-oriented analysis, 60, 522-523.See also service modeling

business analysts and, 53design principles in, 105-106explained, 52-53process, 521service-orientation principles and,

105-106technology architects and, 53

service-oriented architecture. See SOAService-Oriented Architecture: A Field

Guide to Integrating XML and WebServices, 492

Service-Oriented Architecture: Concepts,Technology, and Design, 5, 100, 432,518

service-oriented classes, designing,472-474

service-oriented computingelements, 37-42explained, 37-54goals and benefits, 55-56

566 Index

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 566

business and technology domainalignment, 61

design principles, relationshipwith, 498-499

increased business andtechnology domain alignment,60-61

increased federation, 58-59increased intrinsic

interoperability, 56-57increased organizational agility,

63-64increased ROI, 61-62increased vendor

diversification, 59reduced IT burden, 64-65as related to service-orientation

principles, 104-105relationships between, 56vendor diversification, 59-60

governance, 88implementation, 41-42relationships among elements,

40-42service compositions and, 39-40service inventory and, 40service inventory blueprints and,

51-52service models and, 43-46service-oriented analysis and,

52-53service-oriented design and, 53-54services and, 39SOA and, 38, 56terminology, 484-485vision, 55Web services and, 49-50

service-oriented design, 377, 521, 525,527-528

contract first design, 53, 131,173, 194

explained, 53-54Service Abstraction


encapsulation, 235-237non-technical contract

documents, 237-238service granularity and, 238-239service models and, 239

Service Autonomydesign principles, relationship

with, 314-317service granularity and, 311-312service models and, 311-314

Service Composabilitycomposition autonomy and, 430design principles, relationship

with, 432-436orchestration and, 430, 432service granularity and, 427-428service models and, 428-430

Service Contractsdata transformation, avoiding,

140-142service granularity, 142-144service models, 144

Service Discoverabilitydesign principles, relationship

with, 378-380policy assertions and, 378service granularity and, 378service models and, 377-378

service models and, 526-527Service Statelessness


Index 567

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 567

granularity and, 346messaging as deferral option,

343-344service instances and, 344-346service models and, 346-347

service-orientation principles and,106-107

service-oriented solution logicdefined, 39implementation, 42relationship with service-oriented

computing elements, 40service-to-consumer coupling, 180services

agnostic, 62, 82, 91business-centric, 45in case study, 154as collections of capabilities, 69-70communications quality, 365as components, 176-177as containers, 70counter-agile delivery of, 87defined, 39dependencies between, 165discoverability, 364-367explained, 39, 68-69as federated endpoints, 58functional context, 70implementation, 42, 47interoperability, 84interpretability, 364-367as IT assets, 62non-business-centric, 46normalized, 65, 83ownership, 88real-world analogy, 68-70relationship with service-oriented

computing elements, 40reusable versus agnostic, 268-269

reuse. See reuse; ServiceReusability (principle)

ROI, 62roles

service consumers, 48-49service providers, 48-49

scalability, 326, 333, 340, 348service candidates versus, 52standardization of, 89symbols for, 39usage requirements, 318Web services versus, 49

session data (state management),336-337

shared autonomy, 305-306, 488silo-based applications, 92

advantages of, 76-78counter-federation and, 80disadvantages of, 78-81integration and, 81redundancy, 78

Simple Object Access Protocol. SeeSOAP

single responsibility principle. See SRPsingle-purpose programs, 255SLA (service level agreement), 152-153,

237-238, 249, 382, 386, 483SOA (service-oriented architecture), 5.

See also service-oriented computingexplained, 38goals and benefits, 498-499governance, 88relationship with service-oriented

computing elements, 40scalability, 326, 333, 340, 348service-oriented computing

versus, 56vendor diversified, 60vendor-agnostic, 60

568 Index

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 568

vision, 55Web services and, 46-51

architecture, 48-49standards, 47-48

SOA: Design Patterns, 4, 31-32, 111, 122,150, 474, 515, 530-531

The SOA Magazine Web site, 533SOAP (Simple Object Access

Protocol), 47attachments, 334, 344headers, 337-338, 344-346, 410processors, 334

software composition. See composition(OOAD)

specialization (OOAD), 461-462SRP (OOAD), 466-468standardization. See also standards

functional expression, 147of service contracts

data representation, 134-137,140-142, 155


functional service expression,133-134, 155

service granularity, 142-144service models, 144service policies, 137-139

of vocabularies, 484Standardized Service Contract

(principle), 71, 464agnostic service contracts and, 144capability granularity, 143case study, 154-161considerations when designing

service-oriented classes, 473constraint granularity, 143coupling types, 169-173

consumer-to-contract coupling,185-191, 214, 473, 486

contract-to-functional coupling, 180

contract-to-implementationcoupling, 177-179

contract-to-logic coupling,174-175

contract-to-technology coupling,176-177

logic-to-contract coupling,173-174

data granularity, 143design risks, 149

development tool deficiencies,151-152

technology dependencies, 150versioning, 149-150

design standards and, 132effect on other design principles,

144-148functional meta data, 374origins of, 127-129interoperability and, 74naming conventions, 147non-agnostic service contracts

and, 144non-technical service contracts,

152-153principle profile, 130-132Service Abstraction and, 146, 240Service Autonomy and,

301-305, 315Service Composability and,

148, 432Service Discoverability and,

147-148, 379Service Loose Coupling and,

145-146, 173, 198service models and, 144Service Reusability and, 147, 278

Index 569

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 569

standardization typesdata representation, 134-137,

140-142, 155design principles, relationship

with, 144-148functional service expression,

133-134, 155service granularity, 142-144service models, 144service policies, 137-139

transformation and, 140-142Web services and, 50

standards. See also design standards;standardization

SOA, 5-6Web services standards, 47-48www.soaspecs.com Web site, 50

state, types of, 335active, 335business data, 338context data, 337-338passive, 335session data, 336-337stateful, 336stateless, 336

state data management. See statemanagement

state databases, 329, 331state deferral

explained, 329messaging as, 343-344state delegation versus, 331

state delegationexplained, 329state deferral versus, 331

state management. See also ServiceStatelessness (principle)

in client-server architectures, 328databases and, 329, 331, 339-343

in distributed architectures,329, 331

explained, 327-328origins of, 328-331performance and, 334service compositions and, 340SOAP attachments and, 334state deferral and state delegation,

329, 331state types, 335

active, 335business data, 338context data, 337-338passive, 335session data, 336-337stateful, 336stateless, 336

stateful state (state management), 336stateless state (state management), 336statelessness. See Service Statelessness

(principle)static business process definition,

explained, 397Status (service profile field), 482sub-classes (OOAD), 459, 461, 463sub-controllers, explained, 398, 429super-classes (OOAD), 459symbols

color in, 13conflict symbol, 13coupling, 165legend, 13service symbol, 13, 15-16, 39

T

tactical reusability, 487measuring, 265

targeted functional coupling, 180targeted reusability, 487

measuring, 266

570 Index

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 570

targeted reuse, example of, 289task services, 340

coupling and, 197example of, 44explained, 44-45functional coupling and, 180Service Abstraction and, 239Service Autonomy and, 313-314service contracts, 144in service inventory, 270Service Statelessness and, 347

task-centric business services. See taskservices

technical communications specialists(role), 494

technical service contracts, explainedin abstract, 127. See also servicecontracts

technology abstractionService Loose Coupling and, 221Web services and, 221

technology and business alignment. Seebusiness and technology domainalignment in service-orientedcomputing

technology architects, role of, 53technology architecture. See

architecturetechnology coupling, Contract

Centralization design pattern,189-190

technology dependencies of servicecontracts, 150

technology information abstraction,219-221, 225, 486

technology services. See utility servicestechnology transformation, 142terminology. See vocabulariestop-down processes, 86-87, 518-519

traditional solution delivery, explained,76-81

transformation. See also datatransformation

avoidance, 135-136, 140-142design standards and, 135-136standardization and, 140-142Standardized Service Contract

principle and, 135-136, 140-142technology, 142

U

UDDI, 47, 367, 372UML (unified modeling language),

447, 453unidirectional coupling, 165Universal Description, Discovery, and

Integration. See UDDIuses-a relationships (OOAD), 469,

471, 474utility services

coupling and, 197design processes, 526explained, 46Service Abstraction and, 239Service Autonomy and, 313service contracts, 144Service Statelessness and, 347

V

Validation Abstraction design pattern,531

validation coupling, 190-191performance and, 202

validation logicconstraint granularity and, 117-118policies, 137

vendor diversification in service-oriented computing, 59-60

Version (service profile field), 482

Index 571

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 571

versioning, 260, 438service contracts and, 149-150

vocabularies, 147for design principle application

levels, 487-488for design principles, 486-487for policy assertions, 137-138service contracts, 133service models, alternative terms

for, 485service-oriented computing

terminology, 484-485standardization of, 484

W

Web Service Contract Design for SOA, 5,150, 153

Web service regions of influencecomposition members, 395designated controllers, 396functional abstraction, 225programmatic logic

abstraction, 226quality of service abstraction, 226service autonomy, 297service contracts, 131-132service discoverability, 370service loose coupling, 169service reusability, 260-261service statelessness, 334technology information

abstraction, 225Web services, 46-51

architecture, 48-49auto-generation of contracts, 54,

152, 175avoiding technology

dependencies, 150consumer-to-contract coupling

and, 186

Contract Centralization designpattern and, 190, 274

contracts, 134-137coupling and, 166design processes, 527federation via, 59first-generation platform, 47implementation coupling and, 166as implementation medium, 114as industry standards, 34as influence of service-orientation,

98, 448interface element, 456Logic Centralization and, 274logic-to-contract coupling and, 201meta abstraction types and, 225-

226, 229-230origins of reuse, 258origins of Standardized Service

Contract principle, 129policies. See policies; WS-PolicyportType element, 456reuse and, 258roles

service consumers, 48-49service providers, 48-49

Schema Centralization designpattern and, 135-137

schema custodians (role), 492second-generation platform, 47service compositions and, 401,

405-406service contracts, 127service description documents, 127service-oriented computing, 49-50services versus, 49standardization, 134-137standards, 47-48technology abstraction and, 221

572 Index

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 572

technology-to-contract couplingand, 177

validation coupling and, 190-191Web Services Business Process

Execution Language. See WS-BPELWeb Services Description Language.

See WSDLWeb services tutorials Web site, 50, 534Web sites

www.soabooks.com, 16, 531, 533www.soaglossary.com, 16, 533www.soamag.com, 17, 533www.soaposters.com, 16, 534www.soaspecs.com, 16, 338, 460,

493, 533www.thomaserl.com, 17www.ws-standards.com, 338,

432, 534www.xmlenterprise.com, 534

wrapper services, 306, 316Service Autonomy design

risks, 318WS-* extensions, 47, 395WS-Addressing, 337-338, 344-346, 373WS-AtomicTransaction, 338WS-BPEL, 197, 239, 431-432, 527WS-Coordination, 338WS-I Basic Profile, 47, 150-151WS-MetadataExchange, 372-373WS-Policy, 48, 129, 131, 483, 493WS-Policy definitions, 127, 137-139, 146,

151, 153, 274contract-to-logic coupling, 179editors, 152structural standards, 139wsp:optional attribute, 139

WS-ReliableMessaging, 137WS-ResourceTransfer (WS-RT), 338

WS-SecurityPolicy, 137WSDL (Web Services Description

Language), 47, 129, 131, 146, 174, 274WSDL definitions, 127, 175

auto-generation, 175standardization, 136XML schemas and, 136

wsp:ignorable attribute, 143, 238, 378wsp:optional attribute, 139, 143, 238,

378

X–Z

XML, 194as industry standards, 34parsers, 334

XML Schema Definition Language, 47,129, 131

XML schemas, 127, 137, 146, 174-175,274, 455

case study, 157constraint granularity

example, 117entity schemas, 136schema custodians (role), 492standardization, 136validation coupling and, 190-191WSDL definitions and, 136

XML tutorials Web site, 534XSD. See XML Schema Definition

Language; XML schemasXSLT, 140

Index 573

27_0132344823_Index.qxd 6/14/07 1:17 PM Page 573

27 0132344823 Index.qxd 6/14/07 1:17 PM Page 539...

Documents

Transcript of 27 0132344823 Index.qxd 6/14/07 1:17 PM Page 539...