J-Sim Features

(1) Loosely coupled, autonomous component programming model:

The software architecture is component-based with clear, well-defined interfaces. Similar to JavaBeans, CORBA, and COM/DCOM, the basic entity in J-Sim is components, and an application is simply a composition of components. Ports are part of a component and are used by the component to communicate with other components. However, unlike the above component-based software packages/standards, the components defined in J-Sim are loosely coupled and autonomous.  By loosely coupled, we mean the behavior of a component is specified in terms of contracts. A contract is bound to a specific port or a group of ports, and defines the causality of data sent/received between the component that owns the port(s) and whichever components that are connected to the port(s).  In particular, it does not specify the components that participate in the communication.  Component binding is deferred until system integration time. By autonomous, we refer to the capability of components to handle data in independent execution contexts.  When data arrives at a port of a component, the component processes the data immediately in an independent execution context.  The interference between different pieces of data handled by the same component at the same time is minimal. 

The ability to handle data in independent execution contexts, along with the fact that components are loosely coupled and only bound to one another at system integration time, is the key reason that a component can be reused in other software systems with the same contract context, in much the same fashion as IC chips are used in hardware design. Refer to autonomous component architecture for a detailed account.

(2) Dynamic thread execution framework for real-time process-driven simulation

In J-Sim, execution contexts are implemented by Java threads, with the thread scheduler in the Java Virtual Machine (JVM) scheduling thread execution.  The runtime contains three classes, WorkerThread, WorkerManager and WorkerPool:

1. The WorkerThread wraps the Java Thread class up with the runtime, execution context information. 
   
2. The WorkerManager class implements the control mechanism that controls the number of WorkerThreads that can be simultaneously active.
   
3. The WorkerPool class creates new WorkerThreads, recycles WorkerThreads that finish processing data, and provides execution control (e.g., stopping or resuming execution of a thread) to the entire system.

In J-Sim, the simulation engine extends the WorkerPool class and monitors the activities of all WorkerThreads.  It maintains a globally-observed, virtual system time that is proportional to the real time (e.g. 1 second in virtual time = 1000 seconds in real time).  When no WorkerThread is currently active, the simulation engine adjusts the virtual system time to the nearest future so that at least one WorkerThread may become active.

With the above mechanism, a simulation runs in the same manner a real system does, in the sense that event executions are carried out in real time as opposed to at fixed time points in discrete event simulation.  The interactions and interferences among event executions, hence take place naturally as in real systems.  When no thread is currently active, the simulation engine performs a "fast-forward" operation in time to the nearest future at which at least one execution can be activated. This preserves the behavior of real systems and hence enhances the fidelity of the simulation.  The thread overhead incurred is mitigated by reusing threads (see Section 3.2 of the autonomous component architecture).

(3) Implementation of a complete suite of Internet Integrated/Differentiated/Best Effort Services protocols

Figure 1. The internal structure of a node

For the purpose of network modeling and simulation, we have 

• defined and implemented an abstract network model on top of the component-based architecture.  In particular, we have defined the generic structure of a node and several generic network components. The centerpiece of the nodal structure is the core service layer that provides the fundamental core internetworking services (Figure 1). We have also decomposed the core service layer into components and well defined the associated contracts.
  
•  implemented every component in the autonomous component architecture or in the abstract network model as a class, and organized classes  into layers. Figure 2 depicts the five-layer class organization in J-Sim.
  
• implemented an (almost) complete suite of Internet best effort, integrated services, and differentiated services protocols.  Table 1 lists the models/protocols currently supported in J-Sim.

Figure 2. The class pyramid in J-Sim.

The implication of the implementation is three fold:

1. With all the Internet protocol classes available, one can compose the protocol stack and conduct the simulation under different network scenarios in a plug-and-play fashion.
   
2. With the abstract classes that capture the fundamental features of network entities and yet are flexible enough to accommodate new technology advances, one can extend J-Sim to a new network architecture, e.g., wireless LANs, optical networks with WDM technology, networks with satellite communication links, or ad hoc networks consisting primarily of mobile sensors. This is done by subclassing appropriate network modules and redefining their network attributes and methods that manipulate the attributes. For example, one needs only to modify the network interface card (NIC) component and the link component to incorporate the error characteristics and the mobility characteristics in order to model wireless mobile networks.  Similarly, one can readily implement a new algorithm/protocol for experimentation and validation, simply by subclassing one or more appropriate protocol modules.
   
3. By virtue of the component hierarchy (i.e., a component can be a composite component that contains child components), one can vary the level of details to which simulation is conducted. For example, if the interaction of protocols across the layers is of concern, one may figure in all the necessary protocol components as inner components of a node component.

Table 1. Algorithms and protocols supported in J-Sim.

(4) A dual-language environment that allows auto-configuration and on-line monitoring

We provide a dual-language environment in which Java is used to create components and a script language is used as the glue or control language to integrate components at run time and to provide high-level, dynamic control. This facilitates fast configuration of customized simulation scenarios, and on-line monitoring and data collection. In the current release,  we have fully integrated J-Sim with a Java implementation of the Tcl interpreter (with the Tcl/Java API extension), called Jacl and developed by Scriptics Corporation. This enables access to, and manipulation of, Java objects, such as creating an object from a Java class and invoking a method or accessing a field variable of a Java object,  in the Tcl environment. 

In conjunction with the dual-language environment, we have also introduce, and export, the information and event ports for data collection and debugging at the component level. One may connect an "instrument" component or script to the information port and the ports in the event group of a component of interest to configure/inspect the component at runtime.  This closely mimics the IC debugging and testing process.

(5) Definition and implementation of generic interface classes for trace-driven simulation

Currently we are working on defining and implementing generic interface classes for trace-driven simulation, with which (i) the network of interest can be emulated based on real network traffic loads and (ii) fidelity of J-Sim can be validated (and the (in)accuracy quantitatively characterized) through analysis/comparison of real network performance data and simulation data.

(6) Realization of network emulation

Currently we are studying how to realize network emulation by (i) porting real applications (e.g., WWW traffic and audio/video streams) on top of the J-Sim socket layers or (ii) replacing NIC modules with true device driver codes.

Return to J-Sim Home Page
Date last modified -- October 25, 2000