ClientServer Database
Volume Number: 11
Issue Number: 6
Column Tag: Client/Server Databases
Client/Server Database Development
A review of the technologies behind a revolution
By Liam Breck, Northampton, MA
Note: Source code files accompanying article are located on MacTech CD-ROM orsource code disks.
What’s the Buzz?
Client/Server Computing is one of the industry’s hot buzzwords today, but just those
two words alone don’t provide enough context for a specific discussion. Client/server
is a very general software architecture that can be applied to a vast range of software
missions. But if you overhear business execs talking about client/server, chances are
you’ll hear about SQL servers in the same conversation. What are they really talking
about? The mundane world of corporate database management. Only it isn’t so mundane
anymore
A great wave of change is swelling at the very heart of the computer industry
where big iron has held sway and users have been stuck in front of mouseless,
monochrome terminals. Mini-computers and even Unix workstations are encroaching
on mainframe turf, while personal computers with a GUI are replacing the terminals.
What’s driving this trend are client/server database (hereafter CSDB) systems based
on a common query language and standardized communications protocols, which allow
unprecedented diversity in large information systems.
In this, and articles that will hopefully follow in future issues, I’ll be discussing
the software components of CSDB systems, with a close eye on the development tools
used in this field. This month I offer a general overview of the field, without
discussing product specifics. If you are eager for specifics, examine the references at
the end of the article, which points to places where they can be found. [Let us know
what you think of these types of CSDB articles too! - Ed. nst]
First, a quick clarification about the people referred to herein. “Vendor” refers
to a company which develops and publishes a particular software tool. “Developer”
refers to a user of that tool (you!). “User” refers to a user of an application created
by that developer (probably using that tool).
Basic Elements
A CSDB system consists of three primary software components (aside from the
network software and operating systems of the computers in question): the client
application (also called the front end), the data access layer (also called middleware),
and the database server (also called a database engine, DBMS, data source, or back
end).
The client application is responsible for accepting input from the user,
submitting a query to the database server based on that input, receiving results from
the server, formatting them, and presenting them to the user.
The data access layer is relatively transparent to the user, but may be very
apparent to the developer of the client app. It provides for the app an API used to
submit queries to a data source without much concern for the network between them.
The database server accepts queries from clients, processes them concurrently,
and returns results. There are a number of different query languages around, by far
the most prevalent of which is SQL. (By the way, contrary to conventional wisdom,
“SQL” doesn’t stand for anything in particular. The ‘S’ isn’t for “standard” or
“structured,” although the ‘QL’ is thought to stand for “query language.”)
Strengths and Weaknesses
Before we get into detail about these primary components, let’s discuss some of the
advantages and weaknesses of these systems. There’s a lot of hype about “moving to
client/server,” “downsizing,” “upsizing,” “rightsizing,” etc. It needs to be put in
perspective. Older systems, by the way, are often referred to as “legacy,”
“centralized,” or “host-based.”
A lot of the expected advantages of these systems are in their hardware
requirements. CSDB systems distribute processing between the client, which runs the
user interface and certain application logic, and the server, which handles the database
engine and centralized data access logic. In an ideal scenario, this division of labor can
prevent the slowdowns associated with systems where all the processing is performed
centrally. However, this distribution creates a new potential bottleneck - the
network. The network is also vulnerable to overloading by use external to the database
application.
Another hardware benefit is the ability of an organization to employ cheap
standard computers for both clients and servers, rather than one vendor’s proprietary
hardware. Such machines are also general purpose - they can be sent on other
missions and moved around the organization. On the other hand, so-called standard
computers are often difficult to integrate. Centralized systems can be more turnkey in
this respect.
In both hardware and software aspects, CSDB systems are billed as being scalable
and modular. This is true to the extent that the designers plan for it. It is possible to
develop CSDB systems which can evolve smoothly and incrementally into large
services and whose components are replaceable with new products. It is
discouragingly easy, however, to develop a CSDB system whose user capacity and/or
transaction capability has a low ceiling, or whose components are tied to one another.
But with careful planning, a CSDB system can be better in both respects than a
host-based design. Keep in mind that diversity, which often follows effective
modularity, can make for a significant management headache, especially where
software deployment is concerned.
A major advantage claimed by CSDB proponents is the quality of development
tools in this market. It is undeniable that major advances have been made in
development tools in the last few years, and CSDB tools have made the most advances of
any. Procedural 4GLs, object-oriented 4GLs, graphical GUI builders, object-oriented
GUI builders, even graphical object-oriented “languages,” data modelers, component
repositories The list of features to boost programmer productivity is quite long.
Reduced development time is the expected gain from all this tool evolution, and
this is the area of CSDBs I’ve seen hyped the most. “Develop a full working CSDB
application in an hour without writing a single line of code!” Don’t believe a word of it.
As development tools have improved, expectations of applications have risen doubly so.
While it’s true that you probably won’t spend as much time poring over SQL source,
and may not ever have to write a line of C, you will have to exploit all your
development environment’s functionality, and this may mean writing a substantial
amount of (OO)4GL code. In fact, the environment often won’t do something you need,
or won’t do it fast enough, and you will be forced to write an external procedure in C or
another 3GL.
Just as in every other area of software development, it is easy and common to
seriously underestimate the time required to turn out the application as spec’ed, and it
is highly unlikely that someone important will not insist on a change in the spec during
the implementation phase! Be pessimistic when drawing up the schedule.
There is a major potential software disadvantage, too. Let’s face it, modern
personal computer software - including operating systems, system extensions,
development tools, and commercial and custom applications - is just not that stable.
Hardly ever is a commercial product fully debugged before its next major version is
released and the vendor ceases to support the previous one. Feature fever is bad for
software stability, and almost never is “bug-free” regarded as an important feature
by vendors. Mission critical systems simply cannot depend on such software. It
wasn’t always this way. I’ve heard stories about older computer systems that have
actually never crashed at most of their installations!
The advantages of CSDB systems are leading many organizations to consider
migrating to them. Migrating a user base of any size from a host-based database to a
CSDB system really requires re-engineering the business processes underlying the
software of the legacy system. Business processes are usually developed with the
computers of their day in mind. Re-implementing an existing business process in a
new environment may not provide any of the expected benefits if that process is
especially well adapted to a legacy system, or if it is fundamentally inefficient.
Business Process Re-engineering is a whole field unto itself, and is outside the scope of
MacTech, let alone this article. I can only caution the reader that software design is
not the first, nor the most difficult, issue in migration.
Ess-Cue-Elle Spelled Out
The proliferation of SQL as the lingua franca of database systems has pushed the trend
towards diverse, distributed data systems, despite the current (and hopefully
temporary) lack of full interoperability of SQL-based products. The view here is
focused solely on SQL-based tools, but there is not a single feature set for all
SQL-accessible servers, nor one for all SQL-capable clients.
SQL is more of a language family than a single language. Although there is an
evolving standard for it, many vendors have made proprietary extensions to the 1989
standard, in some cases creating incompatibilities with the 1992 standard. SQL is a