TAPAS Configuration Management Architecture
From TAPAS Wiki
Due to the increase in both heterogeneity and complexity in today’s networking, wide-area distributed computing and service provision systems, there arises a demand for a platform with functionalities beyond existing solutions.
TAPAS aims at providing a generic platform for enhancing the flexibility, efficiency and simplicity of system installation, deployment, operation, management and maintenance by enabling dynamic configuration of teleservices and network functionality. It allows hardware and software components as well as network elements that constitute a communication system to configure themselves when installed into the network and then to provide services according to their capabilities. Moreover, it permits adaptation of the system to the changing environment, in order to achieve mandated performance levels and at the same time be able to meet user satisfaction.
TAPAS dynamic configuration architecture is based on TAPAS basic architecture, which defines a service system (that is a Plug-and-Play (PaP) service system) as a decomposition of service components. A service component is realised by a role figure based on a role defined by a manuscript and is executed by an actor. A role figure, however, is realised in an executing environment in a node and is utilising capabilities. A capability is an inherent property of a node (or a capability component). These concepts of service components and capability components reflect two different viewpoints of a TAPAS system. A capability component may have several capabilities. These capabilities are offered to actors, which constitute role-figures in various plays. The ability to play roles depends on the defined required capability and the matching offered capability in a node where an actor is going to play. Examples of capabilities are processing, storage and communication resources (e.g., CPU, harddisk and transmission channels), standard equipment (e.g., printers and media handling devices), special equipment (e.g., encrypting devices), and data (e.g., user login and access rights).
An architectural framework for dynamic configuration in TAPAS, comprises the following main entities:
- Capability & Status Repository
- Play Repository
- Capability, Status & Event Monitor
- Configuration Manager
- Service Installer
- Service Reconfigurator
Contents |
Capability & Status Repository
Capability & Status Repository (CSRep) stores specifications of capabilities offered by components in a system and maintains information reflecting the situation and status of the system at a particular time. Such status information can be certain environment conditions, observable values of the current QoS characteristics as well as their calculated measures, which will be analysed by the Configuration Manager when computing (re)configuration plans for the system.
Play Repository (PlayRep)
Play Repository (PlayRep) comprises a set of play definitions defining functional behaviours of particular service systems, each consisting of several actors playing different roles with certain requirements on available capabilities and status. A play definition is an aggregation of the following four specifications:
- Manuscripts define the functional behaviour of each role which not only embraces its internal behaviour, but also the interactions and cooperation with other roles. Note that a role is the total behaviour of a role figure.
- Role specifications identify, for each role, its requirements on both available capabilities and status.
- Play configuration rules describe service system configuration constraints, such as specification of the maximum number of roles which are allowed to install at a specific node in order to avoid an overload situation. For instance, one may define that during a peak hour, each node in the system cannot execute more than five roles. Moreover, in some application domains, optional and mandatory constraints as well as conflict handling and priority information could be identified. For example, one could restrict that actors playing the FTP server and FTP client roles must not reside at the same node, and the server is mandatory while the client is optional.
- Reconfiguration rules define application-specific reconfiguration policies for handling substantial reconfiguration-related events. Examples of such events include a service component failure, a decrease in system QoS and resource unavailability. With application-specific reconfiguration rules, the system can perform appropriate actions to alleviate a problem in a running system.
Note that role specifications and manuscripts define two different aspects of roles in a play: the static and dynamic models. The former describes the metadata of each role and the latter models its functional behaviour in terms of UML state diagrams. Hence, they provide information of “what the role is” and “how it is realised”, respectively.
Capability, Status & Event Monitor
Capability, Status & Event Monitor (CSEMon) monitors the system capabilities/status and also maintains the CSRep. Moreover, it listens to certain events indicating changes to the system and its environment, which would prevent the system from getting the desired level of services. In response to such events, it notifies the Configuration Manager for further proper reactions, in order to keep the system functioning with an acceptable QoS level.
Configuration Manager
Configuration Manager (CM) is responsible for:
- Generation of appropriate configurations for composing new services to be installed in a system: When there arises a request for installing a new service (i.e., a service request), the CM fetches a corresponding play definition and retrieves the system capabilities and status from the PlayRep and the CSRep, respectively. Valid configurations for such a service are then generated and analysed, and an appropriate configuration will be selected based on the specified selection criteria, e.g., system performance and QoS, user preferences and cost. Such a selected configuration, defining which nodes in the system should execute actors constituting certain roles, will be forwarded to and executed by the Service Installer.
- Determination of a location for executing a particular role: In the running service system, a request for instantiation of a particular service component (i.e., a service component request) may arise. In response to such a request, the CM dynamically determines the best location (node) for its installation, based on the current system configuration, available capabilities and status as well as the component’s requirements. It then notifies the Service Installer to load a corresponding manuscript from the PlayRep and instantiate it on the suggested node.
- Computation of reconfiguration schemes for dynamic reconfiguration of existing service systems: Upon the receipt of a trouble report indicating a problem in a running system, the CM analyses the problem, fetches related information from the CSRep and the PlayRep, and produces a service reconfiguration plan to be executed by the Service Reconfigurator. Possible plans include actor relocation, re-initialisation, load balance and distribution. Selection of an appropriate plan depends on the defined reconfiguration rules as well as the nature of a problem (e.g., whether it is hardware or software failure, significant or ignorable).
Service Installer
Service Installer is responsible for the installation of a service into the system by creating corresponding actors for execution of certain roles, according to an obtained play configuration generated by the CM. Allocation of capabilities as well as instantiation of a manuscript for each role are also performed by this entity.
Service Reconfigurator
Service Reconfigurator initiates and performs reconfiguration of a service system based on an obtained reconfiguration plan.
Capability and status concept
In TAPAS Capabilities can be classified into:
- Resources: physical hardware components with finite capacity, such as processing, storage and communication units,
- Functions: pure software or combined software/hardware components which perform particular tasks,
- Data: just data, the interpretation, validity and life span of which depend on the context of the usage.
Although physical resources and their functionalities are depicted as two separate entities, they are in most cases closely related and undividable. A function is usually realised by installing physical resources and/or some related software. Typically, a resource can realise more than one function. For instance, a particular VGA card may function as a VDO controller and a VDO capture; a multi-function printer may provide printing, scanning and fax-receiving functions, which cannot be distinguished in hardware. The relationship between these concepts of resources and functions are many-to-many: a hardware resource may realise several functions, and a function can utilise a range of resources. The power of each capability function and resource is measured by its respective QoS characteristics.
Besides being classified as resources, functions and data, capabilities can also be characterised by their varieties, i.e., whether they are optionable or absolute. For example, transmission function is optionable (it has a variety of bandwidth options), while access right data is not. Moreover, capabilities can, by arrangement or use, be exclusive or shared. For instance, transmission channels and Web servers are by nature shared resources, a password is by nature exclusive information, and access rights can be either exclusive or shared depending on the application domain. In addition, each capability can be associated with certain operational and behavioural properties. For example, operational properties of a printer include paper sizes supported, font types installed and duplex print option.
Status is, at a certain time instant, the situation in a PaP system with respect to the actual number of nodes, playing plays, traffic situation as well as operational and non-operational states of each node or each capability component in the system. It can comprise observable counting measures, measures for QoS or calculated predicates related to these measures.
The developed framework proposes the use of standard XML-based metadata and ontology languages for modelling and providing semantic description of capabilities and status of PaP systems. RDF (the W3C recommended metadata language) and its extensions (e.g., DAML and OWL) appear to meet this language need. However, so far a standard, common ontological schema for describing network management resources in such languages does not yet exist. Therefore, the framework employs and extends CIM schema developed by DMTF (Distributed Management Task Force) for representing capabilities and status.
As previously discussed, the proposed approach emphasises the use of standard Web metadata languages for system data modelling. Moreover, because CIM does not provide means for representing various types of messages required by the developed TAPAS dynamic configuration architecture, RDF and DAML languages are exploited to model each type of messages used in the framework. Basically, each message carries its URI (Universal Resource Identifier), information of the actor who sends the message (i.e., the sender) and the date/time of composing it. A sender’s information includes its URI, the installing location and the playing role. Other message attributes can also be encoded depending on the purpose of the message.
Messages
Two types of requests are defined (see the figure below):
- Service Request: a request for installation and execution of a particular TAPAS service system, which has not yet been installed in a TAPAS system. It encodes the service request URI, the requester information, date/time, and the requested play URI identifying the type and version of the service to be installed.
- Service Component Request: a request for instantiation of a particular service component in a running TAPAS service system, which contains the request URI, information of the actor who makes the request, date/time and the name of the role for realising the desired component.
Trouble reports are classified into:
- Actor Error Report: This report is used for notifying the CM when an actor-involving problem occurs. It has the following two subtypes:
o Actor Unreachable Report: When an actor in a running system wants to communicate and cooperate with another existing actor which constitutes a particular role but is somehow unreachable or not responding, the former generates a trouble report indicating such a problem to the CM. o Insufficient Capability Report: An actor sends this type of trouble reports to the CM if the node where it is installing and running has insufficient capability (such as insufficient disk space, memory or CPU speed) to satisfy its capability requirement.
- QoS Degradation Report: This report is used to notify the CM when a QoS-sensitive service system encounters a decrease in its QoS to an unsatisfactory level.
The Figure below defines the possible types of reconfigurations:
- No Action: System developers may decide to disregard and perform no action for certain types of troubles.
- Actor Reconfiguration: This requires reconfiguration of some particular service components constituted by corresponding actors in a system, and can be further classified as follows:
o Actor Initialisation: The action is decomposed into (i) the instantiation of a new actor at a specified node, (ii) the installation of the manuscript defining the actor behaviour which corresponds to the role to be played, (iii) the execution of the actor’s operation according to the installed manuscript. o Actor Termination: The specified actor will be terminated and the resources allocated to and consumed by that actor will be freed. o Actor Re-initialisation: The specified actor will be terminated and re-initialised at the same node. o Actor Relocation: It involves moving of an actor currently executing at one node to another. In general, this reconfiguration is carried out when an actor has insufficient capabilities to execute its functions; thus, to proceed with its operation, the actor must be relocated to a node with higher capabilities. TAPAS mobility architecture discussed how actor mobility is realised in TAPAS systems. · Play Reconfiguration: The whole running service system, defined by the specified play and consisting of multiple cooperating actors, will be reconfigured. The best node for executing each actor will be re-determined and the actor will be relocated to that new location.
In order to study and experiment with the concept and framework discussed above a demonstratio on an Intelligent Printing Management (IPM) system has been carried out.
IPM is a concept in managing network or Internet shared printers. The basic assumption is a set of printers serving tens or hundreds of users, i.e., several servers and many clients. Such a system demands a rather high degree of configuration and strategic planning, in some cases agreed-on-policies and priority matching. Users of these network printers have to check the availability of printers and their print job queues. In any type of arrangement there is a high probability of inefficiency in terms of printer usage and achieved tasks. The only way to come around this matter is by paying a great deal of attention to what is being printed and where, and set out a detailed set of policies regarding document sizes, working hours and types of printers. Nevertheless, queues of print jobs will not be dealt with if there is any congestion at a printer, or any type of operational errors. These jobs could be lost, if someone reset the queue, or double printed if one decides to print them somewhere else, in case the queue is not accessible and therefore jobs cannot be cancelled. The IPM is simply a solution to the problems mentioned above. In the figure below, a basic configuration of a network using the IPM application consists of several plugged-in printers controlled and managed by a node running IPM manager role, which is visible to every user’s terminal demanding an access to printers.
Related links
- Support Specification and Selection in TAPAS : general introduction to the concept and the preliminary project vision, concept, and implementation issues.
- On Adaptable Networking : general introduction to the architecture and demonstration issues.
- Case study : on-line demonstration of the framework.( under construction)
