A Few Possible Use cases

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