Back to the basics

                                Sitaram Lanka
                                 Amazon.com
                             mailto:lanka@amazon.com


The first generation architectures that supported the back office of the various web servers 
dealt with availability and scalability as an after thought. Obviously middleware products 
such as TP monitors, and light weight messaging infra-structure must be brought to bear to 
achieve sacle and availability. An even more important issue is to integrate these middleware 
solutions with existing legacy applications. It has been our exeprience that such an 
integration is time consuming, error prone and ends up being a lot of work at the application 
level. Perhaps, in due time, the middle-ware products will solve some of these problems, thus 
reducing the burden on the application writer.

These issues can be more concretely stated in the context of a specific application being 
worked on at Amazon.com. The "payment systems" application essentially services all payment 
needs at Amazon.com. On one hand, the payment systems application connects to the various 
clearing house banks and supports: different payment methods -- credit cards, direct debits, 
and checks; several curriencies; security issues; different protocols to communicate to 
different banks and deal with various failure scenarios. On the other hand, it communicates 
with several client applications -- the order processing engine, and customer service. The 
problems we had to solve was to make a legacy payment systems application scalable, highly 
available and decouple the clients from the various clearing house banks. We employed 
asynchronous messaging framework to: decouple the clients and the payment systems, for 
scalability and for fauly tolerance. Integrating with existing applications was involved -- 
participating in a closed event loop, signal handling and multithreaded issues, error 
handling end-to-end, dealing with multiple message formats and various versions of 
message formats, were some of the thorny issues.

In summary, applications are better off designing for scale and availability from the start. 
Middleware products should close some of the gaps that are being filled in by the application 
writers. Moreover, useful middleware products such as a workflow engine that is integrated 
with the messaging infra-structure are still at their infancy and would aid in speeding up 
such an integration.