The chapter discusses key concepts of loose coupling in service-oriented architectures (SOA) such as asynchronous communication, heterogeneous data types, and the use of mediators. Loose coupling aims to reduce dependencies between distributed systems to improve scalability, fault tolerance, and flexibility. While loose coupling has benefits, the document notes it also has drawbacks such as added complexity, so the appropriate degree of loose or tight coupling must be determined for each system.

1. Book Author: Nicolai M. Josuttis
Chapter Four: Loose Coupling
IT-Slideshares http://it-slideshares.blogspot.com/

2. 4.0 Loosely Coupling (SOA)
 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.

3. 4.1 The need for Fault Tolerance
 If you're not fast enough, flexible enough, and cheap
enough, you'll soon find yourself out of the market.
 Fast and cheap solutions, however, can't be well
designed and robust. Cost of opportunity or money
when systems are down.
 Fault tolerance is key for large distributed systems.
When problems occur, it is important to minimize
their effects and consequences.

4. 4.2 Possible Forms of Loose Coupling concepts
Tight Coupling Loose Coupling
Physical Connection Point-to-Point Via Mediator
Communication Style Synchronous Asynchronous
Data Model Common Complex types Simple Common types
Type System Strong Weak
Interaction Pattern Navigate through Data-centric, self-
complex object trees contained message
Control of Process Logic Central Control Distributed Control
Binding Statically Dynamically
Platform Strong platform Platform Independent
dependencies
Transactionality 2PC (two-phase commit) Compensation
Deployment Simultaneous At different time
Versioning Explicit upgrades Implicit upgrades

5. 4.2.1 Asynchronous Communication
•Asynchronous communication usually means that the sender of a
message and its receiver are not synchronized.
•One problem with asynchronous communication occurs when the
sender needs a reply.
•Programming, testing, and debugging all the possible eventualities can
be very complicated and time consuming.
• How ESB handles message queues

6. 4.2.2 Heterogeneous Data Types
 The harmonization of data types over distributed systems (argument
against SID model)
 Large distributed systems typically have different owners, it was tough
to reach agreements.
 “Analysis paralysis": if you try to achieve perfection when analyzing all
requirements, you'll never finish the job.
 The price of harmonization becomes too high. Keeping all the systems
in sync is simply too expensive in terms of time and money.
 You need data type mappings (which include technical and semantic
aspects). Although mapping adds complexity, it is a good sign in large
systems because it demonstrates that components are decoupled.
 The advantage is that systems can modify their data types without
directly affecting other systems (modified service interfaces affect only
corresponding consumers).
 The drawback is that you have to map data types from one system to
another.

7. 4.2.3 Mediators
 In principle, there are two kinds of mediators:
 The first type tells you the correct endpoint for your service call before
you send it. That is, you still have point-to-point connections, but with
the help of these mediators, you send your service calls to different
addresses. Such a mediator is often called a broker or name server. You
ask for a service using a symbolic name, and the broker or name server
tells you which physical system to send your request to. This form of
mediation requires some additional intelligence at the consumer site.
 The second type chooses the right endpoint for a request after the
consumer sends it. In this case, the consumer sends the request to a
symbolic name, and the infrastructure (network, middleware, ESB)
routes the call to the appropriate system according to intelligent
routing rules.
 Web Services are technically point-to-point connections, where you
typically use a broker to find the physical endpoint of a request, and/or
you insert some so-called interceptors that route your request at
runtime to an available provider.

8. 4.2.4 Weak Type Checking
 In order for the SOA infrastructure (ESB) to check
types, it needs to have some information about those
types.
 Modifications of the interface requires synchronize
updates to all adapters and ESB  tighter
dependencies
 Solutions: make ESB generic and impose type
checking only on the consumer/provider based on
contract (those who publish/subscribe to the service)
 Make judgment based on the stability of the data
 Find the ‘right’ kind of coupling (loose or tight … ?)

9. 4.2.5 Binding
 Binding (the task of correlating symbols of different
modules or translation units) allows a form of loose
coupling that is similar to weak type checking. Again,
you have to decide between early binding, which
allows verification at compile or start time, and late
binding, which happens at runtime.

10. 4.2.6 Platform Dependencies
 You have more freedom of choice if platform-
independent solutions are preferred over strong
platform dependencies.

11. 4.2.7 Interaction Patterns
 Recommend to have a basic set of fundamental types that you can compose to
other types (structures, records) and sequences (arrays). Be careful with
enumerations (an anachronism from the time when each byte did count—use
strings instead), inheritance, and polymorphism (even when XML supports it).
 Are only strings supported, or can other fundamental data types (integers,
floats, Booleans, date/time types, etc.) be used?
 Are enumerations (limited sets of named integer values) 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)?
 The more complicated the programming constructs are, the more abstractly
you can program. However, you will also have more problems mapping data to
platforms that have no native support for a particular construct.

12. 4.2.8 Compensation
 2PC vs. compensation
 2PC may lead to delays and deadlocks
 Compensation approach modifies the first backend,
and then modify the second backend; if only one
modification is successful, you then "compensate" for
the problem appropriately.
 The drawback of compensation is that you have to
explicitly provide and call services that revert previous
services or programs for manual error handling.
 BPEL, the process execution language of Web Services,
directly supports compensation.

13. 4.2.9 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. Failure of such a central component
will stop the whole process.
 On the other hand, if you have decentralized or
distributed control (where each component does its
job and knows which component will continue after)
you avoid bottlenecks, and if some systems fail, others
can still continue to work.

14. 4.2.10 Deployment
 Whether you require that system updates be deployed
simultaneously, or at different times, is related to
coupling. Of course, systems are bound more tightly to
each other if it is required that they update
synchronously. 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.

15. 4.2.11 Versioning
 If the provider introduces a new type version, the
consumer will have to upgrade explicitly to this new
type; otherwise, the provider will have to support both
types. If, on the other hand, the provider just adds the
attribute to the existing type, this might cause binary
compatibility issues, and require the consumer to
recompile its code or use another library.
 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.

16. 4.3 Dealing with Loose Coupling
 To avoid asynchronous communication whenever possible, based on
the experience that it led to race conditions at runtime that were very
hard, or even impossible, to reproduce in a development environment,
and therefore almost impossible to fix.
 Synchronous calls were allowed only for reading service calls because
the performance was not good enough for writing service calls.
 ESB should be separated from a backend via a protocol, or via an API.
 via an API usually means that the ESB provides libraries each backend
or backend adapter has to use. So, deployment and binding become
issues.
 On the other hand, using a common API (protocol), you can hide some
aspects of synchronous or asynchronous communications inside the
ESB.

17. 4.4 Summary
 Loose coupling is a fundamental concept of SOA (and
large distributed systems in general) 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.
IT-Slideshares http://it-slideshares.blogspot.com/