Cloud Computing and SOA Convergence in Your Enterprise: A Step ...

120 Chapter 6 Working from Your Services to the Clouds
component should not take down other components in the system, such as a
cloud platform outage stopping the processing of key on-premise enterprise
applications. Therefore, loose coupling creates architectures that are more resilient.
Moreover, loose coupling also better lends itself to creating failover
subsystems, moving from one instance of a component to another without affecting
the other components, which is very important when using cloud
computing platforms.
It should be noted, however, that not all tight coupling is bad. In some
cases, it makes sense to more tightly couple components, such as when the
dependencies are critical to the design. An example would be two services
that cannot work apart and must function as one, and thus are better tightly
coupled—for instance, a transactional service that requires the remote databases
to be up and running for the service to work correctly. These services
should be tightly coupled, and it is not a bad thing to do so. You have to look
at your requirements and determine the degree of coupling required in your
architecture, and it may not always be loose coupling.
Are You Loosely Coupled
Now that we know the basic differences between a tightly and loosely coupled
architecture, as well as the advantages, perhaps it is a good idea to break down
loose coupling into a few basic patterns: location independence, communication
independence, security independence, and instance independence.
Location independence means that no matter where the service exists, the
other components that need to leverage the service can discover it within
a directory and leverage it through the late binding process. This comes
in handy when you are leveraging services that are consistently changing
physical and logical locations, especially services outside of your organization
that you may not own, such as cloud-delivered resources. Your
risk calculation service may exist on-premise on Monday and within the
cloud on Tuesday, and it should make no difference to you.
Dynamic discovery is key to this concept, meaning that calling components
can locate service information as needed and without having to
bind tightly to the service. Typically, these services are private, shared, or
public services as they exist within the directory.
Communications independence means that all components can talk to
each other no matter how they communicate at the interface or protocol