Collaborative electronic commerce is the basic idea behind the work we describe. So far, most of the e-commerce activities performed on the Web can be characterized as solitary ones: users logged in on a shopping site can only browse around pages, view and buy items essentially by themselves, experiencing everything on their own.
Let's consider, instead, two Web users, Alice and Bob, who decide to go out shopping together. First, one of the users, say Alice, downloads our collaborative framework (consisting of a Java applet and some Java scripts) in her ordinary Web browser and initiates a collaborative session. Next, Bob, having also downloaded the collaborative framework, sees that Alice has created a session and decides to join Alice in that session. Bob then chooses to "follow" Alice: this means that the pages that Alice visits will be displayed in a frame of Bob's browser. Alice, in turn, decides to "follow" Bob.
Now, suppose Alice decides to go to a Web shopping server S1 to purchase some items. Alice registers on S1 and buys two items (ItemAlice1onS1 and ItemAlice2onS1). In the meantime Bob has gone to the Web shopping site S2 and has selected two items there (ItemBob1onS2 and ItemBob2onS2). Since Alice is "following" Bob, Alice can see where Bob is and, being interested in what is sold on site S2, joins Bob there and buys another item (ItemAlice1onS2). Up to this point, Alice cannot see what Bob has chosen so far, nor can Bob see what Alice has selected; they can only follow each other on their respective surfing around the Web. At this time, Alice decides that she's interested in letting Bob know the two items that she chose on site S1. So, she marks both ItemAlice1onS1 and ItemAlice2onS1 public, meaning that they immediately become visible to Bob. Seeing ItemAlice2onS1, Bob decides to go to S1 and get one for himself too. Bob also decides to mark the item public. While Bob goes to site S1, Alice decides she wants to finish her shopping: she navigates to site S3 and buys ItemAlice1onS3.
So far this is the situation:
Alice has ItemAlice1onS1 (public, Bob can see it), ItemAlice2onS1(public, Bob can see it), ItemAlice1onS2 (private, Bob can't see it), ItemAlice1onS3 (private, Bob can't see it);
Bob has ItemBob1onS1 (public, Alice can see it), ItemBob1onS2 (private, Alice can't see it), ItemBob2onS2 (private, Alice can't see it).
Both Alice and Bob decide its time to check out and pay. Each of them clicks a special button and the billing is performed in a "one stop" process, thereby avoiding their carrying out separate transactions with every merchant they have visited (three transactions for Alice on S1, S2, S3; and two transactions for Bob on S1, S2).
We present a client-server architecture, with an intermediate server playing the role of a Shopping Mediator, designed and implemented to support our collaborative shopping idea. The main role of this intermediate server is mediating requests from the users, allowing their interaction with the heterogeneous environment represented by the shopping Web sites. The Shopping Mediator also maintains important information about the active collaborative shopping sessions and the state for each client.
This state consists of all the relevant information about a collaborative shopper:
the URLs of the pages he currently sees in his browser;
all of the items he buys on the shopping sites he visits.
The current locations (URLs) of a user are necessary for sharing the navigation with others.
As for the sharing of resources, the collection of all of those virtual carts the user has on every site visited during a shopping session represents the multicart containing all the items that have been chosen, no matter which site they are from.
In order to share some of these items with other users in the same collective session, this multicart is maintained up-to-date on our Shopping Mediator, so that each user is able to access every item he has and to change properties he might be interested in letting the others know about. In particular we've seen in the example the concept of public and private items. Traditional WWW shopping sites don't support public and private resources. Everything is automatically private since there's no concept of sharing.
The Shopping Mediator must be able to efficiently update the shared cart on behalf of every client. To support this feature, we must assume a uniform interface to handle the interaction with an inherently heterogeneous environment represented by the shopping servers. For the prototype, we have chosen to create the well-defined class ShoppingCart to represent a generalization of the object exchanged by the Shopping Mediator with the shopping servers through a Merchant Server API, made up of methods used to retrieve, reset and purchase a shopping cart on a shopping server that supports the API.
Since there are no existing shopping servers that export the Merchant Server API, we implemented our own Merchant Server, which provides also our own login procedure. Our Merchant Server consists of a small Java application that listens for HTTP requests, serves some special HTML pages and supports "special" links that are really method calls to: login to the Merchant Server and receive the handle for a shopping cart, view the shopping cart and add items to the shopping cart. Through Java RMI, this server also exports the Merchant Server API interface defined above.
We believe that increased support for collaboration and cooperation is a logical next step in the evolution of the WWW. We have developed an architecture aimed at supporting, as a particular kind of collaboration on the Web, the idea of a novel form of electronic commerce involving multiple users simultaneously shopping together on multiple shopping sites.
|Home||Back||Top of Page||Feedback||www.telcordia.com|
© 1999 - 2002 Telcordia Technologies, Inc.
An SAIC Company