Log Monitor
The purpose of the Log Monitor tool is to make it possible for the developer of AAL applications to monitor important events when debugging or running an application and provide additional information to support their interpretation. In particular, it will make it possible to view the messages that are exchanged on the busses of the middleware. However, all messages using the universAAL logging mechanism as defined in the container artefact of the middleware can be viewed.
The Log Monitor has multiple views to show
- all log messages in tabular format
- a visualization of RDF Graphs if such a graph is contained in a message
- information about the service bus matchmaking
- information about the uSpace, its peers, modules, and the bus members
- ontologies registered on the peer
- the flow of messages between bus members
The main view shows all log messages that are issued using the universAAL logging mechanism. The upper part of the window shows message information in a tabular format, i.e.:
- the time of the message
- the logging level, one of trace, debug, info, warn, or error
- the module (in OSGi: the bundle) that issued the message
- the Java package name
- the Java class name
- the Java method name
- short version of the message
The following screenshot shows an example of this view.
According to the Design Decisions of the middleware and, especially, the Basic Data Representation Model, all messages exchanged over the buses are modeled in RDF/OWL. Thus, most information in the universAAL platform is represented in a data structure of classes derived from Resource. The visualisation should help developers to easily understand the structure of that data. The following Figure shows a screenshot of this visualization. At the left side of the window, the messages are added as they arrive with the time of the log entry occurrence, the name of the class and the method that has issued the log entry, and the actual message. Additionally, the Log Monitor tries to give a short interpretation of the RDF message for some well-known resources, e.g. a ServiceRequest for calling a service that implements the controlledLamps method of the Lighting ontology (the first line in the Figure)
At the right side of the window, the RDF graph is shown with:
- resources with java class name (bold) and URI
- green boxes for types
- yellow boxes for literals
- properties are sorted alphabetically, only type properties are always at the beginning
Since the service matchmaking is done completely by the service bus it is sometimes not obvious why a certain service request does not match. Therefore, some trace log messages have been added to the service bus that are evaluated and shown by Log Monitor. The following screenshot shows an example of this view. On the left side, all service requests are listed together with the overall result of the matchmaking. On the right side, detailled information are given for a certain service request.
The results of the matchmaking process starts with the overall result and a short overview in tabular format. This table lists all registered service profiles that have been considered in the matchmaking process and lists (1) the result of matching the service request with this service profile, (2) if the matching was not successfull, the reason why the request does not match the profile (one of input, output, effect), and (3) the URI of the profile.
Each of these rows in the table is described in more detail in the lower section. Again, there is the result (as graphical icon) and the reason as in the overview on the top. If the profile does not match the request, it is followed by an error number with a short reason followed by a detailled reason.
Each of the elements, the service request as well as the individual service profiles, can show additional information in form of serialization (as turtle) or as an abstract view. The abstract view for the getLampInfo service profile is shown below as example:
Service ontology class hierarchy:
http://ontology.universaal.org/Lighting.owl#Lighting
http://ontology.igd.fhg.de/LightingServer.owl#LightingService
Inputs:
input:
URI: http://ontology.igd.fhg.de/LightingServer.owl#lampURI
type: http://ontology.universaal.org/Lighting.owl#LightSource
exact cardinality: 1
Effects: no effects defined
Outputs:
output:
parameter binding: http://ontology.igd.fhg.de/LightingServer.owl#brightness
at the property path: http://ontology.universaal.org/Lighting.owl#controls
http://ontology.universaal.org/Lighting.owl#srcBrightness
output:
parameter binding: http://ontology.igd.fhg.de/LightingServer.owl#location
at the property path: http://ontology.universaal.org/Lighting.owl#controls
http://ontology.universAAL.org/uAAL.owl#hasLocation
The service of type LightingService is a subclass of the service type Lighting. As input parameter, it needs exactly one (exact cardinality) instance of LightSource. It does not define any effects, but there are two outputs defined:
- at the property path #controls, #srcBrightness
- at the property path #controls, #hasLocation
This additional information is available on demand by selecting one of the links, as shown in blue in the screenshot (to show or hide the information). All details can be shown/hidden by selecting the appropriate link directly below the overview table. The content of the results as shown in the right part of the window can be copied to the clipboard in HTML format and pasted in an external document editor. This way, it can be stored or shared with other developers.
For this view to be shown correctly, the Log Monitor must run on the node that is the service bus coordinator.
This view shows detailled information about
- the uSpace
- the peers (or nodes) of the Space
Please note, that the peer role (shown as 'coordinator' in the screenshot below) denotes the coordinator property of the discovery part, but not whether this node is the service bus coordinator - the modules of a peer
- the bus members of a module
the bus members are shown with 3 types of information:- the bus: being either Service, Context, or UI
- the bus member type: publisher, requester, responder, subscriber
with the following correspondences:- Service requester: class ServiceCaller
- Service responder: class ServiceCallee
- Context publisher: class ContextPublisher
- Context subscriber: class ContextSubscriber
- UI requester: class UICaller
- UI responder: class UIHandler
- an ID that is just an integer value inremented each time a new bus member registers at the bus
- the registration parameters of a bus member
are shown in a way as known from the service bus matchmaking view
The ontology view shows all ontologies that are registered at the local node. The focus here is on the structural information, i.e. classes and their properties. Therfore, not all information contained in the ontology is shown. To get the whole ontology, it is recommended to save the ontology (e.g. in XML/OWL format, or in Turtle format with the MessageContentSerializer of the middleware) and use an external tool.
To simplify the browsing the ontologies in the left view are grouped in three categories:
- Application ontologies:
your ontology would show up here - universAAL Ontologies:
the ontologies from the Ontology Repository - universAAL Middleware Ontologies:
the ontologies from the Middleware Repository with the most basic information that is needed by the middleware to fulfill its purpose
This view shows all messages on the different buses. In horizontal direction, the registered bus members are shown, and in vertical direction are the different messages. Each message is shown with the time stamp, the bus members that are involved in the message (a big box denotes the origin of the message, a small box the receiver, an arrow indicates the direction), and an interpretation. For example, for a service request the interpretation is the service to be called, and for a context event the interpretation shows the triple (subject, predicate, object).
A right-click opens a menu where you can show/hide individual bus members or complete buses. A double click on a service request opens the appropriate matchmaking result in the service bus matchmaking view. The scrollbar on the right is color coded and indicates when a message has occured on a certain bus. Each bus has a certain color, that is also used in the main view.
It is recommended that you re-use existing bus members. For example, if you have to send multiple context events, then you should create the DefaultContextPublisher only once for all the context events to publish. Otherwise, this view can get quite confusing.
For this view to be shown correctly, the Log Monitor must run on the node that is the service bus coordinator.
- Saving always saves all images and saving is very time-consuming
- Currently, not all information about the service bus matchmaking is available, this depends very much on the log messages issued by the service bus and needs to be synchronized
- Service Matchmaking view: does not show basic matchmaking of OWL constructs
- RDF Vis: Interpretation of more well-known resources - no demand.
- Log message view: Sorting of messages - low priority
- Log message view: Filtering of messages - low priority
- New views for showing matchmaking in Context Bus and UI Bus - significant effort required.
The purpose of the Log Monitor tool is to make it possible for the developer of AAL applications to monitor important events when debugging or running an application. In particular, it will make it possible to view the messages that are exchanged on the busses of the middleware.
The video-tutorial below will guide you through the process of using the tool.