Cloud Computing and SOA Convergence in Your Enterprise: A Step ...
Cloud Computing and SOA Convergence in Your Enterprise: A Step ...
Cloud Computing and SOA Convergence in Your Enterprise: A Step ...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
118 Chapter 6 Work<strong>in</strong>g from <strong>Your</strong> Services to the <strong>Cloud</strong>s<br />
<strong>and</strong> exposed, we can place them on on-premise or cloud-delivered platforms,<br />
as depicted earlier <strong>in</strong> Figures 6.1 <strong>and</strong> 6.2.<br />
Keep <strong>in</strong> m<strong>in</strong>d that services have the follow<strong>in</strong>g capabilities with<strong>in</strong> this<br />
type of architecture:<br />
The ability to <strong>in</strong>voke services as if they were native no matter where they<br />
exist, on-premise or cloud-based, over the local network or the Internet.<br />
The ability to mix <strong>and</strong> match services with<strong>in</strong> composite applications or<br />
processes, s<strong>in</strong>ce the <strong>in</strong>terfaces are typically st<strong>and</strong>ard (e.g., Web Services<br />
Description Language <strong>and</strong> Simple Object Access Protocol).<br />
The ability to manage <strong>and</strong> govern services centrally.<br />
Underst<strong>and</strong><strong>in</strong>g Coupl<strong>in</strong>g for the <strong>Cloud</strong>s<br />
One of the key concepts to consider when talk<strong>in</strong>g about services <strong>and</strong> cloud<br />
comput<strong>in</strong>g is the notion of coupl<strong>in</strong>g. We need to focus on this because <strong>in</strong><br />
many <strong>in</strong>stances, coupl<strong>in</strong>g is not a good architectural choice consider<strong>in</strong>g that<br />
the services are not only hosted with<strong>in</strong> separate data centers but hosted by<br />
one or more cloud comput<strong>in</strong>g providers.<br />
S<strong>in</strong>ce the beg<strong>in</strong>n<strong>in</strong>g of comput<strong>in</strong>g, we have been deal<strong>in</strong>g with the notion<br />
of coupl<strong>in</strong>g, or the degree that one component is dependent on another component,<br />
<strong>in</strong> the doma<strong>in</strong>s of both applications <strong>and</strong> architectures. Lately, the<br />
movement has been toward loose coupl<strong>in</strong>g for some very good reasons, but<br />
many architects who build enterprise architectures that leverage cloud comput<strong>in</strong>g<br />
underst<strong>and</strong> the motivations beh<strong>in</strong>d this because we do not want to become<br />
operationally dependent on a component we do not own nor control.<br />
Break<strong>in</strong>g this concept down to its essence, we can state that tightly coupled<br />
systems/architectures are dependent on each other. Thus, changes to any one<br />
component may prompt changes to many other components. Loosely coupled<br />
systems/architectures, <strong>in</strong> contrast, leverage <strong>in</strong>dependent components <strong>and</strong> thus<br />
can operate <strong>in</strong>dependently. Therefore, when look<strong>in</strong>g to create an <strong>SOA</strong> <strong>and</strong> leverage<br />
cloud comput<strong>in</strong>g resources, generally speak<strong>in</strong>g, the best approach is a<br />
loosely coupled architecture.<br />
Keep <strong>in</strong> m<strong>in</strong>d that how loosely or tightly coupled your architecture exists<br />
is a matter of requirements <strong>and</strong> not as much about what is popular. Architects<br />
must underst<strong>and</strong> the value of cloud comput<strong>in</strong>g <strong>and</strong> loose coupl<strong>in</strong>g <strong>and</strong><br />
make the right calls to <strong>in</strong>sure that the architecture matches the bus<strong>in</strong>ess ob-