Mapping Distributed Communicating Processes
Introduction
In this article we will demonstrate that an end-to-end enterprise business automation cannot be mapped to a set of computing devices, such as desktops, servers, handheld and specialized devices based on individual operation systems, virtual machines and the client-server model.
The computing model for an end-to-end distributed automation of business functions is Distributed Communicating Processes (DCP). To illustrate the model, consider the UNIX operating system with regard to processes, threads and their communication (IPC). Suppose you write the entire enterprise software for the UNIX operating system, but that the processes and threads are created on a heterogeneous network of computing devices such as UNIX, Palm, and Windows etc.
In this view, the computing devices comprising the network are merely power sources for executing the software. On the other hand, engineers develop the software in the same vain as one writes C++ software for execution on a single UNIX box.
In this article, we will also illustrate how Z47 technology provides the infrastructure for developing device-free end-to-end distributed enterprise software. That is, Z47 is a mapping of DCP to a network of heterogeneous nodes.
DCP is an abstraction for a computation model, and as such it can only be discussed linguistically. In other words, a linguistic formalization, such as Z++, is the only means of materializing an abstract model. On the other hand, Z47 is a transparent mapping that powers the execution of software developed in Z++.
The Prevailing Problem
The main software of most large corporations is still written in COBOL, assembly and a large number of macros in a variety of macro languages. The desktops are generally used for a GUI presentation of the main programs. Often, desktop software is written in Visual BASIC, Java, C++ and so on.
Due to the lack of expressiveness of the languages for distributed computing, the desktop software is plagued with a large number of gluing technologies and third party libraries. In particular, each time a new technology is added to the ailing software, the complexity rises exponentially. This simply follows from the fact that the new technology needs to interact with many of the existing ones.
One scenario for eliminating unnecessary cost of maintenance would be to rewrite the software utilizing computing devices of all sizes and shapes, including laptops, desktops, servers and a variety of handheld devices. In this scenario applications that comprise the automation of enterprise functions become processes running on computing devices scattered all over. These processes will be interacting in complex ways, communicating, signaling while exceptions may be occurring at one end that need to be handled at some other end. Thus, the model for end-to-end enterprise automation is DCP.
The Mapping Problem
What we are going to make clear is that the DCP model cannot be mapped onto a set of standalone operating systems, languages based on virtual machines and the gluing technologies.
Consider a modern computing device powered by UNIX Operating System (OS). The functions of an OS relating to an application can be divided into two main categories. First, the OS acts as a sophisticated device deriver managing file system, keyboard and other input devices, as well as the screen and other output devices. This category is usually standardized through libraries such as C++ stream libraries.
The other category comprises of support for developing complex applications, including the creation of processes, threads, Inter-Process Communication (IPC) and signaling. The OS functions in this category are intimately bound to the OS. In fact some OS (particularly handheld devices) lack some of these functions. This is why C++ does not attempt to standardize this category. Instead, one utilizes OS system calls.
A successful, and limited form of distributed computing is modeled based on the ability of OS to send and receive data from external hosts. This is known as the client-server model. In this model, the server is started first, and clients connect to it for its specialized services. Let us see why the client-server model cannot directly support the DCP model.
In client-server model each server can become a client for another server. However, it is important to note that all servers must already exist so clients can connect to them. On the other hand, in DCP model parent processes recursively create new child processes and threads, rather than connecting to already existing servers.
The impossibility of mapping the DCP model follows from the fact that a process on one UNIX box cannot create a child process on another UNIX box and interact with it as it does on the same box. The problem becomes more visible when the other box is not UNIX. Note that all processes of an operating system have resources associated with them, and in particular each process receives a slice of time for its execution.
The Starting Point for a Solution
As far as an engineer is concerned, solutions for automating business functions are expressed in a language. Therefore, any approach to providing a DCP model would have to be top-down. First, there must be an expressive language for stating solutions, then an engine to provide the execution power for the statements in the language.
If we start with a virtual machine and design a language around it, our language will be bound to the capabilities of the virtual machine rather than the issues of DCP. Indeed, virtual machines suffer from the same problem as individual operating systems in that a process on one computing device cannot create a child process on another computing device. Since that is exactly what we need for the DCP model, it is easy to see why a bottom-up solution furnished by virtual machines is essentially useless.
Let us emphasize the main issue. A complex application on a single computing device needs to create child processes, threads and allow for interactions among them. In the same vain, an end-to-end enterprise application needs to create child processes and threads on any computing device while allowing for their interactions.
In short, an enterprise application must appear to an engineer as an application running on a single operating system. The computing devices scattered all over are to be viewed simply as sources of power, like batteries Furthermore, a distributed application need not be aware of the type of the devices, nor their being replaced. The latter means that an application should not even need a rebuild when we replace a device in the network.
The Technological Infrastructure
From what we have said so far, it should be clear that DCP model needs a true distributed operating system. Exactly what do we mean by a distributed operating system?
We mentioned earlier that an OS provides two main categories of services for applications. The file system and more generally IO devices can be dealt with via standardization. However, one cannot impose a standard on process and thread creation. Indeed, OS for many handheld devices is closer to a sophisticated device driver and lacks such notions. This creates an impasse for mapping a language for distributed computing on the OS of individual computing devices.
Furthermore, it should be clear now that a distributed operating system must allow for the creation of processes independent of the OS that controls a computing device. The processes of an OS controlling a computing device are bound to that OS. In other words, a distributed operating system must be self-contained in its services for creating processes, threads, IPC and other inter-process operations such as signaling.
Suppose such a self-contained OS is running on each computing device in a network. Then, a process can start off on one device, and create a child process on any other device because these are processes of the distributed OS. At language level the engineer will see the entire application executing on a single operating system while in fact child processes and threads of the application may be running on many different physical computing devices.
The Z47 processor is a self-contained distributed operating system that manages its own processes, threads and their interactions. The self-contained is actually the required criterion. For instance, an application running on Palm cannot create a process on a device running UNIX. Indeed, Palm OS is oblivious of the notion of process. However, an application written in the language Z++ becomes a process of Z47, not the underlying OS. Thus, a Z++ application for Palm can create Z47 child processes on Palm, Linux, Windows or any other OS controlling any device in the network.
The Z++ Language
As complex as it may be, C++ is the most expressive language. Nevertheless, C++ engineers need to fall back on system calls when developing applications. The first conclusion is that, C++ is a system programming language. This means that one develops an application for a particular OS powering a computing device. The second conclusion is that a language less expressive than C++ is not expressive enough for building complex applications thereby resulting in lengthy and hard to maintain programs.
Z++ evolves C++ to a language for distributed computing while enhancing the expressiveness of C++ even for building standalone applications. Z++ presents its linguistic constructs for distributed computing, as well as component-oriented development as minimal extensions to the notion of class. Furthermore, the actual details of creating processes and threads are abstracted away within the automation provided by the compiler.
A Z++ engineer sees the entire enterprise software as a set of components. Each Z++ component is also a standalone executable, and therefore a Z47 process. Since components can start on any computing device within the network, this satisfies the conditions for a true DCP model as needed for automating end-to-end enterprise business functions.
Beyond Distributed Computing
The ability of a Z47 process to create child processes on any computing device in a network provides the infrastructure for Distributed Communication Processes. However, Z47 processes are also capable of moving from one physical device to another.
The movement of a process can be illustrated as follows. A process loses its execution time-slice on one computing device, and later it receives its time-slice on a different computing device.
Z47 process movements are entirely transparent at Z++ language level except for telling the application where to go to, and when. The interpretation of process movement at application level is known as strong mobility. This is because the application travels to another device maintaining its entire state as if it had been executing all along on the device at which it arrived.
The automation of strong mobility paves the way for future intelligent software known as autonomous agents. A Z++ agent, for instance, can take off from Palm and land on a Linux box, and later travel to a Windows box, etc.
In this article we will demonstrate that an end-to-end enterprise business automation cannot be mapped to a set of computing devices, such as desktops, servers, handheld and specialized devices based on individual operation systems, virtual machines and the client-server model.
The computing model for an end-to-end distributed automation of business functions is Distributed Communicating Processes (DCP). To illustrate the model, consider the UNIX operating system with regard to processes, threads and their communication (IPC). Suppose you write the entire enterprise software for the UNIX operating system, but that the processes and threads are created on a heterogeneous network of computing devices such as UNIX, Palm, and Windows etc.
In this view, the computing devices comprising the network are merely power sources for executing the software. On the other hand, engineers develop the software in the same vain as one writes C++ software for execution on a single UNIX box.
In this article, we will also illustrate how Z47 technology provides the infrastructure for developing device-free end-to-end distributed enterprise software. That is, Z47 is a mapping of DCP to a network of heterogeneous nodes.
DCP is an abstraction for a computation model, and as such it can only be discussed linguistically. In other words, a linguistic formalization, such as Z++, is the only means of materializing an abstract model. On the other hand, Z47 is a transparent mapping that powers the execution of software developed in Z++.
The Prevailing Problem
The main software of most large corporations is still written in COBOL, assembly and a large number of macros in a variety of macro languages. The desktops are generally used for a GUI presentation of the main programs. Often, desktop software is written in Visual BASIC, Java, C++ and so on.
Due to the lack of expressiveness of the languages for distributed computing, the desktop software is plagued with a large number of gluing technologies and third party libraries. In particular, each time a new technology is added to the ailing software, the complexity rises exponentially. This simply follows from the fact that the new technology needs to interact with many of the existing ones.
One scenario for eliminating unnecessary cost of maintenance would be to rewrite the software utilizing computing devices of all sizes and shapes, including laptops, desktops, servers and a variety of handheld devices. In this scenario applications that comprise the automation of enterprise functions become processes running on computing devices scattered all over. These processes will be interacting in complex ways, communicating, signaling while exceptions may be occurring at one end that need to be handled at some other end. Thus, the model for end-to-end enterprise automation is DCP.
The Mapping Problem
What we are going to make clear is that the DCP model cannot be mapped onto a set of standalone operating systems, languages based on virtual machines and the gluing technologies.
Consider a modern computing device powered by UNIX Operating System (OS). The functions of an OS relating to an application can be divided into two main categories. First, the OS acts as a sophisticated device deriver managing file system, keyboard and other input devices, as well as the screen and other output devices. This category is usually standardized through libraries such as C++ stream libraries.
The other category comprises of support for developing complex applications, including the creation of processes, threads, Inter-Process Communication (IPC) and signaling. The OS functions in this category are intimately bound to the OS. In fact some OS (particularly handheld devices) lack some of these functions. This is why C++ does not attempt to standardize this category. Instead, one utilizes OS system calls.
A successful, and limited form of distributed computing is modeled based on the ability of OS to send and receive data from external hosts. This is known as the client-server model. In this model, the server is started first, and clients connect to it for its specialized services. Let us see why the client-server model cannot directly support the DCP model.
In client-server model each server can become a client for another server. However, it is important to note that all servers must already exist so clients can connect to them. On the other hand, in DCP model parent processes recursively create new child processes and threads, rather than connecting to already existing servers.
The impossibility of mapping the DCP model follows from the fact that a process on one UNIX box cannot create a child process on another UNIX box and interact with it as it does on the same box. The problem becomes more visible when the other box is not UNIX. Note that all processes of an operating system have resources associated with them, and in particular each process receives a slice of time for its execution.
The Starting Point for a Solution
As far as an engineer is concerned, solutions for automating business functions are expressed in a language. Therefore, any approach to providing a DCP model would have to be top-down. First, there must be an expressive language for stating solutions, then an engine to provide the execution power for the statements in the language.
If we start with a virtual machine and design a language around it, our language will be bound to the capabilities of the virtual machine rather than the issues of DCP. Indeed, virtual machines suffer from the same problem as individual operating systems in that a process on one computing device cannot create a child process on another computing device. Since that is exactly what we need for the DCP model, it is easy to see why a bottom-up solution furnished by virtual machines is essentially useless.
Let us emphasize the main issue. A complex application on a single computing device needs to create child processes, threads and allow for interactions among them. In the same vain, an end-to-end enterprise application needs to create child processes and threads on any computing device while allowing for their interactions.
In short, an enterprise application must appear to an engineer as an application running on a single operating system. The computing devices scattered all over are to be viewed simply as sources of power, like batteries Furthermore, a distributed application need not be aware of the type of the devices, nor their being replaced. The latter means that an application should not even need a rebuild when we replace a device in the network.
The Technological Infrastructure
From what we have said so far, it should be clear that DCP model needs a true distributed operating system. Exactly what do we mean by a distributed operating system?
We mentioned earlier that an OS provides two main categories of services for applications. The file system and more generally IO devices can be dealt with via standardization. However, one cannot impose a standard on process and thread creation. Indeed, OS for many handheld devices is closer to a sophisticated device driver and lacks such notions. This creates an impasse for mapping a language for distributed computing on the OS of individual computing devices.
Furthermore, it should be clear now that a distributed operating system must allow for the creation of processes independent of the OS that controls a computing device. The processes of an OS controlling a computing device are bound to that OS. In other words, a distributed operating system must be self-contained in its services for creating processes, threads, IPC and other inter-process operations such as signaling.
Suppose such a self-contained OS is running on each computing device in a network. Then, a process can start off on one device, and create a child process on any other device because these are processes of the distributed OS. At language level the engineer will see the entire application executing on a single operating system while in fact child processes and threads of the application may be running on many different physical computing devices.
The Z47 processor is a self-contained distributed operating system that manages its own processes, threads and their interactions. The self-contained is actually the required criterion. For instance, an application running on Palm cannot create a process on a device running UNIX. Indeed, Palm OS is oblivious of the notion of process. However, an application written in the language Z++ becomes a process of Z47, not the underlying OS. Thus, a Z++ application for Palm can create Z47 child processes on Palm, Linux, Windows or any other OS controlling any device in the network.
The Z++ Language
As complex as it may be, C++ is the most expressive language. Nevertheless, C++ engineers need to fall back on system calls when developing applications. The first conclusion is that, C++ is a system programming language. This means that one develops an application for a particular OS powering a computing device. The second conclusion is that a language less expressive than C++ is not expressive enough for building complex applications thereby resulting in lengthy and hard to maintain programs.
Z++ evolves C++ to a language for distributed computing while enhancing the expressiveness of C++ even for building standalone applications. Z++ presents its linguistic constructs for distributed computing, as well as component-oriented development as minimal extensions to the notion of class. Furthermore, the actual details of creating processes and threads are abstracted away within the automation provided by the compiler.
A Z++ engineer sees the entire enterprise software as a set of components. Each Z++ component is also a standalone executable, and therefore a Z47 process. Since components can start on any computing device within the network, this satisfies the conditions for a true DCP model as needed for automating end-to-end enterprise business functions.
Beyond Distributed Computing
The ability of a Z47 process to create child processes on any computing device in a network provides the infrastructure for Distributed Communication Processes. However, Z47 processes are also capable of moving from one physical device to another.
The movement of a process can be illustrated as follows. A process loses its execution time-slice on one computing device, and later it receives its time-slice on a different computing device.
Z47 process movements are entirely transparent at Z++ language level except for telling the application where to go to, and when. The interpretation of process movement at application level is known as strong mobility. This is because the application travels to another device maintaining its entire state as if it had been executing all along on the device at which it arrived.
The automation of strong mobility paves the way for future intelligent software known as autonomous agents. A Z++ agent, for instance, can take off from Palm and land on a Linux box, and later travel to a Windows box, etc.
Labels: client-server, distributed applications, Distributed Communicating Processes, distributed operating system, distributed software, UNIX, virtual machine, Z++, Z47
posted by Dr.Z. at 9:40 PM
0 Comments:
Post a Comment
<< Back to Blogger Start Page >>