Xpect provides a generic framework for electronic commerce where multiple providers can be flexibly integrated and coordinated.
Electronic commerce emerges as one of the most relevant applications on the Internet, with the potential of revolutionizing the shopping habits of millions of people and the whole structure of the produce-retail-consume chain. Electronic commerce should allow to provide people with functionalities that cannot be found through traditional commercial channels, e.g.: - transactional payment for handling contracts between providers and customers. - workflow for scheduling and synchronizing the various steps of complex processes, e.g. delivery of purchased merchandise. - multi-party agreement for coordinating multiple providers in the context of a complex transaction. For example, a typical electronic commerce application may require coordination, on behalf of a client performing a travel reservation, of several independent transactions on different servers such as reserving a flight, reserving a car, reserving an hotel room and checking the payment and delivering the flight tickets. Here the electronic commerce system should ensure that the customer request is considered as a whole. Thus, either all or none of the reservations are performed. Moreover, providers should be able to dynamically modify their service offering, e.g. add new services, such as a new product color, a new delivery service or payment method. Through the electronic commerce system the new service offering should be immediately accessible to the user.
The functions outlined above are not yet widely available. The aim of Xpect[1,2] is to provide a generic framework for electronic commerce where multiple providers and services can be flexibly integrated and coordinated in order to offer such functions. With Xpect, the term of provider is sufficiently flexible to include existing centralized electronic commerce systems. Different types of actors are involved in the Xpect electronic commerce framework,: Providers, Customers, Bankers, Brokers etc.
Providers own the goods and provide catalogs describing them. A catalog is, in this context, more than a classical paper catalog: it consists of a set of data items and a set of search forms that allow the selection of items corresponding to user requirements. The Providers make their catalogs available to the Broker. They receive orders from the Broker and process them, initiating the delivery of goods.
Customers issue requests for goods to the Broker. A request may initially be more or less precise. The Customer engages into a dialogue with the Broker, to further specify the items s/he is interested in, both in terms of product characteristics and price / delivery etc. while the Broker transparently negotiates with providers to find matching offers.
Once an agreement is found, the Customer triggers the commercial transaction. If it succeeds, the Customer will receive the corresponding goods. In the meantime, s/he can track the delivery process. If the commercial transaction fails, the Customer may analyse the cause of failure, e.g. the Provider cannot deliver the good, the Banker cannot perform money transfer etc. In consequence the Customer can take an appropriate action and retry the (possibly modified) transaction .
In addition to managing multi-party commerce transactions, Xpect also makes it possible to extend the offers of providers and build "virtual services" by combining available offers. As an example, consider the use of different payment methods. The Banker is in charge of the payment in a commercial transaction. It manages the "wallets" of the Customers and possibly those of the Providers. A wallet may contain not only electronic cash but also traditional credit cards. The Banker allows the Customer to select a payment method (electronic cash, credit card, payable on delivery) without any limitation due to Provider restrictions. For instance, if a Provider does not accept electronic cash but only credit cards, the Banker first accepts payment from the Customer in electronic cash and then pays the Provider with a credit card. Thus, neither a Provider nor a Customer is obliged to hold many different payment methods. The Customer may even select different payment methods within the same transaction, for different items.
The Broker coordinates all the other agents. Its activity consists of several phases: It supports the Customer in the process of searching items of interest from the Providers'catalogs. Once an agreement is found with the Customer and the Providers, the Broker enacts the financial transaction. It sends to the Banker a Transaction Descriptor authenticated by the Customer which specifies what the Banker may do on behalf of the Customer during the transaction. If the financial transaction succeeds, the Broker issues a Delivery Voucher which requests the different Providers involved in the transaction to start delivery.
An important feature of the Xpect framework is that it allows a quick specialization to specific domains of electronic commerce. For instance here we describe a print on demand system: the providers are digital libraries, print shops and fast delivery companies, the goods are digital documents, printed matter, the services are printing facilities and fast delivery.
Let us describe how this particular instance of Xpect may be used. Consider a customer living in London, who would like to offer to her daughter, for her birthday, two French books: ``Le Petit Prince'' by A. de St Exupery and the French version of ``Jonathan Livingston Seagull'' by R. Bach . The birthday is in three days and, if it is not possible to obtain both books on time, the customer would probably have to find another gift.
Being used to shopping on the Web, the customer first contacts a broker in order to find one or more digital libraries owning such titles. As a result, three libraries return offers (all in digital form). Library libA offers both books, libB only the first one and libC only the second. More specifically, booka (i.e. ``Le petit prince'') provided by libA contains color pictures, while libB provides only a black and white version. The book bookb (i.e. ``Jonathan Livingston Seagull'') only contains black and white pictures in both offers from libA and libC. Libraries libA is the most expensive in both cases, but it is also the only one to propose a color version of booka. Finally, the customer decides to buy booka from libA and bookb from libB.
The second step is to find print shops able to print the two books. The time constraint (2 days before the birthday) implies that either the books have to be printed near London or at a location from where it is possible to have them delivered in 48 hours by a fast courier company. The broker is first asked for printing facilities around London for both booka and bookb. We assume that only one print shop PSA makes an offer. It is located near the City but proposes only black and white printing facilities and has no color facilities. It could therefore handle bookb, but not booka.
The broker then is asked to enlarge the search to other print shops offering color facilities for booka. The offers will be combined with delivery offers in order to respect the 48 hours time constraint.
A print shop PSB located in the USA makes an offer, together with another print shop PSC located in France. The latter is more expensive, but closer. The offers for the delivery of bookb are proposed by the courier companies delA and delB which offer delivery from both USA and France. We end up with four distinct solutions for bookb:
Although printing in the US is cheaper than printing in France, the lowest total price is preferred and the chosen solution is to print the book at PSC and to contract delivery with delB.
As a final step, the financial transaction involves libC, PSA for bookb and libA, PSC and delB for booka . The last step, but not the least, is to combine the different payment systems the providers accept and the customer would use in order to finalize the commercial transaction. If, for any reason, one of the partners in this transaction fails to support its offer, the whole transaction should abort. In this case the customer may decide to consider one of the other solutions proposed by the system.
This whole scenario could of course be executed manually by the customer, who would then have to access each service separately. The purpose of the generic brokering service of Xpect is precisely to relieve the customer from this burden, and to offer a high-level service which coordinates all the others according to the customer requirements (and under her control).
Xpect is built on top of the Coordination Language Facility (CLF)[3,4]. This platform, developed internally, provides advanced features to build distributed applications and to deploy them over large scale distributed systems.
J-M. Andreoli, F. Pacull, and R. Pareschi. Xpect: A framework for electronic commerce . IEEE Internet Computing, 1(4):40-48, 1997.
J-M. Andreoli, F. Pacull. Distributed Print on Demand Systems in the Xpect Framework . Proc. of Internatinal Conf. Trends in Electronic Commerce'98.
J-M. Andreoli, D. Pagani, F. Pacull, and R. Pareschi. Multiparty negotiation for dynamic distributed object services . Journal of Science of Computer Programming, 1999.
Xpect is built on top of the CLF/Mekano framework
For more information on the Xpect research project please contact Xerox Research Centre Europe
6 chemin de Maupertuis
38240 Meylan, France