Loose Coupling

From Training Material
Revision as of 18:44, 8 November 2012 by Izabela Szlachta (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


Scalability

  • Scalability can be understood as:
    • an ability to add new features
    • increase the utilization (number of users, requests, the size of data, etc..) of an existing system
  • Minimizing the impact of modifications and failures on the system landscape as a whole
  • Maintainability


The Need for Fault Tolerance

  • No time for well-elaborated, robust system designs.
  • Changing requirements
  • A flight booking system failure may cost $100,000 an hour, a credit card system breakdown may cost $300,000 an hour, and a stock-trading malfunction may cost $8 million an hour.


Loose Coupling

  • The aim of loose coupling is to minimize dependencies.
  • When there are fewer dependencies, modifications to or faults in one system will have fewer consequences on other systems.
  • Loose coupling is a principle; it is neither a tool, nor a checklist


Forms of loose coupling

Tight Coupling Loose Coupling
Physical connections Point-to-point Via mediator
Communication style Synchronous Asynchronous
Data model Common complex types Simple common types only
Type system Strong Weak
Interaction pattern Navigate through complex object trees Data-centric, self-contained message
Control of process logic Central control Distributed control
Binding Statically Dynamically
Platform Strong platform dependencies Platform independent
Transactionality 2PC (two-phase commit) Compensation
Deployment Simultaneous At different times
Versioning Explicit upgrades Implicit upgrades


Asynchronous Communication

Soa-asynchronous-communication.png

  • The systems exchanging service messages do not have to be online at the same time
  • Long answering times don’t block the service consumer
  • Logic of the service consumer gets (much) more complicated


Heterogeneous Data Types

  • Systems can modify their data types without directly affecting other systems (modified service interfaces affect only corresponding consumers)
  • You have to map data types from one system to another


Mediators

  • First type is when sender may know the physical address of the called system (broker or name server). You ask for a service using a symbolic name, and the broker or name server.
  • The second type chooses the right endpoint for a request after the consumer sends it. The consumer sends the request to a symbolic name, and the infrastructure (network, middleware, ESB) routes the call to the appropriate system.

Weak Type Checking and Binding

  • Early and late binding
  • Generic ESB
    • ESB isn't coupled with any of the systems
    • only general statistics
    • general routing
  • Type specific ESB
    • Details statistics
    • Routing based on specific conditions (type, value in a element, source, etc..)
    • There is a dependency between the type and the ESB


Interaction Patterns

  • Are only strings supported, or can other fundamental data types (integers, floats, Booleans, date/time types, etc.) be used?
  • Are enumerations supported?
  • Can you constrain possible values (e.g., define certain string formats)?
  • Can you build higher types (structures, records)?
  • Can you build sequence types (arrays, lists)?
  • Can you design relations between types (inheritance, extensions, polymorphism)?


Compensation

  • Two-phase commit (2PC)
  • If only one modification is successful, you then “compensate” for the problem appropriately
  • System updates don’t have to be performed synchronously
  • You have to explicitly provide and call services that revert previous services or programs for manual error handling
  • BPEL supports compensation


Control of Process Logic

  • Process-control decisions can also lead to different forms of coupling. Having one central component controlling the whole process logic creates a bottleneck because each involved system must connect with it (Orchestration, BPM)
  • Decentralized or distributed control (where each component does its job and knows which component will continue after) you avoid bottlenecks (Choreography, CEP)


Deployment

  • Simultaneous deployment creates dependency
  • The more loosely coupled approach of updating at different times, however, leads to a very important drawback: the need for migration, which leads to versioning


Versioning

With a more loosely coupled form of data type versioning, the consumer won’t have to do anything as long as the modifications are backward compatible.


Summery

  • Loose coupling is a fundamental concept of SOA aimed at reducing dependencies between different systems.
  • There are different forms of loose coupling, and you will have to find the mixture of tight and loose coupling that’s appropriate for your specific context and project.
  • Any form of loose coupling has drawbacks. For this reason, loose coupling should never be an end in itself.
  • The need to map data is usually a good property of large systems.