Why patterns?

Patterns help you build on the collective experience of many skilled software engineers

Architectural Styles

General constraints: Usually there is one dominant style for each architecture.

George Fairbanks

Architectural Patterns

Fine-grained constraints: Many patterns are usually combined. The same pattern can be used many times

Interoperability

• Why two adapters?
  • For Point to Point solutions one adapter is enough (direct mapping)
  • In general, when integrating among N different platforms, the total number of adapters is reduced by using an intermediate representation
• Adapters do not have to be re-implemented for each component, but can be generalized and shared among all components of a given platform
• This pattern helps to isolate the complexity of having to deal with a different platform when building each component. The adapters make the heterogeneity transparent.
• Warning: performance may suffer due to the overhead of applying potentially complex transformations at each adapter

Dependency Injection

• Used to design architectures that follow the inversion of control principle (“don't call us, we'll call you”, Hollywood Principle)
• Components are passively configured (as opposed to actively looking up services) to satisfy their dependencies:
  • Components should depend on required interfaces of services so that they are decoupled from the actual service implementations
• Flexibility:
  • Systems are a loosely coupled collection of components that are externally connected and configured
  • Components could be reconfigured at any time (multiple times)
• Testability: Easy to switch components with mockups

Event Monitor

• Necessary only if a service (or a component) does not provide a publish/subscribe interface
• To minimize the amount of information to be transferred, snapshots should be tailored to what events the client is interested in detecting. This may be a problem if the service interface cannot be changed.
• One event monitor should be shared among multiple clients by using the observer pattern
• Clients should be able to control polling frequency to reduce the load on the monitored service
• Warning: this solution does not guarantee that all changes will be detected, but only those which occur at most as often as the sampling rate of the event monitor

Publish/Subscribe

• The interaction between published and subscriber is similar to the Observer pattern. It is also more decoupled, as messages are routed based on their type.
• Warning: event types become part of the interface of a service, and it may be difficult to determine the impact of changes in event type definitions
• Like in the Observer pattern, subscriptions should be made persistent, as it is difficult for clients to realize that the pub/sub service has failed.
• Unlike with the Observer pattern, all events in the system go through a centralized component, which can become a performance bottleneck. This can be alleviated by partitioning the pub/sub service by event type.

Scatter/Gather

• This is a simple composition pattern, where we are interested in aggregating replies of the components processing the same message.
• Alternatives for controlling the components:
  • The recipients can be discovered (using subscriptions) or be known a priori (distribution list attached to request)
• Warning: the response-time of each component may vary and the response-time of the scatter/gather is the slowest of all component responses
• Different synchronization strategies:
  • Wait for all messages
  • Wait for some messages (within a certain time window, or using an N-out-of-M synchronization)
  • Return fastest reply (discriminator, maybe only under certain conditions)
• Example:
  • Contact N airlines simultaneously for price quotes
  • Buy ticket from either airline if price<=200 CHF
  • Buy the cheapest ticket if price >200 CHF
  • Make the decision within 2 minutes

Canary Call

• Performance/Robustness Trade-Off:
  • Decreased Performance: the scatter phase waits for the canary call to succeed (response time doubles)
  • Increase Robustness: most workers survive a poisonous call, which would have failed anyway
• Apply when worker recovery is expensive, or when there are thousands of workers involved
• Heuristic: Failed canary calls are not necessarily poisonous

Master/Slave

• This composition pattern is a specialized version of the scatter/gather pattern.
• Clients should not know that the master delegates its task to a set of slaves
• Master Properties:
  • Different partitioning strategies may be used
  • Fault Tolerance: if a slave fails, resend its partition to another one
  • Computational Accuracy: send the same partition to multiple slaves and compare their results to detect inaccuracies (this works only if slaves are deterministic)
  • Master is application independent
• Slave Properties:
  • Each slave runs its own thread of control
  • Slaves may be distributed across the network
  • Slaves may join and leave the system at any time (may even fail)
  • Slaves do not usually exchange any information among themselves
  • Slaves should be independent from the algorithm used to partition the work
• Example Applications:
  • Matrix Multiplication (compute each row independently)
  • Movie Rendering (compute each picture frame independently)
  • TSP Combinatorial Optimization (local vs. global search)

Load Balancing

• This composition pattern is similar to the master/worker pattern, but there is no partitioning of the request nor aggregation of the response
• Clients should not know that the master delegates its task to a set of workers
• Master Properties:
  • Different load balancing policies may be used
  • Fault Tolerance: if a slave fails, resend the request to another one (assuming idempotent failed requests can be detected by the master)
  • Master and load balancing policies are application independent
• Worker Properties:
  • Each worker runs its own thread of control
  • Workers may be distributed across the network
  • Workers may join and leave the system at any time (may even fail)
  • Workers do not usually exchange any information among themselves
  • Workers should be independent from the algorithm used to load balance the requests
• Variants:
  • Stateless load-balancing (every request from any client goes to any worker)
  • Session-based load-balancing (requests from the same client always go to the same worker)
  • Elastic load balancing (the pool of workers is dynamically resized based on the amount of work)

Composition

• Composition is recursive: a composite service is a service that can be composed.
• Services involved in a composition do not necessarily have to know that they are being orchestrated as part of another service and may be provided by different organizations
• Services can be reused across different compositions and compositions can be reused by binding them to different services
• Composite services may be implemented using a variety of tools and techniques:
  • Ordinary programming languages (Java, C#, ...)
  • Scripting languages (Python, PERL, ...)
  • Workflow modeling languages (JOpera, BPEL...)
  • Compositions may be long-running processes and involve asynchronous interactions (both on the client side, and with the services)