Visibility through inspection

The PalCom architecture supports Visibility/Invisibility by enabling the actor to notice and inspect the functioning of a running PalCom system at various levels of granularity. As such, Visibility is related to Understandability in that it assists the actors to increase their level of understanding of the running PalCom system by inspecting as much or little about the PalCom system as they choose, as illustrated below.

Figure above: Achieving visibility by inspecting a PalCom system at various levels, gradually revealing more and more of the system state. Specifically, figure illustrates how the visibility of an assembly gradually increases as the inspection reveals the internals of the assembly; stepping through its contained second order resources (in this case, services). Hence, by first inspection only the assembly is visible, though some user interfaces might display placeholders revealing background representation of lower-level resources. When inspecting the assembly its second order resource, Service A, becomes visible. Increasing visibility through inspection of Service A, its second order resources, Service B and C, become visible etc.

The PalCom architecture achieves the Visibility/Invisibility challenge through a combination of (1) the H-Map introspection data structure, and (2) inspectable second order resources. These let the user introspect a running PalCom system using specialized user interfaces for interpreting the system specific information and presenting that in a human understandable manner, or at least to a level of understandability chosen by the user.

Visibility through Introspection

The H-Map represents an introspection data structure containing information about the running PalCom system. The top level of inspection is the root of the H-Map from where the actor can get a sense of the whole running PalCom system.

By traversing down in the H-Map data structure, the user can retrieve both static information about the running system, such as its device capabilities, installed components etc. as well as dynamic information about other parts of the running system. Specifically, this dynamic information is retrieved from the live components etc. mounted to the H-Map during instantiation. As such, these dynamically mounted entities enable the user to have seamless access to inspect these resources.

Inspecting Resources

Visibility on the resources is enabled through so-called inspectability interfaces that the resources can implement, defined as part of the PalCom architecture. The resources provide these interfaces such that they can be mounted into and made accessible through the H-Map. Through these inspectability interfaces, the actor can reflectively query a particular resource about any part of its internal state that it wants to reveal.

The kind of state information and the granularity hereof that each resource reveals in its inspectability interface is specific to each resource implementation. For example, the implementor of a communication channel used in an application context might at one extreme simply have chosen to provide information about the status of some connection in the form of connected/disconnected values, or it may choose to enable inspection of the connection status through monitoring of individual bytes being send/received over the connection.

In accordance with the concept ontology, second order resources can contain other second order resources, which allows for gradual visibility of system information. Self-description and inspectability clearly help the actor to improve their understanding of the running system at different levels; those levels being from service level at the lowest to assemblies at the highest. Support for gradually exposing more complexity empowers the actor to actively dissect the running system to the appropriate inspectibility level revealing the information necessary for the actor.

In terms of inspectability, first order resources are a bit special in that they are not directly inspectable. However, the PalCom runtime environment can supply special wrapper services that provide access to the low-level first order resources. As normal services, these wrapper services are thus inspectable through the H-Map likewise.

User Inspection Interfaces

To do the actual inspection, the users need to have suitable tools, i.e., user interfaces, that can interpret the details offered by the system at the various levels of granularity and present them in a way that is considered understandable to the users. In fact, at each level of granularity, these tools might offer several different views of the details, each presenting the information in different ways.(The PalCom project only includes a limited amount of interface design as the main attention is towards the architecture.) Of course, the user can freely chose and switch between these views wherever they are available.

Invisibility

Of course, invisibility is implicitly given by gradually hiding information about the first and second order resources, as illustrated in the figure above, by following the arrow from right to left. However, for some second order resources, invisibility might be absolute. Whether a second order resource enables inspection and, if so, how much is reveals is specific to each resource implementation, and is defined in its inspectability interface. In fact, some second order resources might not at all be subject to inspection and thus not expose any visible information. For instance, a second order resource representing a service that encapsulates some security functionality might want to be completely sealed in order to avoid any breaches.

Automated Inspectability

Visibility/Invisibility is not only relevant for the actor being an end-user. The PalCom architecture also enables automated inspectability through the H-Map. This enables the PalCom Middleware Management managers to, e.g., inspect parts of the H-Map to monitor the state of the running Node (in terms of first and second order resources) and thus address potential problems before they happen. For instance, the Assembly Manager could (directly/indirectly) use the H-Map to periodically monitor, say, the level of available memory (first order resource), and through this knowledge make appropriate decisions, e.g., to avoid problems related to resource constraints, such as rejecting taking part in an assembly which would put additional contraints on the memory level.