The presentation covered service oriented architecture design patterns including contract centralization, contract denormalization, and the facade design pattern. It provided examples of each pattern and discussed when they should be used. It also presented a case study on redesigning an inventory management system to better utilize these patterns and abstract interactions with a legacy system.

1. Presentation on Service Oriented Design
Pattern and Case Study
2/14/2015 1

2. Presented By:
– Shanto Rahman
Presented To:
Alim Ul Gias
Lecturer at IIT, DU
2/14/2015 2

3. Content
 Overview of Service Oriented Architecture
 Contract Centralization
 Contract Denormalization
 Facade Design Pattern
 Case Study
 Q & A
2/14/2015 3

4. Service Oriented Architecture
2/14/2015 4

5. 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

6. Service Contract Design Patterns
Contract 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 directly
2/14/2015 6

7. Service Contract Design Patterns
Contract 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 service
architecture. This is why much of service-orientation is focused on contract design
2/14/2015 7
Consumer

8. Service Contract Design Patterns
Contract 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

9. Service Contract Design Patterns
Contract 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

10. Service Contract Design Patterns
Contract 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 better
accommodate the individual requirements of the three consumers
2/14/2015 10

11. Service Contract Design Patterns
Contract 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

12. Service Contract Design Patterns
Contract 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

13. 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

14. 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

15. Architecture of Facade Design Pattern
Facade
(Storekeeper)
Client2Client1
Package1
Package2 Package3
Class Class Class
2/14/2015 15

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. public class Client {
public static void main(String[] args) {
StoreKeeper keeper = new StoreKeeper();
RawMaterialGoods rawMaterialGoods = keeper.getRawMaterialGoods(“Packaging”);
}
}
:
Client.java
Code Example

24. 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

25. 2/14/2015 25

26. 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

27. 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

28. Case Study
2/14/2015 28
Fig. 5: The back-end implementation details of the InvLegacyAPI service operations. Notice how the GetItemCount
operation bypasses the API to access the database directly

29. 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

30. 2/14/2015 30
Case Study

31. 2/14/2015 31
Case Study

32. Case Study: Run Lab Project
2/14/2015 32
Fig. 6: Cutit decides to go ahead with the delivery of the new Inventory service

33. 2/14/2015 33

34. 2/14/2015 34