soa design pattern
DESCRIPTION
TRANSCRIPT
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 7Chapter 7Chapter 7Chapter 7
Chapter 8Chapter 8Chapter 8Chapter 8
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
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
Chapter 14Chapter 14Chapter 14Chapter 14
Chapter 15Chapter 15Chapter 15Chapter 15
Chapter 16Chapter 16Chapter 16Chapter 16
Thanks for your attentions!