Contents |
Overview
The following diagram show 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).
Architecture Block Descriptions
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.
All subsequent sections describe the APIs available to any application. These APIs are described in detail in the SAFplus Platform Web Director API document.
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.
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.
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 state and start and stop them.
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 is 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 "import"ed. 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.
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.