distributed discrete event simulation using the three ... - CiteSeerX

DISTRIBUTED DISCRETE EVENT SIMULATION USING THE THREE-PHASE APPROACH AND JAVA

Ricardo A. Cassel & Michael Pidd Department of Management Science Lancaster University Lancaster LA1 4YX UK

ABSTRACT The recent rapid growth in the Internet and the use of this technology for corporate intranets presents new opportunities for parallel discrete event simulation, hitherto limited to specialist groups with dedicated computer facilities. This paper describes research on distributed discrete event simulation using the three-phase approach and implemented in Java. Two specific implementations are described, one for client/server work and the other a distributed, parallel simulator using conservative synchronisation protocols. The problem of managing shared states with competing resources is specifically discussed.

KEYWORDS Parallel Discrete Event Simulation, Three-Phase Approach, Java

-1-

1.0 INTRODUCTION The idea of Parallel Discrete Event Simulation (PDES) is to accelerate the execution of a simulation model by dividing it into smaller sub-models and running these concurrently on a set of processors. The processors are either spatially distributed or part of a multiprocessor system in a compute-box. Thus, the computation proceeds in parallel and is distributed across several processors and the main challenge is to manage that computation in a safe and efficient manner. Fujimoto (1990) provides an elegant overview of the important issues in PDES, showing that it presents greater challenges than many other areas of parallel or distributed computation. There are two broad approaches to the atomisation of a simulation model into components that may be run in parallel. These are usually known as time and space parallelisation (Nicol and Fujimoto, 1994). In time parallel simulations, the progress of a running model is assigned to different computer processors so that each processor runs the entire logic of the simulation, but only for a short period of time. Such approaches depend on application specific features such as those that occur in systems that display regenerative behaviour (Fishman, 1973). In space parallelism, which is the main concern of this paper, the logical behaviour of the model is shared out across a number of processors so that each processes only part of the simulation logic. Thus, at best, the processes of a simulation model are divided into a set of logical processes that interact with one another. Each logical process may be assigned to a separate physical processor and each logical process may have its own simulation clock and may also have one or more event lists. Thus, the simulation proceeds at the speed of its slowest logical process. There should be a reduction in overall run time, compared to a single processor, sequential simulation, if the work loads of the processors are well balanced and if inter-process communication is low. As in all discrete event simulations, a parallel simulation should employ a discipline, or world-view, within which the logic of the system being simulated is expressed. Most PDES research employs a process-based or event-based discipline. The work discussed here takes the three phase approach, suggested by Tocher (1963), and develops a simple PDES library in Java to permit distributed simulation using Internet technologies.

-2-

2.0 BASIC ISSUES IN PDES 2.1 Process synchronisation A major concern in PDES is the avoidance of causality errors. These occur when events in the simulation are executed out of their correct time sequence. In a conventional sequential simulation model, notices about future events are placed on an event list, with a note (a time stamp) saying when they are due. The future events are then processed in time-stamp sequence. In PDES there may be no single event list and no global simulation clock, and there is, therefore, a danger that simulation events will be processed out of their true timestamped sequence. For example, a logical process may have an event list in which the next event is due at time t and might, therefore, move its clock to time t and then execute the activity due at this event. Unfortunately, the logical process may then receive another message from another process with a time stamp of less than t, meaning that its local time had got ahead of the local time in the sending process. If this were to happen, then ‘the future could affect the past’(Fujimoto, 1990) – a causality error. Correct process synchronisation is, therefore, of great importance in PDES. Hence, much research has been directed at this problem, with new protocols appearing from time to time, for examples, see Nicol et al (1992) and Turner & Xu (1992). Synchronisation protocols are usually divided into those that are conservative and those that are optimistic. In conservative protocols, a process is only permitted to process an event when it is known to be safe to do so. That is, a process containing an event with time stamp t, will only execute that event if there is no possibility that it will later receive an event request with a time stamp less than t. Processes that cannot be sure if it is safe to proceed must block, waiting for safety. There is, therefore, a significant risk of deadlock if a conservative approach is taken. Various deadlock-avoidance strategies have been proposed, the most common being based on Chandy and Misra (1979) and Bryant (1977), who suggested that processes send null messages to one another. The null messages guarantee a period within which an earlier time-stamped message will not be sent, enabling internal processing to continue until the time of the null message is reached. If the implied time interval on the null messages is greater than zero, then this guarantees a lookahead period in which safe processing is possible. On the other hand, optimistic protocols permit processes to continue to execute events until it becomes clear that a causality error has occurred: that is, until an event has

-3-

been processed out of sequence. Thus, optimistic protocols must include causality error detection methods. Once an error is detected, simulated time on each processor is rolled back to some known safe time, undoing erroneous events en route. This implies that each process keeps a record of its recent processing so that this roll-back can proceed. Once time is rolled back to some safe point, the optimistic processing re-starts. The parallel simulation approaches discussed here use a conservative protocol with null messages and lookahead. 2.2 Communication speed Another concern, especially for simulations in which the computation is spatially distributed, is the speed of communication between the processors. Clearly this is an important issue if the Internet or intranets are to be used to support PDES. It seems likely that communication bandwidth on such networks will greatly increase in the future, nevertheless, so will the demands placed on these networks. It is, therefore, important to devise ways in which the communication demands of PDES are reduced as far as possible, since there is no point in having fast processors that have to wait for incoming messages. The main efforts of current research in this area are focused on attempts to reduce the number of messages being exchanged by the several processors involved in a simulation, therefore reducing the demands on bandwidth. One obvious way to do this is to ensure that messages are only sent when they are needed and that they are never merely broadcast, but have specific recipients. This is usually done by creating relevance filters, or interest managers, to manage the messages and to send them only to the places where they are needed (see, for example, Saville (1997)). 3.0 THE THREE-PHASE APPROACH The three-phase approach was first proposed by Tocher (1963) and differs from the process-based approach that is common in PDES. For a comparison of the three-phase approach with simulation worldviews based on process interaction, see Pidd (1998). As with process-based approaches, there are difficulties to be faced in using the three-phase approach in PDES, but these are not insurmountable. In a three-phase simulation, the modeller recognises that there are two different types of system activity.

-4-

• Any activity that stems from events with known execution times can, therefore, be scheduled via an event list. Often these events mark the termination of some activity, such as the end of a service in a queuing system, or the end of a manufacturing operation in a factory. These events can be attached to a particular simulation entity, for example the server in a queuing system, or to several entities if need be. When the simulation clock reaches the time that such an event is due, the executive can send a message to the entity or entities requesting them to perform this activity. In the parlance of three-phase simulation, these are known as B activities or as B events (Bs for short). They are Bound to happen at some time, hence the B. • The remaining activity whose start times cannot be scheduled on an event list since they depend on the states of other system entities or on the availability of system resources. For example: the start of service in a queuing system (which depends on there being a waiting customer and an idle server), or the start of a manufacturing operation in a factory (which may depend on there being a job in the operation buffer, on there being a machine free and an operator ready to start the operation). In the parlance of three-phase simulation, these are C activities or C events, the C indicating that this activity is Conditional. The actions within a C (for example, to engage the server and take the customer from the head of queue) are guarded by conditions (for example, is a server idle and a customer waiting in the queue?). In a three-phase approach, each cycle of the simulation executive works as follows. • A Phase: Examine the event calendar and find the time at which the next B is due, then move the simulation clock to the time of this B. • B Phase: Execute, one by one, all the Bs that are due at this new clock time. • C Phase: Try to execute each of the Cs in turn. Only execute a C if its conditions can be met. Repeat this C scan until no more Cs can be executed at this time. The Cs are attempted in a sequence determined by the priorities in the simulation, so that a high priority C will prevent the operation of a low priority C if they are in competition for the same entity or resource. It is important to realise that all Bs due at the current clock time are executed before any Cs are attempted. This is fundamental to three-phase simulations and, since most Bs release resources or make entities available before any Cs try to use them, this avoids most deadlock problems. By contrast, in a process-based simulation, at each clock time every

-5-

active entity is moved individually as far as possible through its process. Because this process movement makes no distinction between resource release and engagement, process-based approaches have a much greater risk of deadlock when there is resource contention. In an object-oriented approach, the Bs can become member functions or methods of the class of entity to which they are linked. Thus, for example, the B ‘end service’could be a member function of a server class or of a customer class. By contrast, the Cs may belong to no entity class in particular, since they may depend on the co-operation of several classes of entity and on a range of resources. As will be discussed later, this creates some problems when a three-phase approach is used in PDES. For a comparison of Java in process-based, event-based and three-phase simulation, see Pidd and Cassel (1999). 4.0 JAVA Java is an object-oriented language syntactically similar to C and C++, based on an objectoriented approach with many similarities to SmallTalk. Java is often associated with the world-wide-web, because of Java applets on web pages and because the language is intended to be portable. A Java applet is a small program that is automatically downloaded from a web site and which can be run within a Web browser in response to instructions contained within the web page being viewed (Anuff, 1996). This allows dynamic content on web pages. Java is portable because it is neither a compiled nor an interpreted language in a pure sense. When a Java source program is compiled, a new file with the suffix class is created. This class file contains an intermediate byte code which is not executable machine code, and which will be the same on whatever platforms it is compiled. This file is then interpreted by a platform-specific interpreter or JVM (Java Virtual Machine), which will know exactly what to do with the code according to the platform in which it is installed. This feature is attractive to those who wish to use the Internet, because their code can be sited in one computer and be downloaded to and run in another, completely different, computer. In addition to its attraction for web use as discussed above, it has a number of other features that provide potential support for PDES.

-6-

• Multi-threading: a thread, sometimes known as a lightweight process, is a segment of computer program that can be run relatively independently of the rest. A program that contains threads can, therefore, run these threads concurrently if more than one processor is available. Each thread can be assigned to one processor and be run independently from the others. This also presents a few problems since thread management is usually handled by a computer’s operating system and different operating systems may manage threads differently. For the time being, this makes it hard to recommend Java for mission critical work, especially in real-time. • Object Serialization: this is the technique for bundling Java objects so that they can be passed along in communication streams. This means that any object that was created in Java can be “disassembled” into a binary representation, sent through a stream, and be “assembled” back to its original form at the other end of the communication stream. • Remote Method Invocation (RMI): RMI is provided by the java.rmi package and it enables a method sitting on one computer to be invoked by a call from another computer without worrying too much about the detail. For example, consider a computer known as computer1, with a class called class - which itself has a method called method. Suppose that a class on another computer wishes to call this method, then what it has to do is to locate the class that owns the method in the computer1’s registry. When this is done, the method on the computer can be invoked as if it were on the local machine, without worrying too much about where it really is. • Reflection: this is an API (Application Programming Interface) that allows the inspection of objects and classes for their methods, constructors, and fields (Weber, 1997). This means that reflection enables the classes to “reflect”, or to look inside themselves, and even invoke the methods that are defined by them. This allows the use of run-time binding, which would usually be achieved via pointers in a language such as C++. Since pointers are not available in Java, reflection is used instead. Reflection also gets round one of the basic problems of object orientation discussed in Pidd (1995). The problem is that methods of descendent classes must have prototypes in their base class if they are to be invoked via their base class, as is needed in run-time binding. For example, if a method Rotate is to be called for a new graphics class (say a shape known as a Squodge) then this can only be achieved via run-time binding if the base class of Squodge (say Shape) has a prototype function with the same name Rotate. This makes it hard to allow a simulation executive to call unknown methods for

-7-

unknown classes without some considerable jiggery-pokery in most languages. Reflection makes it rather simple. Because of these characteristics, Java seems to be a language that could be useful in programming parallel simulations. Besides that, Java is a object oriented language, and according to Fujimoto (1993), parallel simulation strategies and object-oriented programming have obvious similarities in that a logical process is similar to an object, and sending a message is similar to invoking a method. 5.0 THE JUST CLIENT:SERVER SYSTEM The research discussed here has led to a number of three-phase systems implemented in Java. For ease of reference, these are known as the JUST (Java Ubiquitous Simulation Tools) systems. The initial version of JUST, discussed in detail in Pidd and Cassel (1998) is a client:server package using standard Internet technology in Java. In this package, the server manages the simulation and the clients have the implementation of the models. Several clients may connect to the server and have their models simulated concurrently. The simulation models may be identical, allowing simultaneous replication of the same experiment, or may be quite different models that are run simultaneously. The initial implementation of the JUST system supports client:server applications as shown in figure 1. This assumes that there are at least two computers co-operating to execute a simulation model. One of these computers is the simulation server and the others (one or more) are simulation clients. In the usual terms of discrete simulations, the simulation server plays host to the simulation executive and to (most of) the simulation library. The application logic sits on the client computer(s). The programs on all the computers must be written in Java, using the principles of the JUST system and should be already in byte code. Each computer must have a compatible Java Virtual Machine to translate the byte codes into executable forms. The computers must be linked by a network with standard internet protocols, which could be a local intranet or the global Internet.

-8-

Internet protocols Client side GEntity class Application entity classes CActivities

Server side InitiateServer Manager class GEntity class

Figure 1: Client:server simulation in JUST

In this client:server package, the tasks of the client and the server are clearly differentiated. The server waits for the client’s call, and once the call arrives, it creates a thread that will run the simulation executive. This thread is dedicated to this client and will call methods that are defined in the client. The client, in the other hand, has all the classes and methods that define the model, and will call the server to have its model simulated. A client can have more than one thread in the server, depending on how many replications of the model it wants to run. As might be expected, such a client:server package runs rather slower than would a simulation in which all components sit on the same computer. However, it does suggest that simulation software might, in future, be marketed on a payfor-use basis whenever a simulation client connects to a remote simulation server. This would make upgrades of simulation software rather easier to manage as well as opening up a new way to sell the software. 6.0 JUSTDISTRIBUTED: PDES IN JAVA JUSTDistributed is a Java package implementing a parallel discrete event simulation system that allows the user to create a PDES model and to run it using standard Internet technology. Like the other packages in the JUST systems, it uses the three-phase approach, though modified to permit space parallelism with conservative synchronisation, null messages and lookahead. It utilises some of the features of Java that make it a potentially attractive language for PDES.

-9-

6.1 Java in JUSTDistributed The first special feature of Java used in JUSTDistributed is multi-threading. A thread can be used to represent a logical process, since a thread is a lightweight process that can be run relatively independently and concurrently alongside other threads. On a single processor computer, this concurrency is virtual, not real. On a multi-processor architecture, this concurrency can be real with different threads running on different processors, opening the way for PDES. The use of a multithreaded language such as Java enables the creation and management of the logical processes of a PDES as threads. In the JUSTDistributed package, each logical process is a different thread that could be run on a different processor. In its current implementation, the processors are a network of single processor PCs running Windows NT4, each one executing a piece of the model. Secondly, remote method invocation (RMI). The usual conservative protocols for PDES assume that computation is controlled by message passing. The messages are requests from one processor to another, usually resulting in future work for the recipient. There are also null messages to guarantee that the receiving process will avoid causality errors. Java itself assumes that computation is based on messages that are passed from class to class, as a result of which the class instances (objects) engage on computation. The RMI API of Java enables message based computation to be easily and safely implemented across a network, rather than being limited to a single computer. Instead of sending a normal message through the network, the JUSTDistributed sends an invocation to a remote method. This method is sited in the logical process receiving the message, and the recipient simply enters details of the invocation as a parameter on an event list. This facilitates the programming of the message manager, since all the marshaling and unmarshaling of the messages is done automatically by the Java Virtual Machine. However, to make this work, a third feature of Java has to be used: object serialization. As explained before, this characteristic allows Java objects to be transmitted through a communication stream as if they were primitive types (like int, float, char,...). This feature is especially useful in the JUSTDistributed system because the parameters of the remote methods can be “serializable” objects that were created during the simulation. Finally, the JUSTDistributed package makes use of reflection for two reasons. The first is that Java, unlike C and C++, has no pointers and therefore function pointers are not available. Reflection is required because an event invocation message needs to specify

- 10 -

what entity is to engage in the event, what event is to be invoked and at what time. In languages that permit pointers, the reference to the B that needs to be scheduled could be a member function pointer. Instead, with reflection, a simulation executive can ‘look inside’ the relevant entity to see what event is due at this time. The second reason for using reflection is the problem of Bs and Cs indicated above – which is, to which classes in the simulation should the Bs and Cs belong in a three-phase simulation? The problem has two sources (Pidd, 1995), firstly because a C will usually involve more than one entity class and may also deal with simulation resources, which may not belong to any individual entity class. The second source is the problem with the Bs highlighted earlier in this paper when the Reflection API was discussed: the need for the base class to have a prototype of its descendants’methods for use in run-time binding. 6.2 Resource contention and shared states One problem in PDES is the issue of shared states required when there is resource contention. Resource contention occurs when two different entities are competing for the same resource when wishing to engage in their own activities at the same simulation clock time. Thus, in a factory, a machine operator may have to attend to several machines and, if more than one requires his attention then they must compete for the machine operator resource. Resource contention can lead to deadlock in any discrete simulation, whether executed on a single processor or distributed, since one process may be waiting for another, which itself is waiting for the first one. However, it is a particular problem in PDES since each LP is, effectively, a semi-independent simulation and unless informed, will not know the states in another logical process. Shared states are state information that is needed by more than one logical process. For example, in a service system we need to know whether the server is free and whether a customer is waiting for service. If these two classes of entity are simulated in different logical processes, then we need some way for each to know about the other's state. Resource contention increases the need for shared states because logical processes may need some access to data describing the states of other logical processes. JUSTDistributed uses Central Cs to manage resource contention and to represent shared states. The next sections introduce the concept of Central Cs and discuss the two approach to Central Cs implemented within JUSTDistributed.

- 11 -

6.3 Managing shared states 6.3.1 Cellular simulation

In the three-phase approach used in the JUSTDistributed system, the shared states must be accessed in the C phase, when the conditions (or states) of the model are checked. In addition, the shared states will be updated in the B phase, when resources are released and entities are freed. However, not every C and all Bs need access to all shared states, instead it is possible to group the Bs and Cs into cells (Spinelli de Carvalho & Crookes (1976)) which need the same shared state data. In this ‘cellular simulation’approach, the Bs and Cs of the model are grouped into cells consisting of a set of Bs with only those Cs that can be triggered by the immediately prior occurrence of those Bs. This avoids a complete C scan on some occasions, making the simulation run faster, and also permits the organisation of state data such that pseudo-shared memory is possible. 6.3.2 Push processing and replicated routes

Fatin (1996) suggests that each logical process (LP) in a PDES model may decide whether to use a shared resource if push processing and replicated routes are used. This is best explained by an example, such as that of the Harassed Booking Clerk, used in Pidd (1998). This example concerns a theatre that employs booking clerks during the day. Clerks are employed to sell tickets and to answer any enquiries which may arise. Seat bookings are accepted only if the customer turns up in person at the theatre and pays for the tickets. Enquiries can come either from someone there in person or from someone phoning the theatre. Clerks are instructed to give priority to personal customers— after all, they may hand over some cash. Thus if the phone rings just as a customer arrives in person, then the personal enquirer is served first. Thanks to a sophisticated phone system, incoming calls can queue on a FIFO basis until answered and phone callers never ring off in frustration. In PDES this could be modelled in many different ways, one would be to create four different LPs. LP1 for the arrival of personal customers, LP2 the arrival of phone calls, LP3 for the service of personal customers and LP4 for answering the phone. Each LP has its own simulation executive managing its own Bs and Cs. It is clear that LP3 and LP4 depend on the same resource, the booking clerks. One way to manage this as a PDES would be for each LP to contain its own state data and for them to communicate with one another so as to decide which of them could access the shared resource whenever it was needed.

- 12 -

Fatin (op cit) suggests that each LP competing for a shared resource should have, besides its own C activities, a copy of the C activities of its competitor(s) and a copy of the shared resource. Moreover, each message sent to one LP should be sent to its competing LP(s) as well, as shown in Figure 2. In this way, each competing LP can verify the relevant states and decide whether it gets the shared resource because each competing LP has the same information. The replicated codes and duplicated states reduce the messages that have to be passed to sort out the resource contention, but the programming becomes more complex and may make the enhancement of a program more difficult. It may also mean that the each LP runs somewhat slower since each will be more complex than if left with only the code of their ‘own’Cs.

Personal arrival

Phone arrival

LP1

LP2

Booking clerks LP3

Shared resource

LP4 Phone conversation

Personal service

Figure 2: Shared resources by activity replication

- 13 -

6.3.3 Central Cs

Linking the cellular approach with Fatin’s work suggests that it may be better to create a set of Central Cs, one to each cell. In three-phase simulation, the general form of a C is as follows: if then

// the test head

A central C contains a set of test heads (the conditions governing whether the activities will occur) and the shared state information that is needed. Any message sent to an LP in a cell must be sent to the central C of that cell and the central C contains the only copy of the shared resource. Central Cs can be implemented in one of two ways, depending on the message load and the computational load on each LP. In the first implementation, shown in figure 3, the central C is responsible for computing the activity durations of each actual C, with any detailed processing of the actions being left to the ‘true’C. Thus, the Central C examines the set of test heads to decide which C (therefore which LP) should be fired and then computes the duration of this activity. It must then tell that LP to start processing and to schedule the B that will terminate the activity which has just been started.

- 14 -

Phone arrival

Personal arrival

LP2

LP1 Shared resource: booking clerks Activity test heads and duration computations LP3

LP4

Personal service

Phone conversation

Figure 3: Central Cs with event time computation

This type of Central C has the advantage of reducing the number of messages being sent. Since the Central C knows the duration of the events, it does not need to receive a message from the LP informing it that the activity has ended. However, if the calculation of the duration of the activity needs a lot of processing time, the LPs of the ‘true’Cs in that cell will be waiting for the Central C to compute the activity duration. This loses some of the advantages of distributing the processing. A second variant on the Central C thus presents itself – a Central C with feedback messages, shown in figure 4. In this, the Central C does not compute the activity durations but, instead, this is done in the ‘true’Cs of the LPs in the cell. To ensure proper activity termination, the LP involved must then pass back a message, containing the time of the resulting event, to the Central C. This allows better distribution of the processing load amongst LPs, but increases the number of messages that must be passed.

- 15 -

Phone arrival

Personal arrival

LP2

LP1 Shared resource: booking clerks Feedback Activity test heads

Feedback

LP3

LP4

Personal service

Phone conversation

Figure 4: Central Cs with feedback messages

Both implementations of the Central C reduce the number of messages that are needed under Fatin’s approach since messages do not have to be broadcast to all LPs but only to the one affected, plus the Central C. There is also no need to create multiple instances of the shared resources, which should lead to faster running and lower storage requirements. Finally there is no need to keep multiple copies of the ‘true’Cs within a Central C, but only their test heads. As with Fatin’s approach, however, information is pushed to the LPs as required rather than being pulled by an LP as it is needed. In Fatin’s approach, LPs may be sent information which is of no relevance to them in their local future. Central Cs send only the information that is needed. 6.0 CONCLUSIONS AND SUGGESTIONS FOR FURTHER WORK The work on the JUST systems demonstrates that PDES using Java and a three-phase approach is feasible on the Internet and intranets. The systems developed so far include a

- 16 -

client/server simulation package and a system to support true PDES via conservative synchronisation with null messages and lookahead. In the latter case, the main issue to be faced was how to represent the shared states needed for the Cs that form a central plank of the three-phase approach. Central Cs provide a way of doing this that is simple to implement and may be much more straightforward than other approaches. However, the research is far from over. More tests have to be made on the JUSTDistributed package, involving more complex models and different computer platforms, to analyse its real portability. New PDES packages will also be created where other synchronisation approaches will be used. In addition, the problem of communication speed on the Internet remains. Research is needed to try to understand the situations in which Internet-based PDES has a pay-off when compared to sequential simulations on more powerful computers. Enough questions remain for a fertile research programme to continue. ACKNOWLEDGEMENT Ricardo A. Cassel’s research is funded by the Brazilian Government through CAPES – Fundação de Aperfeiçoamento de Pessoal de Nível Superior. REFERENCES ANNUF, E. The Java sourcebook (John Wiley & Sons Inc., New York, 1996). BRYANT, R. E. Simulation of packet communications architecture computer systems. MIT-LCS-TR-188, Massachusetts Institute of Technology (1977). CHANDY, K. M. & MISRA J. Distributed simulation: A case study in design and verification of distributed programs. IEEE Transactions on Software Engineering, SE5(5) (1979) 440-452. FATIN, F. A Programming Structure for Parallel Simulation. Ph.D. thesis, Brunel University, 1996. FISHMAN, G. S. Concepts and methods of discrete event digital simulation (John Wiley & Sons, New York, 1973). FUJIMOTO, R. M. Parallel Discrete Event Simulation. Communications of the ACM, Vol. 33, No. 10 (1990), pp. 30-53.

- 17 -

FUJIMOTO, R. M. Parallel Discrete Event Simulation: Will the Field Survive? ORSA Journal on Computing, Vol. 5, No. 3 (1993), pp. 213-230. NICOL D. and FUJIMOTO R.M. (1994) Parallel simulation today. In: Annals of operations research, 53 (ed: O. Balci, 1994) pp 249-285. NICOL, D. & GREENBERG, A. & LUBACHEVSKY, B. & ROY, S. Massively Parallel Algorithms for Trace-Driven Cache Simulation. In: Proceedings of the 6th Workshop on Parallel and Distributed Simulation, Vol. 24 (SCS Simulation Series, January, 1992) pp. 3-11. PIDD, M. Object-orientation, discrete simulation and the three-phase approach. Journal of the Operational Research Society, 46 (1995) pages 362-374. PIDD, M. Computer Simulation in Management Science (4th ed) (John Wiley & Sons Ltd, Great Britain, 1998). PIDD, M. & CASSEL, R. A. Three-Phase Simulation in Java. In: Proceedings of the Winter Simulation Conference 98, (Washington D.C., December, 1998) 367-371. PIDD M. and CASSEL R.A. Web based simulation using Java. Accepted for publication, IEEE Potentials (1999). SAVILLE, J. Interest Management: Dynamic Group Multicasting Using Mobile Java Policies. In: Proceedings of the 1997 Fall Simulation Interoperability Workshop, (1997) pp. 125-134. SPINELLI DE CARVALHO, R. & CROOKES, J. G. Cellular simulation. Operational Research Quarterly, vol. 27, No. 1, i, (1976) pp. 31-40. TOCHER, K. D. The Art of Simulation (English University Press, Great Britain, 1963). TURNER, S. & XU, M. Performance Evaluation of the Bounded Time Warp Algorithm. In: Proceedings of the 6th Workshop on Parallel and Distributed Simulation, Vol. 24 (SCS Simulation Series, January, 1992), pp. 117-128. WEBER, J. Special Edition Using Java 1.1. (3rd ed) (QUE Corporation, United States of America, 1997).

- 18 -