Skip to end of banner
Go to start of banner

Domain model

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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 PlatformIdenthttps://195.227.0.189/NovaSpy/wiki/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.

  • No labels