Information Technology Reference
In-Depth Information
The
Market sensor
gathers market information, for example data concerning
the past and current number of sellers and buyers on the market and information
concerning the resources traded. This is achieved by using GridSim interfaces of
the architecture layers responsible for resource and job management.
The
Infrastructure sensor
monitors the usage of computational resources.
In particular, it monitors the utilisation and performance of the underlying oper-
ating system and hardware infrastructure. For example, processor utilisation and
speed, number of threads, memory usage, hard-disk usage, etc. The infrastruc-
ture monitoring is based on the interfaces defined by the
java.lang.Management
package, which is a management interface for monitoring and management of
the Java virtual machine as well as the host operating system.
Despite the large flexibility of GridSim, its numerous interfaces and multi-
layered architecture, creating a simulation scenario is not a trivial task, as many
market actions and the creation of communication objects between the layers
of GridSim are left to the user. However, GridSim does provide a small set of
examples that illustrate the implementation of simple trading scenarios. In our
feasibility study, we applied one of the example scenarios. This example allowed
us to control basic trading properties, i.e. the number of buyers and sellers in
the market and the number of requests per buyer, etc., which for our purposes
was adequate. It also enabled the construction of a market, establishment of
participants and resources, and provided an easy platform upon which to imple-
ment a monitoring framework. It was also straightforward to implement a basic
benchmark scenario to test the monitoring framework.
However, we encountered diculties when we created more realistic and elab-
orate scenarios, for example: different participant types (e.g. malicious users,
market makers, speculators, monopolists, and other strategic behaviours); more
complicated trades, i.e. multiple resource entities; dynamic context: adding or
removing participants or resource types at runtime; and engineering aspects like
market growth or contraction. When trying to create such scenarios, we en-
countered runtime exceptions for the following reasons: (1) GridSim expects the
number of users to remain fixed; (2) it is not possible to change the quantity
of resources that sellers offer and buyers request, i.e. total supply and demand
is predefined; (3) new resource types cannot be added at runtime; (4) it is not
possible to manage the timings of the bid/ask submissions, this is controlled
by GridSim's event handlers, which makes it dicult to implement users with
specific participation strategies. Through our efforts to counter these as well as
other challenges, we were moving away from GridSim's initial use case, eventu-
ally making it impossible to control and extend further. Consequently, we were
no longer confident that changes in the market were engineered by us as opposed
to errors in the GridSim runtime. It would be easy to say that this is a failing
of GridSim, but our scenarios were straying outside of GridSim's scope.
