Loose Coupling in a Service-Oriented Architecture (Page 1 of 4 )
SOA applies to large distributed systems. Scalability and fault tolerance are key to the maintainability of such systems. Another important goal is to minimize the impact of modifications and failures on the system landscape as a whole. Thus, loose coupling is a key concept of SOA.
This chapter will discuss the motivations for this concept (for large distributed systems), exploring variations of loose coupling from the technical and organizational points of view. This topic will demonstrate that SOA is a paradigm that leads to special priorities when designing large systems. However, again, there is no rule prescribing which kind or level of loose coupling you should employ. This decision must be made based on your specific circumstances.
4.1 The Need for Fault Tolerance
We live in crazy times. The market rules, which means you won’t usually have enough time to create well-elaborated, robust system designs. If you’re not fast enough, flexible enough, and cheap enough, you’ll soon find yourself out of the market. Thus, you need fast, flexible, and cheap solutions.
Fast and cheap solutions, however, can’t be well designed and robust. Consequently, you will have to deal with errors and problems. The important point here is fault tolerance. The most important thing is that your systems run. According to [ITSecCity02] , 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. As these figures show, fault tolerance is key for large distributed systems. When problems occur, it is important to minimize their effects and consequences.
4.2 Forms of Loose Coupling
Loose coupling is the concept typically employed to deal with the requirements of scalability, flexibility, and fault tolerance. 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. When you design your SOA, it is up to you to define which kinds and amount of loose coupling you introduce. However, there are some typical topics you might want to consider when you think about loose coupling in your system. Table 4-1 lists them (this list is an extension of a list published in [KrafzigBankeSlama04], p. 47).
TABLE 4-1 . Possible forms of loose coupling in SOA
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
This table is far from being complete, but it’s pretty typical for large distributed systems. Note again that this is not a checklist. There is no SOA certification saying you conform when all or at least 50 percent of the forms of loose coupling are in use. However, it would be very strange if none of these forms of loose coupling were used in your SOA. If this were possible, your system would appear not to have the common requirements of large distributed systems with different owners. That’s OK, but you shouldn’t call your solution SOA. (Well, it may help you get money and resources for it, but beware of false impressions.)
If there is such a fine list of aspects of loose coupling, and minimizing dependencies is good, you might be wondering why you don’t simply use all these forms of loose coupling in each SOA. The answer is that there is a price to pay for loose coupling, in that it makes systems more complex. That means more development, and/or maintenance effort.
To explore how the forms of loose coupling listed in Table 4-1 can help and the costs they can incur, let’s examine some more closely. Most of these topics will be discussed in more detail later in the book, so I’ve included references to future chapters where appropriate.
Web Services 
