- From: Debasish Banerjee <debasish@us.ibm.com>
- Date: Wed, 21 May 2003 17:29:44 -0500
- To: "Addison Phillips [wM]" <aphillips@webmethods.com>
- Cc: <public-i18n-ws@w3.org>
Hi, Here are initial ideas for a few use cases dealing with eBusiness and business choreography. 1. Assume the existence of an online store in some country (say Russia) offering various goods and services (Caviar, Vodka, Matruskas, Chess lessons, Science books, etc.). The base price of each good is in Russian currency: Rubles. For a non-Russian customer, not familiar with the Russian currency system, the price of the offered goods and services in Rubles may make very little sense. For non-Russian customers, the online catalogue of the retailer may intend to display prices in two currencies: the base price in Rubles, and an approximate price in the default currency derived from the country code portion of the customer's locale. Thus an American user will see prices both in US $ and Russian Rubles; a Japanese customer in Japanese Yen and Russian Rubles and so on. A Russian customer will of course see the prices only in Russian Rubles. The system can use some local 'currency conversion' module (or even a remote 'currency conversion' web service) for converting Rubles into other forms of currencies. If a default currency can not be derived out of 'caller's locale', the default base currency can always be used. Note that, the values displayed in customers default currencies are approximate and intended for user friendliness. During the actual business transaction, when the buyer submits his credit card, the accurate currency conversion will be performed--most probably by some specialized Web services interfacing with the financial institutions. 2. Again assume the existence of an online retailer selling goods (say books). Assume a Japanese customer ordered a few books from the catalogue after supplying his/her credit card details to the retailer. The online store software after accepting the order will probably send asynchronous message(s) to it warehouses(s) requesting the actual shipment of the books. The warehouse(s) after shipping the order will probably eMail the customer about the shipping details: courier(s) used, the tracking number(s), date(s) shipped, expected date(s) of arrival at customer address, etc. The eMail is generated from a standard template and SHOULD be produced in the customer's locale (language). This requires the propagation of the inbound caller's international context information in the asynchronous messages(s) from the eStore to warehouse(s). Since warehouse(s) typically require a few days for actual shipment, the internationalization context should be stored along with the order until the entire transaction gets completed. The eMail to the customer SHOULD also show the amount charged to his credit card formatted according to customer's locale and not in the locale of the warehouse server. In real life scenario, other intermediate eMails may get directed to the customer during the entire business transaction. One or more books may be temporarily out of stock, partial shipment, etc. All these communications SHOULD originate from appropriate servers of the online retailing system in the locale of the customer. 3. Imagine a travel agency service providing complete travel assistance including airline reservation, car rental, hotel reservation, etc. Customer submits a travel itinerary and the travel agency fires three parallel processes to process airline, hotel and car rental reservations based on the input itinerary. Imagine, two reservation tasks succeeded (say airlines and car rental) and the third one (the hotel reservation) failed. The travel agency will now compensate the already reserved airlines and car rental bookings. As a part of the overall compensation, the travel agency software informs the customer too. Sophisticated systems may suggest alternative itinerary to the customer. The material communicated to the customer may get generated from standard templates and SHOULD be in the customer's locale and not in the locale of the travel agency server. This requires the storage of the inbound customer's internationalization context to be stored until the entire long running transaction (LRT) gets complete. The stored internationalization context may get used in driving parts of the compensation logic.
Received on Wednesday, 21 May 2003 18:30:30 UTC