The NetAlive System's Features

The following sections describe NetAlive's functions:

I. Intertasks and Self-Replication. Distribute applications among clients, servers, and peers, and manage communications between the parts of the application.

II. Development Environment. The NetAlive design tool helps write, debug, and install applications.

III. Communications Architecture (separate document). NetAlive's communcations system consisting of Netscape Client API (NCAPI) and direct Winsock access.

I. Intertasks and Self-Replication

An Intertask can self-replicate. This property lets NetAlive aid debugging and installation in a natural and powerful way. Consider how self-replication makes the following software tasks easy:

Network software development. Say a programmer is editing a network program. Once they change one character of source, they have created a new and unique program. To debug the program, the new program has to be sent to all the computers necessary to run it. If the program is an Intertask, the self-replication capability makes this happen naturally. The application starts on the developer's computer and expands by self-replication to all the other computers.

Agents. Say a buyer wants to find the most appropriate and lowest priced product to fit some need. To do this with agents, the buyer's computer sends an "agent" computer program to a database owned by a merchant. The agent scans the database and sends the result back. However, current operating systems are not set up to execute code received over a network. However, one can set up an Intertask with both the user's front-end and the agent code for the server. When the user requests a search, the Intertask self-replicates itself to the server. NetAlive addresses and automates key issues such as security and variable instruction sets.

Software management. Computer network applications have many parts that have to be managed together in order for the application to work. For example, a Web application typically has multiple HTML pages as a front-end and multiple CGI scripts as a back end. Furthermore, there may be variants of the application depending on the browser being used. If the software changes inconsistently, the application may fail. In contrast, an Intertask makes this all straightforward: the Intertask has the application's appearance and function for both client and server. Since everything is in one entity, the parts cannot separate easily.

How Does an Intertask Execute and Replicate?

For the technically-minded, here are the steps involved in Intertask execution (the document A NetAlive Application's Parts describes the components of an Intertask):

  1. To execute an Intertask, a computer loads the entire Intertask and then executes only those tasks whose address is the same as their network host name.
  2. If an interconnection would carry data to another computer, that data gets sent as a message. If necessary, an Intertask will replicate onto another computer before sending data to it.
  3. To replicate itself, an Intertask sends itself to another computer, which executes this procedure starting with step 1.

Say that the Intertask in the figure below starts on host A. Host A "executes" the text box because its address is that same as A's network address. Executing a task with a widget makes the widget visible, as shown on the screen on the lower-left.

When the finishes typing into the text box, NetAlive attempts to move text "123abc" through the interconnection. However, this interconnection leads to a task on another computer. So A sends a message to B saying "do you have version 1 of Intertask file:///c|/erik/net/" If B responds with "no" then A sends B the entire Intertask. Either way, A then sends the data "123abc."

Once B has the Intertask loaded, it receives data "123abc" and puts it into the list box.

How Does the Intertask Replication Work During Software Development?

Lets say the developer changes the Intertask in the example above. What makes host B load the changed Intertask rather than continue to use the one it has? The answer lies in the Intertask's version number. The design tool increments the version number when an Intertask changes. Thus, adjusting the GUI or changing a function increments the version number from 1 to 2.

Later A will send a message to B saying "do you have version 2 of Intertask file:///c|/erik/net/" When B gets this message it kills version 1 and responds with "no." It then gets version 2 and everything proceeds as expected.

II. Development Environment

NetAlive consists of a series of system programs for creating NetAlive entities and interpreting the NetAlive format. This series includes a "full product" (or design tool) and subsets of the full product. The rationale is as follows: A design tool needs to have a viewer in it to test a design. However, many end-users do not want a design tool in their viewer. This is because unused tool commands would create unwanted complexity. NetAlive addresses this issue through a series of products that cut out advanced features at various levels.

The full NetAlive system has six interface levels of progressively more complexity. The levels form natural subsets appropriate to different types of use. The most sophisticated users will need all six levels, less sophisticated ones need five levels, etc.

Each level corresponds to a view in the standard document/view architecture. As is common in the document/view architecture, most commands are accessible only through a view. Thus, disabling or removing a view disables access to its commands. The "button bar" has icons representing views in order of complexity. A user can switch to a particular level by punching the appropriate button.

Each subset of the full NetAlive system simply disables views above a certain level. Descriptions of the different levels appear below in order of increasing complexity (the graphic is the button switching to the level).

The document level shown below runs the application. This is the highest level in the mini-viewer version of NetAlive

The option settings level shown below is a dialog that accepts configuration information for the application. Higher levels control which information collected. For example, a news reader could use this level to let the user enter the name and password for their subscription to a news service. This is the highest level in the configurable mini-viewer version of NetAlive

The constrained replacement level presents a drag-and-drop GUI that changes the behavior of the document within tight constraints. For example, a news reader could use this level to customize the buttons under "sources." The user gets a palette with all the supported Internet news sources. They can drag any news source from the array and drop it on an icon corresponding to a "check box." This is the highest level in the full viewer version of NetAlive

The edit document level shown below displays the document in its final geometry with active resizing borders. This is the highest level in the graphical interface builder version of NetAlive

The Intertask level shown below displays both widget and functional tasks as icons of a standard size. Arrows show data dependencies. A GUI permits editing of the all attributes. This level presents a palette of tasks, but only higher level commands can change the palette. This is the highest level in the desktop publishing system for online media version of NetAlive

The task definitions level displays a dialog controlling the content of a specific task. This is the highest level in the Network Integrated Development Environment (Network IDE) version of NetAlive (often called a NetAlive design tool).

Explore Our Site

Common links:
Next Section Previous Section Parent Document
This is part 2 of a 5 part document:
Parts Features Security
Comparing NetAlive Platforms
This document was referenced from:
NetAlive Technology
For reference:
Home Page