soa design pattern

SOA Design PatternSOA Design PatternSOA Design PatternSOA Design Pattern

2011.04.072011.04.07

ContentsContents1.1. IntroductionIntroduction

2.2. Service Inventory Design PatternsService Inventory Design Patterns

3.3. Service Composition Design PatternsService Composition Design Patterns

4.4. Service Design PatternsService Design Patterns

1. Introduction1. Introduction• The simplest way to describe a pattern is The simplest way to describe a pattern is

that it provides a proven solution to a that it provides a proven solution to a common problem individually documented common problem individually documented in a consistent format and usually as part in a consistent format and usually as part of a larger collectionof a larger collection

• A design pattern describes a common A design pattern describes a common problem and provides a corresponding problem and provides a corresponding solutionsolution

Patterns - Why ?Patterns - Why ?• Design patterns are helpful because theyDesign patterns are helpful because they1.1. represent field-tested solutions to common design problemsrepresent field-tested solutions to common design problems

2.2. organize design intelligence into a standardized and easily "referencable" formatorganize design intelligence into a standardized and easily "referencable" format

3.3. are generally repeatable by most IT professionals involved with designare generally repeatable by most IT professionals involved with design

4.4. can be used to ensure consistency in how systems are designed and builtcan be used to ensure consistency in how systems are designed and built

5.5. can become the basis for design standardscan become the basis for design standards

6.6. are usually flexible and optional (and openly document the impacts of their application are usually flexible and optional (and openly document the impacts of their application and even suggest alternative approaches)and even suggest alternative approaches)

7.7. can be used as educational aids by documenting specific aspects of system design can be used as educational aids by documenting specific aspects of system design (regardless of whether they are applied)(regardless of whether they are applied)

8.8. can sometimes be applied prior and subsequent to the implementation of a systemcan sometimes be applied prior and subsequent to the implementation of a system

9.9. can be supported via the application of other design patterns that are part of the can be supported via the application of other design patterns that are part of the same collectionsame collection

10.10. enrich the vocabulary of a given IT field because each pattern is given a meaningful enrich the vocabulary of a given IT field because each pattern is given a meaningful namename

Type of SOA patternType of SOA pattern

Service Inventory Design PatternsService Inventory Design PatternsService Composition Design PatternsService Composition Design PatternsService Design PatternsService Design Patterns

Huu Hau : 6, 7, 8Huu Hau : 6, 7, 8

Van Khanh: 9, 10, 17Van Khanh: 9, 10, 17

Lan anh : 11, 12, 13Lan anh : 11, 12, 13

Vu Doan: 14, 15, 16Vu Doan: 14, 15, 16

Doan LapDoan Lap18,19,20,2118,19,20,21

Work assignmentWork assignment

Service Inventory Design PatternsService Inventory Design PatternsService Inventory Design PatternsService Inventory Design Patterns

Chapter 6Chapter 6Chapter 6Chapter 6

Chapter 9Chapter 9Inventory Implementation PatternsInventory Implementation Patterns

Chapter 9Chapter 9Inventory Implementation PatternsInventory Implementation Patterns

Dual ProtocolsDual Protocols•Problem:

•Canonical protocol wants to use same communication for all services•It’s difficult to use single protocol

•Solution:•Services are delivered with:

•A primary level based on preferred protocol•A second level based on alternative protocol

Canonical ResourcesCanonical Resources• Problem:

• Services uses different infrastructure for same purpose inconsistent architectural dependencies• i.e. databases A, B, C

•Solution:• Use same infrastructure for same purpose•Resource implementations are different

B

AC

State RepositoryState Repository

• Problem:• Large amount of state cache data consume too much memory decrease the scalability

• Solution:• Write state data and retrieve from dedicated repository

Stateful ServicesStateful Services

• Problem:• Manage state data of some activities take so much memory

• Solution: •State data is managed stateful utility services.

Service GridService Grid

• Problem:• State Repository or Stateful Services could make performance bottlenecks and failure because of lacking volumes

• Solution:• Service grid establishes replicated instances of stateful grid services across different server machines increased scalability and reliability of state data

Inventory EndpointInventory Endpoint

• Problem:• How to expose only expected services to consumers and hide other services?

• Solution:• Abstract the relevant capabilities into an endpoint service

Cross Domain Utility LayerCross Domain Utility Layer• Problem:

• Some service inventories use same service

• It makes the unnecessary redundancy

• Solution:

• Establish a common utility service layer

Chapter 10Chapter 10Inventory Governance PatternsInventory Governance Patterns

Chapter 10Chapter 10Inventory Governance PatternsInventory Governance Patterns

Canonical ExpressionCanonical Expression• Problem:

• Services may express similar capabilities in different ways

It makes the inconsistency and risking misinterpretation

• Solution:

• Service contracts are standardized using naming conventions.

Metadata CentralizationMetadata Centralization

• Problem:

• Manage existing services in large enterprises.

• Developers will have risk to delivery existing services.

• Solution:

• Service metadata can be centrally published in a service registry

• Interpret services to determine its suitability

Canonical VersioningCanonical Versioning

• Problem:

• Service contracts within the same service inventory with different version

It makes governance problem!

• Solution:

• Make the version naming rules according to the same convention

• i.e. overarching strategy

3. Service Composition Design 3. Service Composition Design PatternsPatterns

3. Service Composition Design 3. Service Composition Design PatternsPatterns

Chapter 17Chapter 17Capability Composition PatternsCapability Composition Patterns

Chapter 17Chapter 17Capability Composition PatternsCapability Composition Patterns

Capability CompositionCapability Composition• Problem:

• A capability may need to invoke other capabilities from other services

It affects the integrity of the service context and risking service renormalizations

• Solution:

• Create a capability which composes all dependent capabilities to solve problem

• i.e. capability A in service E

Capability RecompositionCapability Recomposition• Problem:

• Using agnostic service logic to only solve a single problem is wasteful.

• Solution:

• Allow agnostic logic to be reused as part of different service aggregates to solve different problems

Canonical VersioningCanonical Versioning

• Problem:

• Service contracts within the same service inventory with different version

It makes governance problem!

• Solution:

• Make the version naming rules according to the same convention

• i.e. overarching strategy

Chapter 18Chapter 18 Service Messaging Patterns Service Messaging Patterns

Chapter 18Chapter 18 Service Messaging Patterns Service Messaging Patterns

Intermediate RoutingIntermediate Routing

• Solution:

•Message paths can be dynamically determined through the use of intermediary routing logic

• Problem:

•The larger and more complex a service composition is, the more difficult it is to anticipate and design for all possible runtime scenarios in advance, especially with asynchronous, messaging-based communication

State MessagingState Messaging

Problem: When services are required to maintain state information in memory between message exchanges with consumers, their scalability can be comprised, and they can become a performance burden on the surrounding infrastructure.

Solution:Instead of retaining the state data in memory, its storage is temporarily delegated to messages

Chapter 19Chapter 19 Composition Implementation Composition Implementation

PatternsPatterns

Chapter 19Chapter 19 Composition Implementation Composition Implementation

PatternsPatterns

Composition AutonomyComposition Autonomy

Problem: Composition controller services naturally lose autonomy when delegating processing tasks to composed services, some of whichmay be shared across multiple compositions.

Solution:All composition participants can be isolated to maximize the autonomy of the composition as a whole

Atomic Service TransactionAtomic Service Transaction

Problem: When runtime activities that span multiple services fail, the parent business task is incomplete and actions performed and changes made up to that point may compromise the integrity of the underlying solution and architecture.

Solution:Runtime service activities can be wrapped in a transaction with rollback feature that resets all actions and changes if the parent business task cannot be successfully completed

Chapter 20Chapter 20 Service Interaction Security Patterns Service Interaction Security Patterns

Chapter 20Chapter 20 Service Interaction Security Patterns Service Interaction Security Patterns

Data ConfidentialityData Confidentiality

Problem: Within service compositions, data is often required to pass through one or more intermediaries. Point-to-point security protocols, such as those frequently used at the transport-layer, may allow messages containing sensitive information to be intercepted and viewed by such intermediaries

Solution:The message contents are encrypted independently from the transport, ensuring that only intended recipients can access the protected data.

Data Format TransformationData Format TransformationProblem:How can a service verify the credentials provided by a consumer?

Solution:Service capabilities require that consumers provide credentialsthat can be authenticated against an identity store

Chapter 21Chapter 21 Transformation Patterns Transformation Patterns

Chapter 21Chapter 21 Transformation Patterns Transformation Patterns

Data Format TransformationData Format TransformationProblem: How can services interact with programs that communicate with different data formats?

Solution:Intermediary data format transformation logic needs to be introduced in order to dynamically translate one data format into another

Protocol BridgingProtocol Bridging

Problem:How can a service exchange data with consumers that use different communication protocols?

Solution:Bridging logic is introduced to enable communication betweendifferent communication protocols by dynamically convertingone protocol to another at runtime

4. Service Design Patterns4. Service Design Patterns4. Service Design Patterns4. Service Design Patterns

Chapter 11Chapter 11 Foundational Service Patterns Foundational Service Patterns

Chapter 11Chapter 11 Foundational Service Patterns Foundational Service Patterns

Functional Decomposition Functional Decomposition Problem:To solve a large, complex business problem a corresponding amount of solution logic needs to be created, resulting in a self-contained application with traditional governance and reusability constraints

Solution:The large business problem can be broken down into a set of smaller, related problems, allowing the required solution logic to also be decomposed into a corresponding set of smaller, related solution logic units

Service EncapsulationService EncapsulationProblem:Solution logic designed for a single application environment is typically limited in its potential to interoperate with or be leveraged by other parts of an enterprise

Solution:Solution logic can be encapsulated by a service so that it is positioned as an enterprise resource capable of functioning beyond the boundary for which it is initially delivered

Chapter 12Chapter 12Service Implementation PatternsService Implementation Patterns

Chapter 12Chapter 12Service Implementation PatternsService Implementation Patterns

Service FaçadeService FaçadeProblem:The coupling of the core service logic to contracts and implementation resources can inhibit its evolution and negatively impact service consumers

Solution:A service façade component is used to abstract a part of the service architecture with negative coupling potential

Redundant ImplementationRedundant ImplementationProblem:A service that is being actively reused introduces a potential single point of failure that may jeopardize the reliability of all compositions in which it participates if an unexpected error condition occurs

Solution:Multiple implementations of services with high reuse potential or providing critical functionality can be deployed to guarantee high availability and increased reliability, even when unexpected exceptions or outages occur

Chapter 13Chapter 13 Service Security Patterns Service Security Patterns

Chapter 13Chapter 13 Service Security Patterns Service Security Patterns

Exception ShieldingException Shielding

Problem:Unfiltered exception data output by a service may contain internal implementation details that can compromise the security of the service and its surrounding environment

Solution:Potentially unsafe exception data is “sanitized” by replacing it with exception data that is safe by design before it is made available to consumers.Unsafe exception-related data is “sanitized,” a process by which this information is identified and replaced with exception information that is safe by design

Message screeningMessage screeningProblem:An attacker can transmit messages with malicious or malformed content to a service, resulting in undesirable behavior

Solution:The service is equipped or supplemented with special screening routines that assume that all input data is harmful until proven otherwise

Thanks for your attentions!

soa design pattern

Documents