System components
The MINER system consists of 4 main components:
The following figure provides a MINER system overview.
Clientlibrary
The Clientlibrary provides programmatic access to the MINER functionality. By utilizing the Clientlibrary, the user can define the activities of an experiment (called Scenario, see below), execute it and retrieve results. The Clientlibrary can be made available in various programming languages – currently a Java version exists.
The Clientlibrary is not strictly needed in the sense that the MINER functionality can be accessed directly through a REST-style webservice that the Server provides. However, programming applications on top of the Clientlibrary is simply more comfortable. The Clientlibrary allows the user to program in his/her preferred language (currently Java). One of the core tasks, the specification of the Scenario, is achieved by simply creating objects and using their setter/getter methods. If the application would use the Server’s API directly, the user would have to create an XML document to define a Scenario. Additionally, the Clientlibrary shields the user from communication details and error handling tasks.
Server
The Server is the core component and implements the main features of the MINER system. It provides an interface towards the user (which is normally utilized via the Clientlibrary) and communicates with the ToolProxies. The Server maintains a database to store various entities like Scenarios, Executions, Results, available ToolProxies and MinerTools, etc..
Scenarios can be submitted to the Server where they are validated and stored in the database. The execution of Scenarios can be scheduled by the user. The Server dispatches Executions at the right time. The execution procedure involves several steps like loading the Scenario from the database, distributing it to the ToolProxies involved, ensuring that all MinerTools initialize correctly and so on. The Server coordinates the implementation of the Execution plan and maintains the current state of all active Executions.
The results that are produced by the Tools are sent to the Server which stores them persistently. The Server makes these results accessible to the user by providing a query service. When a result violates a Condition as defined in the Scenario, the Server provides various means to notify this violation.
The Server maintains a registry of all ToolProxies and MinerTools available in the system. A MinerTool can only be employed in a Scenario if it has been successfully registered at the Server in a prior step. The same is true for ToolProxies which need to register at the Server before they can be utilized in a Scenario. At all times, the Server is aware of the existing ToolProxies, their state, and their available MinerTools.
ToolProxy
A ToolProxy is a mediator between the MinerTools and the Server. There is 1 ToolProxy instance running on each experimentation node. On behalf of the MinerTools, the ToolProxy receives requests from the Server and takes care of their implementation. When it receives a Scenario Execution request, it parses the Scenario, instantiates the required MinerTools and follows the Execution plan by directing the lifecycle of the Actions that comprise the MinerTools.
MinerTool
It is finally the MinerTools that do the “real work”, i.e. implement some activity that has to take place as part of the experiment. Basically, any executable code can be turned into a MinerTool. A MinerTool can e.g. actively generate network traffic, configure a component of the system under test, or read values from some sort of sensor. A MinerTool defines the set of results it can possibly produce. A user must explicitly specify in the Scenario which of these results shall actually be produced (if any). A MinerTool implements the tool integration API and is provided as an OSGi bundle: a Java Archive (.jar) containing some special metadata.