A recursive model for distributed computing

The contemporary crude and ad hoc models for distributed computing are the main cause of defective and inadequate applications. The diversity of computing devices brings about great excitement, only to be followed by frustration and disappointment in trying to get an application up and running. So many companies start out with great ideas, and vanish soon after because their engineers cannot generalize the application to take advantage of the diversity of computing devices.

The notion of distributed communicating applications is abstract and therefore simple and general. The term abstract connotes lack of dependence to any particular platform. Thus, the abstract model presented through a language must be supported by a time and space efficient infrastructure for all devices and platforms.

The infrastructure (a virtual processor or machine) must be self-contained and only depend on well-established and universally supported standards. A virtual machine that depends on platform characteristics to support the facilities of its language promotes different subsets of the language, thereby creating inconsistencies and confusion. On the other hand, limiting the supported platforms as a means to reduce confusion is only to the advantage of the owner of those platforms.

The Z47 processor depends only on the following standards.

A C++ compiler for compiling the processor to the target platform.
A data transfer protocol support such as TCP/IP.

Beyond the two requirements listed above, the Z47 processor is completely self-contained. The Z++ language supported by the processor contains a threaded version of the entire language C++ as a small subset. In this article, however, we are only interested in distributed communicating applications.

For purposes of this discussion, we assume an application is properly designed with a set of API (application programming interface), or entry points. This is ideal even for applications with the GUI component comprising the bulk of their source. In other words, there has to be a set of entry points allowing access to the services of the core engine of an application.

The entry points of an application define the boundary to its services. For instance, a TV is a black box with the entry points of channel selector, volume etc. The TV user interface could be a remote controller or buttons on the box itself. The point is that, the user interface must interact with a set of API that defines the boundary of the functionality supported by what is inside the box.

In order to illustrate the recursive mechanism of component-oriented nature of Z++ we need to abandon the distinction between an entire application and the modules comprising the application. A component is an abstraction (black box) bounded by a set of entry points. An entry point is just a function specified as “entry”. However, a component cannot call its own entry points while other components can only call its entry points. This is a fundamental abstraction for component-oriented software development.

A component may provide services to a GUI, or become part of another larger component. As far as the Z47 processor is concerned, components can reside anywhere in the universe of computing devices. Each component simply calls the entry points of any other component, thus the terminology communicating distributed applications.

A function call in this context is usually referred to as sending a message. The Z++ model can be viewed as autonomous components passing messages to one another. The Z++ language hides all the details, instructing the Z47 processor how to pass messages among components, regardless of their physical location.

It should be clear that Z47 processor eliminates the need for data representation and transmission. The only statements visible at language level are function calls. However, we have not yet explained the recursive nature of component-oriented software development.

In Z++ language, a component X is introduced in another component Y as a class type. The entry points of X become the methods of this class, say CX. The component Y simply creates instances of the class CX, and invokes the methods. Exactly how these calls are invoked, data transmission and indeed the entire detail, is irrelevant from the perspective of component Y.

The recursion should be apparent now. Components become classes for other components. What may not be apparent is the fact that a component could be an entire application, such a spreadsheet. Indeed, different PDA devices, depending on their presentation capabilities, may define the spreadsheet class for their specific needs. The spreadsheet component will presumably reside on a larger machine.

Let us recapitulate the abstract model we have presented here. First, there is no distinction between an application and modules making up the application. We referred to either one simply as a component.

A component has a boundary comprising of its entry points. A component cannot invoke its own entry points, while other components can only invoke its entry points.

A component is used in another component as a plain class. The invocation of entry points of an included component is a simple method call, without regard to the physical location of the component.

The Z++ language is considerably more precise and expressive than its subset C++. Furthermore, Z++ can link with C++ dynamic libraries, such as DLL, in a manner analogous to Z++ components for SOA (service-oriented architecture) and similar applications.

Z++ is freely available from ZH Micro.