1. PROGRAMAÇÃO DE
SISTEMAS
DISTRIBUIDOS
Paulo Gandra de Sousa
pag@isep.ipp.pt

2. Disclaimer
1
ISEP/IPP
 Parts of this presentation are from:
 Paulo Sousa (PARS)
 Ron Jacobs (ARC01)
 Greg Young
 Udi Dahn

3. Today’s lesson
2
 Design Patterns
 Patterns for distributed Systems
 Service Orientation patterns
 CQRS

4. Design patterns

5. What is a Pattern?
4
ISEP/IPP
Each pattern describes a problem that occurs
over and over again in our environment and
then describes the core of the solution to that
problem in such a way that you can use this
solution a million times over without ever
doing it the same way twice.
Christopher Alexander

6. What is a design Pattern?
5
ISEP/IPP
A design pattern names, abstracts, and identifies
the key aspects of a common design structure
that make it useful for creating a reusable
object-oriented design.
Design Patterns-Elements of Reusable Object-oriented
Software, Gamma et al. (Gang of
Four)

7. What a pattern is not
6
ISEP/IPP
 A miracleous receipt
source: British Medical Journal

8. What is a pattern
7
ISEP/IPP
 A set of best-practices
 A typified solution for a common problem in a giving
context
 Creates a common vocabulary
 Patterns are discovered not invented
 “Patterns are half-baked”
 Martin Fowler

9. Anti-pattern
8
ISEP/IPP
 An example of what not to do
 Proven techniques that have shown bad
results

10. Patterns for distributed
applications

11. Architecture
15
ISEP/IPP
“client” application
Service
Gateway
“server” application
Remote
Façade
Service
Layer
Business
logic
Data
Transfer
Object
Service
Locator
contract

12. Service Gateway
16
ISEP/IPP
 An object that encapsulate the code that implements the
consumer portion of a contract. They act as proxies to other
services, encapsulating the details of connecting to the
source and performing any necessary translation.
fonte: Enterprise Solution Patterns Using .NET
Pattern

13. Service Gateway
17
ISEP/IPP
 Hides the details of accessing the service (ex.,
network protocol)
 May be considered a data access component
 Native support from most tools (e.g., Visual Studio,
Netbeans, Rational software Architect) by web
service proxies
 See also Proxy and Broker pattern
Pattern

14. Service locator
18
ISEP/IPP
 Hides the complexity of finding and creating
service gateways
fonte: Core J2EE Patterns

15. Remote Façade
19
ISEP/IPP
 Provides a coarse-grained façade on fine-grained
objects to improve efficiency over a
network
fonte: Patterns of Enterprise Application Architecture
Pattern

16. Remote Facade
20
ISEP/IPP
 Domain object interfaces are tipically fine grained
 Inadequeate for remote operations
 Create a surronding layer above domain objects
 Local clients use the local interface
 The facade may encapsulate the interface of one or more
business objects
 Domain objects:
 Address.New
 Address.Set
 Person.AddAddress
 Person.Update
 Remote Facade:
 AddressFacade.AddNewAddressToPerson
Pattern

17. Data Transport Object
21
ISEP/IPP
 An object that carries data between
processes in order to reduce the number of
method calls.
fonte: Patterns of Enterprise Application Architecture
Pattern

18. Data Transport Object
22
ISEP/IPP
 Since XML is the de facto standard DTO should support serialization
to/from XML
 Should be independent of the underlying domain object
 Should be implemented in accordance with the requiremnts of the
remote application
 CompleteCustomerInfoDTO
 BasicCustomerInfoDTO
 Should be independent of the underlying platform (e.g., programming
language)
 DataSet/DataTable .net
 ResultSet JDBC
 DateTime .net
Pattern

19. Service Layer
23
ISEP/IPP
 Defines an application's boundary with a layer of
services that establishes a set of available operations
and coordinates the application's response in each
operation
fonte: Patterns of Enterprise Application Architecture
Pattern

20. Service Layer
24
ISEP/IPP
Pattern
 Domain logic pattern in the context of service
orientation
 May be implemented as a Remote Facade or
may be called by a Remote Facade

21. Business Logic
28
ISEP/IPP
 Outside of the scope
 Excellent reference: Patterns of Enterprise
Application Architecture
 Table Module
 Table Data Gateway
 Domain Model
 Active Record
 Data Mapper
 Optimistic Offline Lock
 …

22. Service Orientation

23. CRUDy interface: Service Anti-pattern!
30
interface CustomerService {
int createCustomer(string name, …);
CustomerDTO readCustomer(int id);
bool updateCustomer(CustomerDTO c);
bool deleteCustomer(int id);
}
interface CustomerService {
int createCustomer(string name, …);
CustomerDTO readCustomer(int id);
bool changeAddress(int id, AddressDTO c);
bool makePrefered(int id)
bool deactivateCustomer(int id, string reason);
}

24. Loosey-Goosey : Service Anti-pattern!
31
 Design highly flexible interface
 E.g., Expose direct SQL access
 In the intent to provide flexibility, there is no
service contract
interface CustomerService {
CustomerDTO[] readCustomer(string where);
}

25. Document Processor
32
 Provide a document centric contract, not an
RPC-like contract

26. Idempotent operation
33
 Executing once or many times has the exact
same side effects
 Allows for repeated request
 Ensures same outcome and only one end-state
change
 E.g.,
 setBalance() vs. addBalance()
 delete()
 read()

27. Reservation
34
 Allows for long running transactions without
locking
 Must have compensation procedure
 ACID transactions are for databases not for
distributed systems!
 Look at the world around you, e.g., travel
arrangements
 Rent a car
 Book the hotel
 Buy the plane ticket

28. Compensating Transaction
35
Source: http://msdn.microsoft.com/en-us/library/dn589783.aspx

29. Queue-based load leveling
36
Source: http://msdn.microsoft.com/en-us/library/dn589783.aspx

30. Web/Worker roles
37
 Separate acepting requests from handling the
requests
Web role Queue Worker role
 Both roles can scale independently

31. Scaling out
38
Web role Queue Worker role
Thousands of
instances
Dozens or
hundreds of
instances
 Queue must ensure reliability, transactionality
and (possibly) single reader

32. Competing consumers
39

33. Exercise
 Remember the
example DS you
provided in the last
session.
 Define an
hypothetical SOA for
that system
 Define contract
 Identify where you
would use the
presented patterns
40
ISEP/IPP

34. 41 CQRS

35. Stereotypical distributed system
42
Source: http://martinfowler.com/bliki/CQRS.html

36. Typical data flow
43
1. request data
2. DTO is sent from the
server
UI Backend
3. do some change to the
data
4. send updated DTO to the
server
5. ack/nack

37. Typical API & UI
44
interface CustomerService {
int createCustomer(string name, …);
CustomerDTO readCustomer(int id);
bool updateCustomer(CustomerDTO c);
bool deleteCustomer(int id);
}

38. Problems with Stereotypical
distributed system
 Read vs Write frequency
 Read model vs Write model
 Does not capture user intent
Does not scale well

39. CQRS
46
 Command
 Query
 Responsibility
 Segregation

40. Separating Commands from
Queries
47
Source: http://martinfowler.com/bliki/CQRS.html

41. Two APIs
48
interface CustomerQueryService {
CustomerDTO readCustomer(int id);
}
interface CustomerCommandService {
int createCustomer(string name, …);
bool updateCustomer(CustomerDTO c);
bool deleteCustomer(int id);
}

42. Separating Query model from
Transaction model
49
Adapted from: http://martinfowler.com/bliki/CQRS.html
Periodically
sync query
model

43. Two models
50
 Command = Transactional
 Optimized for transactions
 Highly normalized in case of relational data
 Query
 Highly denormalized
 Read-only
 Safely redundant

44. Capturing user intent
51
1. request data
2. DTO is sent from the
server
UI Backend
3. choose a task & fill in the
task s data
4. send command to the
server
5. ack/nack

45. Task-based UI
52
CRUD interface Task-based UI

46. Task-based UI => Intentional
API
53
interface CustomerQueryService {
CustomerDTO readCustomer(int id);
}
interface CustomerCommandService {
int createCustomer(string name, …);
bool changeAddress(int id, Address a);
bool makePrefered(int id);
bool deactivateCustomer(int id, string reason);
}

47. Exercise
 Think about the
system we have
been discussing in
the class and
discuss if and how
CQRS would be
applicable and why.
54

48. Patterns Bibliography
55
ISEP/IPP
 Buschmann, F.; Henney, K. And Schmidt, D. (2007) Pattern-
Oriented Software Architecture: A Pattern Language for Distributed
Computing, Volume 4. Willey.
 Patterns of Enterprise Application Architecture. Martin Fowler.
Adisson-Wesley.
 Core J2EE Patterns: Best Practices and Design Strategies. Deepak
Alur, John Crupi and Dan Malks. Prentice Hall / Sun Microsystems
Press. http://java.sun.com/blueprints/corej2eepatterns/index.html
 Enterprise Solution Patterns Using Microsoft .NET. Microsoft Press.
http://msdn.microsoft.com/architecture/patterns/default.aspx?pull=/li
brary/en-us/dnpatterns/html/Esp.asp

49. Patterns Suggested readings
56
ISEP/IPP
 Design patterns : elements of reusable object-oriented software. Erich
Gamma, Richard Helm, Ralph Johnson, John Vissides.
 Pattern-oriented Software Architecture: System of Patterns. Frank
Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad,
Michael Stal
 Principles of Service design: service patterns and anti-patterns. John
Evdemon (2005) http://msdn.microsoft.com/en-us/
library/ms954638.aspx
 Cloud Design Patterns. Microsoft Patterns & Practices.
http://msdn.microsoft.com/en-us/library/dn568099.aspx
 Designing Data Tier Components and Passing Data Through Tiers.
Microsoft Patterns & Practices.
http://msdn.microsoft.com/library/?url=/library/en-us/
dnbda/html/BOAGag.asp?frame=true

50. CQRS Bibliography
57
 Martin Fowler (2011) CQRS,
http://martinfowler.com/bliki/CQRS.html
 Greg Young, CQRS documents,
http://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf
 Microsoft Patterns & Practices (2012) Exploring CQRS and Event
Sourcing, Microsoft Patterns & Practices. Available at
http://msdn.microsoft.com/en-us/library/jj554200.aspx