Name: Application Development Basics- Application Design Techniques
Date: 6/8/2
Volume: 2
Author: Mike Chrisman
In the last article, I defined the
three layers of any application: Presentation, Business Logic, and
Storage. In this article I will talk
about current design techniques and where each layers fits within those techniques.
The techniques I will be talking
about include Centralized Processing, Stand-a-lone, Client Server, and
Disconnected. (No I didn't forget about Web apps, just keep reading.) Almost
all applications developed today can be placed into one of these techniques.
Centralized Processing:
Centralized
Processing (or main frame) applications were the first apps to be
developed. Typical Centralized
Processing app has a "dumb" terminal on the client side that handles
just the presentation layer, while the Business Logic and Storage Layers are
handled on a "centralized" computer. While modern "dumb"
terminals can handle some of the Business Logic Layer, the main task is to
handle just the Presentation Layer. A dumb terminal can include a dedicated box
that does nothing but act as a terminal, to a desktop computer with emulator
software running on it. The
"dumb" is determined by the software, not hardware it is running on.
The
Centralized piece usually consists of a computer where the Business Logic and
Storage Layers are handled for all terminals. In the early days, the Business
Logic and storage where handled on one computer, but modern main frames can now
span multiple computers allowing the Business Logic and Storage Layers to be on
separate computer. These computers
typically are stored in a centralized computer room, away from users.
This
technique provides for easy data sharing, but development tools are not very
robust (by today's standards) and debugging of apps typically requires many
"print" statements placed within the app.
A modern
version of this technique is Web applications.
The Business Logic is typically on a centralized computer (or
computers). Storage is also on
centralized computers with the Business Logic computers and user runs a
"dumb" terminal emulator (the browser).
Since
main frame and web apps are both Centralized Processing techniques, they also
share many other things in common, like development and debugging techniques.
Stand-a-lone:
With the
introduction of the "personal" computer, a new technique was created.
This is the stand-a-lone app. A
stand-a-lone app is one that the Presentation, Business Logic and Storage
Layers are all done on one computer. Now some Stand-a-lone apps do have pieces
of Business Logic that run on different computers, they are still considered
Stand-a-lone since all three layers exist on a single computer (typically
located at the user's location). Although, not a popular as it once was, it
still has uses today. Examples include
games and applications for portable devices (PDAs, phones, etc.)
This
technical has some great development tools (IDEs) that make developing and
debugging software very easy, but it does not allow the easy sharing of data.
Client/Server:
Once
desktop computers were networked together, a derivation of the Stand-a-lone
technique was created that allowed for the sharing of data. While the Presentation and Business Logic
Layers are still on the client's computer, the Storage Layer is now on a
centralized server.
Modern
adaptations of this allow for pieces of the Business Logic Layer to be on other
computers (Com/DCom, Com+, Corba, RMI).
This
technique allows for both the sharing of data and the use of good development
and debugging tools (IDEs).
Disconnected:
With the
rise of the "mobile" computing device (any computing device that you
do not have to use at your desk), a new technique was needed that would allow a
user to use the application by itself (like a stand-a-lone app), but allow it
to still share data. The disconnected
technique is a cross between the Stand-a-lone and Client Server. Here you have all three layers on one device
(the portable device) and another Storage Layer on a centralized computer.
Typically
the portable device has the Business Logic to talk to both the local Storage
and the centralized Storage. The two Storage Layers usually don't have the same
format/layout. This technique allows a
user to use the application on the portable device whenever they need/want
too. Then, when they have returned to a
centralized location (like their desk), they active a different set of Business
Logic in the application that takes the data from the portable device and
"syncs" it with the central Storage Layer. This "syncing" Business Logic is located either be on
the portable device itself, or on an intermediary computer that talks to both
the portable device and the central Storage Layer.
This
technique introduces some interesting issues that the "sync" Business
Logic Layer must address. Notably the issue of reconciling the data, since it
is very likely that two people could change the same piece of data at the same
"time". (Time being relative since it is from the last time the user
"synced".) This is something
that must be addressed when you design your application.
With modern tools available today,
the line between each technique can get very blurred. The key to determining which technique to use is to look at where
each layer is logically meant to run. As time goes on and new needs arise, new
techniques will be created, but they will always consist of the three layers of
all applications.
In out next article, I will talk
about the protocols, or languages, you can use to have the layers communicate
with each other.