• No results found

6.7 Experiment 5: External JARs Over HTTP

6.7.3 Procedure for Experiment

The experiment aims to reproduce the same functionality observed in Experiment 4. As before, all functionality is tested in separate virtual machines, including that of the HTTP server. Two steps are needed, the removal of the commons-math JAR from the package, and the development of the modified ability which uses a URL class loader.

Removal of Math JAR from WAR File

For this experiment, the changes made to the code base for Experiment 4 were re- versed. The commons-math-2.2.jar was once again removed from the list of JARs to be included in the basic-agent package. On building a WAR file from this package, the absence of this JAR was verified by listing the contents of the WARs created.

Development of a ‘No JAR’ Ability

The abilityGetSimilarityin agent S-1 of figures 6.16 and 6.17 in Experiment 4 was renamed and modified to becomeGetSimilarityNoJar.

While the logic and outward functionality of the ability remained the same, the internal code was modified to use a URL class loader to access some classes. The changes to that code are described here.

The cosine-similarity calculation within that ability uses three classes and meth- ods from the commons-math JAR. One of these classes,OpenMapRealVector is used here as an example to illustrate the different approach needed when loading a class from a remote JAR. This is then compared to that of the usual and ‘conventional’ approach, i.e. when the class is available locally.

In terms of Java syntax, for the conventional scenario, classes are ‘imported’ at the top of a class and instantiated by calling the Constructor method for each class as needed. Following this, methods can then be invoked on each instance. The segments of code which do this are shown in figure 6.22. By contrast, to implement the same

// import at top of class, Class is visible one of the available class loaders. import org.apache.commons.math.linear.OpenMapRealVector;

// instantiate an object

OpenMapRealVector vectOne = new OpenMapRealVector(termsHmapAll.size());

// invoke a method on the object, arguments are ‘int’ and ‘double’ vectOne.setEntry(position, frequency);

Figure 6.22: Conventional Java Code with Import of Classes.

logic where the OpenMapRealVector class is loaded from a URL class loader, the (longer) syntax required is illustrated in figure 6.23. Notice in figure 6.23, a Method object has to be created for each method which is invoked. This object is then used to invoke a method of the instance.

Programming for using classes which are only available via a network class loader is inherently more verbose and complicated when compared to code which uses ‘lo- cally available’ classes. Methods are called on classes where the method signatures

// Note: OpenMapRealVector is NOT imported at the top of this class.

// Get the current class loader of the application ClassLoader contextClassLoader = Thread.currentThread()

.getContextClassLoader();

// use this class loader to load all classes in the remote JAR urlLoader = new URLClassLoader(new URL[] { new URL(

"http://123.123.123.123/classes/commons-math-2.2.jar") }, contextClassLoader);

// the class for OpenMapRealVector is defined omrvCL = Class.forName(

"org.apache.commons.math.linear.OpenMapRealVector", true, urlLoader);

// an instance of one of its constructors is instantiated Constructor<?> ctor = omrvCL.getConstructor(int.class);

// the constructor instance is used to create an instance // of the class to which the constructor belongs, i.e. omrvCL vectOne = ctor.newInstance(termsHashmap.size());

// this gets a method of this class of vectOne, i.e. omrvCL Method setEntry = omrvCL.getMethod("setEntry",

new Class[] { int.class, double.class });

// invoke the method, arguments are an ‘int’ and ‘double’ setEntry.invoke(vectOne, new Object[] { position, frequency });

Figure 6.23: Java Code for Remote Classes.

are specified ‘blindly’ by the developer. The method names and signatures speci- fied must match those of the actual classes used. For this reason, and because of

unreliable networks and other opportunities for errors, Java URL class loading and Reflection code is surrounded by several exception and error catching braces.

Figure 6.24 shows an SGA with the modified GetSimilarityNoJar ability. The

GetSimilarityNoJar Commons-math.jar RealVector.class OpenMapRealVector.class SparseRealVector.class Class Loader

URL Class Loader

JVM

SGA

SGA ability

Access to classes available in the class loaders of the application and of the JVM.

HTTP Server

Key

Access to classes only available on a remote HTTP server, accessed using a URL class loader.

JAR files or individual classes can be stored on the remote server. Network

Figure 6.24: SGA access to a remote JAR file using URL class loader.

SGA in figure 6.24 corresponds to agent S-1 in figure 6.17, the system used in Exper- iment 4. This figure shows the ‘access routes’ the ability uses to load the classes it needs to execute. The majority of classes will be available in the class loaders of the JVM. For the classes required from the JAR commons-math, the code of the ability calls for classes to be loaded using the URL class loader.

6.7.4

Running the Experiment

A small multiple-agent system of agents S-1, S-2 and S-3, the same as that in Exper- iment 4 was created (see figure 6.17), using the MAS creation mechanism as before. The newly developed abilityGetSimilarityNoJarwas used in agent S-1 and replaced the GetSimilarity used in Experiment 4.

the experiment attempted to invoke the agent S-1. This failed as expected. This was done to ensure that the required classes were not inadvertently being made available due to caching or a programming error.

Having made the requiredcommons-mathJAR available on the HTTP server, the test was repeated, this time with a successful outcome. That is to say, the same functionality and behaviour was observed as was seen in Experiment 4 and the test ran without any errors or failures.

Access to the HTTP server was observed in the logs for that system, a sample of which is available in figure 10.1 in appendix J, page 210. Examination of that figure shows the initial failed attempt to fetch the commons-math-2.2.jar file (causing a 404 error) and two further successful responses for the required JAR file. Also in figure 10.1, prior to these entries, the request for the abilities XML file and social profile XML file can be seen.