Page 256 -

255
Q6-3 How Does the Cloud Work?

from salesperson to salesperson, and possibly from day to day with the same salesperson. The
records of approvals are inconsistent. Such an organization will have varying levels of process
quality and inconsistent results, and should the company decide to open a facility in another city,
these operations cannot be readily duplicated, nor should they be.
Using SOA principles, each department would formally define the services it provides.
Examples are:
For the Credit Department:

• CheckCustomerCredit
• ApproveCustomerCredit
For the Inventory Department
• VerifyInventoryAmount
• AllocateInventory
• ReleaseAllocatedInventory
Further, for each service, each department would formally state the data it expects to receive
with the request and the data it promises to return in response. Every interaction is done exactly
the same way. There is no personal contact between certain people in the departments; no sales-
person need know who works in Credit or Inventory. Instead, requests are emailed to a generic
email address in Credit or Inventory, and those departments decide who will process the request
and how it will be processed. No department has or need have any knowledge of who works in
another department nor how the department accomplishes its work. Each department is free to
change personnel task assignments and to change the way it performs its services, and no other
department needs to know that a change occurred. In SOA terms, we would say the work of the
department is encapsulated in the department.
With this organization, if Best Bikes wants to add another Inventory Department in another
city, it can do so and no salesperson need change the way he or she sets up, submits, or receives
responses to requests. Sales continues to send a VerifyInventoryAmount service request, format-
ted in the standard way, to the same email address.
With multiple sites, the Inventory function would change the way it implements service
requests to first identify which of the several Inventory Departments should process the request.
Sales would not know, nor need to know, this happened. Best Bikes could dynamically create 1,000
Inventory Departments and the Sales Department need not change anything it does. Later, it could
reduce those 1,000 Inventory Departments to three, and, again, sales need not make any change.

SOA for Three-Tier Architecture

From this discussion, you can see how SOA is used to enable cloud processing. The description
and advantages and disadvantages of this analogy for SOA are the same for the cloud. Consider
Figure 6-13, which shows the three-tier architecture with SOA drawn in. In this case, the
commerce server application formally defines services that browsers can request, the data they
must provide with the request, and the data that each will receive in response to the request.
Sample services are:

• ObtainPartData
• ObtainPartImages
• ObtainPartQuantityOnHand
• OrderPart

And so forth. Again, each service also documents the data it expects and the data it will return.
Now, JavaScript (or another code language) is written to invoke these services correctly. That
JavaScript is included as part of the Web pages the server sends to the browsers, and when users
employ the browsers to purchase, the JavaScript behind the Web page invokes the services in the
correct way.