Usage Scenario:
Conversation Protocols of Car dealer / Bookseller Services

Name: Conversation Protocol of the book purchase service

Author(s): Boualem Benatallah, Fabio Casati, Farouk Toumani

URL(s) or other references:

1. B. Benatallah, F. Casati, F. Toumani and R. Hamadi, Conceptual Modeling of Web Service Conversations, In J. Eder and M. Missikoff eds, Advanced Information Systems Engineering, 15th International Conference (CAiSE'03), Klagenfurt, Austria, June 16-18, 2003, Springer, pp. 449-467, LNCS 2681;

Domains: searching and selling books


A bookstore provides a portal that allows user to search and buy books. This use case attempts to describe the conversation protocols of these services (i.e, operations, their implications and effects from user perspective, activation properties).

The main purpose for this scenario is to understand and make explicit the need for semantic at the protocol level, that is, the need for endowing protocol specifications with semantic annotation so that both the users and the middleware are aware of the implications (effects) of invoking a certain operation when the service is in a certain state. The bookseller service is just a motivating example to motivate the need for semantic annotation in protocol definition languages such as BPEL, WSCL, WSCI, and the like.


These scenarios show that existing service description models (e.g., WSDL, the above mentioned protocol languages, and also the other WS-XX specs that are supposed to be consumed by the Web services middleware, such as WS-Transaction) do not cater for describing some important aspects of web services conversation such as implications and effects of an operation.

Actors & Goals

The Web services of the Booksellers and of the customers are the main actors for this specific use case. Semantic annotations are however meant to be "consumed" by both developers (typically, developers of the customer's web service) to understand how to  write applications that correctly interact with the bookseller's service, and by the semantic web services middleware, at runtime, to execute actions as prescribed by the annotations.

Stakeholders & Interests

Interested parties are the bookseller, the customer, and middleware vendors. On the service provider's  (bookseller's) side, a richer protocol language enables the definition of more sophisticated behavior (in the specific example of a bookseller, this may include specifying different "penalties" for the cancellation of an order, and different constraints to denote when an order can be cancelled).

On the client's side, the interest lies in easier understanding of the service's behavior and in the simplified development, thanks to the additional support that is enabled by design and runtime tools that are aware of the semantic annotations  and of how to leverage them.

On the middleware vendor's side,

Modification History

Use Case Title:

Bookseller's conversation protocol


Same as scenario actors


search and order books




The steps of the conversation protocol of the booksellers are described in [REF1]: 

This includes searching for a book, ordering a book, cancelling an order (before the shipment of the book), shipping a book, returning a book (this is allowed with a period of time).

 We have used an extended state machine model to describe conversation protocols.


Ontologies and Semantic Descriptions

We based our analysis on Web portals (in this case booksellers' portals) rather than web services because: (i) Web services area is still rather immature, (ii) E-commerce portals often include ``terms and conditions’’ documents that describe the semantics of many operations (in particular those that involve some form of commitment on the client or the provider side). We have used a simple state machine model and we extended it to represent abstractions such completion (implications and effects of an operation from a user perspective, e.g. whether user can cancel an operation and what is the cancellation cost) and activation abstractions (when a transition one state to another must/can occur).

Completion abstractions include:

-        Compensation (for example, user can cancel a previously performed operation by invoking a given compensation operation). Compensation may have an associated cost and is typically allowed only within a period of time. In the bookseller's example, these include the following:

            1. A buyBook transition can be canceled only within a certain time interval T_max

            2. if it is canceled before T_min, there are no penalties

            3. if it is canceled after T_min but before T_max, shipping expenses have to b refunded.

-        Resource locking (the execution of certain operations seem to acquire some resources for the client (e.g., hold seats on a plane)). Again this may come with a cost and may have a validity limited in time. In the bookseller's example, a used copy of a book can be reserved (locked), but only for a certain period of time. After this period, the lock expires. In a variation of the scenario, one can think that the "locking" is only available to certain customers ("gold" customers), or at a cost.

Activation abstractions:

these include implicit and timed transactions. There are cases in which transitions between states occur without an    explicit invocation of operations. Some of these transitions are timed in the sense that they occur automatically, e.g., after a time interval is elapsed.

For both activation and completion abstractions, the issue is how to semantically characterize the definition of each state transition in the protocol. The characterization may be horizontal or vertical. Horizontal semantic annotations are not specific to any vertical domain, but are instead generally applicable to characterize the behavior of many different services.  The examples provided above are horizontal, as they deal generically with "cancellation", "time", and "cost".

Other semantic abstractions/annotations can be vertical. For example, the bookseller can state in the protocol definition that   the effect of a certain state transition (triggered by an operation invocation) consists in activating a subscription to a journal.

Reasoning Techniques Required

-        Compatibility between services

-        Validation of service composition models (e.g., checking the correctness of a composite service with respect to the usage of component services)

-        Joint analysis of composition and conversation models