RNA Service Integration Design Document
Generic Database Service
Phase 2

Rationale: A database server running on an appliance still requires some administrative and initial configuration. This include initial "database" creation as well as user/permission accounts. This document describes our initial RNA interface to generic databases.


Many customers are asking for "database services" for our server appliances. This includes both the ISP and the SBS server product variations. Both products need access through the "ASP" services we currently offer, i.e. PHP, JSP and CGI.

Normally, a database would live on a server that is separate from the servers that contain the application and presentation (Web) layers. However, for a server appliance we will need to come up with a way of putting all the tiers on a single server platform. Note: This is a key selling point for our Immunix security technologies.

The database service offering will be introduced to our OEM customers in a series of phases. This will allow us to be quick-to-market, get early customer feedback, and limit the expense to build.

Phase 1 was complete with the ISP 2.0 product. Phase 3 is an ambitious project is beyond the scope of this document. This document will primarily describe "Phase 2."


Phase 2 has the following engineering requirements. These are based on customer and marketing feedback as well as engineering wish-lists.

Design Features

The RNA database service integration will follow standard development methods that have been previously employed. This section has two distinct parts: The top-level user interface and the underlying API that does the work of administrating database servers.

User Interface Design

This section describes the user interface design from the perspective of the menu structure placed under the Services menu. Each menu item listed references a "form sequence" described later.

Database Service Menu. The database service menu will contain the following structure:

Database Configure Forms

The first form will contain a listing of all database services available on the appliance. They will be listed in a series of "radioitem" elements with a short description of the advantages of the particular database. The user will select on database to continue. This initial form will display the status of each of the databases as to whether they are configured or currently running.

The second form will allow the user to set the DBA password for the database server.

We may detail other configuration values that are specific for the particular database server. We need a way for a "database-specific" form to be displayed.

Once the database is configured, it will be started (they will not initially be started immediately following installation).

List Databases Form

This form will simply display a table of all the configured database servers, their databases, the tables, and the roles (with permissions) for each database/table. For instance:

MySQL Database Server
bobbark_com BobBarker (All)
Customer table bobread (Select), bobwrite (Insert, Delete, Update)
Product table bobread (Select), prodwrite (Insert, Delete, Update)
Order table bobread (Select), bobwrite (Insert, Delete, Update)
CreativeFuse TinkyWinky (All)
Client table reader (Select), cliwrite (Insert, Update), clidel (Delete)
Service table reader (Select), cliwrite (Insert, Delete, Update)
PostgreSQL Database Server
gunsRus billyBob (All)
Products table reader (Select), cliwrite (Insert, Update), clidel (Delete)
Parts table reader (Select), cliwrite (Insert, Delete, Update)

Create Database Forms

The first form will have an initial field that specifies which of the configured database server the database should be created in. Note, if only one server has been configured, this field will not be displayed.

The first form will also allow the name of the database to be entered and checked for validity.

An initial role name (called DB Owner?) and password that will have ALL privileges to the database will be also on this first form.

An optional second form that is specific to a particular database may need to be displayed with the extra information given to the perl scripts for creating a database with special features (notice Oracle's variations of the CREATE DATABASE command).

Perl API Design

The RNA forms will eventually (after gathering user information) will call a perl script. These perl scripts will be designed using the new WireX Perl module structure. In other words, they will be simply shell wrappers that use "database-related" functions imported from a module.

We will create a WireX::DBAdmin module that contains a number of functions for accomplishing the tasks described in this document. Each function will take, as the first argument, a string that describes the database server to work with. For instance:

	WireX::DBAdmin::create_database("mysql", "customerX", "...");

Will simply be a wrapper for a MySQL-specific function located in another module, for example:


These modules will take advantage of our "Callback" infrastructure, however, these will not use the DOM config file modules since the database servers have a front-end command-line program that can be used for configuration.