|> 1) "Standard Client/Server"
|> PC ----------------------- LAN or WAN ---------------- Relational DB
|> (Powerbuilder) (Sybase/Oracle)
|> 2) "Application Server"
|> PC ---- LAN or WAN ------ UNIX application server --- LAN --- Relational DB
|> (running an X server) (running the App in Motif) (Sybase/Oracle)
|> THE QUESTION IS WHICH ARCHITECTURE HAS LOWER BANDWIDTH REQUIREMENTS TO THE
THE ANSWER IS: IT DEPENDS.
BUT EITHER WAY, THE SECOND ARCHITECTURE IS BETTER.
The second architecture will probably have "lower bandwidth requirements to the PC's." X traffic is
generally smaller than data traffic. But anyone giving a concrete answer to this question is on shaky
ground, for two reasons.
1. You didn't specify enough details
(what app? # users? size/type of data? volume of graphics? are you backing up the PCs? ...)
2. It's dynamic; a right answer today may be wrong tomorrow.
That's one reason the second architecture is better. It is modular. It allows you to optimize the
network and the application on one side INDEPENDENT of the network and the application on the other,
instead of optimizing for both at the same time.
Here are 10 reasons why the second architecture is better:
I. The open systems design of the second approach gives you a choice of application servers.
If your client application only runs on PC's, you become captive to Microsoft.
The application server model lets you use UNIX, NT, VMS, and so on, or any combination.
They can all send X display info to the desktop.
II. The application server model gives you a choice of desktops, rather than forcing you to use PCs.
PC's can be too expensive to own and administer in large organizations.
X allows you to use whatever's best for you: PC's, workstations,
or an optimized, low-cost solution: X terminals.
III. Clean-layering with a modular design is easier to implement.
Developing a client/server app is hard enough without bundling the UI requirements
IV. Clean-layering with a modular design positions you well for the future.
WHOOPS! You need to add another application. Do the PC's have the horsepower for both?
With the application server model, ADD another server rather than replace every desktop.
V. Putting applications on the desktop limits performance.
No matter how fast a device you put on the desktop, you're limited to that much speed.
As applications and OS's grow, your device slows down, eventually forcing you
to replace it. But with an app. server model, you can configure MUCH faster
CPU's centrally, and add servers when you need them. It is more scalable.
VI. Applications on the desktop waste CPU cycles and memory.
Desktop computers are not shared resources. They must include enough power
and memory to run the application--on every desktop. Not all of the computers
are in use by all of the users all of the time. There's a lot of waste.
In order to beat the performance limits (V.), people sometimes over-configure the
desktop device, trying to extend its life, wasting even more resources.
VII. Putting applications on the desktop causes frequent desktop hardware upgrades.
Anyone running a SPARCstation 1? A 286 PC? Running applications demands
ever increasing horsepower. The user interface is stable, and does NOT demand
increasing horsepower. Therefore, running only the user interface on the desktop--
with apps on a centralized server--greatly prolongs the life of the desktop device.
VIII. Putting data on the desktop has more security risks.
Any desktop computer that allows local I/O puts you at risk of unauthorized removal
of sensitive data, or of unwitting introduction of viruses. X terminals eliminate
this risk altogether, but even PC's running X allow you to develop apps such that
the sensitive data is controlled and more secure.
IX. Data on the desktop doesn't get backed up.
If backing up desktop computers isn't a problem for you, congratulations. It is
for most everyone else who uses them.
X. Putting applications on the desktop costs more to administer.
Running applications on the desktop means running desktop computers. In and of itself,
that makes the architecture more expensive. But the administrative costs of putting
applications, with incumbent upgrades, troubleshooting, etc. on every desk is very
high as several prominent studies attest.
Bill Prescott Market Development Program Manager
If you write software based on the X Window System,
please tell me about your product!