Experiment Environment Considerations

Host Container IP Addresses as State

In chapter 4, consideration was given to setting state in instances of classes prior to loading them to the SGA’s data-structure. In this experiment, some of the state which has to be added consists of web service addresses which are used for communications between SGAs. These consist partly of the IP addresses of the hosting the containers

in which the agents run. For this experiment, temporary VMs in Cloud infrastructure are used, the IP addresses of which are not known until after each VM is created. When available, these values are manually inserted into a Javavariables file and used by a custom Java program when creating the serialised object files (recall section 4.7). Therefore, in this experiment environment, the IP addresses for each SGA must be known before any of the serialised object or abilities configuration files can be created. As touched on briefly in section 4.1.1 on page 55, planning the layout of a multiple- agent system is not the focus of this thesis. The workings described are merely the mechanisms needed to create the necessary serialised object and ACFs necessary for recreating and configuring the required SGAs. Furthermore, in a real-world environ- ment, IP addresses for the machines to be used would most likely be known and fixed. However, at the center of this mechanism are the tools which could be used in any

mechanism used to create such abilities configuration files.

Development vs. Real Environment

In the original SGA work [107], this small system of agents tested the behaviour of SGAs in a simulated grid-job submission scenario. Depending on the availability of suitable infrastructure and available grid services, this experiment can be run either in a software development environment or with SGAs deployed in web-service containers in virtual machines (VMs).

For this thesis, I have used a development environment for testing and prototype work. After initial developments in an IDE, agents and abilities were sometimes tested in a web service container on the development machine (see section 6.2 for details of this environment). For this experiment (and all those of this chapter), each SGA is created as a web-service application. Each one runs in a separate web- service container, all of which are located on separate virtual machines. This was done to recreate a truly distributed environment where communications required sending ‘real’ message via HTTP over an IP network. Working in a ‘real’ distributed environment aims, as far as possible, to eliminate the possibility of classes or JAR files being inadvertently made available to a class loader in a scenario where, for

example, ‘class loading’ is the actual functionality being examined. This proved to be a fruitful exercise as some of the issues addressed in this thesis did not surface until the mechanism under examination was tested in this distributed environment.

In either the development or real environments, ‘dummy’ job submission code which simulates randomly successful or failed grid job submissions is used in place of the Service Providers which would actually interact with real-world ‘grid job sub- mission’ infrastructure (e.g. by executing the gLite commands described in section 2.2.1, page 12). Due to the current unavailability of grid services in my development environment, dummy execution Service Providers will be used in place of ‘real’ grid job submission. It is worth noting that examination of successful job submission is not the subject of this experiment. This was examined in the work of Pierantoni [107]. Furthermore, none of the job submission, pricing policies, etc. set out in that work have been altered.

WAR File Packaging

The code-base on which all the ‘basic’ agents for this experiment are based was stripped of all the classes which were to be added. This means that none of the classes which were added as abilities were already available in the package of the application (i.e. the WAR file in this case). A sample from the list of the 138 class files and the 37 JAR files which are necessary for the ‘basic’ agent are listed in appendix D, page 202. Although the full list is not shown in this appendix, it is important to state that there was no overlap with this inventory of classes created for the agent configuration (listed in appendix C, page 201).

Class Loading and Inheritance

All of the classes which were added as abilities were subclasses of aServiceProvider super class. This super class definition is already included in the WAR file package of the SGA and also acts as a super class to the minimal set of abilities which are necessary for the SGA to run initially. Without the presence of this super class in the WAR, loading any class which extends it would not be possible.

Scope of Transient Fields in Serialized Classes

Transient fields or variables are a common feature of classes which are intended for serialisation. A transient field is one which remains null while the class is serialised; it will subsequently be null when the class is deserialised. In order to be able to use these deserialised classes agent-side, it was necessary to change the scope of such fields from beingclass scope tomethod scope (i.e. move each field within the methods in which they were required). Classes with transient fields which are class scope can be successfully serialised, transported and loaded to the SGA, but will throw a null pointer exception at runtime when that ability is used by the agent, specifically when the transient field is referenced.