Introduction
The OpenClovis SAFplus Platform Web Director is a web-based tool that helps manage clusters and chassis in telecom applications. This article gives an overview of the structure and functions of AWD.
What is the OpenClovis SAFplus Platform Web Director?
OpenClovis SAFplus Platform Web Director is a web-based cluster and chassis management system from OpenClovis Inc. It is designed to simplify and accelerate the development of Telecom application software over the OpenClovis platform. It provides a simple and powerful mechanism to examine and modify an online SAFplus Platform cluster to share critical chassis resources, install and manage new applications, and dynamically modify the SAFplus Platform Information Model.
The OpenClovis SAFplus Platform Web Director is also a “living” case study for customers to use when creating a web-based EMS (element management system) or network management glue layer. It can be easily rebranded to provide essentially an off-the-shelf EMS for SAFplus Platform deployments, customized to provide enhanced EMS functionality, or used as a reference when integrating OpenClovis SAFplus Platform into an existing EMS framework.
Organization
The following diagram shows the major functional blocks provided by the SAFplus Platform Web Director.
The complete AWD package includes everything above the red curve that denotes the Python/C boundary. Above the red curve, blue boxes denote software created by OpenClovis while brown boxes show the free open-source software that the AWD utilizes.
For explanatory purposes, the fundamental components of your cluster are shown below the red curve. These include the OpenClovis SAFplus Platform (required), HPI (optional and it is bundled with SAFplus Platform), a SQL database, and Linux (or other OS supported by SAFplus Platform).
- SAFplus Platform Web Director
The SAFplus Platform Web Director itself is a thin layer that simply implements the GUI look and feel and calls the underlying APIs. It uses the TurboGears web application framework and templating system to serve particular web pages. To facilitate rebranding, customization, and extensibility, this layer is carefully constructed to contain only the web logic and not any SAFplus Platform functionality.
- Software Management
The software management layer consists of APIs that handle software deployment onto any node, software bundle and version management, and in-service software upgrade (ISSU). This layer uses the Object Access Layer to access the SAFplus Platform middleware and Linux services to deploy software.
- Object Access Layer
This set of APIs presents the cluster Information Model as a set of objects and methods, instead of presenting it functionally as occurs in the lower layers.
a. ClusterInfo
The ClusterInfo library presents the AMF Information Model (both configuration and current state) as a set of objects. Since the Information Model naturally consists of objects (Service Groups, Service Units, and Components for example) this abstraction greatly simplifies the effort required to access the data. Also included are routines that create internally consistent groups of Information Model entities. For example, a single function call will return a complete SAF Service Group hierarchy (Service Group, Service Unit, Components, Service Instances, and Component Service Instances) for a new application that is both internally consistent and consistent with the existing Information Model. This set of objects is not yet installed into the system, allowing you to tweak and modify their configuration before “committing” the group.
b. AspAmf
The AspAmf library contains all functions that modify the AMF Information Model. These functions are tightly integrated with the ClusterInfo entities and encapsulate a tremendous amount of functionality as compared to the underlying functional interface. For example, modifying the Information Model to implement common operations such as adding or removing a Service Group can require hundreds of function calls at the AMF layer. However, this can be done in a single AspAmf API call called “InstallApp”. This single call takes as a parameter a list of AMF entities, and (from the user’s perspective) it simply adds them into the AMF Information Model. But actually doing so is not so simple! The function ensures that the entities are created if they do not exist, or modified to match a new configuration if they already exist. It also ensures that the entities are created in the proper order and that they correctly reference each other and existing objects within the Information Model. The end result is a very simple API to accomplish a complex task. The AspAmf library also contains APIs to query entity states and start and stop them.
c. AmfPy
The amfpy library allows a Python program to register itself as an AMF component and therefore receive AMF component control callbacks (start, stop, CSI assignment, etc). Both extending and embedding are supported — that is Python can either be embedded as a small interpreter into an SAFplus-aware C program, or it can be run standalone and the amfpy functionality can be “imported”. Python programs can either be spawned automatically by the AMF’s component manager or can be run from the command line (using the asp_run tool provided by the SAFplus Platform) and register with the AMF dynamically.
d. SWIG Interfaces
Most OpenClovis SAFplus Platform functions are directly available at the Python interpreter using an automatically generated Python-to-C translation layer. However, it is often inconvenient to use these functions since they correspond one-to-one with equivalent C functions. Additionally, if the function uses complex pointer or object relationships (such as forced casting of pointers) it is sometimes very difficult or even impossible to express the parameters in a type-safe language like Python. Therefore it is recommended that this layer only be used if the functionality does not exist in the higher layers.
Conclusion
By leveraging a full set of APIs of the OpenClovis SAFplus Platform Web Director, the integrators, designers, and system architects can easily develop Telecom application software over the OpenClovis platform. AWD also provides simple and powerful mechanisms to manage and deploy elements in a cluster. If you need to know details about AWD don’t hesitate to reach out to us at support@openclovis.org