Re: A Few Possible Use cases

Deb,
Be careful with a metrics example using quantity - US vs. UK 
measurements are different.  See 
http://www.travelinterface.com/CookConv.asp for some approximate details 
(I don't think these conversions are on the money, but they're close). 
US and UK differ from each other in ounces, teaspoons, tablespoons, 
gills, pints, and gallons.
Also, I think you might mean matushka (little mother) dolls in the 
Russian example?
Andrea

Debasish Banerjee wrote:
> 
> 
> 
> 
> 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 Tuesday, 17 June 2003 18:18:45 UTC