Confidential WireX Whitepaper

Design and Implementation
of the

This white paper describes the design and implementation of the RNAEngine™. It assumes the reader is familiar with server appliances and web technologies. This document is confidential to WireX.

Executive Summary

The RNAEngine is a web-based administration system that effectively takes a standard Linux server and converts it into a server appliance. It is easy-to-use, localizable (internationalized), customizable and extensible. This document describes the application in detail.

The first section of this document, the RNAEngine Interface, covers advantages of using the RNAEngine:

The second section, the RNAEngine Design, provides additional design details of the RNAEngines' four major modules:

RNAEngine Interface

When it comes to web-based server administration, appearance means a lot. A user with no server administration experience (and possibly minimal general computer experience) may need to change network settings, add a user account, or view web statistics. All of these can be daunting tasks for an inexperienced user. The RNAEngine was designed to make the customer's experience with these tasks simple.

Design Objectives

Following are key design objectives that make using the RNA interface a simple experience for our customers. The design allows a novice user can perform tasks without spending a lot of time learning how to navigate the interface. If you can navigate around the Internet, you can use the RNAEngine.

Easy to use

The RNAEngine was designed to convert general-purpose servers into server appliances, and as such, it was designed for the novice user. The list below highlights features that make the RNAEngine Interface easy to use.


Each person using the RNAEngine has a different background of computer experience. While the RNAEngine's interface is simple enough for a novice, the user can select his own preference level, i.e. Basic, Detailed, or Expert. The Basic mode shields the user from the details of the Operating System. The Detailed mode contains moderate shielding. The Expert mode contains no shielding at all.

This concept can be extended so that different users of the system have different menu selections. The system's administrator has complete access to all menu selections, while an owner of a domain (a virtually hosted domain administrator) or a regular user with only an email account, has access to different menus and different forms based on the user's permissions.


The language of all text presented to the user is sensitive to the web browser default language settings; therefore, users are not required to do anything special to see the product display text in their own language. Quite often, programs require users to select their language preferences during the installation of the product, but the RNAEngine Interface works seamlessly with the user's web browser. Users do not have to wade through an unknown language to change their language settings.


The RNAEngine can be customized for your company by using your company's own colors and logo. The product has been designed to be robust, yet versatile engine that fits inside an infinite number of packages.

The look and feel of the RNAEngine is determined by a collection of images and HTML files. These files contain none of the product functionality and receive their design instructions dynamically from the RNAEngine. By separating the design and stylist elements (images, graphics, layout) from the text and code OEMs can brand or customize the front-end style without having to rework the other entities.

The layout of the forms within the RNAEngine is also flexible. Forms can be reordered or fields can be added to the RNAEngine without affecting the style, code or text (which could be in many different languages) because the layout of the forms and fields are separated from the code, text, and design.

Flexible and Extensible

The RNAEngine is unique in that it can be used to enhance your own services and server applications and it integrates seamlessly with these products. This means that not only can you brand the RNAEngine to give it a similar look and feel as your other products, but you can also utilize it as an extension of your other products. The smooth transition from your product to the RNAEngine will leave users feeling as though they have never exited your product. It can distracting and confusing for users to be jolted from environment to environment within the same product. The RNAEngine overcomes these obstacles by integrating an OEM's products with a consistent interface.


The RNAEngine was designed from the start to be secure and less vulnerable to outside attacks.

RNAEngine Design

High level goals established when the RNAEngine was being designed are:

To achieve these goals (and the interface design goals), the RNAEngine internals were organized into a modular design, where each module works in its own world, but has an interface into the other modules. The RNAEngine integrates these modules into a consistent whole.

Like pieces to a puzzle, each module has hooks into the engine, but still has a distinct form and function. The four component modules are described in the following section.

Style Component

The look and feel is determined by a collection of HTML files. Where a single HTML file, instead of displaying a complete web page, now displays only one small piece of a greater whole. For instance, menu_topopened.html contains only the HTML code to render the top-level menu entry when that menu entry is opened. Another file, menu_topclosed.html contains the HTML code to render the same menu entry when it is closed. See the illustration at the right.

While one of these HTML files describes a single section of a page, that section may be used many times. For instance, our previous example of menu_topopened.html contains code to display each top-level menu entry.

In the actual HTML file, are tags where the RNAEngine substitutes text and icons before rendering the file. For instance, when rendering a top-level menu entry file, we would look through the file until we came across the tag,, and substitute it with the word, System before displaying it.

There are thousands of tags and messages to go with them. Each word, phase, and picture is substituted. This not only helps isolate the look-and-feel, i.e. you can change how the menu entry is displayed without worrying about the individual menu entries themselves, but it helps in localizing the text.

Style Files

In the example style file below, you will notice some of the tags are used as place-holders to substitute text or other data.

Another feature is the ability to display browser-specific code. Every web designer knows how difficult it is to display a web page correctly on every browser, yet still make it look good. The RNAEngine has a number of different HTML-like tags that specify when to display HTML code for Internet Explorer, as opposed to Netscape. The result is a beautiful display on any type of browser.

Style Advantages

Isolating the look-and-feel into specific style files has the following advantages:

Form Data Component

The RNAEngine gathers input from the user through a collection of forms that have been organized as a wizard, i.e. with a "Next" and "Back" button.

However, to be truly a wizard, the "Next" button must be able to dynamically choose the next form based on the user's selection. For instance, why ask the user details on their firewall, if the firewall was not enabled?

Because of this dynamic order of the forms, the RNAEngine aids the engineer in automatically handling the "Back" button.

Each of these forms is "display independent" ... this means that an engineer simply asks for a particular type of field, he/she doesn't worry about how that field looks, or how that field interacts with the user. This also helps the engineer who develops the back-end code, because this engineer doesn't have to deal with any user-interface issues, he/she just expects a collection of data fields.

In the following illustration, you can can see that we start with one form that contains a radio button. If the first one is selected, then we go to the top form, if the second one is selected, we go to the form in the middle, etc.

The forms labeled, Departmental and Collocated have redundant information. There is no reason to list them twice, and it is difficult to maintain them if you do. Instead, we will store those redundant fields in a separate form that will be included into these other forms.

This illustration is meant to give a rough idea of how a complex sequence of forms can be designed on a whiteboard and implemented fairly easily using Form Data Files (RFF).

Form Data Files

A Form Data File (RFF) is simply a description of how a single form should be displayed. Mainly this is a collection of fields, where each field is completely (but abstractly) described. The rendering of the form is done by the RNAEngine.

In the following illustration, you will notice the simple format. Each line is simply described as a series of variable=value lines. Each form has two sections, the first (global) section describes the form as a whole. It contains the form's title and intial paragraph (that we refer to as the help paragraph). This section usually contains the "next" file. This can be either a form file, or a perl script to "do some work."

The next section describes each of the fields. Each field has a name, a descriptive help paragraph, a statement telling the RNAEngine what type of field it should be (e.g. a text field, a radio button, a pull-down menu, etc.).

These fields can also have specified what kind of data it can contain, e.g. a date, a number, an IP address, etc. When the user presses the "next" button, these variable will be evaluated for valid syntax.

It would be nice if when the user leaves a field, we evaluated the field for correctness, or if some value is entered into one field, another field is calculated and modified. This can be done with JavaScript, and JavaScript snippets can be embedded into the form file.

Forms and fields are most often described using static form files, however, just like the web requires dynamic web pages, forms can be described dynamically using Perl scripts or Java beans.

Text Component

The RFF is a powerful way to represent a form. However, these files contain both text descriptions as well as what would be considered "code," i.e. JavaScript code, default values from a perl script, etc. Another problem is when the product is handed over to a translation firm to make a version available for the Chinese market. This firm may or may not realize what parts they should translate. For instance, if they see the following line:

	default=`perl /usr/bin/userlist --get name`

Should they translate the word "name" or not?

A better solution is to use the tag-mechanism used by the style module. First, we create a resource property file that contains text messages. Each message is given an arbitrary name. We can then use these named messages later.

Note: In the following example, you can contain HTML code in order to help the layout and markup of the text messages. Also, you will notice a link into the help system.

Shipping to a new locale simply involves translating the resource files. No code needs to be modified, and the text that needs translating is clearly known.

Now let's take a look at our previous RFF file, and see how it changes now in order to take advantage of this localizable feature. Wherever there is a text message, we remove it and place it into a resource property file, name it, and place the name as a tag in the form file:

Code Component

The last component is the muscle that does the actual work of administrating the system. The previous components were concerned about the user's experience of entering in the data that we need in order to "do some work." Now it is up to the code component to actually "do the work."

In the following illustration, notice on the left a collection of RFF form files that will gather data from the user. The RNAEngine takes these entries and passes them to the Perl script (on the right) as part of the environment variables. The script then executes based on the values passed to it.

Normally, the last form calls a Perl script to do the work; however, depending on the job, a Java class could instead be automatically loaded and executed by the RNAEngine. Each of these approaches address different needs, the determination of which is best left up to the developers.

Extending the Appliance

Extending the RNAEngine to configure a new service or server application is a fairly straight-forward series of tasks:

  1. Build, integrate or license a Red Hat-compatible Linux application or service.
  2. Create configuration scripts.
  3. Create form files to gather user input
  4. Extend a "menu" file to call the initial form.
  5. Create localizable resource property file to contain all the text.
  6. Build an installable RPM.


The RNAEngine is a powerful way to turn a standard server into a server appliance. It is powerful in that different teams with different abilities can concentrate on their domain.

It is powerful, in that adding new services and server applications is a simple process. No special tools are needed to do this. It is also powerful, in that The RNAEngine itself can be extended through a Java interface.