Over the past few years Web services have grown from a conceptual draft based on the ideal of cross-platform programmatic interoperability to a formal specification and a vision of grand-scale distributed system architectures. Today we are putting that vision to work and designing systems with service-oriented architectures that are critical to our businesses. Amazon.com has been one of the forerunners in the adoption and promotion of Web services. Consistently striving to remain on the forefront of technology, Amazon has thoroughly embraced Web services - so much so in fact, that you can tie some serious revenue numbers directly to the external use of Amazon's Web services. For the remainder of this article I will outline for you just one of the avenues Amazon has taken to leverage Web services to generate new business.

Most of us are familiar with Amazon.com and have come to notice that other companies offer many of the products sold on Amazon; it isn't uncommon at all to browse direct product offerings from dozens of merchants such as Bombay and Sharper Image on Amazon.com. In fact third-party sellers play a critical role for Amazon in terms of breadth and depth in product offering, but how does the product information of these third-party sellers get there? Also, how are business-critical order, inventory, and price data exchanged reliably and in a timely manner for hundreds of merchants utilizing various platforms and technologies?

The answer: Amazon has developed a highly scalable SOA platform that leverages industry-standard technologies and incorporates the ability to conduct secure transactions, thus effectively allowing third-party sellers to fully control product listings directly on Amazon.com. A true service-oriented architecture allows merchants the ability to put their products in front of millions of Amazon customers; in return Amazon captures a commission on the sale and everyone is happy. The challenge of building a platform to handle hundreds of business partners with millions of transactions took some serious considerations into account.

Knowing that business partners would be utilizing various technologies to programmatically exchange data required not only a standard for the data format but also a security standard for the data transmission as well. By relying on XML schemas to define the structure of the documents to be exchanged (HTTPS as the transport protocol, and SwA [SOAP with Attachments] as the communication protocol), those key transport issues are addressed. Amazon publishes to its third-party sellers the XSD specification to each message Amazon sends and receives. A third-party seller has only to implement the XSD, extract their product data, transform it per the XSD, and post it to Amazon with a SOAP message over HTTPS.

Another design consideration involved the assumption that business partners would have a myriad of system designs that if addressed individually would require custom data definitions, connectors, and message exchange choreography for each partner. This forced the idea that the Amazon platform must be agnostic with regard to partner systems; nothing better lends itself to being agnostic than a service-oriented architecture. In some cases the disparity in partner systems can be so extreme that a system component such as fulfillment, which is critical to business operations, can be owned by a separate company at a different physical location. By encapsulating services in the Amazon interface the partner has significant flexibility in their integration design and can easily incorporate disparate systems.

Because real dollars are impacted with every message exchange, all message exchanges had to be secured and guaranteed. All exchanges utilize HTTPS and require three credentials for validation against an existing account. In order to ensure business-critical documents such as order reports are exchanged successfully an exchange acknowledgement has been incorporated. As displayed in the diagram below, the first operation is a service request for existing document IDs. The return value if null delays for 15 minutes and then requests again. If the return is positive it will contain an array of document IDs. At this point we step into the scope of a document exchange. By calling the getDocument service and passing a document ID, the return result will be the physical document represented by the ID, in this case an order report. Now the document provider (Amazon) knows a request has been made by the requestor (merchant partner) and has responded appropriately by sending the document, but does not know if the document has reached the requestor successfully. The requestor now needs to ensure the successful receipt of the document and perform the final operation of acknowledging to the provider that the document has been received successfully. Subsequently the provider can transfer the document ID from the "outbound" queue to the "sent" queue. In all, this design ensures the state of a document is managed by the requestor who is responsible for follow up operations - in this case fulfillment of the order.

By implementing the system designs in Figure 3, Amazon has been able to successfully integrate product offerings from hundreds of merchants - from small domestic companies to large multinational corporations, Amazon's single platform scales to support them all.