Loose Coupling

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

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