CHAPTER 2

TECHNOLOGICAL INFRASTRUCTURE

2.1 Component Technology

In software development world, reliable reusable classes become building blocks. The building blocks are software components. Component-based software development systems may support some or all the following capabilities.

• Object-Oriented Programming. Under OOP, software is developed as objects consisting of attributes (data members) and methods (member functions). The advantages of encapsulation, inheritance and polymorphism have been well documented.

• Persistence. Mechanisms are provided to save and restore the state of executing objects with little or no programming. Traditionally, these operations required a substantial amount of custom coding.

• Introspection. By following certain coding conventions (design patterns) and by providing supplementary classes, different software components can be made to interact without any custom coding. For example, one class may inquire about properties, methods or events of other classes. Properties are appearance or behavioral attributes that are exposed (e.g., by get/set methods) to other classes or visual tools.

• Distribution. Although not a requirement, it is useful to able to have components work together even if they are not executing on the same machine. This is facilitated by providing high-level mechanisms for distributed objects to communicate, typically through remote method calls or remote handling of events.

• Platform Independence. While "Write-Once, Run Anywhere" is not a requirement, it certainly simplifies the developer's job. If this is fully supported, any object can be downloaded to any machine and executed without recoding or even recompiling.

At present, software components may be developed with either ActiveX or Java Beans. Java Beans has the advantages of platform independence and a simpler programming environment (full object-orientation, automatic garbage collection, safe use of memory and a straightforward approach to multithreading). For these reasons, Java and JavaBeans have been chosen to develop JSIM. Speed disadvantages of Java versus C++ are becoming less of an issue as Just-In-Time (JIT) and native-code compilers are becoming available.

2.2 Java Beans

JavaBeans are standard component model for Java Language. "A Java Bean is a reusable software component that can be manipulated visually in a builder tool" (JavaSoft 1996). The builder tools may be Web page builders, visual application builders, GUI layout builders, or even server application builders. Sometimes the "builder tool" may simply be a document editor that is including some beans as part of a component document. Some builder tools may operate entirely visually, allowing the direct plugging together of JavaBeans. Other builders may enable users to conveniently write Java classes that interact with and control a set of beans. Other builders may provide a simple scripting language to allow easy high-level scripting of a set of beans.

Individual Java Beans will vary in the functionality they support, but typically they support the following

• "Introspection", so that a builder tool can analyze how a bean works.

• "Customization" so that when using an application builder a user can customize the appearance and behavior of a bean.

• "Events" as simple communication metaphor that can be used to connect up beans.

• "Properties", both for customization and for programmatic use.
• "Persistence", so that a bean can be customized in an application builder and then have its customized state saved away and reloaded later.

Among all these features, events are one of the core features of the Java Beans architecture. Events provide an easy way for components to be connected together in an application builder, by allowing some components to act as sources for event notifications that then can be caught and processed by either scripting environments or by other components. Conceptually, events are a mechanism for propagating state change notifications between a source object and one or more target listener objects [Hamilton, 97].

The outlines of the event model are [Javasoft. 97]:

• Event notifications are propagated from sources to listeners by Java method invocations on the target listener objects.
• Each distinct kind of event notification is defined as a distinct Java method. These methods are then grouped in Event/Listener interfaces that inherit from java.util.EventListener.
• Event listener classes identify themselves as interested in a particular set of events by implementing some set of EventListener interfaces.
• The state associated with an event notification is normally encapsulated in an event state object that inherits from java.util.EventObject and which is passed as the sole argument to the event method.
• Event sources identify themselves as sourcing particular events by defining registration method that conform a specific pattern and accept references to instances of particular EventListener interfaces.
• In circumstances where listeners cannot directly implement a particular interface, or when some additional behavior is required, an instance of a custom adaptor class may be interposed between a source and one or more listeners in order to establish the relationship or to augment behavior.

Based on the relationship to events, a component can be either a producer of events or a consumer of events. An event producer creates an event when a particular thing happens to the producer component, for example, a mouse click or sufficient data has been collected from model output. The producer can fire the event with or without including data in the event. The first option is used if producer needs to pass some information to event listeners. The second option is feasible if the event source just make a notification to event listeners that something they are interested has happened. The data included in an event object can be of any type. Usually Vector is preferred for its great flexibility. When a source bean sends out an event, how the source bean can make sure that its message is sent to the right consumer beans. The listener registration mechanism guarantees that only listeners, registered to the event, can receive that event. The event registration process can be done easily in a visual builder tool or by hard coding. A component can play a role as a producer and a consumer at the same time in the event-listener environment. It can be a producer of one event and a consumer of another event. A component can become a transmitter. In this case, it is a consumer and producer for the same event. This particular scheme is used when the component tries to modify or simply add some data to the event. Therefore, different JavaBeans components play roles as consumers or producers or both. They can notify each other or transmit data by the event-listener mechanism. Users define the logic of an application when they assemble components in the visual builder tool.

Currently available visual builder tools include IBM’s VisulAge, Sun’s Beans Development Kit (BDK), Symantec’s Visual Café, Lotus BeanMachine, Borland Jbuilder, and Microsoft J++.

2.3 Agent Technology

Component technology gives more freedom to the simulation analyst to do his job. As the number of components in simulation application increases, increasing complexity of the system is inevitable. To solve this dilemma, agent technology built on top of software components may help. Before the further discussion, a brief overview of agent technology is helpful.

Perhaps the general way in which the term agent is used is to denote a software-based computer system that has some of the following properties [Wooldridge and Jennings, 95]:

• autonomy: agents operate without the direct intervention of humans or others, and have some kind of control over their actions and internal state;

• social ability: agents interact with other agents (and possibly humans) via some kind of agent-communication language [Genesereth and Ketchpel, 94];

• reactivity: agents perceive their environment, (which may be the physical world, a user via a graphical user interface, a collection of other agents, the INTERNET, or perhaps all of these combined), and respond in a timely fashion to changes that occur in it;
• pro-activeness: agents do not simply act in response to their environment, they are able to exhibit goal-directed behaviour by taking the initiative.

• mobility: agents have the ability to move around an electronic network [White, 94]

2.3.1 Ability to make decision

An important thing aspect of an agent is its ability to make decisions. The domain of the agent will have a significant impact on the type of decision-making ability, which the agent may have. If the agent has a limited number of situations it needs to respond to, hardcoding into procedural program code may be a solution. If the agent has to build or use sophisticated models of the problem domain and solve problems at different levels of abstraction, then knowledge-based methods may be helpful [Foner, 96].

2.3.2 Perception, communication and action

In order for an agent to take an appropriate action, it first has to be able to perceive what is going on around it. This could be done actively, by sending messages to other agents or systems, or it could be done passively by receiving a sequence of event messages, including GUI events like a mouse click etc., from the system, the user, or other agents. Again, the higher-level event interface called EventSource/EventListener framework is a good alternative of communication [Belgrare, 95].

To have effective communication between the user and agents, the user must explicitly tell the agent what to do. The events that are generated could contain all the information the agent needs to determine the current state and an appropriate action.

2.3.3 Multiagent Systems and cooperating agents

For a complicated task like simulation, multiple agents working together toward a common goal may be required. They must coordinate and speak a ‘language’ they can understand each other [Belgrare, 95]. In a collaborative design system, there might be some overlap among the different agents. A change in one agent may impact several others.

2.3.4 Mobility

There are several different aspects to mobility in the context of agent technology. Java’s portable bytecodes and JAR files allow groups of compiled Java classes to be sent over a network and then executed on the target machine. Java applets provide a mechanism for running Java code remotely via Web browsers. Other environments, such as the IBM’s aglets, allow Java processes to be started, suspended, and moved.