/
Domain model

Domain model

Owned by ssiegl (Unlicensed)
Last updated: Nov 24, 2009

This document describes the domain model of inspectIT.

Requirements

The reworking of the Central Measurement Repository, basically the domain model which will be used by hibernate to persist the data, is needed to use less data transformers than currently utilized. At present, the user interface receives completely different data objects than the data objects that are sent by the Agent to the CMR, and these are even different from the objects that are persisted by hibernate.

The goal is to create a domain model which will be used by the user interface, too, to display the menu structure. By removing additional data adapters and transformers the code will be easier to maintain, modify and extend. The Agent will not access and use this domain model to lower the network traffic. Instead, data objects are filled accordingly with input and sent to the CMR which are then persisted right away. These data objects contain some id attributes which will help identifying this object on the CMR.

CMR domain model

The above UML model will be persisted by Hibernate on the CMR. The Agent(s) are indirectly creating these classes by calling remote methods with proper arguments. Indirectly because the Agent(s) do not know of these classes.

The first Ident that is created by every Agent is the PlatformIdent.This identification object holds specific information about the target computer and target Java Virtual Machine. It is needed to uniquely identify different Agents which are later listed in the user interface. Additionally, restarting a JEE server for example with an inspectIT agent installed, will be recognized and registered by the CMR with the same ID as before so that all measurements from the same Agent are always stored with the same PlatformIdent.

The next step for every Agent is then to register all available Sensor Types. The CMR differentiates currently between two kinds of Sensor Types:

  • The MethodSensorTypeIdent is used for all Sensor Types which are based on an instrumented method to calculate the measurements. For example the Timer Sensor Type computes the execution time of a method, thus the target method has to be modified to get this data.
  • The PlatSensorTypeIdent is used as an identification object for all Sensor Types which are notbased on an instrumented method. For example a Sensor Type which collects data from the M(X)Beans or one which is used to read the VM arguments. A main difference to the Method Sensor Types is the fact that the collection of the data is not triggered by entering or leaving a method, but on different actions. It will be even possible in the future that some Sensor Types (think of a Sensor Type which collects much information about the target VM) are executed from the user interface.

The separation of the two sensor types leads to another advantage, mainly for the user interface: If the MethodSensorTypeIdent would be the only one available, the interface would have to iterate over all MethodIdent objects to get the reference to all Sensor Types, no matter if they are based on an instrumented method or not.

The last Ident object that is created is for every instrumented method on the target system. With this information, the user interface can provide a tree based view containing the package, class, method and method attribute names.

Transfer objects

The above model represents the data objects used to transmit the measurements from the inspectIT Agent(s) to the CMR and from the CMR to the user interface. The data containers, which extend the SystemSensorDataand provide dymanic informations, contain only the measured data (for example: min, max, total). Stuff like the average will be calculated at the client side. Every data container has to extend either the SystemSensorData or MethodSensorDataclass. As these data objects are created on the Agent(s) after the registration process on the CMR is finished, they have to contain information about to which Ident object they belong.

Again, the data objects are divided into two categories. Every object which holds data for a specific method has to extend the MethodSensorData class. In contrast to the objects which are extending SystemSensorData, these objects contain an additional field methodIdent which is needed for correct mapping on the side of the CMR (and later the user interface).

Important to know for the data objects is the fact that they are received and accepted on the CMR and persisted right away. Value objects on the other side are used just to transmit the measurements from the Agent(s) to the CMR and are transformed into their corresponding data objects so that they can be persisted afterwards. The user interface will always use data objects and never value objects.

Timer model

Instead of aggregating the data right away on the Agent(s) for the execution time of a specific method, the data can also be stored in raw format in the PlainTimerVO object. This value object is transmitted to the CMR and then transformed to the TimerData object which will be persisted.