A Few Possible Use cases

Hi,

(a) I am reposting essentially the same note that was posted earlier. I
just
added a paragraph about Metric <--> English (?) conversion in use case (1),
as
suggested by my colleague from Shanghai.

I would like to have discussions about the 'application-level' (ref.
Addison) use
cases during our "Tuesday Afternoon Teleconference" (just trying to mimic
late Prof.
Dijkstra's famous "Tuesday Afternoon Club"). We can discuss the comments of
Dr. Davis and Addison, make the use cases closer to real life.

(b) Here is one URL for the WS-Policy document:
ftp://www6.software.ibm.com/software/developer/library/ws-policy.pdf


Thanks,

Deb



======= O L D   N O T E ======================

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.

Just like the case of user-friendly currency, the proposed online store
can also help a potential customer by performing "metric --> English"
conversions
when appropriate. A traditional American customer may want to see the
weight of
Caviar in ounces (not in grammes) or the volume of liquids in pints
(not in liters). Based on the inbound locale, the online catalogue may
display the weight, volume, etc. in two systems: the base system (almost
sure
that Russia follows the metric system) and the system usually associated
with locale (say the English system for the American customer).

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 Monday, 9 June 2003 20:29:49 UTC