1 Introduction

1.1 Purpose

This document is intended to give specifications of what will be developed by developers of the Standard Management Library (abbreviated to SML) and what will be provided for clients (users of Standard Management Library), the Standard Management Library will be coded in C++.

1.2 Scope

The Standard Management Library is aimed at assisting management application programmer in developing resource management programs in an easy way. Using this library is not mandatory in the development, even without it client can use the under layer API which the SML also depend on to accomplish management tasks.

However, by using the SML client can totally ignore the existence of the low-layered API for accessing CIM objects but rather focus on application level logic instead. Rather than preparing a long procedure for obtaining pieces of information from a particular resource element, client of SML can easily get the information of that resource element by calling methods provided in the SML in critically short sentences. This will be achieved by using the SML view of resource rather than that of the CIM, although the SML view based on the CIM view. SML view will be more natural and friendly with respect to OO programming. Another advantage of using SML is that clients are freed from remembering the context of providers as incorrect uses of context names are often reflected till run time.

1.3 Definitions

CIM:
Common Information Model (http://www.dmtf.org/standards/cim/)
CIM Client API:
An open API for access to CIM object, like those provided by OpenWBEM(http://www.openwbem.org), OpenPegasus?(http://www.openpegasus.org)
CIM Object:
view of resource from the CIM abstraction perspective (CIM Schema, (http://www.dmtf.org/standards/cim/))
CIM Server:
Hosted on the server side within the management architecture (Figure 2.1), CIM Server always contains a CIM Object Manager for operating CIM Object in response to the request from client end
Client:
the user of the Standard Management Library
Context name:
To access resource information, names(include provider names, properties names and methods names) are required in calling the API which the SML or other client program depends on
Developer:
Someone who will be involved in developing the Standard Management Library
Management Application:
An application used to manage lower level resource without the direct touch to the raw resource but by help of CIM object operations or the SML as specified in this document (Figure2.1)
Provider:
CIM object will be constructed by the corresponding provider which is closely related to resource itself and the resource environment
Resource:
Environment dependant entry like Process on Redflag Linux System
Standard Management Library(SML):
name of this product

Role of SML(Standard Management Library

1.4 References

1.5 Overview

Section 2 will give out the overall description of the SML, and section 3 will specify the requirements

2. Overall Description

2.1 Product Perspective

The SML (Standard Management Library) is applied between Management Application and the traditional CIM object access API. The SML is truly set up on CIM Client API which should be a C++ compatible API as SML will be implemented in C++. The SML itself will provide a set of API distributed in different header files, these API are limited to a number of providers prompted on (Technology Roadmap-2.2, 2006-11-02 OpenDRIM Camp Agenda). Since the SML will be implemented in C++, most of resource entries will have their mirrors in the SML and be operated via instances (objects) of specific classes

The SML will provide the following functionality modules(limited to the prompted providers):

Computer System:
come out to be the root node in the SML, everything except Date Time can be obtained by this node, Date Time should be considered as independent module. Operating System and Hardware can be obtained from this node directly
Hardware:
represent hardwares installed on the specific computer system, all the hardwares’ information(include Processor, Network Card, Disk) can be retrieved from this node
Processor:
describes the processor on the specific computer system
Network Card:
describes the network card installed on the specific computer system
Disk:
describes the hard disk of the specific computer system
Operating System(OS):
represent the operating system running on the specific computer system., nodes can be got from this node include: Service, System Monitor, User and Group Manager, RPM Manager, Logical Volume Manager
Service:
represent a service hosted on the specific computer system, like Network, HTTP Server, FTP Server, Task Scheduler, Firewall, Logs
System Monitor:
monitoring the performance of the specific computer system
User and Group Manager:
administrating user and group on the specific computer system
RPM Manager:
install or remove a package from the specific computer system
Logical Volume Manager:
used to manage the logical volume on the specific compute system
Task Scheduler:
task can be scheduled to run at a specific time on the specific computer system
Log:
log the system events on the specific computer system
HTTP Server, FTP Server, Network Config, Firewall, DHCP, DNS, Proxy:
configuration on the specific computer system

2.2 Product Functions

The SML resource classes will provide:

  • a set of functions for obtaining resource properties
  • a set of functions for setting resource properties
  • a set of functions for get associations, a set of functions for executing methods supported by their under layer provider
  • a set of functions for handling event and producing responses

2.3 User Characteristics

This product is aimed to aiding client programmers in building top level management applications. These clients are not expected to have knowledge of CIM although knowing it is a great benefit.

2.4 Constraints

The SML functionalities are restricted by the capabilities of following providers: Computer System, Processor, OS Information, Network, Service, System Monitor, User and Group Management, RPM, Log, HTTP, Logical Volume Management, FTP, DHCP, DNS, Proxy, Firewall

2.5 Assumptions and Dependencies

  • Date and Time play role of representing data types used in functionality modules
  • Only retrieving status of a specific hardware is supported
  • Network Config, HTTP Server, FTP Server, Task scheduler, Firewall, Log, DHCP, DNS and Proxy are services and grouped as Networks.

Figure 2.2 illustrates the dependency diagram

dependency

Figure 2.2 Dependency diagram of the SML

2.6 Apportioning of Requirements

Type conversion, date time dependency, event handling functionalities

3. Specific Requirements

3.1 Interface Requirements

Computer System(SML_ComputerSystem.h)
Input: an IP address, admin account info
Output: an instance of Computer System
Input: methods for getting subentries (like: Hardware, Operating System)
Output: instance of subentries
Hardware(SML_Hardware.h):
Input: a specific index of hardware or a get method
Output: an instance of that specific hardware description class Processor for example
Processor, Network Card, Disk(SML_Hardware.h):
Input: a method, generally a getXProperty of the class Output: values represent current status of hardwares
Operating System(SML_OS.h):
Input: an index of module or a method for obtaining that module(class) Output: an instance of required module(class)
Service(SML_Service.h):
Input: methods for obtaining properties like description, status, start type or start order
Output: values of required field
Input: methods for starting, stopping, restarting or freshening the service
Output: result flag indicating the post-condition of that executing
System Monitor(SML_SystemMonitor):
Input: methods for retrieving processes, sending signals to processes
Output: instance of Process, post-condition of sending signals to processes
Input: methods for inspecting the usages of system resources (memory, CPU)
Output: value reflecting the usages
User and Group Manager(SML_UserGroup.h):
Input: methods for adding, removing, editing user and group, changing password
Output: post-condition reflecting the execution
RPM Manager(SML_RPM.h):
Input: methods for installing, uninstalling a specific package
Output: post-condition of the operation
Logical Volume Manager(SML_LogicalVolume.h):
Input: methods for mounting, un-mounting, formatting logical volume
Output: post-condition of the methods execution
Task Scheduler(SML_TaskScheduler.h):
Input: method for list the tasks on schedule
Output: short description of scheduled task
Input: method for scheduling a new task
Output: post-condition of schedule operation
Log(SML_Log.h):
Input: method for retrieve the log (list)
Output: value of the log
HTTP Server, FTP Server, NetworkConfig?, Firewall, DHCP, DNS, Proxy(SML_Networks.h):
Input: methods for setting configuration
Output: post-condition reflecting the setting operation
Date Time(SML_DateTime.h):
Input: operations for creating date time, converting date time
Output: result date time

3.2 Performance Requirements

  • For System Monitor Module, the response time should less than the management application’s minimum sampling time interval (less than 0.5 second (Windows task manager), less than 1 seconds (Redflag Linux rftask) when ignoring the connection delay).
  • For slow hardware properties scanning, it should not cause the application stucking.

3.3 Design Constraints

  • The design of the SML should be based on C++ in Linux platform.
  • For the API that the SML depend on should be easily switched from one kind to anther kind
  • The SML should not exposure any CIM or the supplement API related information to the clients

Attachments