Electronic Commerce Research and Applications 1 (2002) 281–300 www.elsevier.com / locate / ecra
vCOM: Electronic commerce in a collaborative virtual world Xiaojun Shen a , *, T. Radakrishnan b , Nicolas D. Georganas a a
Multimedia Communication Research Lab ( MCRLab), School of Information Technology and Engineering, University of Ottawa, Ottawa, Ontario, Canada K1 N 6 N5 b Department of Computer Science, Concordia University, Montreal, Quebec, Canada H3 G 1 M8
Abstract Existing e-commerce applications on the web provide the users a relatively simple, browser-based interface to access available products. Customers are not provided with the same shopping experience as they would in an actual store or mall. This experience, however, can be achieved by the creation of a virtual shopping mall environment, simulating most of the actual shopping user interactions. The virtual mall brings together the services and products of various vendors. Users can navigate through the virtual shopping malls, adding items of interest into a virtual shopping cart, and perform searches assisted by ‘intelligent agents’. A Collaborative Virtual Environment (CVE) can realize a sophisticated virtual shopping application. In such a CVE, a large number of potential users may interact with each other. In this paper, vCOM, a VRML and Java3D-based prototype is presented, which permits users to navigate around virtual e-commerce worlds and perform collaborative shopping and intelligent searches with the assistance of software agents, in order to find the products and services of interest to them. They can then negotiate with sales agents to bargain for the best possible price and then make a secure buying transaction. The virtual mall prototype also allows the user to communicate with an ‘intelligent shopping assistant’ using simple voice commands. This assistant interacts with the shopper using voice synthesis and helps him / her use the interface to efficiently navigate in the mall. Real-time interactions between the entities in this shared environment are implemented over the High Level Architecture (HLA), an IEEE standard for distributed simulations and modeling. The paper focuses on user interface design, collaborative e-commerce through HLA and multi-agent architecture. 2002 Published by Elsevier Science B.V. Keywords: E-Commerce; Collaborative virtual environment; HLA / RTI; Voice-enabled; Intelligent agents
1. Introduction It was hard to imagine 10 years ago that people could handle their lives so easily, by just logging
*Corresponding author. E-mail addresses:
[email protected] [email protected] (T. Radakrishnan), mcrlab.uottawa.ca (N.D. Georganas).
(X. Shen), georganas@
onto the Internet, using computer networks, to find out all sorts of information they need, evaluating the products or services they need, comparing prices and making a purchase right away. All these things, which would have been completed in more traditional ways before the evolution of the Internet, are being conducted today through the new business tool—Electronic Commerce (EC). Electronic commerce refers to commercial activities conducted electronically, such as the buying and selling of
1567-4223 / 02 / $ – see front matter 2002 Published by Elsevier Science B.V. PII: S1567-4223( 02 )00021-2
282
X. Shen et al. / Electronic Commerce Research and Applications 1 (2002) 281–300
products and services, and the transfer of funds, through public or private digital networks. The goals of e-commerce are to reduce cost, expand business, and improve customer response time and quality. The core of e-commerce, as distinguished from traditional commerce, is referred to as a ‘fully-digital business.’ A market is composed of three components: sellers and buyers (or agents), products, and processes [3]. These components are mostly digitized at the core of e-commerce. E-commerce is not simply an interactive Internet version of traditional retail business. E-commerce, as a new medium of communication, provides more useful information, expands choices, simplifying purchasing processes and lowering costs. While the actual execution of e-commerce is so different from its real-life counterpart, what shoppers want to experience online, ironically, are characteristics of the real-life-shopping environment. Existing electronic commerce applications have the following characteristics: 1. Only provide the users with a relatively simple, browser-based interface to access the available products and services. 2. These applications often lack in the emulation of the social factor. The customers are mainly kept separated and everyone is shopping, as if s / he was in an empty shop. Thus, customers are not provided with the same shopping experience, as they would be in an actual store or mall. Shopping actually is a social activity people enjoy doing along with friends and relatives. In particular, it is likely that shopping is an activity that is socially facilitated, meaning that when done in the company of others, people engage in it more often and enjoy it more. Marathe [25] states ‘people don’t like to shop in an empty store.’ To substantiate this opinion, he cites a survey, which shows that 90% of shoppers prefer to communicate while shopping. Warms et al. [26] argue for shopping communities because they ‘increase stickiness (customer loyalty) [and] viral marketing (word of mouth), reduce [the] cost of customer acquisition, and drive higher transaction levels.’ Considering the current growth in e-com-
merce on the Web and the desire to make shopping as easy, natural and enjoyable as possible, it is imperative to extend the way people currently shop on the Web by adding support for more collaboration between customers and salespersons or among customers. Therefore, providing a virtual reality web shopping experience is closer to the experience people have in real shopping environment. Based on the innovations in 3D Virtual Reality online store technology, it would not be long that customers would find online malls of the future more like their offline counterparts. Shoppers would imitate ‘walking’ around the virtual mall using their ‘avatars’ and controlling their moves by pointing their mouse or using simple voice commands. If they find items of interest in the navigation process, they can purchase them. Users navigate the virtual commerce world, visit stores and manipulate items therein, only using their browsers. In this paper, a solution called vCOM is presented, which is based on Collaborative Virtual Environment (CVE) technology. With the creation of a virtual shopping mall, simulations of the actual shopping environments and user interactions can be achieved to a great extent. The virtual e-commerce prototype presented in this paper holds three major advantages over existing online HTML-based e-commerce applications. First, the multi-faceted dynamic virtual reality environment allows merchants to implement stronger marketing and branding initiatives than what is available on a ‘flat’ Web page. The second benefit of the 3-D environment is a longer shopping retention period. According to the survey conducted by Active Worlds [10], the average user session in a 3-D shopping mall is 45 min—an abundance of time to market effectively to shoppers. In comparison, the average user session at regular web site is less than 5 min. The third advantage of this new technology is the enhanced interactivity between merchants and consumers, among customers and visitors. Virtual mall technology enables online merchants to offer features that are lacking in most of today’s e-commerce stores. For example, the virtual mall makes it easy for storeowners to provide real-time customer support, sales assistance, cross-selling, promotion and individualized care that have traditionally been proven to improve sales.
X. Shen et al. / Electronic Commerce Research and Applications 1 (2002) 281–300
2. Background The research presented in this paper was part of a larger project, ‘Enabling Technologies for Electronic Commerce’, funded by the Canadian Institute of Telecommunications Research (CITR). The complete e-commerce application scenario, implemented in that project, is shown in Fig. 1. The shopping process is as explained in the following steps: • A user logs-in by using the URL of the ecommerce web-based application. • Upon proper authentication, the user is asked to select an existing user profile or enter a new profile, specifying his / her interests. The system will use that profile in helping the user in finding items of interest. • The user is then presented with the choice of searching the e-commerce world by either database search queries or by navigating virtual shopping malls. • If the latter is chosen, a list of the available virtual shopping malls is presented and one is selected for navigation. The graphics of that shopping mall are then downloaded from the database server.
283
• A Quality of Service (QoS) Broker checks available network QoS and may switch connection to another database server, if the network QoS there is better there. • The Virtual Mall graphics are presented on the user interface (either through a VRML plug-in in the normal web-browser, or through a Java3D browser). • The user can ‘navigate’ through the virtual shopping mall, either by keyboard commands, mouse movements or by voice commands, through a voice recognition / synthesis system. • A ‘User Interface Agent’ (UIA) monitors the user’s actions and modifies his / her searching preferences accordingly. An UIA is specialized to serve its user and is persistent over time. • Items of interest may be found and placed in a virtual shopping cart. If, during that process, the user wants to ‘communicate’ with a vendor or jointly examine an item of interest with others, a Collaborative Virtual Environment (CVE) is defined with the vendor’s computer through the HLA standard [4,13]. Avatars are used to represent the buyer and the vendor. • A similar CVE is defined among buyers who wish to do collaborative shopping. Items of
Fig. 1. Overview of vCOM Prototype.
284
X. Shen et al. / Electronic Commerce Research and Applications 1 (2002) 281–300
interest to the buyer(s) can be viewed in 3D by retrieving appropriate 3D graphics from the database server. • Finally, when a buyer is ready to buy and exit, the system brings forward a secure purchasing environment using the Secure Electronic Transactions (SET) protocol. Collaborative Virtual Environments are currently one of the most challenging virtual reality (VR) research areas. A CVE is a shared virtual world that could radically alter the way people work, learn, consume, and entertain. It adds new dimensions to the needs of human-factors, networking, synchronization, middleware, object model acquisition and representation. The human-factors research in VR has traditionally focused on the development of user interfaces that are easy to use and easy to learn for manipulating virtual objects and traversing virtual landscapes. Collaborative manipulation, on the other hand, requires the consideration of how participants should interact with each other in a shared space, in addition to how co-manipulated objects should behave and work together [4]. The main issue in such a collaborative virtual environment is how distributed clients and servers share and maintain the common resources. This problem has to be solved in the framework of many hardware and software platforms, in other words, in a totally heterogeneous environment. In order to support e-commerce co-operative work (e.g. collaborative shopping) within a CVE among many users over long distances, the architecture for scaleable distributed virtual environments is being addressed. This paper investigates how HLA and its Run-Time Infrastructure (RTI) [13] can play a role in the design of such a CVE for e-commerce applications. The concepts and terminologies of RTI / HLA are discussed in the Appendix. Five important problems in implementing a CVE are listed in the sequel [4,12] and have been addressed in our research: 1. Consistency: The fundamental model presented by a CVE platform is a shared 3D space. Since all clients accessing or updating the data share the 3D graphics database, the issue of distributed consistency must be solved by any CVE to
ensure the same view is presented to all participants. Since the number of participants is not fixed, and during the run time users may enter the environment after the environment has been changed from its initial state, a CVE needs to be able to provide support for latecomers and early leavers. 2. Scalability: The number of possible interactions between n simultaneous users in a multi-user system is of order O(n 2 ) at any moment. Ideally network traffic should be almost constant or grow near-linearly with the number of users. Usually, not all the data in the CVE environment would be relevant to a particular user at a given time. This suggests the idea of partitioning the environment into regions (or zones, locales, auras) [1,8,9] that may either be fixed or bound to moving avatars. Events and actions in remote zones need not be distributed and remote objects need not be visualized or might be visualized at a coarse-grain level. Most of the traffic is isolated within zones. 3. Ownership: A multi-user CVE world is subject to conflicts. Conflicts occur when collaborating users perform opposing actions, for example, a conflict may arise if one user tries to open a window while another user is trying to close it. These conflicts must be avoided or solved. One method to determine the attributes of objects that may be modified by certain users is to assign temporary ownership to objects. Manipulation of objects may include the change of the object’s coordinate system and the change in the scene graph: users may grasp objects and take them to a different world. Operations like this are essential for applications like virtual shopping. 4. Persistence: Some of these applications that involve a large number of users need a largescale, persistent collaborative virtual environment (PCVE) system that is ‘never-ending’ or ‘always on’. This is either because its users require that it is always running, or because it is so large or distributed that stopping the entire simulation to make changes is just not possible. There are a number of issues that should be addressed to support PDVE. Persistence would be the first feature that characterizes a PCVE
X. Shen et al. / Electronic Commerce Research and Applications 1 (2002) 281–300
system. It describes the extent to which the virtual environment exists after all participants have left the environment. 5. Dynamic configuration: This property allows a PCVE system to dynamically configure itself without user interaction, enabling applications to take on new functionalities after their execution. CVEs should be modifiable at run-time by accepting the contributions of new objects and new behaviors. Although web business models in e-commerce differ from the traditional brick and mortar type shops in many ways, the fundamental needs of consumers and businesses remain much the same. Consumers want to compare products and services from different vendors side by side to get the best bargain; businesses want to grow sales by attracting the right shoppers to their sites. These needs give rise to the possibility of using a variety of intelligent agents that work for buyers and sellers over the web. In an endeavor like e-commerce applications (buying, selling, and multiple objectives), it is quite natural to think of using Multiple Agent Systems (MAS). A special category of agents has come to be known as user interface agents. They are based on models of the users and such models may include user needs, preferences, goals and their operating encoded in their knowledge bases to assist the users. A user interface agent may possess the ability to learn from its dialogs with the user and by watching user actions. For this purpose, it becomes necessary to characterize the situations under which learning can take place. Following this detailed introduction, the system architecture of CVE over HLA / RTI and MAS, which are used for the virtual e-commerce prototype vCOM, will be discussed in the next sections. The paper concludes with the technologies involved and some future work. An overview of RTI / HLA is given in Appendix A.
3. Virtual Mall: the vCOM system This Virtual Mall vCOM prototype focuses on e-commerce and the infrastructure that is needed to implement an Internet-based version of this e-com-
285
merce application. We identify the following five main aspects of technology that pertain to e-commerce: 1. Through user interface design, virtual reality and intelligent agents, make e-commerce applications attractive and usable for end users. 2. Ensure electronic payments are secure-essential to the success of e-commerce. 3. Using data-warehousing, data-mining, and management, add value to an application, or to the application’s data flow. 4. Design software architectures for various applications and solutions. 5. Measure quality of service under a given set of resources. This paper, however, only discusses the CVE-based user interface and intelligent agents design pertinent to the first aspect.
3.1. Overview A user uses its web browser, logs on to a given URL and follows proper authentication / access control. Registration is required, if it is a new user. The user needs to give his / her personal information, such as name, birthday, or credit card number. The information will be stored in the User Profile Database. The user then may choose the browsing mode that he / she prefers—search engine or virtual mall. A search engine plays a major role in the traditional electronic shopping on the Internet. The user can check all sorts of information he / she wants, evaluate the products or services he needs, compare prices and makes a purchase right away on a ‘flat’ web page. The corresponding application scenario was described earlier. vCOM has a CVE user interface through which the user can retrieve the virtual shopping mall realized in VRML (Virtual Reality Modeling Language) or Java3D. He / she then can navigate the virtual world, where both the users and agents are represented on the screen by 3D animation avatars. The users can explore the cyberspace through different views, including the ‘eyes’ of the avatar, or from a third-person view. In the third-person view, the user can view his or her avatar from ‘space’,
286
X. Shen et al. / Electronic Commerce Research and Applications 1 (2002) 281–300
capturing the broad scope of the environment, or from a ‘wingman’ position, capturing a more local and detailed context. A Quality of Service (QoS) architecture that introduces a brokerage function between clients and servers has been defined. QoS brokers continuously monitor the performance of affiliated servers and assign them to clients according to a defined server selection policy that optimizes the capacity of the system based on server performance characteristics and user requirements. There are a number of data management issues that need to be addressed in e-commerce applications. These include, among others, the development of virtual catalogs, intelligent query access of these catalogs, and support for the management of transactions between customers and vendors. The multimedia catalog enables users to access multiple, distributed and potentially heterogeneous catalogs in a uniform and transparent manner. In vCOM prototype, the user queries the database through CGI scripts. The user search agent is responsible for generating the CGI scripts, parsing the responses from the database, which is in CGI format as well, and showing the results on a query window. The user may pick up items of interest, and add them to his / her shopping cart and negotiate with a vendor’s
sales agent to bargain for the best price. After that, the Secure Transaction Manager helps the user to conclude with a payment for the transaction.
3.2. System architecture The vCOM CVE is a shared 3D virtual world supported by HLA / RTI on the Internet. This is indeed one of the first uses of the HLA standard in an e-commerce setting. Fig. 2 depicts the basic three-layer system architecture on each client site. The top layer is the graphics-rendering layer, where there are two kinds of browser modes from which the user can choose: a VRML-enabled web browser, i.e. Netscape, or a Java3D-based browser, which offers performance advantages. The Java controller layer (middle layer) plays a pivotal role in the creation of CVEs. It not only controls the virtual scenes (VRML scenes) but also communicates with the RTI through the Java Native Interface (JNI) [7]. The Java controller layer also implements the services that RTI provides, such as RTI Object Declaration, Object Ownership Management and Data Distribution Management (DDM), which will be addressed in detail in the following sections.
Fig. 2. System architecture.
X. Shen et al. / Electronic Commerce Research and Applications 1 (2002) 281–300
3.3. System implementation 3.3.1. User interface design and implementation In the case of a single-user VRML e-commerce world, the entire description of the world is typically contained in one VRML file. In the case of dynamically changing VRML worlds, however, this type of organization management is not suitable, since objects are typically added, removed or their attributes changed during the lifetime of the world. Furthermore, since objects can send and / or receive events, the controlling application must be able to identify objects and access them individually. This necessitates some sort of indexing or naming scheme for objects so that events that are received can be expediently routed to the correct object in the virtual scene. For this reason, the VRML scene is considered to consist of a self-contained hierarchy of objects. Moreover, interaction with objects is only possible through the event interface of their top-level VRML node. In order to implement such a VRML-based shared
287
virtual space in collaborative e-commerce, an event must be propagated to other clients, when it occurs in the VRML scene. The Java controller layer receives the notification of the event’s occurrence by means of a callback mechanism, which is provided by an interface called External Authoring Interface (EAI) [6]. EAI defines a set of functions on the VRML browser, so that the external environment can perform to affect the virtual world. The ‘callback’ returns the values of the event, the (local virtual) time of its occurrence and relevant user information associated with the event. In the typical case, the Java controller layer sends the event immediately to other clients who are interested in the event. In some cases, however, such as the rapid succession of transformation events (e.g. translation or rotation events) caused by the movement of the object in the scene, the Java controller layer’s logic may decide to forward the event only when some minimum changes have been exceeded, thus considerably avoiding the creation of more network traffic. Fig. 3 depicts the Web Browser Based User Interface.
Fig. 3. Web browser based user interface.
288
X. Shen et al. / Electronic Commerce Research and Applications 1 (2002) 281–300
In the final-phase of the vCOM project, a Java3Dbased user interface was also implemented. For the virtual mall vCOM prototype, the VRML version of electronic mall was translated into Java3D objects using Java3D Loader classes, resulting in better performance and greater control over the mall interactions. Java3D provides a simple, high-level programming model that enables a program developer to build, render, and control the behaviors of 3D objects and virtual environments. The new interface allows much faster rendering and navigation of graphics once the Virtual Mall has been downloaded from the database. Programs written in Java can be easily adapted to specific needs of business owners.
3.3.1.1. Shopping mall navigation Navigation in virtual 3D spaces may not be easy for the average user, using typical UI mechanisms. Controlling the mouse to maneuver to the desired direction requires a high level of coordination: in addition users could easily get lost in 3D spaces and not be able to find the right direction to move. To facilitate users’ navigation in multiple virtual shops (depicted in Fig. 4) in the vCOM prototype, the following tools were developed: the user can enter specific stores either through navigation tools
like mouse-click, 2D location map in the user interface, keyboard commands or via a voice-enabled helper. The vCOM prototype allows the user to communicate with an ‘intelligent assistant’ (IA) using simple voice commands. This assistant interacts with the customer using voice synthesis and helps him / her use the interface to navigate efficiently in the mall. Voice-enabled agents provide users with a friendly speech-command interface, and also act as a general ‘help’ facility for the user interface, accepting simple voice commands and giving voice responses. Speech recognition and speech synthesis provide a more natural interface for users. It frees the user’s hands for other tasks and allows the user to take advantage of his / her natural voice communication skills. In the e-commerce application, speech recognition is put alongside with the web browser simulation to aid a customer to find items of interest in the virtual mall. The Microsoft Speech Engine SAPI 1 is used to provide a speaker independent recognition of predefined commands described by a SAPI grammar. This way simple commands such as ‘go to the video 1
The Microsoft Speech Engine can be downloaded from http: / / www.microsoft.com / IIT / Download /.
Fig. 4. Multiple virtual scenes (Entrance, Virtual Book Store, Toy Store and Video Shop).
X. Shen et al. / Electronic Commerce Research and Applications 1 (2002) 281–300
room’, ‘turn left’, are recognized by the SAPI module. The speech recognition module was implemented using ActiveX components and its integration to the prototype was made via native DLL loaded by the Java Native Interface (JNI). The speech recognition module works independently from the other modules, by sending recognized commands into the prototype via a predefined local socket. An ontology has been built for basic voice commands and is accessed through agents. The effectiveness of SAPI in this context has been studied in a Master’s thesis in the MCRLab [18,4].
3.3.2. Collaborative shopping The design and implementation of current online shopping places (e.g. virtual bookstores such as www.amazon.com or internet shopping malls such as shopping.yahoo.com) have primarily focused on the process of exchanging goods. Online catalogues of mail-order companies are created and metaphors of shopping baskets and virtual cash desks are introduced. While these metaphors aim at easing the process of shopping by emulating real world experiences, current virtual market places often lack in the emulation of the social interaction factors [29]. We therefore argue to combine the virtual market with a social place again, which was the goal of the vCOM project. Customers who participate in the virtual market should change their role: from consumers to people, who want to satisfy their wide range of needs through shopping. The purchase of goods is only one of them; social interaction, learning, or excitements are others, which can be satisfied in a community. The role of markets that bring together people, who did not know each other, could create new social communities. If the members of the community are encouraged to exchange their ideas and their knowledge, this could have a large impact on all brands of live. When shopping in malls, there are different kinds of activities performed by customers. Navigating through the mall to find the specific shop is the most common activity when customers do shopping; it is abstracted in vCOM by avatar’ movements through the virtual shopping mall. The second activity for the customers is to look for items of interest. Goods in vCOM prototype are presented using shelves. Thus, the customers might just pick the item from the shelf
289
and examine it. This offers a first-person perspective of the item to the customer. Customers may cooperate, which is the third activity that may take place among customers or between customer and salesperson. It is this activity that adds the social element to the virtual mall. In vCOM prototype, the co-operation is simulated as interaction among avatars, the digital representatives of customers and sales assistants. For a social market place, the system provides awareness between users who share the same section of a shop. Users should be able to do something together, when they meet. Taking into account the real world setting, the most obvious activity would be to chat. Chats can be without any goal or they can be goal centered. The second kind of chats is especially important for communities, since it produces reasonable events. If two users currently watch ‘Star Wars’ in the demo room at a virtual video shop, they may then be able to start a synchronous communication like text-based chatting and discuss their current interest or exchange their experiences of the movie. Besides chatting, visitors can join and do the shopping together. If they have noticed that they are looking for goods within the same category, they could talk to each other, ask the others’ opinions and find the desired goods more effectively. Fig. 5 shows an example in the vCOM prototype where online users Bob and Nancy are doing collaborative shopping in a virtual bookstore. Bob finds an interesting book, shows it to Nancy and asks her opinion. Co-operation can be the interaction between a customer and a salesperson; the salesperson can serve the customer in a variety of ways: provide information about products and services available.
3.3.2.1. Sharing users interactions The virtual world consists of various types of entities, each of which has a visible body containing its state. In particular, it contains its geometry and physical characteristics. One entity often needs information about other entities: it is affected by them, and may need to interact with them. At first sight, it appears that there is a fundamental distinction among active entities (such as avatars), passive entities (such as the merchandises that need to be co-manipulated by avatars) and inactive entities (like the background objects in the virtual worlds).
290
X. Shen et al. / Electronic Commerce Research and Applications 1 (2002) 281–300
Fig. 5. Collaborative shopping in a virtual book store.
Different entities may behave differently in, for example, the way they move and walk or the way they are interacted with. In vCOM, different objects are used to embody different entities in the virtual environment at each of the three layers of the application—Graphics, Java Controller and RTI Interface. HLA Declaration Management (DM) provides the services to a ‘federate’ to declare its intention to generate and consume information. Object Management (OM) deals with the registration, modification, and deletion of object instances and the sending and receiving of interactions. A Publication / Subscription scheme is applied in HLA for shared information distribution. When a federate intends to send updates of certain objects, it must publish the object class as well as the attributes that need to be published. Similarly, when a federate intends to receive updates of certain objects, it should subscribe to the object class and the attributes of that object that it is interested in. To support our goal of shared user interactions, we allow VRML scripts to communicate events to the scene graphs managed by other browsers via RTI. Our approach provides a mechanism to share a user’s (represented by an avatar) interaction, which offers
methods for non-verbal clues between collaborators, within all browsers in the 3-D world. The model is a replicated script mode with each browser downloading the same script and executing it locally. Typically these scripts would be associated with objects that are in the initial downloaded VRML file. In Fig. 6, we can see the message flow as a result of a user interaction. User A selection (1) causes a local script to run (2). This in turn invokes the callback event by EAI in the Java applet, which then retrieves the event (3) and asks the RTI to send attribute update through JNI (4). RTI passes the event and invokes the remote federate ambassador on User B to reflect updated attribute. The latter one is a ‘RTI initiated’ service (5). The Java applet retrieves the message to its browser (6), which then converts the message to an event that causes the execution of the local script (7).
3.3.2.2. Object manipulation A CVE should allow users to interact with objects in a natural manner such as the case of a user picking goods from a shelf. One of the attributes of an object in the virtual worlds is its ownership, which indicates which user (process) is allowed to access or manipulate the object. The manipulation is performed
X. Shen et al. / Electronic Commerce Research and Applications 1 (2002) 281–300
291
Fig. 6. Sharing user interactions.
through modifying some of the attributes of an owned object (such as position and rotation). In the RTI implementation, a given object instance has one single owner at any given time. However, attribute ownership may change during the execution. This mechanism allows two or more users to handle the same object through the transfer of ownership within the CVE. HLA Ownership Management (OM) services provide a facility to transfer attribute ownership and to keep the administration of the update responsibilities up-to-date [22]. The OM methods provide a facility for exchanging attribute ownership among federates in a federation execution using a ‘push’ and / or a ‘pull’ model. A federate can try to give away responsibility for one or more attributes of an object instance—or push ownership. Alternatively a federate can try to acquire responsibility for one or more attributes of an object instance—or pull ownership. The push model cannot thrust ownership onto an unwilling federate. Similarly, the pull model cannot usurp ownership. Pull and push approaches for transferring attribute ownership may be applied in different scenarios. For instance, when a customer wants to view merchandise, he / she needs to request the ownership of the object from the vendor by using the ‘pull’ scheme, before he / she takes the object from shelves whose owner is the vendor. After that, he / she can put the object back onto the shelf by ‘pushing’ back the ownership to its original owner. As noticed, both the push and pull transfer mechanisms of RTI are based on object attributes only. In
cases where several attributes or even entire object have to be migrated, problems may arise. Multiple federates may react with a pull attempt on one single push attempt. Since the HLA Interface Specification does not specify how the RTI must deal with multiple pull requests for the same attribute, it is not clear which federate will be the new owner [5]. Thus the RTI could migrate different attributes of the same object to different federates. In vCOM, the user usually needs to be granted ownership of all attributes of the object in order to manipulate it. A solution is to define an entire object ownership transfer based on the Ownership Management service, which is referred to as Object Ownership Transfer Protocol (OOTP). Details of OOTP are omitted for the sake of brevity.
3.3.3. Persistent collaborative virtual environment The web-oriented e-commerce application vCOM is an example of a persistent collaborative virtual environment, where simulations of most of the actual shopping environments and user interactions can be achieved with the creation of a virtual shopping mall. Most of the existing distributed systems require clients’ knowledge about each other’s application functions and behaviors, thus the different types of entities that will be participating in a simulation must be set up a priori. To introduce new entities, simulation programs have to be modified, recompiled and restarted, which obviously will cause problems for web applications. HLA, however, uses Object Model Templates (OMT ) to define the standardized
292
X. Shen et al. / Electronic Commerce Research and Applications 1 (2002) 281–300
formats of the functionality of simulation models and the interaction between models. As a result, the capabilities of all simulation models are determined before the actual simulation takes place. OMT in simulation is defined as Federation Execution Data (FED) and each federate in a federation keeps the same FED copy file in its local storage. FED determines object classes at which object instances may be registered and discovered in the simulation, instance attributes that are available to be updated and reflected, as well as interactions that may be sent. This static property of the FED prevents federates from injecting an undefined objects into simulation in progress. To overcome this limitation of HLA / RTI, dynamic properties [24] concepts are introduced to create and inject new objects into the simulation space on the fly. The major appeal of this is that an object class is predefined in FED, which is reserved for all dynamically created object instances, and an interaction class is used for the implementation code transmission of the object instance between creator and receiver. Entities in shared space may have attributes to update / reflect, e.g. position and rotation. These attributes may be defined in different data format. But how to send / receive the attributes through one predefined attribute ‘PDU ’ in FED remains a question to be solved. After sending / receiving the object implementation module, all federates who subscribe to the object class will have an entity-specific module. Although HLA doesn’t determine the specification of message format, the RTI implementation uses stream data to transmit attribute updates, and since the RTI is not aware of the semantics of an attribute. PDU attribute represents the updates for the object: it is the receiver federate’s responsibility to interpret this attribute. The entity-specific module allows the application to define an update packet format for this entity. The attribute update packet has the format as shown in
Fig. 7, where PDU Type Field indicates what information lies in this packet.
3.3.4. Scalable virtual environment In large virtual worlds the number of objects that require certain synchronization or update messages to be transferred over a network can slow down the interaction of the individual user with the shared world in an unreasonable way. And the user may realize only some parts of his / her surrounding. A solution for this problem is the subdivision of large virtual worlds into several regions or zones [8]. A major mechanism for reducing the required network traffic among participants of shared virtual worlds is the division of such virtual worlds into regions or cells. The participants receive only update messages on virtual world contents of a subset of cells. Thus, the network traffic can be reduced significantly. An example of this is the NPSNET [17]. The landscape is subdivided into hexagonal regions, each with its own multicast group. An area of interest manager (AOIM) [11] manages the regions currently visible to the user. Using the three dimensions of space is a wellknown approach to partition VEs into a more or less disjoint set of AOIs. Static geographical regions are used in applications based on natural terrain; such as in DIS based systems [16]. A different approach uses intersecting volumes to model interaction between participants. This notion of a spatial area of interest associated with a user has evolved out of work in the COMIC project [19]. The spatial area, known as an ‘aura’, determines a boundary; objects or users outside the boundary cannot be influenced or interact with each other. In contrast, all objects within the boundary are candidates for influence or interaction. The COMIC model goes further by defining two notions: ‘focus’ and ‘nimbus’ to represent the degree of interest users have in each other. The focus represents the degree
Fig. 7. Attribute update packet format.
X. Shen et al. / Electronic Commerce Research and Applications 1 (2002) 281–300
of interest one user brings to bear on another. The nimbus represents the degree of attention one user pays to another. The combination of the focus and nimbus of two interacting users defines their level or degree of interaction. It is this model that we seek to implement by using the Data Distribution Management (DDM) of RTI. Routing spaces of the RTI are general and allow implementation of many multicasting schemes, typically what Powell [18] called data-based multicasting. Grid-based filtering, for example, could be implemented by using a region per cell. Filtering based on perception of entity, on geographic locality, frequency domain, etc., are other examples of the kind of filtering that routing spaces are able to handle. In RTI, the producer of data shall employ the DDM service to assert properties of their data in terms of user-defined spaces. Consumers of data shall employ DDM services to specify their data requirements in terms of the same spaces. The RTI distributes data from producers to consumers based on matches between these properties and requirements. For the virtual mall prototype, we partition the virtual shopping mall into several separate shops, which are defined as a routing space in RTI. Then, we register an object instance with a region to associate update regions with attributes of that object instance. RTI only dispatches update messages to the objects within the same region. In our approach, a region allows the subdivision of a large virtual world into arbitrary parts. Regions might even build hierarchies, e.g. a shop might be a sub-region of a particular shopping mall. Our approach on regions is based on VRML EXTERNPROTO nodes, which specify the transformation and contents of the region. Because of the hierarchical scene structure in VRML, all the scene descriptions are defined in different scene nodes. Thus each of the scenes in the shared space may have its own coordination, which conflicts with RTI DDM context that requires the shared environment have a single global coordination. A mapping solution has been applied here: other than sending a position update in a 3-dimensional array floating value, 4-dimensional values have been used to represent the avatar’s current position. The first value shows which room the user is in; the other
293
three are the user’s position information in that room.
3.4. Performance evaluation In terms of a performance model, CVE can be divided into four high level components each adding a delay to the overall system: (1) display—the ‘onscreen’ delay created by monitors, projectors, stereo goggles, and other displaying equipments; (2) graphics—the delay caused by the graphics card / drivers and other graphical components of the system; (3) application: the lag introduced as a result of processing / computing performed by the core multiuser engine hardware and software; (4) interconnections: networking and communication delays. Delay and jitter are the most important parameters in CVEs. Among these, delay has been studied more extensively with actual numbers available, which indicate acceptable levels. The acceptable application1network delay is less than 200 ms [28], with some studies suggesting a more restrictive 100 ms [23]. Jitter (delay variation) is also an important factor, sometimes believed to be more important than delay when it comes to coordinating collaborative tasks [27]. But no actual numbers for it are available in terms of what constitutes an acceptable level of jitter. In our evaluations, the combination of application and network delays is referred to as the client-toclient delay (CCD), which is defined as the average time it takes for a given update message to reach a target federate from initiating federate over the network. It does not include the rendering and graphics delay. In vCOM, this delay includes all layers of Java, EAI, JNI, RTI, and physical network delays. For this CCD test, we have an ‘initiator’ federate who creates an object and performs an update on this object, such as a rotation or a translation. A second federate then receives this update and extracts its information. Then, the second federate performs a similar update on an object created by itself. The initiating federate again performs an update on its object, and so on. This procedure is repeated for a given number of times or duration, which was about 5 min in our tests. Another evaluated parameter is the Ownership
X. Shen et al. / Electronic Commerce Research and Applications 1 (2002) 281–300
294
Transfer Delay (OTD). RTI allows only the owner of an object to manipulate it, although everyone in the session will be able to ‘view’ the manipulation. Ownership of an object must be acquired first in order for someone to manipulate the object. This transfer of ownership results in additional delay. This delay should be small enough to maintain a natural feeling in the virtual world. For the OTD test, we have two federates obtaining and releasing the ownership of an object consecutively and in turn over a period of time. The average time to obtain ownership is then calculated. The application consists of a couple of stations running the e-commerce application where one starts as the owner of a certain object. The other client starts the loop by asking for the ownership of that object. From this point onwards the current owner grants automatically the request in the appropriated callback and asking for the ownership of the same object right away. Such loop is run for a predetermined time interval and the delay averaged afterwards. Three different approaches, push / pull by RTI and proposed OOTP (Object Ownership Transfer Protocol) are evaluated. In the case of OOTP test, it is supposed that a certain Object O has two attributes: rotation and translation. Different scenarios are applied in this OOTP test: Case 1. Federate A tries to get the ownerships of both attributes of O, which are initially owned by a single federate, Federate B; Case 2. Federate A tries to get the ownership of both attributes of O, which are initially owned by differ-
ent federates, e.g. Federate B is the owner of rotation while Federate C is the owner of translation. Object Insertion Delay (OID) measures how long it takes for an undefined object to be introduced by a federate into simulation and all other federates who are interested in this object to retrieve and initialize the corresponding code stream. The procedure of OID test procedure can be described as such: Federate A first creates an object, then sends the code stream of the object to Federate B using ‘interaction’ class of RTI. After discovering the created object, Federate B registers and initializes the discovered object, and then it will create its own object and sends the code stream to Federate A. Federate A again performs the same procedure and so on. All tests are performed on Pentium III class PCs running Windows 2000 and connected to a 100 Mbps Ethernet. RTI 1.3v6 is the version that is used for the tests. The graphics is set at 128031024 24-bit color screen resolution with 3D accelerator cards. All machines are running typical operating system and networking background processes. All the tests have been conducted on both of Web browser-based and Java3D-based user interface. Table 1 shows the performance results. We notice that Java3D has better performance on all the tested parameters. That is because, in Web browser based UI, EAI, the interface between rendering layer and Java applet costs additional delay. However, in the Java3D version, Java controller can access graphic rendering layer directly. RTI exhibits acceptable performance on CCD, which are 162 ms
Table 1 Performance result (all delays are in millisecond)
CCD OTD Communication delay a OTD (Pull Mode) OTD (Push Mode) OTD (OOTP Case 1) OTD (OOTP Case 2) OID a
Web browser based UI
Java3D based UI
162 235 91 267 225 269 292 362
121 204 91 223 181 233 257 287
This is CCD minus the delays between the RTI and the rendering part (VRML / Java3D).
X. Shen et al. / Electronic Commerce Research and Applications 1 (2002) 281–300
295
for Web-based user interface and 121 ms for Java3D version. It should be noted that CCD test result would not only be an indication of the transmission speed of the underlying network, but also an indication of the end-to-end delay of the entire system including delays caused by the underlying layers such as transport layer, network layer, or LAN datalink layers, and so on. The CCD which is between 100 and 200 ms is acceptable for the vCOM application where the common actions by avatars are navigation, non-verbal interaction and object manipulation. Ownership transfer is more complex than updated message distribution, therefore the shaking-hand procedure of ownership transfer costs more time for the federates to negotiate ownership transfer than CCD. The evaluation results show that the cost of OTD in push scheme is less than that in pull scheme. The reason is that the ‘push’ scheme allows federate to transfer ownership without an advance request. Compared to ‘push / pull’ ownership transfer, OOTP protocol takes more time because it is involved in two phases: the RTI first chooses the new owner by migrating the ObjectOwner attribute, after which the actual transfer takes place. In test case 1, OOTP has approximately the same results as OTD in poll mode, however, in test case 2, if different attributes are being owned by different federates, there will be additional delay due to the communicating with both federates.
transaction is recorded at the consumer’s offered price. In case of a refusal, the user is also notified and the SA has the liberty of making a counter-offer or not. If a counter-offer is made and accepted by the consumer, the SA records the transaction at the counter-offer price. Our architecture is that of a Multi-Agent System (MAS) (Fig. 8). Each vendor in the mall has one instance of an SA. Consumers are represented by User Agents. Each instance of an agent is a separate entity and is running asynchronously in its own process and possibly on its own machine (SAs are assumed to be continuously running). On the client side, a user agent remembers the user’s personal information through the proper authentication. The client queries the multimedia catalog database through CGI scripts. The user agent is responsible for generating the CGI scripts, parsing the responses from database, which is in CGI format as well, and showing the results on a query window. Communication between agents is completed through a message passing system that uses a broker agent with a name resolution service to registered agents. The broker agent is also considered an agent and run in a predefined machine at a predefined port. It is responsible for registering agents and relaying messages to the appropriate agent. Each SA is identified by the unique name of the vendor it represents (e.g. Sears) and each consumer is identified by the unique user ID provided upon registration in the virtual mall.
4. Multi-agent system in e-commerce
4.1. Sales agent design [2]
In the context of a public virtual mall with multiple independent vendors, our goal is to create a software entity (which we call Sales Agent or SA) that will represent each of these vendors. More specifically, we are interested in enabling the consumer to negotiate the price of a commodity by making a binding offer to the SA. The SA is able to respond to the consumer’s offer by making use of decision rules based on private information (such as cost prices and inventory numbers) not available in the public catalogue of the mall. A response consists of either an acceptance or rejection of the offer. In case of an acceptance, the user is notified and the
The price negotiation protocol can have substantial, rippling effects on the nature of the overall system [20,21]. Consequently, special care must be taken in designing such a mechanism. In that sense, a one-to-one negotiation protocol for e-commerce should have the following design goals: • Be intuitive and easy to understand for the consumers. • Allow both the consumer and the SA to make offers and counteroffers. • Allow both parties the option of refusing an offer made b the other party.
296
X. Shen et al. / Electronic Commerce Research and Applications 1 (2002) 281–300
Fig. 8. Multi agent system in vCOM.
• Allow the no deal option. • Favor a fair process, i.e. not totally biased to the consumer’s or vendor’s advantage. • Address the exploitation of strategy problem. • Should not introduce significant delays in the buying process. A protocol that meets such requirements is proposed as follows. The negotiation protocol is designed by modeling upon what typically happens in price negotiations in a physical retail store. In such negotiations, a consumer and a salesperson engage in the process of
making offers and counter-offers in order to reach an agreement. Our approach to the problem is to ‘mimic’ such negotiation scenario. By doing so, we are catering to design goals 1 to 4. A key characteristic of such a scenario is that an initial offer is already on the table namely the original fixed price of the retailer. This offer is typically always available even if the negotiation fails. As such even if no argument is reached at one point in time, the negotiation cycle never really ends because an offer is always available for the consumer to accept. Fig. 9 provides a state transition model that takes into consideration such characteristics in depicting
Fig. 9. Negotiation between the vendor and the consumer.
X. Shen et al. / Electronic Commerce Research and Applications 1 (2002) 281–300
the possible interactions in a negotiation scenario between a retail vendor and a consumer under our protocol. Note that as the model is state driven, the interaction takes the form of a turn-taking in the exchange of offers. The figure shows that the initial and default state is State-A, i.e. the state where the consumer evaluates the vendor’s initial offer or current counter-offer. The vendor also has a corresponding evaluation state, which is represented on the figure by State-B. Since the vendor already made the first offer, we explicitly chose State-A as the initial state to address our design’s goal of fairness. Furthermore, we feel that turn-taking will ensure a fairness in the overall negotiation process. Initially, the ‘ball’ is in the consumer’s court as he / she can decide to do one of the following three things: 1. Accept the current offer (an agreement is reached), 2. Reject the current offer (no agreement reached yet), 3. Make a counter-offer (start a round of negotiation).2 If the consumer decides to make a counter-offer and starts a round of negotiation, the ‘ball’ then moves to the vendor’s court. To transit out of StateB, the vendor has the same three options that the consumer has in State-A, namely to accept, reject the offer or to counter-offer. Note that in the way we modeled the interaction, a round of negotiation is always initiated by the consumer. As such, the vendor finds himself in State-B, if and only if the consumer makes a counter-offer. Furthermore, it’s not up to the vendor whether an agreement will be reached, as the consumer always reserves the right of accepting the last offer from the vendor, be it the initial fixed price offer. Finally, the process can loop back and forth from State-A to State-B until either side decides to move to the end State-C. To address the exploitation of the strategy, we need to avoid situations in which the consumer attempts to get the best price possible by starting bidding with a very low offer and slowly increasing 2
We define a round of negotiation initiated by the consumer as the transition from State-A to State-B, followed by a transition from State-B to either State-A or State-C.
297
his offer till it is accepted. We also need to prevent another similar scenario where the consumer waits for the sales agent to counter-offer down to its lowest price by making only a low increment counter-offer. To prevent these situations from happening, we propose to: (a) notify the consumer that each offer he / she makes is a commitment to buy at the offered price (b) limit the number of negotiation rounds the consumer can initiate to one, hence limiting the number of guesses he / she can have on the vendor’s reservation price. To implement such an idea, we propose to impose significant delays between rounds of negotiation, i.e. between the time the consumer first makes an offer and the time he is allowed to make another one. The idea is that a consumer fairly committed to buying something now might not be willing to wait X units of time to pursue a negotiation, if X is sufficiently high. While studies could be made to determine the appropriate value of X, we propose to set it to 3 days, which in our opinion is dissuasive enough considering the relatively low inference one could do in a single round of negotiation. Furthermore, we note that this solution is not incompatible with our goal of not introducing delays, as there is always an offer on the table that the consumer can accept immediately, namely the fixed price offer or the current vendor counter-offer. The SA is implemented by using the Java Expert System Shell (JESS) [15] and rules for such engine are kept in a .clp file (clp for CLIPS).
5. Conclusions Electronic commerce is becoming a major component of business transactions. With the creation and use of a virtual shopping mall environment, the users can experience more and more functionalities that they encounter in a real-world shopping. Collaboration with others, dealing with sales agents, 3D visualization, and window-shopping with the use of avatars are but some examples. In this paper, a collaborative virtual shopping mall vCOM, based on
298
X. Shen et al. / Electronic Commerce Research and Applications 1 (2002) 281–300
the HLA / RTI standard, is introduced. The vCOM prototype provides UI improvements with personalization through agents, collaboration through avatars and models and convenience through speech interface. The implementation of vCOM and its architecture support extensions to HLA / RTI for collaboration which concept is central for electronic shopping. This CVE system has been prototyped in the context of a much larger project supported by the Canadian Institute for Telecommunications Research. Several demonstrations have been given at workshops and CITR research meetings. However, formal evaluations of the prototype and usability studies are yet to be conducted for studying the effectiveness, and subjective reactions from shoppers. The initial reactions from various participants during our demonstrations are quite encouraging. As one of the first uses of the HLA standard in an e-commerce setting, vCOM is a good start and more work will be done in terms of through usability studies and architectural evaluations.
Acknowledgements The authors acknowledge the research and development contributions of our team members Patrick Desharnais, Rony Abi-Aad, of Concordia University, and Ramsey Hage, Saeid Nourian, University of Ottawa. The financial support of the Canadian Institute of Telecommunications Research (CITR) is also gratefully acknowledged.
interoperate across large numbers of different types of simulations developed and maintained. This HLA architecture is now an IEEE standard (No. 1516) and an OMG (Object Management Group) standard for distributed simulations and modeling. A.2. HLA overview The HLA standard promotes the reuse of simulations and their components. It attempts to specify the general structure of the interfaces between simulations without making specific demands on the implementation of each simulation. In the HLA baseline documents, three basic concepts are defined: The Interface Specification is a formal, functional description of the interface between the HLA application and the Run-Time Infrastructure. A set of technical rules is defined to which an HLA participant has to comply. The Object Model Templates are standardized formats to define the functionality of simulation models and the interaction between models. In this way the capabilities of all simulation models are defined before the actual simulation takes place. The Run-Time Infrastructure (RTI) software implements the interface specification and represents one of the most tangible products of the HLA. It provides services in a manner that is analogous to the way a distributed operating system provides services to applications. A concise description of these fundamental concepts is given below, along with additional HLA terminology. A.3. HLA concepts and terminologies
Appendix A A.1. High Level Architecture ( HLA) This High Level Architecture (HLA) standard is a general architecture for simulation reuse and interoperability [13] developed by the US Department of Defense. The conceptualization of this High Level Architecture leads to the development of the RunTime Infrastructure (RTI). This software implements an interface specification that represents one of the tangible products of the HLA. The aim of it is to develop, under the leadership of the Defense Modeling and Simulation Office (DMSO), reuse and
Within the HLA, federations are defined as a group of federates forming a community. Federations are comprised of federates that exchange information in the form of objects and interactions. Federates may be simulation models, data collectors, simulators, autonomous agents or passive viewers. A simulation session, in which a number of federates participates, is called a federation execution. Simulated entities, such as vehicles or aircraft, are referred to as objects. Live entities can be mapped onto objects (by using simulation surrogates), so that they can appear identical to simulated entities. All possible interactions between federates of a federation
X. Shen et al. / Electronic Commerce Research and Applications 1 (2002) 281–300
are defined in a so-called Federation Object Model (FOM). The capabilities of a federate are defined in a so-called Simulation Object Model (SOM). The SOM is introduced to encourage reuse of simulation models. An Attribute, referred to as objects state, can be passed from one object to another. Objects interact with each other and with the environment via interactions, which may be viewed as unique events, such as a manipulation of the object, or a collision between objects. Initially, an attribute is controlled by the federate that instantiated the object whose state the attribute is part of. However, attribute ownership may change during the execution. This mechanism allows, for instance, users to co-manipulate the same object. In order to reduce network traffic and limit the amount of computation for each federate, the HLA provides a mechanism of publication and subscription. Upon initialization of a federation execution, each simulation registers the objects and their attributes with the RTI. It also registers which attributes and interactions it needs in order to be able to perform its task (subscription). Note that a federate cannot only subscribe to attribute types, but also to (ranges of) attribute values. The aim here is to filter as much information as possible at the source. Both publications and subscriptions are dynamic and may be changed during a session. In this way, multicast communication is realized which reduces the necessary bandwidth. The Run-Time Infrastructure supports HLA compliant simulations through a number of services. The main categories of services are: Federation Management: create / destroy execution (of a federation), join / resign execution (of a federate), pause / resume execution; Declaration Management: subscription / publication; Object Management: instantiate / delete (an object), update / reflect (an attribute), request / provide (an attribute), send / receive (an interaction); Ownership Management: transfer ownership (of an attribute) from one object to another; Time Management: handling of messages in different ways, depending on the requirements of their destinations, e.g. in receive order (appropriate for real-time human-in-the-loop simulators), in priority order, in causal order, or in timestamp order. These
299
last three methods are typically suitable for non real-time event driven simulations. Data Distribution Management: provides a flexible and extensive mechanism for further isolating publication and subscription interests—effectively extending the sophistication of the RTI’s switching capability. For details of the HLA interface specification, see Ref. [14].
A.4. HLA filtering mechanisms A fundamental abstraction of the HLA data distribution management services is the routing space. A routing space is a multidimensional coordinate system in which federates express interest for either receiving attributes / interactions from other federates or sending attributes / interactions to other federations. Federates also agree to maintain associations of data they own to routing spaces. The RTI uses federates’ expressions of interest to establish the network connectivity needed to distribute all relevant data and minimal irrelevant data from producers to consumers. A routing space is made of subscription regions and update regions. Subscription regions are the expression of the interest of a federate and update regions are the expression of what a federate is able to produce. The overlapping of subscription and update regions informs the RTI of the dependency between federates and the communications to be established. The RTI makes a distinction between routing of data (establishing the necessary network connectivity) and actually sending the data. The objective here is to minimize latency and maximize throughput by establishing the necessary network connectivity before it is actually needed [19].
References [1] J.C. Oliveira, X. Shen, N.D. Georganas, Collaborative Virtual Environment for Industrial Training and e-commerce, Proceedings of the Workshop on Application of Virtual Reality Technologies for Future Telecommunication Systems, IEEE Globecom’2000 Conference, Nov.–Dec. 2000, San Francisco.
300
X. Shen et al. / Electronic Commerce Research and Applications 1 (2002) 281–300
[2] P. Desharnais, Agent Assisted Price Negotiation for Electronic Commerce, Master’s Thesis, Computer Science Department, Concordia University, April 2000. [3] S. Choi, A. Whinston, Economics of Electronic Commerce, Macmillan Technical Publishing, Indianapolis, 1997. [4] X. Shen, R. Hage, N.D. Georganas, Agent-aided Collaborative Virtual Environments over HLA / RTI, Proceedings of the IEEE /ACM Third International Workshop on Distributed Interactive Simulation and Real Time Applications (DIS-RT ’99), University of Maryland, College Park MD, Oct. 1999. [5] Defense Modeling and Simulation Office (DMSO), High Level Architecture for Simulations Interface Specification, Version 1.3. [6] The External Authoring Interface (EAI) URL at http: / / www.cosmosoftware.com / developer / eai.html. [7] Java Native Interface, URL at http: / / java.sun.com / products / jdk / 1.1 / docs / guide / jni /. [8] W. Broll, Populating the Internet: Supporting Multiple Users and Shared Applications with VRML, in: Proceedings of the VRML’97 Symposium, (Feb. 24–28, 1997, Monterey, CA), ACM SIGGRAPH, ACM, 1997, pp. 87–94. [9] J.W. Barrus, R.C. Waters, D.B. Anderson, Locales and Beacons: Efficient and Precise Support for Large Multi-User Environments, in: IEEE Virtual Reality Annual International Symposium, IEEE Computer Society Press, March 1996, pp. 204–213. [10] Active Worlds: http: / / www.activeworld.com. [11] M.R. Macedonia, M.J. Zyda, D.R. Pratt et al., Exploiting Reality with Multicast Groups: A Network Architecture for Large Scale Virtual Environments, in: Proceedings of the Virtual Reality Annual International Symposium, VRAIS’95 Los Alamitos, CA. [12] K. Saar, VIRTUS: A Collaborative Multi-User Platform, VRML99, 23–26 February 1999, Paderborn, Germany. [13] HLA Homepage, URL at http: / / hla.dmso.mil / hla. [14] Draft Standard Modeling and Simulation (M&S) High Level Architecture (HLA)—Federate Interface Specification, DRAFT 1, 20 April 1998. [15] Java expert system shell (JESS): http: / / herzberg.ca. sandia.gov / jess /. [16] R. Abi-Aad, A New user model to support Electronic Commerce M. Comp. Sci. Thesis, Department of Computer Science, Concordia University, Montreal, July 2001.
[17] M.J. Zyda, D.R. Pratt, J.S. Falby, C. Lombardo, D.M. Kelleher, The Software Required for the Computer Generation of Virtual Environment, Presence 2(2) (1994). [18] R.Hage, Voice Enabled Interactive E-Commerce, MASC Thesis in Electrical Engineering, University of Ottawa, 1999. [19] S. Benford, L. Fahlen, C. Greenhalge, J. Bowers, Managing mutual awareness in collaborative virtual environment, in: Proceedings of the ACM SIGCHI Conference on Virtual Reality and Technology (VRST’94), ACM Press, Singapore, August 23–26th 1994. [20] C. Beam, A. Segev, Automated Negotiations: A Survey of the State of the Art, CMIT Working Paper 97-WP-1022, May 1997. [21] C. Beam, A. Segev, J.G. Shanthikumar, Electronic Negotiation through Internet-based Auctions, CMIT Working Paper 96-WP-1019, December 1996. [22] F. Moradi, R. Ayani, G. Tan, Object and Ownership Management in Air Traffic Control Simulation. [23] M.M. Wloka, Lag in Multiprocessor VR, Presence: Teleoperators and Virtual Environments (MIT Press), Vol. 4, No. 1, Spring 1995. [24] X. Shen, MAP: A Mobile Agent-based Platform for Collaborative Virtual Environments, Ph.D. Candidacy Paper, SITE, University of Ottawa, 2000. [25] J. Marathe, Creating Community Online, Durlacher Research Ltd, 1999, available at http: / / unpan1.un.org / intradoc / groups / public / documents / apcity / unpan003006.pdf. [26] A. Warms, J. Cothrel, T. Underberg, Return on Community: Proving the Value of Online Communities in Business, Participate.com, April 12, 2000. [27] J. Leigh et al., Preliminary STAR TAP Tele-Immersion Experiments between Chicago and Singapore, High Performance Computing Asia Conference & Exhibition, Singapore, 1998. [28] K.S. Park, Effects of Network Characteristics and Information Sharing on Human Performance in COVE, Master’s Thesis, Electronic Visualization Laboratory, University of Illinois at Chicago, 1997. [29] T. Schuemmer, GAMA-Mall – Shopping in Communities, in: Second International Workshop on Electronic Commerce (WELCOM’01), Heidelberg, 2001.
