Page 255 - Using MIS
P. 255
Q3 How Does the Cloud Work? 223
For the Inventory Department
• VerifyInventoryAmount
• AllocateInventory
• ReleaseAllocatedInventory
Further, for each service, each department would formally state the data that it expects
to receive with the request and the data that it promises to return in response. Every inter-
action is done exactly the same way. There is no personal contact between certain people
in the departments; no salesperson need know who works in Credit or Inventory. Instead,
requests are emailed to a generic email address in Credit or Inventory, and those depart-
ments 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 AllRoad 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, for-
matted in the standard way, to the same email address.
With multiple sites, the Inventory function would change the way it implements service re-
quests to first identify which of the several Inventory Departments should process the request.
Sales would not know, nor need to know, this happened. AllRoad 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 com-
merce 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 that 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.
The server tier can consist of three servers at 3 AM, 3,000 servers at 11 AM, 6,000 servers at
6 PM, and 100 servers at 10 PM. Furthermore, those servers can move around the world; at one
time of day, they can be all located in the United States, and at another time of day, they can all
be located in Europe, and so on. Nothing, absolutely nothing, in the browsers need change as
these servers are adjusted.
To take advantage of the multiple Web servers, a load-balancing program receives requests
and sends them to an available server. The load-balancing program keeps data about the speed
and health of all its assigned Web servers and allocates work to maximize throughput.