6.1.3 Architecture of the Management System

In this subsection, an overview of the architecture is given to get a conceptual view of the management system and its components. Not all components are described here for the purpose of clarity. Only the components relevant to this thesis are presented here.

The management system is realised by a number of distributed components made up of agents using CORBA functionality and services. All objects are CORBA objects and therefore can be referenced through the methods provided by CORBA. The objects can provide functionality with an IDL interface, which can be used from other components.

Figure: Architectural overview of the management system [Radi 98]

The architectural overview is shown in figure . The core system consists of the following components:

Agent System

The mobile agents live on an agent system. There is one agent system per host. Mobile agents are created in an agent system which has the ability to control all of its agents. The mobile agents can migrate to other agent systems for the purpose of availability, load balancing, etc.

Mobile Agent

A mobile agent is used to realise a special service on an agent system. The agent acts as a CORBA server and has a public interface to offer its service which can be used from other CORBA objects in the role of clients. As compared to a stationary agent, it can migrate to other agent systems.

Service

A service provides functionality through a specific public interface. Here, a service is always made up of two components: a factory and the objects produced by that factory. Both the factory and the objects produced by it provide an interface to access their functionality^6.2. Therefore, they act as CORBA server objects, but they can also use services of other server objects, acting as clients in this case. In the management system, the following services can be used:

Policy Service

This service, which is represented on the left in the architectural overview in figure , is realised by the Policy Factory Mobile Agent. The Policy Factory Mobile Agent consists of the Policy Factory and the created Policy Objects by it. As can be seen in the more detailed figure , the policy factory is able to produce three kinds of policy objects: Strategic Policy Objects, Goal-oriented Objects and Operational Policy Objects.

In contrast to strategic and goal-oriented policies, an operational policy is described by a Policy Description Language (PDL), which can be checked to ensure its syntactical correctness. An operational policy, which is inactive at first, can be activated causing the interpretation of its policy description by the Policy Interpreter. If necessary, the interpreter invokes the creation of Enforcement Objects by using the Enforcement Service and binds the operational policy object to a special event channel, the AgentInitChannel by calling a method of the policy object for this purpose. Through the AgentInitChannel the operational policy gets notified if new agents are added or removed.

For decoding the policy description and in order to reference the correct objects, the policy interpreter can make use of the CORBA Topology Service and the CORBA Naming Service. The persistent storage of policy objects is implemented by the Persistence Service.

Figure: Details of the Policy Service [Radi 98]

Persistence Service

The Persistence Service at the centre of figure  is realised by the Persistence Service Mobile Agent. It stores CORBA objects, such as created policy objects, and saves their actual state in a Persistence Object Database. It implements methods to store, restore, insert, and extract persistence objects.

Enforcement Service

The right-hand side of figure  depicts the Enforcement Object Mobile Agent, which realises the Enforcement Service. As the Policy Service, it consists of two kinds of components, the Enforcement Object Factory and the Enforcement Objects created by it. An Enforcement Object Mobile Agent is always specific to a special type of management agent, for example a DHCP^6.3 agent, and can only create Enforcement Objects for this kind of agent.

The creation of Enforcement Objects is usually invoked by the Policy Service by activating an operational policy through the Policy Interpreter. Already created and activated policy objects which are stored in the Persistence Object Database also cause the creation of corresponding Enforcement Objects if the type of the Enforcement Object Mobile Agent matches the type specified in the policy as target.

Figure  shows the details of the Enforcement Service. After creation of an Enforcement Object, the monitoring of the target management agent can be started through binding the Enforcement Object to the event channel of the agent. If an Enforcement Object receives a notification then it starts to verify whether the enclosed subject of the event matches the subject of the policy the Enforcement Object represents. Because subjects are always nomadic computer systems, this is done with the help of the directory service. After that, the Constraint Interpreter evaluates the stated constraint in the PDL description of the policy and activates the Action Interpreter in case of a positive result. The Action Interpreter finally invokes the management actions specified in the policy at the target agent which was the creator of the notification.

Figure: Details of the Enforcement Service [Radi 98]

Monitoring Service

The Monitoring Service is implemented by using the CORBA Event Service. Monitoring is the responsibility of the agents for managed objects. They must use the push model variant of the CORBA Event Service and can send events to an event channel where all objects registered to this event channel get notified of the produced event.

Domain Service

Two different kinds of services are used as domain service, on the one hand the CORBA Naming and Topology Services, on the other hand a directory service.

With the help of the CORBA Naming and Topology Services the structure of the network and its domains can be queried.

The directory service is used to query the home domain of a nomadic system. It is necessary to verify whether the home domain of the subject specified in the policy matches the home domain of the nomadic system identified by its MAC^6.4 address. At the moment, a relational database is used to match the MAC address with the home domain of a nomadic system [Schi 98].