You can read the following article at:
http://www.infoq.com/news/2009/04/coupling
Gervas
<<Coupling
<http://en.wikipedia.org/wiki/Coupling_%28computer_science%29> is "the
degree to which each program module relies on each one of the other
modules". Low coupling is typically a sign of a well-design
implementation supporting the general goals of high readability and
maintainability.
In his new post
<http://iansrobinson.com/2009/04/27/temporal-and-behavioural-coupling/>
Ian Robinson explores how different distributed systems design
approaches - Distributed 3-layer, Command-oriented, Event-oriented and
Emergency services - impact two specific types of coupling: temporal and
behavioral.
He starts by defining temporal coupling as:
... the degree to which the sending and handling of a message are
connected in time. If a sender is dependent on a receiver being
available when a message is sent, we have high temporal coupling...
Processes whose activities are strictly ordered or whose results
carry forward, leaving subsequent activities unable to start until a
response to a prior request has been received, are similarly
temporally coupled.
And behavioral coupling as:
...the degree to which parties share assumptions regarding
behaviors, more specifically, to the implications of assigning the
twin responsibilities for determining what action to execute and how
to execute that action to the parties in a distributed interaction.
In systems that exhibit an extremely high degree of behavioral
coupling, the sender of a message determines what to do, and also
knows something of how the receiver ought satisfy its request...
High behavioral coupling requires a provider to evolve its service
offerings in response to changed consumer requirements.
When a traditional 3-layer architecture is used for building of
distributed systems (*Distributed 3-layer*), it is typically implemented
using synchronous interactions (even when asynchronous messaging is used
as a transport), typically leading to a high temporal and behavioral
coupling. In this case:
Senders tell receivers what to do; receivers execute the sender's
orders. Sender and all intermediaries block until the call stack
unwinds, effectively locking and/or consuming system resources
further up the call chain. This blocking behavior undermines the
autonomy of upstream components and at the same time increases the
availability requirements of downstream components... in these
circumstances the availability of the overall system can be no more
than that of the least available participant, and the probability of
failure is the joint probability of failure in any component or
service.
Usage of the *Command-oriented* design typically allows to lower the
degree of temporal coupling, especially when asynchronous interactions
are used. Coupling can be lowered even further by implementing a
"resumable" programming model common for orchestration engines
implementations. In this design:
Senders typically determine what needs to be done, but rely on
receivers to determine how to execute their instructions. This
behavioral coupling can require providers to evolve (message
formats, supported operations) in lockstep with changing consumer
demands.
Lowest degree of both temporal and behavioral coupling can be achieved
in the case of the *Event-oriented* design, especially when it is
coupled with a "resumable" programming model:
Receivers determine both what needs to be done and how to do it
based on the content of received messages. Can be difficult to trace
the execution path of an end-to-end transaction or activity.
Exposing an "ExtinguishFire" operation is a command-oriented way of
executing a business process; acting on "FireStarted" notifications
an event-oriented approach.
Finally *Emergency services* design is characterized by implementing a
set of services, receiving information about what has happened and
deciding what to do in any particular situations. This design is
characterized by very low behavioral coupling, which allows for the
independent evolution of emergency services implementations, but a
higher degree of temporal coupling - someone has to be there to react at
the given situation. Many RESTful solutions are based on this design.
URI-templated solutions have a higher degree of behavioral coupling
than hypermedia-driven solutions (where servers constrain and guide
what a client can do next, and determine how best to satisfy
requests); client polling and caching can mitigate some of these
temporal coupling issues.
The post provides an interesting analysis of impact of distributed
systems design approaches on the coupling of the resulting systems.
Unfortunately not all of Ian's conclusions seem to be correct.
When it comes to temporal coupling the answer is quite straightforward -
synchronous interactions (not communications) lead to strong temporal
coupling, while asynchronous ones lead to low temporal coupling. Because
any of the design approaches described in the post allow for use of
both, it is not the design approach but rather the interaction used
inside design that defines the temporal coupling characteristics of the
resulting system.
When it comes to behavioral coupling, the issue becomes slightly more
involved. First of all, there are several slightly different definitions
of behavioral coupling, for example
<http://www.grok-programming.com/2008/09/05/watch-coupling-kill-your-project/>:
Behavioral coupling is a sub-form of Content Coupling but instead of
accessing local data within the two pieces of code one module is
restricted because of how another module is implemented (i.e. behaves).
If this definition is accepted, then the most common solution
<http://www.grok-programming.com/2008/09/05/watch-coupling-kill-your-project/>for
the behavioral coupling is an intermediary that shields one of the
participants from behavioral effects of the other.Again, such
intermediary can be used regardless of the design approach.>>
