3 The Amazon E-Commerce Service

The Amazon e-commerce service (ECS)exposes a range of capabilities including the full Amazon product catalogue. A freely downloadable development kit enables developers to create value-added web-sites and services. In addition to exposing product information through comprehensive search capabilities, Amazon offer remote shopping cart resources that can be managed online and submitted for check-out processing.

We use the Amazon scenario to explore the benefits that semantic modeling of web-services can provide. We focus on the requirements for advertising & matchmaking; contracting & negotiation; process modeling & enactment, and express these in terms of a concrete and straightforward challenge for semantic modeling: to assist the customer in buying a copy of "The Description Logic Handbook" at the cheapest price.

The terminology of the scenario is drawn from the Web Services Architecture document (plus extensions from [Preist04]).

Advertising and Matchmaking

We don't assume from the outset that the customer will buy the book from Amazon. They may in fact consult many different book vendors and select the cheapest offer. We are interested in how the customer finds the Amazon service, and how detailed the service description needs to be. Let us be clear, we are not at this stage trying to describe the operational web-service interface for which one may continue to use WSDL. Rather we aim to describe, and advertise, the service in terms of its value proposition.

Advertising is therefore concerned with the description of this service offer and its flip-side the service requirement. It is unreasonable to expect Amazon to advertise their service in terms of each and every product available; they may instead publish a generalized service offer. For example, Amazon divide their product range into a number of offerings including Books, Music, DVDs, etc. The service offer may simply describe Amazon as a book vendor, assuming we have a readily available domain ontology that declares the concept of 'Books' together with a suitable 'offering' relationship. Another resource we have available to describe the type of service offered by Amazon is the MIT Process handbook that classifies the customer interaction with Amazon.com as an example of the 'Sell via electronic store with posted prices' business process.

The service offer is published in some form so that the Amazon service can be discovered either directly by the customer, or by using some third-party discovery service. The service requirements mirror the service offer, though we will assume the request is more general in the way it classifies the service but is more specific in the product detail. The requirements will define only a service that will 'Sell' a Book with the name 'The Description Logic Handbook'. To 'Sell' is more generic than to 'Sell via electronic store...', however the class of Books with this specific product name is more specific than Books in general. Therefore, even in this simple example there is no strict taxonomical relationship between the service offer and requirements.

The function of matchmaking is to identify the relationship (if any) between the service offer and the service request. We are primarily interested in matches in the intersection of the service offer and request. An additional conundrum appears when we consider the service offer, described above, in relation to other service offers. For example, consider an alternative offer that describes Amazon as a Music vendor. If Music is not explicitly disjoint from Books then there are also solutions in the intersection where Music is deemed synonymous with Books. What is the logical justification for ranking the Books offer over the Music offer? SWSL rules may be used to define this matchmaking relationship; the relationship between matching service offers and requirements. These rules may be interpreted by an agent to perform service discovery. Furthermore, the non-monotonic features of SWSL rules enable us to select the best matches available - selecting Amazon Books over Amazon Music.

Contracting and Negotiation

The abstract nature of the service offer means that we can't immediately see if the required book is actually for sale and at what price. The requester must enter into direct negotiation with the service provider agent to fill in the gaps - to come up with the service contract. The contract represents an agreement between the customer and the service provider, defining exactly the service (instance) to be provided. The contract must be specific about the required product, for the title may not be sufficient: for books the Amazon Standard Item Number (ASIN) provides a unique product code equivalent to the book's ISBN.

As with service descriptions and matchmaking, the service contract defines the content of a negotiation process. With Amazon ECS, negotiation involves a catalogue search that returns product info including price and availability. Only at this point do we have the raw material for a service contract - a tangible offer. To flesh-out and and shake-hands on the contract, the agent adds the book to the cart and proceeds to the checkout. We assume the final go-ahead to make the purchase is referred back to the customer. This style of negotiation follows a very simple take-it-or-leave-it  pattern, but requires a technically non-trivial choreography that differs between services. For this reason, we require a method of process modeling so that our agent can negotiate on the customer's behalf.

Process Modeling and Enactment

A key feature of the Service Oriented Architecture is its characterization of the tasks and actions concomitant with the negotiation and delivery of the service. Tasks are modeled as processes, which break down by way of composite processes into more primitive atomic processes that represent these basic actions. Additionally, every process is modeled in terms of its Inputs, Outputs, Preconditions and Effects (IOPEs) which provide an epistemic account of the impact of these actions on the knowledge-base of the agent. Through process modeling we aim to describe the overall negotiation task which involves actions that relate to catalogue search; remote cart management; and checkout processing (there are also tasks that pertain to service delivery, such as order tracking, that are not covered in the immediate scenario). The SWSL process model expresses declarative processes constraints rather than directly executable programs, providing additional flexibility to agents that may use them to govern, rather than determine, their behaviour. The process model is further underpinned by a theory of the semantics of these tasks which captures the meaning and purpose, over and above the mechanics, of the interaction.

For brevity we only model a subset of the Amazon ECS capabilities required to describe the book-buying scenario. One of the basic operations available to the customer agent is to search the product catalogue for the desired item. One of the actions available to the requester agent is to request an ItemSearch. This atomic process is defined below. The search index defines the Amazon store to be searched which for the scenario will be 'Books'. The 'title' of the book is a string as defined above which represents all or part of the required product name. The 'items' parameter represents the search output that will include potentially more than one matching item with pricing and availability details. The example is described using the presentation syntax which is a convenience notation that translates into SWSL-FOL axioms.

aws#ItemSearch(?searchIndex,?title,?items) {
      	Atomic
      	input aws#SubscriptionId xs#string
      	input aws#Operation xs#string 'ItemSearch'
      	input aws#SearchIndex xs#string ?searchIndex
      	input aws#Title xs#string ?title
      	input aws#ResponseGroup xs#string 'Offers'
	output aws#Items aws#ItemsOffered ?items
}

These examples are supported by the creation of a domain ontology that defines the structured objects that appear in the scenario, specifically definitions of 'ItemsOffered', using SWSL. 'ItemsOffered' is simply a collection of 'ItemOffered' (a 'Item') each of which may have a number of actual offers. The only property that is necessary for an item is the ASIN. This is subclassed in  ItemSearch to include offers detailing pricing and availability information. It is also subclassed in CartCreate to include the required quantity for each item.

prefix aws = _"http://webservices.amazon.com#".
prefix xs = _"http://www.w3.org/2001/XMLSchema#".

aws#Items [ aws#item => aws#Item ].
aws#Item [ aws#ASIN => xs#string ].

aws#ItemsOffered [ aws#item => aws#ItemOffered ] :: aws#Items.
aws#ItemOffered [ aws#offers => aws#Offers ] :: aws#Item.

aws#Offers [ aws#offer => aws#Offer ].
aws#Offer [
	aws#price => aws#Price,
	aws#availability => xs#string
].

aws#Price [
	aws#amount => xs#positiveInteger,
	aws#currencyCode => xs#string
].

The advantage of using a domain ontology is that we can work with the data indepedently of any particular message syntax. For example, it may allow us to compare the catalogue content with that of other online stores. We also have a level of abstraction that is resilient to minor version changes in the interface specification (unless there is a semantic difference). The service grounding should identify the appropriate domain ontology and provide enough information for a client to lift message content into this abstract ontology. Amazon web-services are interesting in this respect because they provide two alternative modes of service invocation with equivalent semantics. A Service Oriented Model utilizing SOAP over HTTP is supported, together with a REST-compliant Resource Oriented Model.

In the last example, nothing really changes other than the agent's knowledge of the product catalogue.  Contrast this with the effect of adding the book to the cart. Amazon provides a 'remote shopping cart' resource that is managed by the Amazon server. Operations on the cart allow an agent to add items to a new or existing cart; to clear and modify a cart; and to view the current contents of a cart. The real-world effect is the state-change of a remote shopping cart (a new cart resource is created). Any stateful resource  is described by a fluent that reflects the way it changes in response to events. Effects encode the changes that can be directly attributed to an action. Preconditions describe the state of the world (i.e. not just the knowledge of our agent) that must pertain prior to performing an action.

We look first at adding an item to a new shopping cart with CartCreate. We can add more than one item at a time so the input is again a collection of items. The response includes a URL from which the contents of the cart may be purchased. The existence of this new shopping cart is a statement of fact about the world so this is expressed as an effect; an assertion of the existence of the new cart with a specific cart identifier.

aws#CartCreate(?items,?url) {
	Atomic
	input aws#SubscriptionId xs#string
	input aws#Operation xs#string 'CartCreate'
	input aws#Items aws#ItemsRequested ?items
	output aws#CartId xs#string ?cart
	output aws#purchaseURL xs#anyURI ?url
	effect aws#cart(?cart)
}

This example require additional domain classes that define 'ItemsRequested'. This is again a subclass of 'Items' with the addition in 'ItemRequested' of the required quantity required.

aws#ItemsRequested [ aws#item => aws#ItemRequested ] :: aws#Items.
aws#ItemRequested [ aws#quantity => xs#positiveInteger ] :: aws#Item.

The 'items' are an output of item search and a required input to any cart operation. We can describe this linkage of inputs to outputs as a constraint on the relative ordering of an occurrence of a search and cart operation. In this case we wish to describe a sequential composition where we put the search before the cart. We describe this composite process as a shopping activity, and just like window shopping there is no implication that anything is actually purchased.

aws#shopping(?searchIndex,?title,?qty,?cart,?url) {
	Sequence
	occurrence ?o1 aws#ItemSearch(?searchIndex,?title,?items)
	occurrence ?o2 aws#CartCreate(?items,?cart,?url)
	?o1 soo_precedes ?o2
}

Currently, the Amazon API does not allow an agent to complete a purchase automatically, but each shopping cart has a purchase URL that the customer can visit to finalize the purchase. This creates an interesting challenge for process modeling. How do we represent these out-of-band actions that are not directly performed by the agent and are not grounded in web-services? The effect of order submission is also significantly different from the simple state-changes we see in shopping carts. Adding items to a cart does not commit the buyer to anything. However, when the buyer places a confirmed order, the seller is then under an obligation to deliver the product (and the customer is under obligation to pay). This is understood to be central to the buyer/seller contract and may be described as an obligation between the requester and provider. It represents a commitment to honour an agreement at all future times (until it is discharged). In reality, these obligations are conditional. The buyer has the right to cancel the order at any time up until the order is actually dispatched. Conversely, a permission proffers the right at some future time to perform an action (until it is withdrawn). Both obligations and permissions are described in the web-service policy model.

aws#purchase(?cart,?url) {
	Atomic
	input aws#purchaseURL xs#anyURI ?url
	effect aws#commit(?cart)
}