Flexibility for remote command processors

This article illustrates how the command processor of a remote node can be extended. The flexibility attained from such extension and its benefits are also discussed, and a solution is presented.

The essential role of a command processor

Generally, the purpose for which an application is intended determines its interface. Without loss of generality, we may assume that an interface is a command processor. The User Interface may take any form, such as graphical, vocal or some combination of future possibilities. Our focus is on the interface to the application’s engine rather than its user interface. The command processor of an operating system is usually called a shell, while the lower level interface is presented as a set of system calls.

We interact with a remote node, such as a satellite, through a local user interface. However, the actual interaction with the remote node takes place through its command processor. For all practical purposes the command processor of a remote node is a panel of hardware buttons like those on a stereo system.

Extending a command processor

When interacting with an operating system, such as UNIX, we have the luxury of enhancing the shell by adding new commands or entire applications. However, a remote node is not within our reach, unless it appears to us like a local operating system. For UNIX platform the X-Server does some of the latter.

The ability to extend a shell is simply an application of software flexibility versus hardware firmness. Thus, providing the same level of flexibility for the command processor of a remote node is more than plain curiosity. However, achieving a reasonable level of remote flexibility requires an infrastructure, somewhat like a universal operating system.

After some research we observe that for our purposes, a universal abstract operating system does not need to support the full functionality of an operating system that drives a desktop computer. For the sake of conversation, let Z47 stand for an abstraction of a universal operating system that can be deployed on satellites, PDA, mainframes, as well as desktop computers. Let us review the list of expectations from a Z47, which enables us to extend the command processor of a remote node.

Infrastructure for extending remote command processors

First and foremost we expect Z47 to provide us with an interface so we can compose applications (executables), just as we do for UNIX. However, at this era we expect a more formal and expressive language than scripting and interpreted languages. In particular, simple intuitive linguistic constructs should hide the complexity of routine matters like RPC and remote linkage.

Then, Z47 must handle the creation and management of its threads, processes and their intercommunication (IPC). Last but not the least, it should be possible to initiate a process on a remote node just as we are able to load and run executables on a desktop.

The last requirement, that is initiating a process on a remote node, is of particular interest. On a desktop, executables are kept on a permanent storage medium until needed, at which time they are loaded and executed. For a remote node, in our scenario, the local node acts like a storage medium. When needed, an executable is sent to the remote node and executed there.

Extensible command processor

A local node may send an executable to a remote node, and the executable may later request other executables to be uploaded. This makes the remote node appear as local for all practical purposes. Thus, the remote node is no longer an unchangeable black box with a fixed command processor. Instead, new executables can be launched on the remote node just they are launched on our desktop.

Repairing remote defects locally

Having a local node act like a storage medium for a remote node is quite useful. We can fix defects, or enhance components on the local node. In fact, the new version of a component may be uploaded directly, overlaying its previous version. This helps fix a problem found at a later time when the remote node is not physically accessible.

Sprinkling intelligence

An abstraction such as Z47 opens up the door to other desirable possibilities. For instance, so far as an operating system is concerned autonomous agents are applications. Whether or not an application is intelligent is internal to the application itself. The complexity of sending the executable to a remote node and initiating it must be transparent to the application and its developer. That is, it should not matter to the engineer where the actual execution occurs, and how messages are delivered to objects.

The solution

Clearly, Z47 will need a lower, device level operating system in order to interact with physical devices, such as UNIX, Windows, Palm etc. So long as interactions are properly formalized through linguistic patterns of the programming medium supported by Z47, an engineer does not need to deal with the actual operating system. That is the whole purpose of abstraction, and the power of its generality.

Now, Z47 is the processor that powers the Z++ abstract software development language. The relationship between Z47 and Z++ is like that of UNIX and C, except more abstract and thus considerably more general. Comparing Z++ to a language that runs on a virtual machine, like Java or C#, is a misunderstanding of the idea behind Z47 and Z++. As a matter of fact, Z++ as a programming language is a superset of C++, coherently combining the best of ADA, APL and Eiffel.

Conclusion

Z47 is a tiny distributed operating system, about 500K that captures all mechanisms needed for executing applications of any degree of sophistication. Z47 directly supports Z++ just as UNIX supports C. Thus, applications are developed abstract and independent of platform.

Applications composed in Z++ can move to any node in a heterogeneous network and begin execution. This capability provides the infrastructure for distributed components and mobile, or autonomous agents.

Z++ Visual is freely available from ZHMicro.