Previous Page |
Next Page |
Table of Contents
However, though the client-server architecture was vastly
superior to the monolithic architecture, the approached
forced developers to locate the three main development
layers in just two locations (in the client or in the
Typically, presentation and business rules logic
would always remain within the
purview of the client-side application.
For example, Decisions on locking, updating, deleting and
information presentation were encoded in the client application
directly. This enabled the client application to 'short-cut'
the UI to produce clever designs.
The data however, became the responsibility of
the database or messaging subsystems. As such they were
accessed either via direct API or through thin layers of
'enabling technology' such as ODBC. In some instances, this
provided limited flexibility enabling designers to substitute
like database for like without creating large amounts of work.
The presentation layer would exist as a single layer
within the client side application but the business and
database layers could exist in the database or messaging
server. This enabled the client side application to respond
quickly to cosmetic changes without having to test all
business logic cases, and at the same time allowed the
business rules to change without requiring mass rollouts
at every such occasion.
The client-server model presented a major paradigm shift
when compared to monolithic applications. However, it
remained far from ideal.
In one scenario, the presentation layer and business layer
are constantly diametrically opposed. Fewer updates to the
GUI engender familiarity with an application (and makes it
simple in deployment) but restrict the ability to change
the business rules. Frequent changes to the business rules
cause deployment and testing headaches.
approach is to locate the business rules within the database/messaging
layers. However this tactic means that it is hard to uncouple the business
logic from the data and messaging structures.
The Client-Server architectures also suffered under constant
maintenance strains due to proprietary standards, technologies
and, most importantly, a lack of scalability.
applications performed best in a corporate environment where
groups of users require a focal application which integrates
tightly to key technologies such as database engines, email
server, work flow and document management systems.
As a result, most Client-Server application were
little more that file
and database sharing applications. In fact, early Client/Server
solutions were often oblivious to other clients, behaving in a
While the Client-Server approach does much to create good
solutions there followed a painful growth period during which
applications were built, deployed and maintained. It was during
this "growth" that the issues with Client/Server development
In the client server model all clients have access to nearly
all the services. This forces the services, like email and
the database servers, to ensure that they can maintain
large numbers of permanently connected users.
connection requires processing, memory resources and
extra network traffic - even when the clients are busy
doing nothing of significance against the servers. Load
balancing tools were scarce and the underlying technology
proved problematic to maintain.
From a development perspective there are also issues of
maintaining software that often needs updating when new
versions of API arrive, especially when the new version
fixes existing issues. When this situation occurs the
process of deployment becomes a major issue.
do you deploy to hundreds (maybe thousands) of clients?
How can the developers ensure that there are no conflicts
with other installations? How do you deploy all the supporting
APIs and connectivity libraries?
Certainly, there are solutions to most of these problems,
however, one specific problem remains a constant problem
for all multi-client solutions; scalability. As users are
added to a solution it becomes more and more difficult to
maintain a consistently good level of service without diverting
Technology moves and grows but occasionally a conceptual
shift occurs (a paradigm shift). A shift of this magnitude
arrived in the form of the Internet. With the arrival of
the 'net' many of the client-server problems could be
solved. If not solved, they were meliorated.
Previous Page |
Next Page |
Table of Contents