Download GLADE User's Guide

Chapter 1: Introduction to Distributed Systems
3
1 Introduction to Distributed Systems
A distributed system architecture comprises a network of computers and the software components that execute on those computers. Such architectures are commonly used to improve
the performance, reliability, and reusability of complex applications. Typically, there is no
shared address space available to remotely-located components (that is to say, components
running on different nodes of the network), and therefore these components must communicate using some form of message-passing.
1.1 Using OS Network Services
There are several programming techniques for developing distributed applications. These
applications have traditionally been developed using network programming interfaces such
as sockets. Programmers explicitly have to perform calls to operating system services,
a task that can be tedious and error-prone. This includes initializing socket connection
and determining peer location, marshaling and unmarshaling data structures, sending and
receiving messages, debugging and testing several programs at the same time, and porting
the application to several platforms to uncover subtle differences between various network
interfaces.
Of course, this communication code can be encapsulated in wrappers to reduce its complexity, but it is clear that most of it can be automatically generated. Message passing
diverts developer’s attention from the application domain. The query and reply scenario is
a classical scheme in distributed applications; using message passing for such a scheme can
be compared to using a “goto” mechanism in a non-distributed application. This is considered unacceptable methodology in modern software engineering. A more robust design is
be to use a structured approach based on procedure calls.
In some respects, network programming can be compared to the multi-threading programming issue. The user can decide to split his code into several pieces and to multiplex
the thread executions himself, using a table-driven model. The scheduling code ends up
embedded into the user code. This solution is error-prone and fragile in regard to any
future modification. Relying on an implementation of threads such as provided in POSIX
is a better solution. Relying on language primitives that support concurrency, such as Ada
tasks, is best.
1.2 Using a Middleware Environment
A middleware environment is intended to provide high level abstractions in order to easily
develop user applications. Environments like CORBA or Distributed Computing Environment (DCE) provide a framework to develop client/server applications based on the Remote
Procedure Call model (RPC). The RPC model is inspired from the query and reply scheme.
In rough analogy with a regular procedure call, arguments are pushed onto a stream, along
with some data specifying the remote procedure to be executed. The stream is transmitted over the network to the server. The server decodes the stream, performs the regular
subprogram call locally, and then puts the output parameters into another stream, along
with the exception (if any) raised by the subprogram execution. The server then sends this
stream back to the caller. The caller decodes the stream and raises locally the exception if
needed.