Revisiting the Business Trip in the Not-Too-Distant Future
Let’s revisit C. R.’s business trip described in Chapters 1 and 2 to summarize the Web services, service-oriented architectures (SOAs), and cloud computing related to the business trip. Page references appear within parentheses indicating where you can find more information on the topic in this book.
Services for C. R.’s Business Trip
Chapter 2 provided an introduction to the technology used for C. R.’s business trip. Figure 14.1 is a redrawing of Figure 2.1 from Chapter 2 to show the services and interconnections used to plan and manage his trip.
Figure 14.1 Details of services and data interchange related to C. R.’s business trip.
In all likelihood, there are probably many hundreds of services used in C. R.’s business trip. There are also multiple SOAs assembled from the services. Figure 14.1 shows the collections of services (see page 160). The services are represented in the figure as circles. The collections are represented by the rectangles around the circles.
Notice how everything is connected using Web services (see page 19) within the Internet. In Figure 14.1, the Internet is represented by the vertical shaded area. Web services are shown as a black line within the shaded area. This represents that Web services messaging protocols (SOAP, REST, JSON, etc.) are a subset of all protocols that can be used on the Internet.
There are two enterprise service buses (ESBs) in the figure (see page 62). One is a specialized ESB for the services available related to the big data store and the business information (BI)/analytics in a virtual private cloud. In addition to facilitating the message passing within the virtual private cloud, the ESB also acts as a gateway to the Internet for the services in this particular virtual private cloud (see page 42).
The second ESB in the figure is used by the internal services for C. R.’s organization. Similar to the ESB in the virtual private cloud, this ESB is used for facilitating the message passing among the internal services in C. R.’s organization. It also acts as a gateway to the Internet. C. R’s organization defined a standard semantic vocabulary (see page 29) to use with its ESB. This means that from within this ESB, all services appear to use the same vocabulary and communication protocol, including external services that are in the public cloud, through the use of adapters (see page 63).
Other collections of services in Figure 14.1 may use an ESB. You can use those services without knowing whether or not the service uses an ESB. All you need to know is the top-level service interface they present to the Internet via Web services.
The smartphone applications at the left in the figure represent only the applications that were mentioned in the business trip story. C. R. undoubtedly has more applications than this on his smartphone.
What you don’t see in Figure 14.1 is any hardware. Presumably, everything in the figure executes on virtual machines/servers in data centers (see page 166). The services could be moved to different data centers and there would be no change in the figure. Where the services actually execute is technically not important. There can be legal and other nontechnical reasons for caring where data centers are located.
The data centers are what underlie cloud computing from cloud providers. One of the features that distinguishes cloud computing from just a data center is that cloud computing provides elasticity: “Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time.”1
Nearly all the services in the figure are software as a service (SaaS) cloud providers (see page 42). For example, the customer relationship management (CRM) service and the document scanning service used by C. R. on his business trip are SaaS. These are the cloud provider’s own or custom software.
The big data store and the BI/analytics software were implemented using a platform as a service (PaaS) virtual private cloud provider (see page 42). That software was developed by C. R.’s organization using a cloud provider’s development tools and a NoSQL database management system. C. R.’s organization realized that it needed the capabilities of a cloud (elasticity of resources, high availability, etc.) for storing and analyzing this data but did not want to build a data center to provide all the features of a cloud-computing environment. This way, it only pays for resources that it uses rather than investing upfront in the capabilities and a cloud and the ongoing management costs.
C. R.’s organization retrofitted many of its internal systems to act as services and use the internal ESB. Note that the internal systems are not in any type of cloud. They are probably supported using a data center run by C. R.’s organization. But C. R.’s organization did not see a reason to create a private cloud for its internal services.
The collections of services shown in this figure were used to build multiple SOAs. C. R.’s organization has an SOA that includes the collections of the services at the bottom in the figure. Its SOA mixes public and virtual private cloud computing with the non-cloud computing of its internal data center. Many of the services shown may also have their own SOAs. Among those that might include the airlines, car rental agencies, and the local department of transportation (DOT). The VPA component also undoubtedly has a sophisticated SOA.
Figure 14.1 allows for more connections than were shown in Figure 2.1 because everything is connected using Web services. So, given the correct authorizations/permissions, other capabilities could be constructed. For example, there could be a new service created out of services from the airlines, car rental agencies, hotels, museums, and art that would be a specialized travel service that creates custom travel arrangements for people interested in specific types of art.
The Future for C. R.’s Organization
What is likely to happen at C. R.’s organization as the remaining existing systems age? Will the organization take advantage of the services interface it has in place for these systems and upgrade the hardware and software that is “under” that interface? The other option his organization would have is to maintain that interface but move more of the processing to the cloud. Will it move most of the processing to the cloud and pay for resources as it uses them? A lot probably depends on the experience the organization has with cloud computing and the ongoing development of standards that could make the use of cloud computing more enticing.
Summary
This chapter tied much of the technology of Web services, service-oriented architectures, and cloud computing back to the story of C. R.’s business trip in Chapters 1 and 2. It provided an overview and summary for much of the material that is in this book.
1Peter Mell and Timothy Grance, The NIST Definition of Cloud Computing: Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-145, Sept. 2011, p. 2.