Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Design Patterns on Service Abstraction

•Download as PPTX, PDF•
•
Md. Shafiuzzaman Hira
Md. Shafiuzzaman Hira

This document discusses four design patterns for service abstraction in SOA: 1) Capability Composition hides logic outside a service's boundary and invokes other services' capabilities. 2) Capability Recomposition uses a single capability to solve multiple problems. 3) Decomposed Capability optimizes how a service can be divided into new functional contexts over time. 4) Validation Abstraction separates a service's validation logic from its contract to more easily adapt to changes in business rules.

1 of 20
Service Abstraction SOA DESIGN PATTERNS Presented by Md. Shafiuzzaman
Service Abstraction • Hide non-essential service information
Goal of Service Abstraction • Keep contract content concise • Prevent unnecessary access to service details.
Design Characteristics of Service Abstraction • Hide specific information about technology, logic and function • Concisely define interaction requirements and constraints • Hide implantation information within a particular environment
Design Pattern –I: Capability Composition Problem: How can a service capability solve a problem that requires logic outside of the service boundary? Probable Solution: • Increase service boundary • But Fails!!  May change original context of the service  May introduce functional overlap with other services
Solution Provided by Capability Composition • Do not execute logic that resides outside of the service’s functional • Instead invoke the capability How?  Aggregate the individual capabilities of services
Design Patterns on Service Abstraction
Application • Apply throughout the service delivery lifecycle  Modeling phase: Assemble composition candidates for conceptual aggregation  Design phase: Analyse potential involvement of capabilities  Development phase: Embed distributed invocation logic within capability routines • If no service contains an external body logic • Create a new service with new capability
Limitation • For remote services impose runtime performance overhead • Reduce autonomy of a service (increase dependency on other services) • New service creation increases unexpected scope in service delivery
Design Pattern –II: Capability Recomposition Problem: • A service to solve a single problem is wasteful • How can the same capability be used to solve multiple problems?
Application • Fully dependent on successful orientation of other SOA patterns • Design a service for  Numerous scenarios  Concurrent invocation
Challenges & Limitations • Inherits collective challenges and complexities of other patterns • Amplified governance • Need a unique process for effective combination
Design Pattern –III: Decomposed Capability • Services are often extended with additional capabilities after developed or deployed • As a result  Leads to a bulky functional boundary  Difficult to govern  High reuse may leads to processing bottleneck Solution: Needs to decompose the service How can a service be designed to optimize the process of the service deconstruction?
Design Patterns on Service Abstraction
Application • It is difficult to predict how a service will be decomposed when initially defining it • Before designing a service following points need to be defined  How the current functional scope can potentially be divided?  How capabilities can be defined for new functional contexts?
Limitations • Initial service contract may be large and difficult to use • Impose performance overhead on service consumers • Service may be populated with fine-grained capabilities
Design Pattern IV: Validation Abstraction • Validation logic of a service expresses fixed terms of engagement with consumer programs • Established contract can’t be changed without releasing a new version. • So what happens when business rules or requirements change (which affects validation logic)? • New contract versions introduce governance burden • How can service contracts be designed to more easily adapt to validation logic changes?
Solution • Abstract away validation logic and rules from the service contract
Application • Depending on the nature of the message data exchange, separate validation logic • Move abstracted validation logic to a service logic or a different service
Disadvantage • Increase maintenance effort

More Related Content

Design Patterns on Service Abstraction

  • 1. Service Abstraction SOA DESIGN PATTERNS Presented by Md. Shafiuzzaman
  • 2. Service Abstraction • Hide non-essential service information
  • 3. Goal of Service Abstraction • Keep contract content concise • Prevent unnecessary access to service details.
  • 4. Design Characteristics of Service Abstraction • Hide specific information about technology, logic and function • Concisely define interaction requirements and constraints • Hide implantation information within a particular environment
  • 5. Design Pattern –I: Capability Composition Problem: How can a service capability solve a problem that requires logic outside of the service boundary? Probable Solution: • Increase service boundary • But Fails!!  May change original context of the service  May introduce functional overlap with other services
  • 6. Solution Provided by Capability Composition • Do not execute logic that resides outside of the service’s functional • Instead invoke the capability How?  Aggregate the individual capabilities of services
  • 8. Application • Apply throughout the service delivery lifecycle  Modeling phase: Assemble composition candidates for conceptual aggregation  Design phase: Analyse potential involvement of capabilities  Development phase: Embed distributed invocation logic within capability routines • If no service contains an external body logic • Create a new service with new capability
  • 9. Limitation • For remote services impose runtime performance overhead • Reduce autonomy of a service (increase dependency on other services) • New service creation increases unexpected scope in service delivery
  • 10. Design Pattern –II: Capability Recomposition Problem: • A service to solve a single problem is wasteful • How can the same capability be used to solve multiple problems?
  • 11. Application • Fully dependent on successful orientation of other SOA patterns • Design a service for  Numerous scenarios  Concurrent invocation
  • 12. Challenges & Limitations • Inherits collective challenges and complexities of other patterns • Amplified governance • Need a unique process for effective combination
  • 13. Design Pattern –III: Decomposed Capability • Services are often extended with additional capabilities after developed or deployed • As a result  Leads to a bulky functional boundary  Difficult to govern  High reuse may leads to processing bottleneck Solution: Needs to decompose the service How can a service be designed to optimize the process of the service deconstruction?
  • 15. Application • It is difficult to predict how a service will be decomposed when initially defining it • Before designing a service following points need to be defined  How the current functional scope can potentially be divided?  How capabilities can be defined for new functional contexts?
  • 16. Limitations • Initial service contract may be large and difficult to use • Impose performance overhead on service consumers • Service may be populated with fine-grained capabilities
  • 17. Design Pattern IV: Validation Abstraction • Validation logic of a service expresses fixed terms of engagement with consumer programs • Established contract can’t be changed without releasing a new version. • So what happens when business rules or requirements change (which affects validation logic)? • New contract versions introduce governance burden • How can service contracts be designed to more easily adapt to validation logic changes?
  • 18. Solution • Abstract away validation logic and rules from the service contract
  • 19. Application • Depending on the nature of the message data exchange, separate validation logic • Move abstracted validation logic to a service logic or a different service