| Coupling
refers to the interrelatedness and interdependencies between two
or more components or web services.
One simple way to think about coupling is this: how easy is it
to change something about web service A without having to change
web service B. If many changes in A require something in B to
be changed, they are tightly coupled.
If A can be changed easily without B being touched, then they
are loosely coupled.
Tightly coupled architectures are much harder to maintain and
reuse, so loose coupling is a major goal in a service
oriented architecture. Coupling can occur in many ways.
The most obvious form of coupling is a dependency on a specific
commonly understood interface between the requestor and service
provider. This can be avoided by using WSDL
or other interface definition language to describe the interface.
Another common form of coupling is created when the requestor
expects the service provider to be at a specific location. UDDI
and other discovery vehicles
services are meant to avoid this form of coupling.
Two or more components can be coupled by requiring a common language
or common platform. To prevent this form of coupling, web services
use SOAP or some other form of platform
independent remote protocol.
|
Components can also
be coupled by putting responsiveness constraints on the produced.
The request response invocation
style, for instance, requires that the service provider respond
to a request quickly. The one way style
of method invocation generally creates a looser form of coupling
since it allows the service provider to respond “eventually.”
Finally, and most subtlety, components can be semantically coupled.
Web services has no magic answer to prevent this – that’s
why they pay software designers the big bucks. Semantic coupling
occurs when two web services are so dependent on each other that
it’s virtually impossible to use web service A without using
web service B (or a nearly identical implementation of B). Semantic
coupling is usually caused by web service A being too dependent
on aspects that really should be considered implementation details
of B.
|
