Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Patterns for distributed systems

7.732 visualizaciones

Publicado el

  • Boa tarde Paulo Gandra de Sousa, agradeço desde já a partilha da apresentação. Gostava de perguntar se pode sugerir literatura relativa a SOA Reservations Pattern
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí

Patterns for distributed systems

  2. 2. Disclaimer 1 ISEP/IPP  Parts of this presentation are from:  Paulo Sousa (PARS)  Ron Jacobs (ARC01)  Greg Young  Udi Dahn
  3. 3. Today’s lesson 2  Design Patterns  Patterns for distributed Systems  Service Orientation patterns  CQRS
  4. 4. Design patterns
  5. 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. 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. 7. What a pattern is not 6 ISEP/IPP  A miracleous receipt source: British Medical Journal
  8. 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. 9. Anti-pattern 8 ISEP/IPP  An example of what not to do  Proven techniques that have shown bad results
  10. 10. Patterns for distributed applications
  11. 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. 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. 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. 14. Service locator 18 ISEP/IPP  Hides the complexity of finding and creating service gateways fonte: Core J2EE Patterns
  15. 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. 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. 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. 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. 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. 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. 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. 22. Service Orientation
  23. 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. 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. 25. Document Processor 32  Provide a document centric contract, not an RPC-like contract
  26. 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. 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. 28. Compensating Transaction 35 Source:
  29. 29. Queue-based load leveling 36 Source:
  30. 30. Web/Worker roles 37  Separate acepting requests from handling the requests Web role Queue Worker role  Both roles can scale independently
  31. 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. 32. Competing consumers 39
  33. 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. 34. 41 CQRS
  35. 35. Stereotypical distributed system 42 Source:
  36. 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. 37. Typical API & UI 44 interface CustomerService { int createCustomer(string name, …); CustomerDTO readCustomer(int id); bool updateCustomer(CustomerDTO c); bool deleteCustomer(int id); }
  38. 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. 39. CQRS 46  Command  Query  Responsibility  Segregation
  40. 40. Separating Commands from Queries 47 Source:
  41. 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. 42. Separating Query model from Transaction model 49 Adapted from: Periodically sync query model
  43. 43. Two models 50  Command = Transactional  Optimized for transactions  Highly normalized in case of relational data  Query  Highly denormalized  Read-only  Safely redundant
  44. 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. 45. Task-based UI 52 CRUD interface Task-based UI
  46. 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. 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. 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.  Enterprise Solution Patterns Using Microsoft .NET. Microsoft Press. brary/en-us/dnpatterns/html/Esp.asp
  49. 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) library/ms954638.aspx  Cloud Design Patterns. Microsoft Patterns & Practices.  Designing Data Tier Components and Passing Data Through Tiers. Microsoft Patterns & Practices. dnbda/html/BOAGag.asp?frame=true
  50. 50. CQRS Bibliography 57  Martin Fowler (2011) CQRS,  Greg Young, CQRS documents,  Microsoft Patterns & Practices (2012) Exploring CQRS and Event Sourcing, Microsoft Patterns & Practices. Available at