A Skeleton-Based Approach for the Design and Implementation of Distributed Virtual Environments

Fethi A. Rabhi School of Information Systems The University of New South Wales Sydney, NSW 2052 (Australia) Helen Cai and Brian C. Tompsett Department of Computer Science The University of Hull Hull HU6 7RX (UK)

Abstract
It has long been argued that developing distributed software is a difcult and error-prone activity. Based on previous work on design patterns and skeletons, this paper proposes a template-based approach for the high-level design and implementation of Distributed Virtual Environments (DVEs). It describes a methodology and its associated tool which includes a user-interface, a performance analyser and an automatic code generation facility. It also discusses some preliminary results on a surgical training system.

1 Introduction
In recent years, the demand for distributed systems has been increasing due to the widespread use of real-time and information systems that can operate over general purpose networks. However, the process of developing distributed software is still immature since it involves a large number of complex design issues such as synchronisation, timing constraints, data distribution and fault-tolerance. Part of the problem comes from the fact that most systems are built in a bottom-up fashion i.e. they are often constructed using software modules that have already been developed. Each sequential activity is modelled separately using known techniques and interaction is usually left much later in the design process or only addressed during the implementation phase. Whilst this is unimportant for an information system for example, analysing and understanding the systems overall behaviour is crucial for satisfying the requirements of a large number of systems particularly distributed real-time systems. Fuelled by the popularity of object models and languages, there has been an increasing tendency to use a software layer (called middleware) to link all the software components that comprise a distributed architecture. A standard

such as CORBA [10] is a promising development because it offers the opportunity for software components to communicate and synchronise regardless of their programming language or host operating system. However, such standards cannot deal with issues such as fault-tolerance and timeliness since all interaction-specic details are left to the underlying communication system. In addition, they offer users low level programming interfaces and cannot accommodate changes easily. The aim of this paper is to study the role of patterns and skeletons in the design and implementation of distributed systems, focusing on Distributed Virtual Environments (DVEs) selected as a case study. Section 2 describes DVEs and discusses various approaches for designing and implementing them. Section 3 presents a design pattern which facilitates the extension of a VE into a DVE. Section 4 discusses a skeleton-based methodology for using this pattern and its associated tool. Some preliminary results on a surgical training system are discussed in Section 5.

2 Distributed virtual environments (DVEs)

2.1 Denition
A Virtual Environment (VE) [6] is a computer-generated world accessible to a (human) user through input/output devices. It is similar to a traditional simulation but with an emphasis on three-dimensional graphics, immersion and realtime interaction. A Distributed Virtual Environment (DVE) has several participants interacting simultaneously with the virtual world. A concrete example (described later in the paper) is a surgical training system where participants include one trainer (the surgeon) and several trainees (the observers). The surgeon conducts the operation through a virtual hand controller and provides explanations through a microphone. All observers can visualise the model patient from various angles through a helmet mounted display as well as receive audio information from the surgeon through

Producer Shared data Initialisation() Shutdown() Register() ConcreteActor Virtual Environment Actor State Load_World() Shutdown_World() Collect_Input() Update_World() Display_View() ConcreteSpectator Spectator State Update() Display_View()

Spectator Attach() Detach() Retrieve()

Actor Attach() Detach() Notify()

Figure 1. Structure of the Actor-Spectator-Producer pattern headphones or speakers. Developing such an environment is a challenging task particularly for the inexperienced software developer. First, there are performance requirements (e.g. the virtual world has to run the simulation efciently), real-time requirements (e.g. outputs must be generated within some time constraints), reliability requirements (e.g. the system must cope with users at different geographic locations) and dynamic changes (e.g. users joining and leaving at any time). Secondly, during the design activity, the concurrent aspects of the system must be correctly expressed, an architectural model which embodies the resources and the network(s) involved must be developed and an adequate logical-physical mapping that satises the requirements must be determined. Finally, the system must be implemented using a suitable combination of language(s), operating system(s) and communication protocol(s). entities it maintains in the virtual world to the other participants so that they can update their database. The most important drawback with this method is its large communication overheads. Another solution is to have one computer containing the database and sharing it with all other hosts. This time, the problem is that the databases host computer becomes a communication bottleneck. Alternatively, programmers prefer to create their own system architecture, adapted to their own requirements, using standards such as Distributed Interactive Simulation (DIS) [7]. Ideally, designers would like to dene a software architecture without committing themselves to a particular implementation. Automatic tools would be in charge of tailoring this architecture to the underlying distributed system. This is our preferred option. More precisely, we propose a solution along the following lines:

2.2 Approaches for designing and implementing DVEs

In general, it is likely that a standalone VE is already in operation. For this reason, practitioners are often reluctant to use top-down software design methodologies (such as UML) that are more suited to designing completely new systems. Often, a simple solution which operates at the implementation level is adopted. One possibility is to replicate the virtual world database in each computer. At regular intervals, each host broadcasts the location and state of all

Offer a design pattern [8] specically aimed at DVEs. This will clearly present a high-level description of the system and explain the interaction between the different components in the system. This is described in the next section. Consider the DVE interaction pattern as a basic skeleton [4, 14] and propose a programming environment around it, in similar ways to other skeleton-based programming environments we already developed for parallel applications [11, 12, 17]. This is discussed in Section 4.

3 A design pattern for DVEs

Design patterns vary greatly in aims and scope. They offer solutions ranging from high-level strategies for organising software to low-level implementation mechanisms. Recently, there has been a growing number of patterns which express known concurrent behaviour of interacting entities over a possibly distributed platform [1, 5, 9, 16]. The proposed design pattern is based on the well-known Observer pattern where a server process is in charge of monitoring a real-time environment and informing a set of clients processes (called the observers) when changes in the monitored values (e.g. sensor values) occur. In this context, we will call the information provider an Actor and the information consumers the Spectators. The Observer pattern would be inadequate because the Spectators are likely to affect the real-time response of the Actor, particularly if they are at distant locations. In addition, signicant changes would have to made to Actors code to handle the registration of Spectators, sending notications to the Spectators etc. The main idea behind the proposed design pattern is to introduce an intermediate component between the server and spectators called the Producer. The analogy is that an actor should only concentrate on the performance and delegate to the producer mundane tasks such as advertising, registering spectators and monitoring shows. The proposed pattern works as follows. During the simulation, whenever there is a change in the Actors state, it noties the Producer of this change. Spectators make requests for modications to the Producer on a regular basis to update their own state. This pattern is called the Actor-Spectator-Producer pattern to match the regular pattern denomination in [1]. Figure 1 shows the class diagram, which represents the structure of the Actor-Spectator-Producer pattern. As mentioned before, the Producer acts as a bridge between the Actor and the Spectators and holds the shared data objects related to a Spectators view. The Producers role is very important since it initialises the simulation and synchronises the communications. Most of its code is generic and can be reused for a large number of applications. Figure 2 shows an example of an interaction between one Actor and two Spectators which illustrates the collaborations in the Actor-Spectator-Producer pattern. The pattern and its operations are described in more detail in [15].

pipelines, master/slave, data parallel etc. for which implementations have been studied extensively on a variety of platforms. In the context of this work, a skeleton-based programming environment uses a specic interaction pattern as a design primitive from which parallel programs can be automatically generated given some application-specic information [14]. Such an approach provides a templatebased approach to program design and can be easily incorporated into smart programming environments. In addition, the implementation of a particular interaction pattern can be based on known techniques, experiences and libraries developed over the years in a way that is transparent to the user. Examples of skeleton-based programming systems can be found in [11, 12, 17]. The Actor-Spectator-Producer design pattern provides the basis of a skeleton-based methodology for designing and implementing DVEs. This methodology is to be supported by a tool, whose structure is illustrated in gure 3. Each component in the tool is described next.

4.1 The user-interface

The role of the User-Interface is to allow the following information to be provided by users: 1. VE Application: this represents the (existing) standalone VE application, which requires to be supplied with the same interface as the Actor component in the design pattern. 2. Application-specic parameters: they include a description of the shared data needed for displaying a Spectators view. They also include a description of a Spectators actions when updating the state or displaying the view. 3. Architectural model: a description of the processing elements and the underlying network, including processing costs, transmission costs etc.

4.2 The Scheduler

Given a network of processing elements and accurate estimates of communication costs between these processing elements, the Scheduler nds the optimal schedule that minimises communication overheads and increases real-time response. Each task in the scheduling model corresponds to a process component (i.e. an Actor, a Producer or a Spectator) in the design pattern. It is assumed that the estimated execution time for completing one cycle for each of these tasks is available. It is also assumed that precise information on each hosts processing and communication speed relative to each other is available.

4 A skeleton-based methodology for DVEs

Over the past ten years, there has been considerable interest in parallel algorithmic structures or skeletons [4]. It is based on the observation that many parallel programs share a common set of known interaction patterns such as

Producer Initialisation()

Actor

Spectator 1

Spectator 2

Attach() Register() Load_World() Notify() Display_View() Attach() Register() Retrieve() Update()

Display_View()

Collect_Input()

Update_World() Notify() Display_View()

Retrieve() Update()

Display_View() Attach() Register() Retrieve() Update()

Display_View()

Figure 2. Collaborations in the Actor-Spectator-Producer pattern

USER INTERFACE

Architectural model

Application-specific parameters

SCHEDULER

VE Application DVE Skeleton Libraries

CODE GENERATOR

Schedule

Target code

Figure 3. A Programming Environment Based on the Design Pattern The scheduling algorithm used is adapted from the Cluster Heuristic Algorithm which handles periodic tasks distributed across several hosts in a system [13]. We take into account additional constraints such as replication and distribution constraints. After building the corresponding process graph, the algorithm operates in four phases. In phase one, a list is created of pairs of tasks that communicate, and this list is sorted in order of decreasing pairwise communication, so that tightly-coupled tasks are considered rst during the next phase. In phase two, clusters of tasks are built; a cluster is associated with each processor. As task pairs are considered, if neither task is assigned, both are placed on the least loaded processor (i.e., in the smallest cluster). If one task is assigned, the other is assigned to the same processor unless a specied load threshold has been exceeded, and in that case it is placed on the least loaded processor. Phase three orders tasks within each cluster with respect to precedence constraints, so that each cluster represents a feasible sequence of tasks. Phase four shifts subsequences of tasks to later time periods to enforce precedence constraints among tasks that belong to different clusters. The algorithm produces a mapping between tasks and hosts, to be used during the code generation phase. Rening the scheduling algorithm and validating its predictions against real execution gures is still an on-going research project [2]. between the different components in the system. The second one is to use Java3Ds facilities for dening the shared data objects within the Producer as well as specifying the possible actions that can be selected by a Spectator to process (e.g. visualize) these objects. In Java3D terminology, these actions are called behaviours. The code generator relies on a generic Producer which is provided as part of the DVE Skeleton Libraries (see Figure 3). In its present implementation, the Producer holds all shared data objects. It is automatically notied by the Actor each time a change to the shared data is made and responds periodically to update requests from the Spectators. In future systems, we expect that there will be a choice of other types of producers such as producers that implement other notication schemes, distributed producers etc. Given an Actor component and a Java3D description of the shared data objects and their associated behaviours, the Code Generator produces the corresponding interfaces in CORBAs Interface Denition Language (IDL), generates the Spectators code using the specied Java3D behaviours and links the various components of the system through CORBA calls. For instance, the Producer will be a recognisable entity within the CORBA Naming Service so that all other components can locate it and communicate with it. The Code Generator also allocates components to hosts as specied by the schedule. An example is described in the next section.

4.3 The Code Generator

5 Application to a surgical training system

A simple code generation scheme is realised based on two implementation decisions. The rst one is to use CORBA as the underlying communication infrastructure As a case study, we extended a (sequential) surgical training system into a version which allows a number of

Figure 4. A surgical training system for knee arthroscopic operations surgeons distributed across a network to monitor a simulated operation in real-time. The training system (written in C++) was provided by the Virtual Environment Research Group at the University of Hull [3]. This software, called Meniscus, simulates the deformations of a meniscus of the knee joint subject to a stretching force. It is designed for use by trainee orthopaedic surgeons for knee arthroscopy operations (see gure 4). The interface is composed of a control window and a window containing the representation of the Meniscus. With the help of a space ball (a specic device allowing 3D motion), we can apply forces on the Meniscus to deform it. Different options can be changed during the simulation. We can choose between different representations of the Meniscus. One of them shows the complete volume using a wireframe representation while another only shows the surface. We can add axis, shadow, draw a frame around the object. We can also change the point of view: moving around the meniscus, closing in to it. The distributed application has been executed on the University of Hull network. A Web server located in Belgium was used to host the CORBA Naming Server used to register the Producer, the Actor and the Spectators. The Spectators were run on old computers with a Cyrix 686MX 233 MHz processor, 64 MB of RAM and a plain graphics card, the Cirrus Logic CL-GD5446, whereas the Producer was run on a more powerful computer with an INTEL Pentium II 300 MHz processor, 128 MB of RAM and a 3D graphics card, the Diamond Fire GL 1000 Pro. A snapshot of the Spectators view in the Meniscus application is illustrated in gure 5. For a good impression of uidity of the display and realism to the human eye, the frame rate should be at least around 10 frames per second. For the Meniscus application, performance falls to around 2-3 frames per second on older PCs and 37 frames per second on more powerful PCs with a 3D graphics card. These test results show that the design model is efcient and that CORBA was a good choice of a middleware for this kind of application, giving very good results even when used in conjunction with C++ and Java.

6 Conclusions and future work

The paper has investigated a skeleton-based approach for the design and implementation of Distributed Virtual Environments (DVEs). In particular, it has presented a simple methodology for sharing a VE visual experience amongst a number of passive spectators. The methodology is supported by a tool which provides a high-level design environment for users. The tool includes a User-Interface based on a newly proposed design pattern (Actor-SpectatorProducer), a Scheduler which is designed to increase efciency and improve the real-time response, and a Code Gen-

Figure 5. View of the meniscus by a Spectator erator which makes use of the powerful abstraction mechanisms provided by both CORBA and Java3D. There are plenty of avenues for future work. The most immediate one is to complete and integrate the various components of the tool. Beside the Scheduler, other components that analyse the properties of the DVE application can be added. One useful analysis is predicting different update frame rates depending on the distance (and the priority) of Spectators for example. The Code Generator can be made to choose amongst different Producers for the nal implementation, based on various conditions. An example would be a Fault-Tolerant Producer which migrates to a different host in case of a processor failure or shutdown. Another example would be a Distributed Producer that runs over several hosts. This is particularly useful if the amount of shared data is large or there is a large number of spectators. Finally, since the design pattern does not cover all types of DVEs, it would be useful to tackle other interaction patterns such as:

allowing Multiple Actors to change the shared data concurrently: although this extension would not be useful for developing distributed applications for medical training simulations, the potential for applying this pattern to other elds, such as computer games or ight simulators, is a key factor for developing fully functional systems.

7 Aknowledgements
We wish to thank Thibault Devillers for making the original design pattern proposal and Jean-Francois Dal for implementing the surgical training system. We also wish to thank James Ward, Derek Wills and Paul Chapman from the Virtual Environment Research Group for providing help and expertise on the application side.

References
[1] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. A System of Patterns: Pattern-Oriented Software Architecture. J. Wiley and Sons, 1996. [2] H. Cai. A skeleton-based programming environment for distributed real-time systems. PhD thesis in preparation, Department of Computer Science, The University of Hull, 2000.

giving any Spectator the ability to take over the Actors role: for example, the surgeons who are monitoring the operation could have the possibility to help the trainees in a most efcient way. They would be able to show the trainees the best way to operate in some difcult situations

[3] P. Chapman and D. Wills. Modal analysis: a physical model for virtual environments ? In Proc. Eurographics UK, pages 175182. The University of Leeds, 1998. [4] M. Cole. Algorithmic skeletons: a structured approach to the management of parallel computation. Research monographs in Parallel and Distributed Computing, Pitman, 1989. [5] B. Douglass. Real-Time UML: Developing Efcient Objects for Embedded Systems. Addison-Wesley, 1998. [6] S. Ellis. What are virtual environments ? IEEE Computer Graphics and Applications, 14(1):1722, January 1994. [7] D. Fullford. Distributed interactive simulation: Its past, present, and future. In J. M. Charnes, D. J. Morrice, D. T. Brunner, and J. Swain, editors, Proceedings of the 1996 Winter Simulation Conference, Coronado, California, USA, 1996. [8] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of reusable Object-Oriented Software. Addison Wesley, Professional Computing Series, 1995. [9] N. Islam and M. Devarakonda. An essential design pattern for fault-tolerant distributed state sharing. Communications of the ACM, 39(10):6574, October 1995. [10] OMG. The common object request broker: Architecture and specication, revision 2.2. Report 98-07-01, The Object Management Group, http://www.omg.org/, 1998. [11] B. Osoba and F. Rabhi. A parallel multigrid skeleton using bsp. In D. Pritchard and J. Reeve, editors, Proceedings of EuroPar98: Parallel Processing, Lecture Notes in Computer Science 1470, pages 704708. Springer Verlag, 1998. [12] P. Parsons and F. Rabhi. Generating parallel programs from paradigm-based specications. Journal of Systems Architecture, 45(4):261283, 1998. [13] C. Price and M. Salama. Scheduling of precedenceconstrained tasks on multiprocessors. The Computer Journal, 33(3):219229, 1990. [14] F. Rabhi. Parallel programming methodology based on paradigms. In P. Nixon, editor, Transputer and Occam Developments, pages 239252. IOS Press, 1995. [15] F. Rabhi and T. Devillers. A software architecture for distributed virtual environments: the actor-spectator-producer pattern. In submitted to The First Asian-Pacic Pattern Languages of Programming Conference, KoalaPLoP2000, Melbourne, Australia, May 2000. [16] D. Schmidt. Using design patterns to develop reusable object-oriented communication software. Communications of the ACM, 38(10):6574, October 1995. [17] J. Schwarz and F. Rabhi. A skeleton-based implementation of iterative transformation algorithms using functional languages. In M. Kara, J. Davy, D. Goodeve, and J. Nash, editors, Abstract Machine Models for Parallel and Distributed Computing, pages 119134. IOS Press, 1996.