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

Services Provide the Moving Parts 113
Service-Level
Understanding
Information/Data-Level
Understanding
Data
Application
Data
Figure 6.3 In Chapter 5, we created an information model, or a data/informationlevel
understanding. In this chapter, we look at application behaviors that may be
exposed, or a service-level understanding.
Figure 6.4 shows us the process we follow in this chapter, moving from a
data-level understanding where we created the information model of the
problem domain to a service-level understanding. Thus, we have the core
service model, which provides a jumping-off point to cloud computing, or at
least a foundation to make core architecture calls around the processing of
services, either on-premise or in the cloud.
The candidate services are all services identified within the problem domain
that have the potential of becoming services. We list them to make sure
we identify the right services by identifying and sorting through all services.
This deliverable is nothing more than a list of services and what each does.
We defined the candidate services for our case study earlier in this chapter,
creating a basic list of the services that we think should be services, but
we are not sure yet. The rule of thumb is, when in doubt, add it in as a candidate
service. You can always remove it later.
Services and information creates the links between the candidate services
and the data that is bound to the services. For instance, when considering the
Update_Customer service, we can determine that Update_Customer is bound
to customer data, perhaps First_Name, Last_Name, and Customer_Number.
We talk more about this in the next section. However, let’s look at this in the
context of our case study.