service oriented architecture design pattern
TRANSCRIPT
Presentation on Service Oriented Design Pattern and Case Study
2/14/2015 1
Presented By:– Shanto Rahman
Presented To:Alim Ul Gias
Lecturer at IIT, DU
2/14/2015 2
Content
Overview of Service Oriented Architecture
Contract Centralization
Contract Denormalization
Facade Design Pattern
Case Study
Q & A
2/14/2015 3
Service Oriented Architecture
2/14/2015 4
List of SOA Design Pattern
SOA Design Pattern
Foundational Service Patterns
Service Implementation
Patterns
Service Messaging
Patterns
Legacy Encapsulation
Patterns
Composition Implementation
PatternsService Interaction Security Patterns
Transformation Patterns
Common Compound
Design Patterns
Service Contract
Design Patterns
Service Security Patterns
Service
Contract
Design Patterns
Service Contract Design PatternsContract Centralization
Motivation:
• Consumer programs access the service resources using different entry points
• Implementation dependencies
• Contracts loss its significance
Consumer
Fig. 1 : A service consumer program simply bypasses the service contract to access underlying logic directly2/14/2015 6
Service Contract Design PatternsContract Centralization
Solution:
• Limit the access to service logic
•Avoid implementation coupling
Fig. 2: Through Contract Centralization we place the service contract front and center within a servicearchitecture. This is why much of service-orientation is focused on contract design
2/14/2015 7
Consumer
Service Contract Design PatternsContract Centralization
Application:
• Enterprise design standards
• Service abstraction design principle
• When multiple Agnostic services need to be considered
Impact:
• Forcing consumer programs to access service capabilities and resources via a central contract can impose performance
• Overhead and requires on-going standardization effort
2/14/2015 8
Service Contract Design PatternsContract Denormalization
Problem definition:
• There are services with strictly normalized contracts
• Normalized contracts imposes functional and performance demands on the
consumer program
Fig. 3: The Invoice service provides a Get capability that is not able to facilitate the varying granularity levels different service consumer programs prefer.2/14/2015 9
Service Contract Design PatternsContract Denormalization
Solution:
• Multiple capabilities are used to express the core functions in different ways
for different types of consumer programs.
• Denormalization can impact the autonomy and governance of individual services
Fig. 4: Equipped with additional (albeit redundant) capabilities, the Invoice service is able to betteraccommodate the individual requirements of the three consumers
2/14/2015 10
Service Contract Design PatternsContract Denormalization
Application:
• Granularity is applied at the initial phase
• If new consumer added with different objective, based on their request
granularity will be performed
2/14/2015 11
Service Contract Design PatternsContract Denormalization
Facilities:
Can be offered at different levels of granularity.
New capability is added to an existing task service
Impacts:
Overuse of this pattern can lead to overly large and convoluted service
contracts
Multiple variations of each primary capability are added, the contract can
become unmanageable and difficult to evolve
The effectiveness of agnostic services especially can suffer from poor
functional expression
2/14/2015 12
Facade Design Pattern
Intent:
• Provide a unified interface to a set of interfaces in a subsystem
• Facade defines a higher-level interface that makes the subsystem easier to
use
• Wrap a complicated subsystem with a simpler interface
• Hide the complexities of the system
2/14/2015 13
Facade Design Pattern
• Example:
– Q1. One store has a store keeper. In that storage, there are a lot of things stored
e.g. packing material, raw material and finished goods
• Client want to access different goods
• He/ She do not know where the different materials are stored
• Client just have access to store keeper who knows his store well
• Client will tell the store keeper and seller take it out of store and hands it over to
client on showing him the credentials
• Here, the store keeper acts as the facade, as he hides the complexities of the system
Store
2/14/2015 14
Architecture of Facade Design Pattern
Facade (Storekeeper)
Client2Client1
Package1Package2 Package3
Class Class Class
2/14/2015 15
Facilities Provided By Facade Design Pattern
• Identify a simpler, unified interface for the subsystem or component
• Design a 'wrapper' class that encapsulates the subsystem
• The facade/wrapper captures the complexity and collaborations of the
component, and delegates to the appropriate methods
• The client uses (is coupled to) the Facade only
• Consider whether additional Facades would add value
2/14/2015 16
public interface Store {
public Goods getGoods();
}
public class FinishedGoodsStore implements Store {
public Goods getGoods() {
FinishedGoods finishedGoods = new FinishedGoods();
return finishedGoods;
}
}// End of class
2/14/2015 17
Code Example
public class StoreKeeper {
public RawMaterialGoods getRawMaterialGoods() {
RawMaterialStore store = new RawMaterialStore();
RawMaterialGoods rawMaterialGoods = (RawMaterialGoods)store.getGoods();
return rawMaterialGoods;
}
public FinishedGoods getFinishedGoods() {
FinishedGoodsStore store = new FinishedGoodsStore();
FinishedGoods finishedGoods = (FinishedGoods)store.getGoods();
return finishedGoods;
}
}// End of class
2/14/2015 18
Code Example
public class Client {
public static void main(String[] args) {
StoreKeeper keeper = new StoreKeeper();
RawMaterialGoods rawMaterialGoods = keeper.getRawMaterialGoods();
}
}
:
Client.java
2/14/2015 19
Code Example
Code Example
public class StoreKeeper {
public Goods getGoods(String goodsType) {
if (goodsType.equals("Finished")) {
FinishedGoodsStore store = new FinishedGoodsStore();
FinishedGoods finishedGoods = (FinishedGoods)store.getGoods();
return finishedGoods;
}
else {
RawMaterialStore store = new RawMaterialStore();
RawMaterialGoods rawMaterialGoods = (RawMaterialGoods)store.getGoods();
return rawMaterialGoods;
}
}
2/14/2015 20
public interface Store {
public Goods getGoods();
}
public class FinishedGoodsStore implements Store {
public Goods getGoods() {
FinishedGoods finishedGoods = new FinishedGoods();
return finishedGoods;
}
}// End of class
Code Example
public class StoreKeeper {
public RawMaterialGoods getRawMaterialGoods(String goodsType) {
Storage store = new Storage ();
RawMaterialGoods rawMaterialGoods = (RawMaterialGoods)store.getGoods(goodsType);
return rawMaterialGoods;
}
}// End of class
Code Example
public class Client {
public static void main(String[] args) {
StoreKeeper keeper = new StoreKeeper();
RawMaterialGoods rawMaterialGoods = keeper.getRawMaterialGoods(“Packaging”);
}
}
:
Client.java
Code Example
public class Storage {
public Goods getGoods(String goodsType) {
if (goodsType.equals("Packaging")) {
PackingMaterialStore store = new PackingMaterialStore();
PackingMaterialGoods packingMaterialGoods = (PackingMaterialGoods)store.getGoods();
return packingMaterialGoods;
}
else if (goodsType.equals("Finished")) {
FinishedGoodsStore store = new FinishedGoodsStore();
FinishedGoods finishedGoods = (FinishedGoods)store.getGoods();
return finishedGoods;
}
}
Code Example
2/14/2015 25
Case Study
Appropriate coupling levels are implemented:
• Materials Service
• Formulas Service
• Run Lab Project Service
2/14/2015 26
Entity service model
Task-centric service
Case Study
• To interact with the legacy inventory management system Both the GetPurchased
and ReportStockLevels operations of the Materials service are required (from
Chapter 6)
• This system has limited integration capabilities
• They thought that two operations from the Materials service do not need to
interface directly with the proprietary API
• A separate Web service named InvLegacyAPI is proposed
• Reasons for using InvLegacyAPI:
– Abstracts the legacy environment
– It lowers the Materials service’s overall implementation coupling level
– It is considered a utility service because it essentially acts as a wrapper endpoint for a proprietary
legacy API
2/14/2015 27
Case Study
2/14/2015 28
Fig. 5: The back-end implementation details of the InvLegacyAPI service operations. Notice how the GetItemCountoperation bypasses the API to access the database directly
Case Study
• Service Design Options:
– Accept the contract requirements of the InvLegacyAPI service and allow the Materials
service to bind to the Inventory service
– Introduce a service that provides a contract based on the existing, standardized
Inventory Item schema definition
2/14/2015 29
2/14/2015 30
Case Study
2/14/2015 31
Case Study
Case Study: Run Lab Project
2/14/2015 32
Fig. 6: Cutit decides to go ahead with the delivery of the new Inventory service
2/14/2015 33
2/14/2015 34