Introduction to Systems Development in Time Weaver

Introduction to Systems development in Time Weaver

To develop an application in Time Weaver, two stages are necessary, first the development of the application components that will integrate the application. And second, the development of the software architecture with these components.

Developing components

Developing components in Time Weaver implies developing extension to application agents and the development of the interfaces through which these agents communicate.

Creating new Application Agents

An application agent is a class that process typed events. Because of it to develop an application agent it is necessary to define both the application agent class and to defines the new types of event the application agent will be dealing with.

An application agent is created through the extension of the class ApplicationAgentBase. The extension needs to specify, first the set of interfaces it will be reading and/or writing.

In Listing 1 the code for the definition and constructor of a new application agent is shown. Note that in line 5 a new object of class RadarReading is created. This object is the interface the application agent will be writing. Inside the constructor in lines 9 and 10, specify that this application will be writing the RadarReading interface and that it will not read it. The objects that specify the read/write attributes of the interfaces should be stored in an array variable named implementedInterfaces. In the constructor line 11 create a new array assigned o this variable and the radarReading object is stored in the location zero (the only one). The last point of the specification is the value assigned to the boolean variable inputPortOpened. This variable represents whether the application agent needs to receive an event to start executing. As you can see in line 13 this variable is assigned false, meaning that it can execute without receiving any event, this is also known as an active object.

Listing 1 - An Application Agent definition

The second part of the code of an application agent is the processing of the events. An application agent should implement a method with the signature public Interface ProcessStateChanged(StateChangedEvent sce). This method will be invoked every time the agent receives an event communicated in the sce parameter. The StateChangedEvent class contains a field of type Object named state. This field will contain an object of the interface the application agent is expecting. In the case of application agents that are executed periodically but do not read any interface, the ProcessStateChanged() function will be called with an object of class Tick in the sce.state field.

To send an output event the ProcessStateChanged() method should return an object of some subclass of Interface or null if no object is send out. Listing 2 shows the code for the event processing of our example class. Note that the method does not process the sce parameter but returns the radarReading object after modifying it. This is because this agent is invoked periodically and only generates output.

Listing 2 - processing events

When a component expects an event it should process the sce.state argument received. An example of this type of processing is shown in Listing 3.

Listing 3 - processing of the sce argument

This listing shows how to check for the expected class in the sce.state variable. Note that the return value is null meaning that no interface is written.

When more than one interface is being received or send, the ApplicationAgentBase provides two additional methods:void dispatchStateChanged(Interface i), and Interface getNextChangedEvent().

Listing 4 - additional event handling methods

Listing 4 shows example code on how these two methods are used. In this case the application agent is using an invocation pattern, i.e., it is sending an interface event (line 5) to a component from which it expect an answer that is retrieved with the code in line 6.

Finally you need to define the Interface subclasses the new application agents will be using. This is done by extending the Interface class and adding fields that will carry the information to be transmitted in the event if any.

Listing 5 - Interface definition

Adding new components to Time Weaver

In order to add the new components to Time Weaver, first we need to package them into a jar file. To do this first we need to compile the java classes with the javac compiler (remember to include the couplers.jar library, e.g., “javac –classpath \timeweaver3\couplers\couplers\class\couplers.jar;. RadarReadings.java”) . Then a manifest file should be defined. A manifest file describes the classes that are included in the jar file. Listing 6 shows an example manifest file. Two fields per class needs to be specified, first Name, this is just the name of the class. Second, whether or not the class is a Java-Bean (this is the java concept of component). Given that Time Weaver components are extensions of java beans, both the interfaces and the application agents should be java beans, i.e. “Java-Bean: True".

Listing 6 - manifest

Once the classes are compiled and the manifest was created then you can invoke the jar command to create the jar file, e.g., “jar ctvf radar.jar *.class”. Once the jar file is created it will need to be moved to the directory “%TIMEWEAVER%\timeweaver\timeweaver\jars”. In addition it will need to be added to the classpath in tw.bat as shown in the underlined part in Listing 7.

Listing 7 - tw.bat : classpath setting

Look at %TIMEWEAVER\pgm directory for a simple example of the set of files discussed in this document.