Service-Oriented Architectures Andrew Whitaker CSE451
Today’s Theme How do you allow hundreds of developers to work on a single website?
Amazon.com: The Beginning Initially, one web server (Obidos) and one database ObidosDatabase Internet Details: Front end consists of a web server (Apache) and “business logic” (Obidos)
Amazon: Success Disaster! Obidos Load balancer Amazon.com Internet Database Use redundancy to scale-up, improve availability
Obidos Obidos was a single monolithic C application that comprised most of Amazon.com’s functionality During scale-up, this model began to break down
Problem #1: Branch Management Merging code across branches becomes untenable HelloWorld.c development release Blue changes depend on Red changes (which may depend on other changes…)
Problem #2: Debugging On a failure, we would like to inspect what happened “recently” But, the change log contains numerous updates from many groups Bigger problem: lack of isolation Change by one group can impact others
Problem #3: Linker Failure Obidos grew so large that standard build tools were failing
Service-Oriented Architecture (1) First, decompose the monolithic web site into a set of smaller modules Called services Examples: Recommendation service Price service Catalogue service And MANY others
Sidebar: Modularity Information hiding (Parnas 1972): The purpose of a module is to hide secrets Benefits of modularity Groups can work independently Less “synchronization overhead” Ease of change We are free to change the hidden secrets Ease of comprehension Can study the system at a high level of abstraction public interface List { } // This can be an array, a linked-list, // or something else
Systems and Information Hiding There is often a tension between performance and information hiding In OS’s, performance often wins: struct buffer { // DO NOT MOVE these fields! // They are accessed by inline assembly that // assumes the current ordering. struct buffer* next; struct buffer* prev; int size; … }
Service Oriented Architectures (2) Modularity + a network Services live on disjoint sets of machines Services communicate using RPC Remote procedure call
Remote Procedure Call RPC exposes a programming interface across machines: interface PriceService { float getPrice(long uniqueID); } Client Server PriceImpl getPrice()
SOA, Visualized Website Shopping Cart Price Recommendation Catalogue All services reside on separate machines All invocations are remote procedure calls
Benefits of SOA Modularity and service isolation This extends all the way down to the OS, programming language, build tools, etc. Better visibility Administrators can monitor the interactions between services Better resource accounting Who is using which resources?
Performance Issues A webpage can require dozens of service calls RPC system must be high performance Metrics of interest: Throughput Latency Both average and the variance
SLAs Service performance is dictated by contracts called Service Level Agreements e.g., Service Foo must Have 4 9’s of availability Have a median latency of 50 ms Have a 3 9’s latency of 200 ms
Amazon and Web Services Allow third-parties to use some (but not all) of the Amazon platform Front-end website Catalogue Sleds.com Order Processing Shopping Carts Amazon.com
Searching on a Web Site
Searching Through a Web Service class Program { static void Main(string[] args) { AWSECommerceService service = new AWSECommerceService(); ItemSearch request = new ItemSearch(); request.SubscriptionId = "0525E2PQ81DD7ZTWTK82"; request.Request = new ItemSearchRequest[1]; request.Request[0] = new ItemSearchRequest(); request.Request[0].ResponseGroup = new string[] { "Small" }; request.Request[0].SearchIndex = "Books"; request.Request[0].Author = "Tom Clancy"; ItemSearchResponse response = service.ItemSearch(request); Console.WriteLine(response.Items[0].Item.Length + " books written by Tom Clancy found."); }
Other Web Services Google Calendar Maps Charts Amazon infrastructure services Simple storage (disk) Elastic compute cloud (virtual machines) SimpleDB Facebook Ebay …