Overview
|
| System Architecture |
MyAmazonPlus service is a wrapper around Amazon.com. Clients talk to the MyAmazonPlus server through SOAP [1], which in turn talks to Amazon.com through SOAP, or more specifically, using Amazon Web Services 4.0 API (or AWS 4.0, now renamed to Amazon E-commerce Service 4.0) [7].
MyAmazonPlus supports the following features:
|
| MyAmazonPlus Service |
The MyAmazonPlus server is implemented on top of Apache Axis. We adopted the WSDL-first approach. That is, we designed the WSDL for the service first, and then used Axis' WSDL2Java tool to generate Java classes. The implementation of the service makes heavy use of Amazon's AWS 4.0 SDK. AWS exposes a comprehensive list of interfaces to Amazon.com, such as item searches, item lookups, and shopping cart management. We built simple wrapper interfaces around a small portion of the interfaces exposed by AWS. MyAmazonPlus provides the following operations to the clients:
A Subscription Id is required to invoke AWS services. The Subscription Id is obtained when you register with AWS. Thus all of the operations above require a Subscription Id as an additional argument. We also deployed an instance of our service with authentication, called MyAmazonSecure. We implemented simple password-based user authentication using WS-Security. We consulted Apache WSS4J's source code, but didn't use their library in the end. We installed a UsernameTokenHandler on the MyAmazonPlus server, which will intercept the wsse:security header in the incoming SOAP envelope, extract the username and password from the header and put them into the current MessageContext as properties, and set the "processed" flag of the header to be true. When the message reaches the service implementation itself, the username and password will be read from the MessageContext and compared to a preset username/password pair. The authentication succeeds if and only if the username/password read from the SOAP header matches the preset username/password.
|
| MyAmazonPlus Client |
The client side was a GUI application written in C#. Figure 2 shows the primary user interface of the client side. The user interface is divided into two regions. The upper region provides research setting for users to locate the items they desire on amazon.com and a status summary of the current shopping cart. The lower region uses three separate tab windows to maintain the search result, shopping cart as well as the watch list on the client side. Users can use the search result list to find their desired item, read item reviews and product details (author, ISBN, weight, release date) and add selected items to shopping cart or watch list.
To achieve better usability, the keyword search function on the client side is implemented asynchronously. So the users can still browse the previous search results after a new search request has been submitted to the server. Other web services invocations, such as AddItemsToCart, RemoveItemFromCart, are implemented synchronously. We implemented the web services publication and discovery on the client side by using Microsoft UDDI .Net SDK 2.0 beta [3]. We publish our services on http://test.uddi.microsoft.com with business name "Cal Berkeley SIMS web services course - Jingtao and Kai". UDDI publication/discovery functions can be accessed from Configure -> UDDI -> Publish / Discovery. On the client side, we implemented the WS-Security enhancement by using Web Services Enhancements (WSE) 2.0 SP2 for Microsoft .NET [4]. We didn't choose WSE 1.0 because the name space of WSE 1.0 is "xmlsoap", which is not compatible with the "oasis" namespace used by WSS4J and WSE 2.0. We implemented the username/password mechanism for our web services. The user name/password can be specified by users from Configure -> WS-Security -> User Name / Password. The users also can enable (i.e. switch to MyAmazonSecure service on the server) and disable (switch to MyAmazonPlus service on the server) the WS-Security enhancement by setting the Configure -> WS-Security -> Use Security checkbox.. A valid user name/password pair we chose is "webserv" and "sims04". The pre-compiled binary package of the client side can be downloaded form [5], it requires Microsft .Net Framework 1.1 in the host operating system (Windows 2000/XP/2003). Additional libraries to support UDDI publish/discovery and WS-Security have been included in the binary distribution. The source code of the client side can be downloaded from [6]
|
| Performance and Scalability Analysis |
We employed several techniques to ensure our service is scalable and has good performance. First, we abide by the end-to-end design principle [12] and place most intelligence at the two end points (clients and Amazon.com). MyAmazonPlus server does not maintain any state (e.g., shopping cart) for the clients. Instead, clients maintain local shopping carts and send the final shopping carts to MyAmazonPlus server only when placing orders. As a result, the workload on the server will not increase dramatically when the number of clients increases. In addition, this stateless end-to-end approach, as proved to be compelling by the evolution of Internet, will make our service robust to temporary communication failure and network congestions. Second, we provide coarse-grained operations, i.e., addItemsToCart and deleteItemsFromCart. The following figure illustrates how coarse-grained operations improve performance.
AWS provides minimum support for coarse grained operations (e.g., it allows to add up to two items to cart at a time). Thus although the interface of MyAmazonPlus is coarse grained, the second leg of, say, an addItemsToCart operation, is still fine grained. For this reason, we put our client behind a 56kbps dialup line in our experiments that generated the above diagram, just to amplify the effect of coarse-grainedness. Finally, noticing itemSearch is the most expensive operation among all(each itemSearch operation needs 7-8 seconds to complete), we decided to cache results for recently requested search requests and serve itemSearch requests from this cache whenever possible. The cache size is fixed and we use the LRU (least recently used) cache eviction policy. To ensure the freshness of the results, the cache items must time out after a certain period of time. The parameters (e.g., size, timeout) of the cache are configurable.
|
| Lessons Learned |
We learned the following lessons while working on this project.
|
| References |
|
