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
and, 195-196Service Reusability and, 278
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,
191-192standardized coupling and, 185technology coupling, 189-190
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 Page 543
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
and, 195-196Service Reusability and, 278
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,
191-192standardized coupling and, 185technology coupling, 189-190
Contract Denormalization, 242,305, 312
service contract autonomy and,304-305
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
comparison of object-orientationand service-orientation, 449-452
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
comparison of object-orientationand service-orientation, 459-460
designing service-oriented classes, 473
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
designing service-oriented classes, 473
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
comparison of object-orientationand service-orientation, 454-456
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
service contract autonomy and,304-305
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
designing service-orientedclasses, 474
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
designing service-orientedclasses, 473
service granularity and, 473interfaces
compared to service contracts,456-457
compared to WSDL portType andinterface elements, 456
designing service-orientedclasses, 473
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
with, 432-436design risks
governance rigidity, 438performance limitations, 437-
438single points of failure, 437
effect on other design principles,432-436
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
with, 378-380design risks
communication limitations,381-382
post-implementation application, 381
discovery types, design-time andruntime discovery, 371-373
effect on other design principles,378-380
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 contract autonomy and,302-304
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
effect on other design principles,278-281
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
with, 347-349design risks
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
design principles, relationshipwith, 239-241
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
design principles, relationshipwith, 347-349
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
design principles, relationshipwith, 144-148
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
Top Related