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

112 Chapter 6 Working from Your Services to the Clouds
instances, providing better resource utilization and scalability. In essence,
you talk to the applications through the services interface. The
location where the instance actually runs is transparent to you.
We have the ability to mix and match services for use within composite
applications or composite processes. This provides the agility aspect with
the use of cloud computing architecture and SOA. Not only can you create
application processes quickly to solve business problems, but you can
recreate them as needed and thus provide the core value of agility. The
use of cloud computing provides even more value because we do this using
more cost-effective computing platforms.
Thus, we have the purpose of this chapter: the need to deal with all of
our IT assets as services. We must define them with enough detail to figure
out how they work and play well within our SOA and how some of those services
may reside on cloud platforms if we need them to live there. Assuming
that you are an enterprise or SOA architect, we provide you with enough information
about the “how” that you can be productive in your own cloud
computing replatform project.
Before we continue with our case study, let’s get back to the basics.
Services Provide the Moving Parts
We look at our architecture as a collection of services, and thus as an SOA,
because it is much easier to break the architecture down to a logical, functional
primitive and build it back up as a defined set of services. Once we do
that, we have a starting point for figuring out which services should exist onpremise
and which services should potentially reside in the cloud (see Figures
6.1 and 6.2).
We build services on top of data or information, which we defined in the
previous chapter as the information model. We did that first because services
typically process information or are bound to data. In many instances, it is
much easier to define services after defining data, but some choose to do the
reverse, from the services to the data. Either way works, and how you approach
this depends on your problem domain and on your own requirements
and preferences.
At this point, you have a data-level understanding of your problem domain,
and now we move up to a service-level understanding (see Figure 6.3).