Client-Server Development
Volume Number: 14
Issue Number: 11
Column Tag: Viewpoint
Client/Server Development based on the Apple
Event Object Model
by Sascha Kratky and Christoph Reichenberger (UNI SOFTWARE PLUS)
Edited by Richard Clark
Using AEOM for the design and implementation of the
VOODOO client/server system
The term "Client/Server System" has become one of most used terms in today's
computing world. We use client applications practically every day to transfer
incoming emails from mail servers, download files from FTP servers, or to browse
HTML pages offered on web servers all over the world.
Developers have chosen the client/server architecture as a reasonable means to
structure large software systems, in order to make them leaner, more efficient, and
easier to maintain. The basis of every client/server system forms the protocol that the
client and the server applications are using to communicate with each other. For some
applications like file transfer, mail transfer or hypertext transfer, there are
well-known standardized protocols (e. g. FTP, SMTP, or HTTP) which remove the
burden of having to design a proprietary protocol from scratch. Other areas, such as
software version control, lack standardized protocols.
This article deals with the design and implementation of a protocol for a client/server
based software version control system. It starts with a discussion of the basic
properties of client/server systems. It explains why we chose to design and implement
the protocol for the VOODOO client/server system on top of the Apple Event Object
Model. A section on the problems that the developer faces when implementing a
client/server system on top of the Apple Event Object Model concludes the article.
Client/Server Systems
The term "Client/Server System" refers to a general software architecture which can
be applied to a variety of different applications. Most discussions of client/server
systems take for granted that we are aware of the advantages that arise from using a
client/server-based system. It may be worthwhile to recall the encouragement that
originally led to the widespread use of client/server systems. A main motivation for a
client/server system is that it provides an elegant solution for applications that need
concurrent access of many clients to the same data. This simultaneous access problem
is sketched in Figure 1.
Figure 1. In a non client-server system, multiple clients may access the same
resource concurrently.
In this scenario clients access a database concurrently on the file system level. The
database is usually stored on a file server machine on the network and clients have to
mount the database in order to access it. This results in the following shortcomings:
• All clients make concurrent changes to parts of the database. To avoid
modifying parts of the database that are currently in use by another client, the
clients have to implement a file system-based locking mechanism.
Nevertheless, an unexpectedly interupted client process may leave the
database in an unstable state. The consequences are higher chances of database
corruption and the loss of valuable data.
• Every client application must have full knowledge of the external
representation of the database. A change to this representation means that all
client applications have to be upgraded as well.
• Propagating changes one client has made to the database to the other
clients currently working on the database is difficult and unreliable. Every
client would have to constantly poll the files of the database for changes made
by other users in the meanwhile.
Interestingly enough, many commercial systems that claim to be truly
client-server-based still follow this "file-server" approach and therefore suffer
from the previously-mentioned drawbacks.
In a real client/server-system the clients do not access the database directly but get
the needed data by sending requests to a server application, which is the only process
that directly accesses the database (Figure 2). Instead of mounting the remote