Design and Implementation
of the
RNAEngine^TM

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:

• Easy-to-use. A web-based system that is easy to use because of a simple organization of wizard-based forms.
• Scaleable. Beginning to advanced users can determine how much detail they wish to work with.
• Localizable. The text and entire look and feel can be altered for a particular language and country (locale).
• Customizable. Companies, other than WireX, can replace the WireX brand with their own in order to create a unique identity.
• Flexible and Extensible. New services and server applications can be configured by the RNAEngine.
• Secure. The RNAEngine was designed to ensure that accesses to the server are secure and the server is not compromised during those accesses.

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

• Style- Configuring the Look & Feel. The RNAEngine can be stylistically changed in order to create company branding for each OEM.
• Form- Defining the user interface. The RNAEngine is used to gather information from the customer that can be fed into back-end modules.
• Text- Isolating the text for localization. The RNAEngine makes localization easy for a particular language or country. This feature can also be extended to let different users receive different interfaces.
• Code- Configuring the back-end. The RNAEngine can be extended in order to control new services or other server applications.

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.

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.

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.

• Web based. Web-based products are considered easy to use because they have certain features similar to web sites, making the product easy to navigate even if you have never used it. If you have browsed web sites that are confusing and difficult to locate the information you need, you know a product is not easy to use simply because it is web based. There are other factors that affect the quality of web-based products. The RNAEngine utilizes many web technologies as well as clear graphic design and useability features.
  
  
• Wizard type button navigation. Users familiar with standard PC products are used to the concept of the Wizard, where the application asks some questions, let's the user click a "Next" button to go on to the next series of questions. The user can always change his/her mind by clicking on the "Back" button and re-edit previous questions. Navigation between the forms in the RNAEngine is built on the same Wizard concept, lowering the learning curve for the user.
  
  
• Configuration by Form Entry. The RNAEngine Interface is designed so that you simply need to fill out a form or a series of forms to configure a server. The interface is divided into particular actions you might be required to perform. Each action, such as "Adding a User," has one or more forms that you are guided through, complete with help links and tutorials along the way, if needed. When you Add a User, you must complete all the necessary forms before the user will be added; therefore no details are overlooked as is the case when you don't use the RNAEngine. Once you enter a sequence of forms, even though you have to fill out all the forms to complete the action, you can always exit the forms before you commit your changes.
  
  
• Menu driven. Menus make products easy to use because they divide actions the user has to perform into easy-to-understand categories. The categories can be subdivided even further. It is important that all the actions within a category have something in common so the user will always know where to look to find the pertinent information.
  
  
• Help. The Help Icon can be accessed from anywhere in the RNAEngine interface. When clicked, the help icon displays a complete help system, including an index, glossary and search function.
  
  
• Context-sensitive Help. Context-sensitive help is available for uncommon terms that might require a definition or an example. These terms are highlighted blue and underlined as are hyperlinks in a typical web browser. Simply click the link and a new help window will open with detailed information about the term.
  
  
• Online Tutorial. An on-line tutorial is available to guide you through the product for the first time. It introduces you to all the tips and tricks that you might need to soon become an expert user.
  
  

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.

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.

• Data Encryption. The RNA can not be accessed except through an encrypted SSL channel. With this, the privileged system administrator's sensitive data will not be seen by outside eyes.
  
  
• Data Verification. Some appliance companies only verify the source of data once at login time. This has left them completely open to IP Spoofing attacks, where a hacker can send commands to the machine from a machine posing as the system administrator. The RNA verifies the user's IP address at each transaction.
  
  
• Data Separation. Some appliance companies have their web-based administrative program run in the same space as the standard web server. This leaves it vulnerable to poorly written or malicious CGI programs running with the same privilege as the administrative program.
  
  The RNA runs in its own memory space on its own "web" engine. This engine runs as the "root" account, but does no other work. A separate web server is used to serve web pages.
  
  

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

• Technical writers should be able to do their work independent of engineers. They shouldn't have to wade through code in order to correct an engineer's poor grammar.
• Changing the look and feel shouldn't require changing the code. In other words, graphic designers shouldn't be drowning in code in order to change a table color.
• Engineers, when adding or altering services, shouldn't worry about look and feel, or worry about stylistic issues, etc.
• Engineers, when designing new services, should not have to alter other services.

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.

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, @menu.name@, 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:

• Changing the style doesn't alter the rest of the product.
• Companies can brand the product's interface.
• Multiple products can have different styles.
• Each user can have a different style.

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.

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:

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.

Conclusion

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.