Back

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.

 

Back