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 ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
110 Chapter 6 Work<strong>in</strong>g from <strong>Your</strong> Services to the <strong>Cloud</strong>s<br />
same applications <strong>and</strong> services but never give up the ability to leverage these<br />
systems <strong>and</strong> services. Services are typically location <strong>and</strong> platform <strong>in</strong>dependent.<br />
This means that no matter where the services exist, on-premise or cloudbased,<br />
they are accessible as if they were local.<br />
In many architectural systems, we would create new services as part of<br />
the services model. This book looks at methods to extend an <strong>SOA</strong> to cloud<br />
comput<strong>in</strong>g if that approach make sense. Thus, we limit our discussion to<br />
identify<strong>in</strong>g exist<strong>in</strong>g services, document<strong>in</strong>g those services, <strong>and</strong> relocat<strong>in</strong>g<br />
those services if cost justified. Keep <strong>in</strong> m<strong>in</strong>d that you could be build<strong>in</strong>g new<br />
services as part of this process.<br />
Aga<strong>in</strong>, the ability to address all of these systems through services provides<br />
the architect with the ability to access the underly<strong>in</strong>g application behavior<br />
<strong>and</strong> <strong>in</strong>formation as if the application <strong>and</strong> services were native <strong>and</strong><br />
local. The use of services provides location <strong>in</strong>dependence, mean<strong>in</strong>g you can<br />
leverage services no matter where they exist. A s<strong>in</strong>gle application could be<br />
made up of dozens of services hosted <strong>in</strong> a dozen different locations, onpremise<br />
<strong>and</strong> <strong>in</strong> the clouds. This is why we use services with<strong>in</strong> the context of a<br />
widely distributed system, <strong>in</strong>clud<strong>in</strong>g an <strong>SOA</strong> us<strong>in</strong>g cloud comput<strong>in</strong>g.<br />
S<strong>in</strong>ce they all expose <strong>in</strong>formation <strong>and</strong> behaviors as services, which<br />
typically use a common <strong>and</strong> st<strong>and</strong>ard <strong>in</strong>terface such as Web Services, they are<br />
location <strong>in</strong>dependent (cloud or on-premise), platform <strong>in</strong>dependent, programm<strong>in</strong>g<br />
language <strong>in</strong>dependent, <strong>and</strong> user <strong>in</strong>terface <strong>in</strong>dependent—that is, if<br />
they are properly created.<br />
Cont<strong>in</strong>u<strong>in</strong>g with our case study from Chapter 5, “Work<strong>in</strong>g from <strong>Your</strong><br />
Data to the <strong>Cloud</strong>s,” Blue Mounta<strong>in</strong> Hammocks, or BMH, has<br />
A sales automation system that uses Oracle as the database, with the<br />
application built <strong>in</strong> C++. This application is also connected to BMH’s<br />
onl<strong>in</strong>e store.<br />
An open source <strong>in</strong>ventory management system built us<strong>in</strong>g Java <strong>and</strong><br />
MySQL.<br />
A general ledger system that uses a packaged account<strong>in</strong>g system built<br />
us<strong>in</strong>g dBase, a PC-based database.<br />
They all run on different hardware <strong>and</strong> software platforms, on-premise.<br />
BMH wants to underst<strong>and</strong> its architecture <strong>and</strong> potentially move pieces<br />
of it to cloud comput<strong>in</strong>g. We already obta<strong>in</strong>ed a data-level underst<strong>and</strong><strong>in</strong>g<br />
when we created the <strong>in</strong>formation model <strong>in</strong> Chapter 5.