This document outlines principles and patterns for service-oriented architecture (SOA) design. It begins with an introduction and agenda, then covers service fundamentals like loose coupling and statelessness. Major sections discuss service design principles like autonomy and standardized contracts, inventory design patterns like normalization and layers, individual service design patterns like agnostic capabilities and messaging, and composition design patterns like routing and security. The goal is to discover principles for effective service-oriented design and how patterns support those principles.
5. SOA appliance example
Joint Company
Company 1
Company 2
Customer
Supplier
o getGoods
Company 3
Manufacturer
o createOrder
o getInvoice
o setInvoice
o supplyGoods
Bank
Bank
o settle
•
•
•
Business tasks
Different owners of services
Sessions over Internet
4
4
7. SOA Definition
Service Oriented Architecture (SOA) is a paradigm for
organizing and utilizing distributed capabilities that may
be under the control of different ownership domains.
OASIS
6
9. SOA Capability
“Capability” vs. “Operation”
vs. “Method”
– A service capability represents a
specific function of a service through
which the service can be invoked
– A service operation specifically
refers to a capability within a service
that is implemented as a Web
service
– A service method represents a
capability that is part of a service
that exists as a component.
Service
8
12. Standardized Service Contract
Services within the same service inventory are in compliance
with the same contract design standards
Service contract:
– Interface definition
• operations
• data types
– Behavior attributes
• policy assertions
– SLA
11
13. Abstraction
Hide information about a service not absolutely required for
others to effectively use it.
• Information about services is
limited to service contracts
• Service contracts are
abstracted to contain only
essential information
12
14. Standardized Service Contract
•
design standard for all contracts
•
Introduce formal process of design
•
“contract first” approach to service-oriented design
•
high level of proficiency with XML schema, WSDL
and WS-* stack
13
15. Loose Coupling
Service contracts impose low consumer coupling
requirements
• Coupling types:
– to implementation of service
logic
– to resources of the
implementation environment
– to vendor technology
– to parent business-process
– to service composition
members
14
16. Loose Coupling (consumer-to-contract)
Consumer program must call contract only
Coupling types:
• to implementation of
service logic
• to resources of the
implementation
environment
• to vendor technology
15
17. Autonomy
Freedom and control to make own decisions without the
need for external approval or involvement
• Control over underlying runtime
execution environment
• Gradual transformation
– Reducing shared resources access
– Increasing physical isolation
16
18. Statelessness
Reduce system resource consumption due to unnecessary state
management processing.
• Types of state
– Session
– Context
– Business data
• Maximize service scalability
• State management deferral
– Repository
– Messages
• Empowers composition and
reuse
17
19. Discoverability
Purpose and capabilities of service are easily discovered
and understood.
• Services are supplemented
with meta- data
– Functional
– Quality of Service
• Service Repository for effective
discovery and interpretation
• Service Registry for
effective run-time discovery
and binding
18
20. Reusability
Services are easily reused and recomposed.
• Inventory of reusable enterprise
resources
• Defined by an agnostic functional
context
• The service logic is highly generic
• Solid version control system
• The service logic can be accessed
concurrently
Reusability – key to achieving high ROI
19
25. Enterprise Inventory, Domain Inventory
How can services be delivered to maximize recomposition,
reuse, discoverability?
Services for multiple
solutions are designed within
a standardized, enterprisewide inventory
Domain inventory - domain-specific inventory where services
• Standardized
• Governed
• Managed.
24
26. Service Normalization, Logic Centralization
How can a service inventory avoid redundant service logic?
Normalization:
- Service-Oriented Analysis
- service boundary alignment
- defined how to: add, change,
remove service in the
inventory
Centralization:
- access to reusable functionality is limited to official agnostic services
25
27. Service Layers
How can the services in an inventory be organized based
on functional commonality?
The inventory is structured into two or
more logical service layers for abstracting
logic based on a common functional type.
Layering by Thomas Erl:
Task Layer – charge customer
Entity Layer – account
Utility Layer – validate credit card number
26
28. Centralization patterns
Policy Centralization
• policy assertions are isolated and applied to multiple services.
Contract Centralization:
• access to service logic is limited to the service contract
Metadata Centralization:
• Service metadata is published in a central registry
Rules Centralization
• storage and management of business rules must be centralized.
27
30. Service-Oriented Analysis and Design
Define Analysis Scope
Identify Affected
Systems
Perform Service
Modeling
Process result is a Service Candidate that is input for
Service-Oriented Design
29
31. Service Identification
Functional Decomposition
• Large business problem is broken
down in to a set a smaller ones
Service Encapsulation
• Logic encapsulated as service is an
enterprise wide resource accessible for
reuse
30
32. Agnostic/Non Agnostic Context
Multi-purpose logic grouped together with single purpose
logic results in programs with little or no reuse potential
Isolate logic that is not specific to one purpose into separate services
High reuse
Low redundancy
o Design complexity
o Governance issues
Non-agnostic logic can be located within official services but it’s not
required
31
33. Agnostic Capability
How can multipurpose service logic be made effectively
consumable and composable?
Agnostic service capabilities address common concerns not specific
to any one problem.
32
34. State Management
How can services state data be persisted and managed
without consuming service runtime resources?
Approaches:
•
•
•
Intentionally stateful utility services
Partial state deferral
Shared state repository (temporary cache)
•
Dedicated state repository with regular
replication to central storage
Scaling:
•
Grid technology(e.g. in-memory grids)
33
36. Service contract
• What service does
• How service can be accessed
• Where service can be accessed
35
37. Partial Validation, Validation Abstraction
How can unnecessary data validation be avoided?
– Validate the relevant subset of the
data and ignore the remainder
How can service contract easily adapt to
validation logic changes?
– Business rules abstraction –
business rules engines
36
38. Decoupled Contract
How can a service express its capabilities independently of
its implementation?
• contract is physically decoupled from its implementation.
• contract first approach
• Contract MUST NOT be generated at runtime
37
39. Canonical Expression
How can service contracts be consistently understood and
interpreted?
Naming conventions:
• canonical namespaces : http://<globally unique namespace root>/<domain
name>/ WSDL/<subject>-v<minor version>
• upper-cased complex types and lower-cased elements
• capabilities canonical names : addXXX, getXXX etc.
• versioning in names
• <wsdl:service> must include "Service" into name: e.g:
"IncidentRegistrationService_v1_0"
38
40. Canonical Schema, Schema centralization
How can services be designed to avoid data model
transformation?
Schemas are shared across multiple
contracts:
- introduce data models for common
information sets
- apply design standards
- Service-Oriented Analysis
Examples: ISO 20022, HL7 etc.
39
41. Canonical Versioning
How can service contracts within the same service
inventory be versioned with minimal impact?
Versioning standard:
• Version Identifiers
• Versioning strategy
• Contract lifecycle
• introduction
• change process
• decommission
40
42. Version Identification
How can consumers be made aware of service
contract version information?
Major/Minor Versioning:
• A major change - incompatible change
• A minor change - compatible change
Versioning information is expressed as part of the service contract –
WSDL, XSD, Policy.
Versioning objects:
• Namespaces
• Artifact names
• Endpoint names, etc.
41
43. Compatible/Incompatible Change
Some changes to the service contract can be backwards or
forward compatible, thereby avoiding negative consumer
impacts
Backwards compatibility:
WSDL - adding operation
XSD – adding optional element
Policy - adding optional assertion
Forwards compatibility:
XSD – using wildcards(xsd:any, xsd:anyAttribute)
42
44. Versioning Strategy
Strict(new change, new contract)
Any compatible or incompatible changes result in a new version of the
service contract.
Flexible(backwards compatibility)
Any incompatible change results in a new version of the service contract
Loose(backwards and forwards)
Any incompatible change results in a new version of the service contract
Strategy
Strict
Flexible
Loose
Strictness
high
medium
low
Governance
high
medium
high
Complexity
low
medium
high
43
46. Service Messaging, Messaging Metadata
How can a service interoperate without forming persistent,
tightly coupled connections?
•
Established Message Framework(MOM)
•
Designed service to use messaging middleware
•
Supplemented message with activity-specific metadata
45
47. Capability Composition
How can a service capability solve a problem that requires
logic outside of the service boundary?
Capability is designed to compose one or more capabilities in other
services
46
48. Service Agent
How can event-driven logic be separated and governed
independently?
• Authentication,
Authorization
• Logging
• Audit
• Load balancing
• Other utility logic
Service Agent has no published contract
47
49. Intermediate Routing
How can dynamic runtime factors affect the path of a
message?
• Content based routing
• Load Balancing
• Fail-over routing
(redundancy)
48
50. State Messaging
How can a service remain stateless while participating in
stateful interaction?
Approaches:
• Custom headers
• WS-Addressing extension
Risks:
• Lost message - Lost State
• Privacy of state data is under jeopardy
• Bandwidth extension
49
52. Service Interaction Security
• Data Origin Authentication
– Digital Signature
• XML Signature (WS-Security)
– Non-Repudiation
• Authentication
– Direct authentication
• Shared secret
– Brokered Authentication
• WS-Security and WS-Trust
(Tokens: Kerberos, X.509 PKI, SAML)
51
53. Transformation
• Data Model Transformation
– XSLT
• Data Format Transformation
• Service Agent
– CSV -> XML
– CSV -> compressed XML
• Protocol Bridging
– HTTP <-> JMS
– SOAP 1.1 <-> SOAP 1.2
– SOAP <-> XML
52
54. Sources:
•
•
•
•
•
Thomas Erl – SOA: Design patterns
Thomas Erl – SOA: Principles of Service Design
Thomas Erl – Web Service Contract Design and Versioning for SOA
www.soapatterns.com
www.soamethodology.com
• BEA White Paper – BEA’s SOA Reference Architecture
53
56. Vocabulary
• Design Principle – Design principle represents a highly
recommended guideline for shaping solution logic in a
certain way and with certain goals in mind. These goals
are usually associated with establishing one or more
specific design characteristics.
• Design pattern describes a common problem and
provides a corresponding solution
55
Notas do Editor
Standardized Service Contract – “Services within the same service inventory are incompliance with the same contract design standards.”• Service Loose Coupling – “Service contracts impose low consumer coupling requirementsand are themselves decoupled from their surrounding environment.”• Service Abstraction – “Service contracts only contain essential information andinformation about services is limited to what is published in service contracts.”• Service Reusability – “Services contain and express agnostic logic and can be positionedas reusable enterprise resources.”• Service Autonomy – “Services exercise a high level of control over their underlyingruntime execution environment.”• Service Statelessness – “Services minimize resource consumption by deferring themanagement of state information when necessary.”• Service Discoverability – “Services are supplemented with communicative meta databy which they can be effectively discovered and interpreted.”• Service Composability – “Services are effective composition participants, regardlessof the size and complexity of the composition.”
Service-Oriented Analysis and Service ModelingTo effectively deliver standardized services in support of building a service inventory, itis recommended that organizations adopt a methodology specific to SOA and consistingof structured analysis and design processes.Within SOA projects, these processes are centered around the accurate expression ofbusiness logic through technology, which requires that business analysts play a moreactive role in defining the conceptual design of solution logic. This guarantees a higherdegree of alignment between the documented business models and their implementationas services. Agnostic business services especially benefit from hands-on involvementof business subject matter experts, as the improved accuracy of their businessrepresentation increases their overall longevity once deployed.Service-oriented analysis establishes a formal analysis process completed jointly by businessanalysts and technology architects. Service modeling, a sub-process of serviceorientedanalysis, produces conceptual service definitions called service candidates. Iterationsthrough the service-oriented analysis and service modeling processes result in thegradual creation of a collection of service candidates documented as part of a serviceinventory blueprint.Service-Oriented DesignThe service-oriented design process uses a set of predefined service candidates from theservice inventory blueprint as a starting point from which they are shaped into actualphysical service contracts.When carrying out service-oriented design, a clear distinction is made between servicecandidates and services. The former represents a conceptual service that has not beenimplemented, whereas the latter refers to a physical service.
Functional DecompositionProblem: To solve a large, complex business problem a correspondingamount of solution logic needs to be created, resulting in a selfcontainedapplication with traditional governance and reusability constraints.Solution: The large business problem can be broken down into a set ofsmaller, related problems, allowing the required solution logic to also bedecomposed into a corresponding set of smaller, related solution logic units.Service EncapsulationProblem: Solution logic designed for a single application environment istypically limited in its potential to interoperate with or beleveraged by other parts of an enterprise.Solution: Solution logic can be encapsulated by a service so that it ispositioned as an enterprise resource capable of functioningbeyond the boundary for which it is initially delivered.
Agnostic ContextProblem: Multi-purpose logic grouped together with single purpose logicresults in programs with little or no reuse potential thatintroduce waste and redundancy into an enterprise.Solution: Isolate logic that is not specific to one purpose into separateservices with distinct agnostic contexts.Non-Agnostic ContextProblem: Non-agnostic logic that is not service-oriented can inhibit theeffectiveness of service compositions that utilize agnosticservices.Solution: Non-agnostic solution logicsuitable for service encapsulationcan be located within services that reside as official members of aservice inventory.
State RepositoryProblem: Large amounts of state data cached to support the activity withina running service composition can consume too much memory,especially for long-running activities, thereby decreasingscalability.Solution: State data can be temporarily written to and then later retrievedfrom a dedicated state repository.Stateful ServicesProblem: State data associated with a particular service activity can imposea great deal of runtime state management responsibility uponservice compositions, thereby reducing their scalability.Solution: State data is managed and stored by intentionally stateful utilityservices.Service GridProblem: State data deferred via State Repository or Stateful Services canbe subject to performance bottlenecks and failure, especiallywhen exposed to high-usage volumes.Solution: State data is deferred to a collection of stateful system servicesthat form a grid that provides high scalability and fault tolerancethrough memory replication and redundancy and supportinginfrastructure.Partial State DeferralProblem: Service capabilities may be required to store and manage largeamounts of state data, resulting in increased memoryconsumption and reduced scalability.Solution: Even when services are required to remain stateful, a subset oftheir state data can be temporarily deferred.
The Strict Strategy (New Change, New Contract)The simplest approach to Web service contract versioning is to require that a newversion of a contract be issued whenever any kind of change is made to any part of thecontract.Pros and ConsThe benefit of this strategy is that you have full control over the evolution of the servicecontract, and because backwards and forwards compatibility are intentionally disregarded,you do not need to concern yourself with the impact of any change in particular(because all changes effectively break the contract).On the downside, by forcing a new namespace upon the contract with each change, youare guaranteeing that all existing service consumers will no longer be compatible withany new version of the contract. Consumers will only be able to continue communicatingwith the Web service while the old contract remains available alongside the new versionor until the consumers themselves are updated to conform to the new contract.The Flexible Strategy (Backwards Compatibility)A common approach used to balance practical considerations with an attempt at minimizingthe impact of changes to Web service contracts is to allow compatible changes tooccur without forcing a new contract version, while not attempting to support forwardscompatibility at allPros and ConsThe primary advantage to this approach is that it can be used to accommodate a varietyof changes while consistently retaining the contract’s backwards compatibility. However,when compatible changes are made, these changes become permanent and cannotbe reversed without introducing an incompatible change. Therefore, a governanceprocess is required during which each proposed change is evaluated so that contracts donot become overly bloated or convoluted. This is an especially important considerationfor agnostic services that are heavily reused.The Loose Strategy (Backwards and Forwards Compatibility)As with the previous two approaches, this strategy requires that incompatible changesresult in a new service contract version. The difference here is in how service contractsare initially designed.
Data ConfidentialityProblem: Within service compositions, data is often required to passthrough one or more intermediaries. Point-to-point securityprotocols, such as those frequently used at the transport-layer,may allow messages containing sensitive information to beintercepted and viewed by such intermediaries.Solution: The message contents are encrypted independently from thetransport, ensuring that only intended recipients can access theprotected data.
Data Origin AuthenticationProblem: The intermediary processing layers generally required by servicecompositions can expose sensitive data when security is limitedto point-to-point protocols, such as those used with transportlayersecurity.Solution: A message can be digitally signed so that the recipient servicescan verify that it originated from the expected consumer andthat it has not been tampered with during transit.Direct AuthenticationProblem: Some of the capabilities offered by a service may be intended forspecific groups of consumers or may involve the transmission ofsensitive data. Attackers that access this data could use it tocompromise the service or the IT enterprise itself.Solution: Service capabilities require that consumers provide credentialsthat can be authenticated against an identity store.Brokered AuthenticationProblem: Requiring the use of Direct Authentication (656) can beimpractical or even impossible when consumers and services donot trust each other or when consumers are required to accessmultiple services as part of the same runtime activity.Solution: An authentication broker with a centralized identity storeassumes the responsibility for authenticating the consumer andissuing a token that the consumer can use to access the service.