JADE: Java Adaptive Dynamic Environment Manuel Oliveira
Jon Crowcroft
Mel Slater
University College London Computer Science Department Gower St. WC1E 6PT London {m.oliveira,j.crowcroft,m.slater}@cs.ucl.ac.uk
João Pereira INESC/IST Rua Alves Redol, N.9-6 Esq, Office 623 Apartado 13069, 1000 Lisboa
[email protected]
Abstract Virtual Environments (VE) present a complex problem with interesting non-trivial challenges for software development. The problems increase when considering VE that are both distributed and shared amongst multiple participants. The majority of existing systems supporting Large Scale VE (LSVE) are based on monolithic architectures, making maintenance and software reuse difficult at best. This paper presents an overview of the Virtual Reality Transfer Protocol (VRTP) framework as an alternative to the traditional approach for developing VE systems. The focus of the paper is one of VRTP’s building blocks: Universal Platform (UP). Java Adaptive Dynamic Environment (JADE) is an implementation of the UP consisting of a lightweight crossplatform kernel with inherent capabilities for dynamic extensibility in run-time. The paper discusses in detail JADE’s architecture and fundamental design premises. Although these design principles are applicable to other areas, the implementation is targeted at LSVEs. Keywords Virtual Environments, Framework, Components, Virtual Reality, Java, VRTP.
1. INTRODUCTION Traditionally any Virtual Environment system consists of a complex and intricate software application, where the development expertise is wide spread across the many fields of computing. Existing systems tend to excel at specific tasks, constraining the overall design and consequently the underlying implementation. The imposed restrictions exert a negative impact on system performance when a task not originally considered in the design core is executed. These problems are more acute when considering Large Scale VE (LSVE), where the centralised conformity of a single VE is partitioned across the heterogeneous hosts in the network. Each of the existing systems makes dogmatic and questionable assumptions about the best practise for handling the problems associated with LSVEs, resulting in a wide range of different architectures and implementations. Some of the most well known systems supporting LSVE are listed: AVIARY [Snowdon94], BrickNet [Singh94], DIVE [Hagsand96], MASSIVE [Greenhalgh95], NPSNET [Macedonia94], PARADISE [Singhal96],
RING [Funkhouser96], SPLINE [Anderson95] and VLNET [Capin97]. These systems focus on particular applications, leveraging whenever possible the particularities of each problem domain and consequently constraining the design space and consequently reducing the overall complexity of the implementation. However this approach imposes serious difficulties when it comes to reusability because the properties gained through optimisations generate implementations where the internal architecture is tightly coupled with the specific functionality. Unfortunately, existing systems raise major obstacles when attempting to port the experience embedded into a particular LSVE system to another. The problems stem from the fact that systems are tightly coupled in terms of implementation. Consequently, the design criterion moulds all the mechanisms and processes to the particularities of a system. As a result, it is difficult to extract any relevant code from a particular system and adapt it to the specifics of a target system. In most cases, the incompatibility hurdles renders ineffectual any integration effort.
Although diversity is present in all the system constituents, the infrastructure support for simultaneous participants is the area where the differences are most prominent. In the majority of the cases, a system only supports at most a few dozen of simultaneous participants, such as DIVE and MASSIVE. In these systems, collaboration within small groups has been the main requirement; leading system developers to remove the mechanisms for large scale from the core design of the system. On the other extreme, there are the systems based on the Distributed Interactive Simulation (DIS) [DIS93] protocol, such as NPSNET, that focus on large-scale combat simulation with thousands of participants. The whole design of the system is focused on scalability of large number of users. However, the requirements of these systems are extremely demanding in terms of network and computational resources, resulting in a cost that is prohibitively higher in comparison with any other system. Ideally, it should be possible to extract and customise the component from NPSNET that is responsible for managing the DIS protocol, and integrate it into the DIVE system. Unfortunately, due to the divergence in their designs, such a scenario is not possible. The usage of a common framework would facilitate integration, although some customisation would be necessary due to the fundamental differences in the respective data and processing models. Despite the prominence of monolithic architectures, some systems have begun to break away from their legacy architectures, towards a modular implementation. However, the transition is plagued with re-design problems that are time consuming and in some cases without solution. The tendency for modularity is rippling through VE systems; nevertheless, it has not achieved the goal of software reuse or code portability between different systems. The Java Adaptive Dynamic Environment (JADE) consists of a minimal application kernel that provides a common infrastructure for LSVE systems. JADE follows the premises of the Virtual Reality Transfer Protocol (VRTP) [Brutzman97], implementing a simple framework based on component philosophy, thus promoting a methodology that is based on object-oriented principles. The adoption of JADE does not provide an automatic solution to problems that arise from the traditional approach to the design of LSVE systems. However, the more a system adopts the proposed framework, the more it will benefit from the functionality made available while increasing the code portability amongst different systems. Consequently, a system self-contained within a single component may see only minimal benefits from the proposed framework. On the other hand, if the system has the JADE framework initially ingrained into its design, then it would be possible to gain benefits such as dynamic replacement of parts of the system at run-time. The remainder of the paper is organised into four main sections. In Section 2, the VRTP component framework is described, indicating the role of JADE. Section 3 describes the JADE architecture, explaining the supporting design principles. Section 4 positions JADE in compari-
son to related work. Finally, some concluding remarks are given in Section 5. 2. VRTP The Virtual Reality Modeling Language (VRML) [VRML97] provided the means to enable the World Wide Web (www) with 3D capabilities, enhancing the traditional 2D flat perspective web browsers with windows into virtual worlds. The emergence of eXtensible Markup Language (XML) is revolutionising the www and consequently VRML is being revised to leverage the benefits of XML, where one of the underlying design goals is a component architecture of the respective content browser. The current version of VRML only aims at content definition of 3D scenes in terms of geometry and behaviours. The event model defined by the specification did not foresee distribution of events beyond the local host, thus multiple participants are not directly supported. However, it is part of human nature to communicate, exchange ideas and collaborate with one another, therefore the absence of multi-user capabilities was rapidly recognised. The importance and potential of LSVE can be validated by the analysis of the traditional Multi-User Dungeons (MUDs) [Curtis94, Morningstar90] experiments. These MUDs have demonstrated their potential as social [Morningstar90] enablers and work supporting tools [Curtis94]. LSVE provide a richer interface and medium, thus enhancing the results provided by MUDs. Although VRML does not provide native support for LSVE, several solutions have emerged, such as [Das97, Lea97, Broll98]. These approaches are based either on extensions to the VRML’s event model or other similar mechanisms that operate in parallel to satisfy the multiuser requirements. In the case of extending VRML to support multiple users, the required mechanisms are included into the scene graph and the respective event model by resorting to the use of the Prototype Node. The other alternative is to have a parallel data structure that shadows the scene graph, capturing and disseminating all the local and remote events. The Virtual Reality Transport Protocol (VRTP) framework aims to provide the necessary infrastructure to support LSVE with multi-user capabilities. The overview of the proposed framework is presented in the block diagram of Figure 1. The framework defined by VRTP focuses on the specification of the components along with their interfaces and interactions with one another. This approach gives the developers of choosing what they wish to adopt in their systems, without enforcing any constraints. Although not explicitly represented in Figure 1, each of the main components is in turn composed of other subcomponents. To strengthen the proposal, the VRTP working group (WG) [VRTP99] is developing a reference implementation as open source, but its flexible design allows developers to customise and extend the framework to their needs.
users to host their own worlds within the domain of a LSVE.
Peer-to-Peer. This component handles lightweight objects, corresponding to state, control and event data being composed of small messages. The QoS associated with transmission varies according to the requirements of the semantics of the data. For example, control data requires total reliability of delivery while absolute state dissemination does not share the same requirement. However, it is important to evaluate the impact of the reliability mechanisms on the latency of system. This component is also responsible for group management, which is necessary to alleviate the demand on network resources in exchange for computational resources without compromising the overall experience of the end-user. The effects of grouping entities [Macedonia95, Abrams98] according to their temporal, functional and spatial interests have demonstrated positive results and it has become a common feature of existing VE systems.
Client. The former components represent the underlying system, while the client component encapsulates the application with all the particularities of a solution. The implementation may range from a simple plug-in for a browser to a full complex LSVE for simulation purposes.
Figure 1 - Overview of the VRTP framework
Each component has a well-defined role:
Universal Platform. This is the backbone component of the VRTP framework. It consists of a flexible kernel with dynamic extensible characteristics allowing the system to evolve in run-time. This component also provides low-level networking services in conjunction with a minimal directory service. The Universal Platform (UP) is designed according to the Application Layer Framing principles [Clark90], delegating to the application more network awareness and responsibility in the management of the network related resources. Monitor. The ability to monitor has long been overlooked despite the demand of end-users to understand the reasons behind the degradation of their presence in a LSVE, leaving them without the possibility of adjusting parameters to improve the properties they consider essential. This component monitors the network status, providing necessary feedback for the application so it may adapt as required taking into account the expectations of the user. In current network multimedia applications, such as videoconferencing, the trend is to include the user within the Quality of Service (QoS) framework. The user is empowered with the responsibility of deciding the trade-offs between network quality and the respective cost (in terms of resources and price). Server. The server component is responsible for the management of heavyweight objects, retrieving them from the network when necessary. These objects correspond to significant amount of data, requiring reliable connection-oriented communication for transmission. However, this component may either be inactive or active, depending upon its role. Where it is inactive, the component is only responsible for retrieving data from the network; otherwise, the component may assume an active role that enables end-
When analysing the current topologies of existing systems, one is confronted with a chaotic clutter where the dominance of a best practice case is non existent, proving that field of LSVE is still maturing. This situation condemns to failure any attempt to standardise the infrastructure due to the significant proliferation of solutions. Therefore, VRTP is independent of an architecture for the infrastructure, supporting diverse configurations, ranging from client-server to peer-to-peer, however an architecture does emerge as soon as the components are wired together. This means that the essential capabilities for networking are provided, delegating to the system developer the responsibility of how the services are used and interconnected, thus defining the required topology as necessary. As illustrated in Figure 1, the components’ functionality is aggregated into three distinctive levels of flexibility, allowing different options to the LSVE developer. The flexibility is reduced as the level increases and the components assume particular roles and functionality. Level 0, corresponds to the UP. This basic level provides the minimal infrastructure for a system, without compromising flexibility. However, the VE developer is required to develop the necessary components of the system along with the client application. Level 1 provides a toolkit perspective with the peer-topeer, server and monitor components. The VE developer may adopt the required components while implementing the remaining ones necessary for the application.
Productivity increases while reducing the probability of implementation errors, however the flexibility also is reduced. Level 2 is the topmost level where flexibility is constrained in exchange for a client application requiring minimal customisation. This level has two target audiences:
Bamboo relies upon the Netscape Portable Run-time (NSPR) technology as its underlying infrastructure to support its cross-platform characteristics. In addition, Bamboo uses the concept of language loaders to allow the integration of modules developed in other languages other than C/C++.
•
Users may adopt a fully functional LSVE as it is provided in the reference implementation;
•
VE developers may extend, adapt or customise the elements of the client component. This eases the porting of existing VE systems to the VRTP framework, so it may be possible to develop only wrappers. Thus the system is allowed to take advantage of the components of the other levels without compromising its architecture or implementation.
Bamboo does not provide the possibility of a rich set of APIs to aid the development of a LSVE system. On the other hand, JADE takes full advantage of the rich functionality readily available in any Java Virtual Machine (JVM) along with the functionality provided by the extension libraries such as Java3D [Sowizral97]. The fact that Java has been accepted within the software development industry, promotes its wide deployment across different platforms. Furthermore, it is reasonable to expect the language to continue to evolve, benefiting from a large developer base.
3. JADE The JADE initiative is an implementation of the UP as defined in the VRTP framework, being an alternative to another proposed implementation for the UP, named Bamboo [Watsen98a, Watsen98b]. Both solutions are based on strong software engineering principles, which have previously existed in other fields of computer science, namely operating systems and middleware.
3.1 Modules JADE proposes a framework, which combined with the kernel, achieves the objective of dynamic code management of a LSVE system. The main building block available in the JADE framework is the Module, which has embedded the minimal interface that a component must implement for it to be manageable by the kernel, as depicted in Figure 2.
Although Bamboo and JADE share common functional objectives, they have divergent design architectures and consequently different implementations. These differences result from the adoption of different philosophies, which emerged from the fact that Bamboo adopted C++ as its implementation language, while JADE is based upon Java. The choice of implementation language should not exert any crucial impact to the final design of a system. However, Java consists of more than just a development language, offering a platform with inherent base functionality. So while Bamboo focuses on developing all the necessary mechanisms to support dynamic loading across different platforms and basic resource management, JADE moulds the functionality available in Java towards the same purpose. This results in JADE providing extensions not available in Bamboo. In common with JADE, Bamboo consists of a small flexible kernel, which is ever present in the background. The kernel allows dynamic code management of a system, in terms of loading and unloading segments of executable code. This management is only attainable by following the proposed design principles of partitioning the overall system functionality into components denominated Modules. How the code is organised into Modules depends entirely upon the design of a particular LSVE system. The flexibility characteristic stems from the fact that provided that the Module interface is respected, then code of any nature may be integrated into the kernel. Both JADE and Bamboo provide minimal resource management, thereby avoiding problems normally associated with concurrency.
public abstract void initialise(); public abstract void shutdown(); protected abstract void activate(); protected abstract void deactivate(); protected abstract void buildDescription(); Figure 2 - Minimal Module interface
The minimalist interface maximises flexibility, by avoiding imposing any constraints on the design of the LSVE system. However, it is sufficient for JADE to manipulate any Module. In addition to the minimal interface, the Module benefits from persistency since the base class also implements the java.io.Serializable interface. In case the default persistence provided by Java is not sufficient then the appropriate methods need to be overridden. Considering that the JADE kernel manages Modules that are dynamically loaded/unloaded during run-time, there exist four main states that a Module may have: Loaded, Destroyed, Deactivated and Activated. The combination of these states and respective transitions, result in the state diagram of Figure 3, which corresponds to the Module life cycle. The Loaded and the Destroyed states are merely transitory in nature; the former corresponds to when the Module is resident in memory after being dynamically linked into the kernel, while the latter corresponds to when the Module is unloaded from memory and all resources are liberated to be garbage collected. The JADE kernel, un-
less otherwise indicated, immediately initialises the Module before incorporating it into the running system. The remainder states, Deactivated and Activated, constitute the main run-time cycle of a Module, with the transitioning being triggered by the usage of the available interface.
The getModule method is protected and this is design intentional, relying upon derived subclasses to make Modules available outside the container. The JADE kernel provides such a method retrieveModule, which uses getModule and synchronisation mechanisms to provide accessibility to a Module. With the purpose of having concurrent Modules, there exists a variant to all Modules, named Runnable. This implies that the module is self-contained within its own processing thread. To avoid having a proliferation of threads for the existing Modules, due to the resource cost of each instance, JADE provides a specialised ModuleManager based on the Reactor pattern. The relation between the different types of Modules is depicted in Figure 5, where JADE represents the kernel. The difference in the shade of the shapes symbolises whether or not a Module is Runnable. Intra-Module communication is a two-phase process, where the requestor Module finds the target Module, by requesting from the relevant ModuleManager responsible.
Figure 3 - The Module life cycle diagram
While Activated, a Module may be reloaded. The reload process requires the existence of a policy. To support the execution of these policies, the Module contains a Description that encapsulates its name, version and URLs, which provides the basis for a policy. The current default reload policy of JADE is version control to avoid the replacement of active Modules by older versions. Nevertheless it is possible to replace the default reload policy when configuring the JADE kernel. public void loadModule(…); public void reloadModule(…); public void unloadModule(…); public void unloadAll(); protected Module getModule(…); protected abstract void buildReloadPolicy(); Figure 4 - Core of the ModuleManager
The Module corresponds to a single element, however the JADE framework provides a container of modules, which consists of a particular Module known as ModuleManager. The ModuleManager does not provide solely a means of containment but supports a set of operations to manage modules as enumerated1 in Figure 4. 1
(…) means parameter overloading resulting in several variations of the method
Figure 5 - Relationship between different types of Module
The ModuleManager returns a reference to the target Module should it exist. Once the requestor Module has the reference it may communicate with the target Module, provided it knows beforehand the respective interface or uses reflection mechanism available in the Java language to discover the interface. Should the requesting Module not exist, then two possibilities are available. Either the requestor Module blocks its processing, waiting to be notified of the emergence of the other Module, or it may continue its execution. Naturally, the possibility of blocking imposes upon the developer careful design to avoid livelocks/deadlocks. 3.2 JADE Kernel The JADE kernel is basically a ModuleManager containing particular mechanisms to support the desired functionality as specified by the UP. Towards this end, several helper classes/interfaces reside within JADE, of which the most relevant are: •
JADELoader. This class retrieves Modules, classes or system libraries from any location and dynami-
cally links them to the kernel run-time. The location of the resource ranges from the local hard disk to a remote repository on the Internet. •
Configuration. This interface is implemented by classes containing the procedures to configure the kernel.
•
ReloadPolicy. This class is used whenever a Module is reloaded.
•
ResourcePool. Pool of resources readily available to all Modules. A resource may be something as concrete as a Thread or more abstract, such as a command.
in Java Development Kit 1.2 (JDK) provides fine grained security policies associated with class loading.
These classes will be explained further in the following sub-sections. All of the helper classes/interfaces are transient, so their state is always lost even though the kernel maintains the state of all its Modules. The kernel possesses default implementations for these helper classes/interfaces, providing the designated functionality. However, should the default implementations not suffice, then it is possible to replace them with customised code. This replacement process may be done either at the configuration phase or at run-time, although it is advisable to avoid manipulating the helper classes/interfaces at run-time. The JADE kernel is the hub of all resources of a LSVE system, so it is convenient to have easy accessibility. To provide ubiquitous access2 to the kernel without resorting to reference passing, the JADE kernel implements the Singleton pattern [Buschmann98]. This pattern enforces that only one single instance is available in the JVM at any given time. 3.2.1 JADELoader The JADELoader is the fundamental helper class of the JADE kernel. It is responsible for retrieving resources based on a unique identifier and the URL indicating its location. The relationships between sources and sinks related to the JADELoader are depicted in Figure 6. The retrieval methods employed by JADELoader depend upon what is defined by the corresponding URL, which not only defines a location of the resource, but also the protocol to be used. By default, if the URL does not specify the Hypertext Transfer Protocol (http) then the resource is located on the local host and the system path variables are used. Otherwise, the resource is located remotely, and therefore the appropriate protocol is used for retrieval as indicated in the protocol section of the URL. The JADELoader handles the target resource in different ways, according to its nature. In the case of a Module or a Java class, the JADELoader retrieves the corresponding classfile, linking it dynamically before creating an instance. This dynamic linking mechanism is an inherent property of the Java Virtual Machine [Venners98], which 2
Anywhere in the system the kernel is accessible by invoking Jade.getInstance()
Figure 6 - JADELoader with sources/sinks
The JVM does resolution of classes, meaning that additional classes required by a class being linked are loaded into the same namespace of the current java.lang.classloader. However, the search is done based on the current URLs known, so it is advisable to either compact all required classes in a single jar (or zip) file or guarantee that the classes with interdependencies are located in the same resource path. It is possible to integrate native code (C/C++, Pascal, Assembly, LISP, etc) as long as it is provided by means of a system library3 so the JADELoader may load it into its memory space. In the Windows operating system, the most common library form is the Dynamic Link Library (DLL). Although interaction with these native libraries is possible by resorting to the Java Native Interface (JNI), the goal of having a system with cross-platform characteristics is compromised by the constraints of availability of libraries in each supporting platform. 3.2.2 Configuration The structure of the kernel may be determined at runtime, provided an object implementing the Configuration interface is supplied before initialising the JADE kernel. Should none be given, then the default option is used: JADEConfiguration. This class extends the ConfigurationFile class to implement the particularities of VRTP through the use of a file. The configuration file is segmented into sections. Each section is composed of a section header followed by its body. The section header contains a separator followed by a section name, which is used to identify the dedicated SectionHandler. The SectionHandler is responsible for parsing and interpreting the section body. The addition of more information into the configuration file depends 3
Java supports both dynamic and static libraries.
solely upon the creation of specific SectionHandlers and adding them to the ConfigurationFile. This implementation is based on the Command pattern [Buschmann98]. The JADEConfiguration includes a SectionHandler to parse Modules/libraries and retrieve them with the JADELoader. The class also provides the means of parsing initialisation data from the file related to a particular Module. This function is particularly useful when passing Module(s) responsible for communication, all the relevant information about remote hosts and their parameters in terms of connectivity. 3.2.3 ReloadPolicy This class is invoked whenever a request to reload a Module is given to the kernel. The default implementation uses the description of the Modules to validate version compatibility and verifies if the newer version is originated from an authenticated source. 3.2.4 ResourcePool The ResourcePool manages threads, which are used whenever parallel execution is required, such as loading Modules. This approach is necessary since the JADE kernel handles missing Modules by applying the Java synchronisation mechanisms of wait and notify. As there is no guarantee that Modules will be loaded according to their dependencies, threads are required to avoid deadlocks. 4. RELATED WORK JADE benefits immensely from the Java language and the built-in mechanisms that make it portable across different platforms. The aim of middleware, such as Common Object Request Broker Architecture (CORBA) [Orfali98] (real-time CORBA is an active area of research [Yang98]) and Distributed Component Object Model (DCOM) [Grims97], is to promote software reusability. However it does not present itself as a viable solution due to the real-time requirements of LSVE that make systems very susceptible to any latencies introduced by the middleware. There are several research proposals to build multimedia applications from components (i.e.: MMLite [Helender98]), although none has been proposed for virtual environments. Moreover, their component frameworks are tied to the domain of particular multimedia applications, such as videoconferencing. This makes it significantly difficult to generalise results to other areas, such as LSVE. The problem in defining a framework is to establish the life cycle of components and their management, including the way of interacting with one another. In JADE, the solution is based on defining a flexible interface and providing the mechanisms for Module management. Another alternative is to resort to multicast communication to create a local4 data bus for components to exchange infor-
mation. Such an approach is adopted in [Schulzrine95] and [Otto98], however minimal transmission mechanisms must be used for communication purposes. The associated overhead of those mechanisms incurs significant performance penalties when compared to JADE (an order of magnitude5). Nevertheless it is possible to integrate a Module that implements the data conference bus as defined in the MBus specification [Otto98]. 5. CONCLUSIONS Any LSVE requires an infrastructure, however this research field is still maturing and the existing entropy makes it difficult to integrate different technologies together into a single system. It is clear that there is a need for a dynamic infrastructure that will integrate different components according to the requirements of the system. This will also reduce the cost of development of new technologies (both in terms of resources and time) since the implementation is focused on a particular module rather than a whole system. JADE is an implementation of the Universal Platform as described by the VRTP working group, providing a small dynamic kernel that permits run-time integration of modules and an extensible framework. However, this framework does not impose the constraints and loss of flexibility that is encountered in traditional toolkits. The design of these interfaces is based upon the experience of existing LVSE systems and their common requirements. The use of Java as the implementation language facilitates deployment since the JVM is widespread across major operating systems and browsers, which obviates the enduser of the encumbrance and difficulties regarding installation of a common platform to operate. 6. ACKNOWLEDGEMENTS This work was sponsored by the Portuguese Foundation for Science and Technology. The work has benefited from the useful and insightful comments from Dr. Anthony Steed. The quality of the paper benefited from the comments provided by Kent Watson, Prof. Joaquim Jorge, Dave Pertaub, Mischa Weiss-Lijn and the anonymous reviewers. 7. REFERENCES [Abrams98] Abrams, H., Watsen, K. and Zyda, M., “Three-Tiered Interest Management for Large Scale Virtual Environments”, Proc. VRST’98, Taipei, September, 1998 [Anderson95] Anderson, D., Barrus, J., Howard, J., Rich, C. and Waters, R., “Building Multi-User Interactive Environments at MERL”, IEEE Multimedia, Winter 1995, pp. 77-82 [Broll98] Broll, W., “DWTP – An Internet Protocol for Shared Virtual Environments”, 3rd Symposium VRML’97, Monterey, February, 1998, pp. 15-24 5
4
Locality is achieved by setting the Time To Live (ttl) parameter of each packet to 0.
A simple benchmark was done to validate the performance differences.
[Brutzman97] Brutzman, D., Zyda M., Watsen, K. and Macedonia, M. “Virtual Reality Transfer Protocol (VRTP) Design Rationale”, Workshops on Enabling Technology: Infrastructure for Collaborative Enterprises (WET ICE): Sharing a Distributed Virtual Reality, MIT, Cambridge Massachusetts, June, 1997 [Buschmann98] Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P. and Stal, M., “A System of Patterns”, John Wiley & Sons, 1998 [Capin97] Capin, T., Noser, H., Thalmann, D., Pandzic, I. and Thalmann, N., “Virtual Human Representation and Communication in VLNet”, IEEE Computer Graphics and Applications, Vol. 17, N. 2, Mar-Apr 1997, pp. 42-53 [Clark90] Clark, D. and Tennenhouse, “Architectural Considerations for a New Generation of Protocols”, Proc. SIGCOMM’90, Philidelphis, September 1990, pp. 200-208 [Curtis94] Curtis, P. and Nichols, D., “MUDs Grow Up: Social Virtual Reality in the Real World”, Proc. IEEE Computer Conference, January, 1994, pp. 193-200 [Das97] Das, T., Singh, G., Mitchell, A., Kumar, P. and McGee, K., “NetEffect: A Network Architecture for Large Scale Multi-User Virtual Worlds”, Proc. VRST’97, Lausanne, 1997, pp. 157-163 [DIS93] “Standard for Information Technology – Protocols for Distributed Interactive Simulation Applications”, Institute for Simulation and Training, Technical Report IST-CR-93-15, May 1993 [Funkhouser96], T., “RING: A Client-Server System for Multi-User Virtual Environments”, Proc. Siggraph Symposium on Interactive 3D Graphics, Monterey, April, 1996 [Greenhalgh95] Greenhalgh, C. and Benford, S., “MASSIVE: A Collaborative Virtual Environment for Teleconferencing”, ACM Transactions on Computer Human Interfaces, Vol. 2, N. 3, pp. 239-261, September 1995 [Grims97] Grims, R., “Professional DCOM Programming”, WORX, 1997 [Hagsand96] Hagsand, O. “Interactive Multiuser VEs in the DIVE System”, IEEE Multimedia, Spring 1996, Vol. 3, N. 1, IEEE Computer Society, pp. 30-39. [Helander98] Helander, J. and Forin, A., “MMLite: A Highly Componentized System Architecture”, Proc. 8th SIGOPS European Workshop, Sintra, September, 1998 [Lea97] Lea, R., Honda, Y., Matsuda, K. and Matsuda, S., “Community Place: Architecture and Performance”, 2nd Symposium VRML’97, Monterey, 1997, pp. 41-50 [Macedonia94] Macedonia, M., Zyda, M., Pratt, D., Barham, P. and Zestwitz, S., “NPSNET: A Network Software Architecture for Large-Scale Virtual Envi-
ronments”, Presence: Teleoperators and Virtual Environments, Vol. 3, N. 4, 1994 [Macedonia95] Macedonia, M., Zyda, M., Pratt, D., Brutzman, D. and Barham, P., “Exploiting Reality with Multicast Groups: A Network Architecture for Large-Scale Virtual Environments”, Proc. IEEE Virtual Reality Annual International Symposium (VRAIS’95), North Carolina, March, 1995 [Morningstar90] Morningstar, C. and Farmer, F., “The Lessons of the Lucasfilm’s Habitat”, Proc. 1st Annual Conference on Cyberspace, 1990 [Otto98] Otto, J., Perkins, C. and Kutscher, D., “A Message Bus for Conferencing Systems”, Internet Draft, August 1998 [Orfali98] Orfali, R. and Harkey, D., “Client/Server Programming with Java and CORBA”, 2nd Edition, John Wiley & Sons, 1998 [Schulzrine95] Schulzrine, H., “Dynamic Configuration of Conferencing Applications using Pattern Matching Multicast”, Proc. 5th International Workshop on Network and Operating Systems Support for Digital Audio and Video, New Hampshire, April, 1995 [Singh94] Singh, G., Serra, L., Pang, W. and Ng, H., “BrickNet: A Software Toolkit for Network-Based Virtual Worlds”, Presence, Winter 1994, Vol. 3, N.1, pp. 13-34 [Singhal96] Singhal, S. and Cheriton, D., “Using Projection Aggregations to Support Scalability in Distributed Simulation”, Proc. International Conference on Distributed Computing Systems (ICDCS’96), 1996 [Snowdon94] Snowdon, D. and West, A. “AVIARY: Design Issues for Future Large-Scale Virtual Environments”, Presence Vol. 3 N. 4, 1994 [Sowizral97] Sowizral, H., Rushforth, K. and Deering, M., “The Java3D API Specification”, AddisonWesley, 1997 [Watsen98a] Watsen, K. and Zyda, M., “Bamboo – A Portable System for Dynamically Extensible, RealTime, Networked, Virtual Environments”, Proc. IEEE Virtual Reality Annual International Symposium (VRAIS’98), Atlanta, March 1998 [Watsen98b] Watsen, K. and Zyda, M., “Bamboo – Supporting Dynamic Protocols for Virtual Environments”, Proc. IMAGE Conference, Arizona, August 1998 [Venners98] Venners, B., “Inside the Java Virtual Machine”, McGraw Hill, 1998 [VRML97] “Virtual Reality Modeling Language”, ISO/IEC DIS 14772-1, April 1997 [VRTP99] www.web3d.org/workinggroups/VRTP [Yang98] Yang, Z. and Sun, C., “CORBA for Hard RealTime Applications: Some Critical Issues”, Operating Systems Review, pp. 64-71, Vol. 32, 1998
