Name: Application Development Basics- Protocols

Date: 6/8/02

Volume: 3

Author: Mike Chrisman

 

So far we have defined the three layers of any software application: Presentation, Business Logic and Storage. We've also discussed how each layer is a translator, taking user input to business rules to storage and back again. Now we are going to talk about how each layer talks to each other.

For the purpose of this article, a protocol will describe communication between any two layers. A protocol consists of five things: a language, a wrapper (or envelope), a delivery method, and at least two interfaces. Most of the time, these pieces are done for you and you don't have to worry about them. But if you understand the actual pieces and what they are doing, new options could be open to you.

 

Language:

This is the structure of the data that is being transmitted between the two layers.  For example, if you are going between the Business Logic and Storage Layers, then the language is usually a SQL statement.  The information coming back to a layer is not always in the same language as is was sent in.  For example, in web applications, data from the Business Logic Layer to the Presentation is in HTML format, while data from the Presentation Layer back to the Business Logic Layer is either in Post or Get format. An application usually has to manually convert the data to the proper format (but not always).

 

Wrapper:

Once data is converted to the correct format, it must then be placed inside a wrapper so that it can be transmitted. If you think of formatted data (language) as a letter, you have to put it in an envelope before you can send it. This is what the wrapper does for your electronic data. The wrapper also has the "address" where the formatted data is to go. Examples of wrappers include: HTTP, telnet, ftp, Windows GUI, Net 8, etc. Almost always, the wrapper is the same between a given two layers.

 

Delivery

This is the physical method that the wrapper will use to get to the destination layer.  This is usually some type of type of cable (cat5) or even wireless connectivity.  Now it may seem strange to talk about the physical wire that the data is being sent over since it is rare that a developer even thinks about the wire the data is sent on, but if you think of it as a "delivery" method, new non-traditional options can be open to you.

 

Interface:

Each layer must now be able to create and receive the data via the transfer.  This means that 1) each layer must know how other layers will talk to it, and 2) be setup to listen and talk on those "protocols".  This is often done for you in the form of listeners.

 

Now, I have described a pretty complex process to just send information back and forth. Fortunately, most of this process is automated and simplified for us when we develop applications. Let's look at a few examples. 

 

In a typical web based application, let's look at the protocol between the Business Logic layer and the Storage layer.  In this example, we look at an NT to Oracle.  From the Business Logic Layer, if first creates the message in the language (SQL), then it sends the statement to the interface (ODBC driver)..  The ODBC driver then sends the message with the address information to the Net 8 interface. The Net 8 interface then takes the message and wraps it in a Net 8 package and addresses it with the information provided and sends it over the Network.  The Listener (interface) on the database server then grabs the package, grabs the return address, gets the message out from the package, and passes the message to the database. The database then executes the message and returns the results back to the listener.

The listener then takes the results, places it in a package, addresses it with the return address, and sends it out on the network. The NET8 listener then grabs the package, gets the message from it, and passes it on to the ODBC driver. The ODBC driver then passes the message to the application.

 

This type of transaction takes place between any two layers, and some times within a layer. Also, there maybe more than two of a given piece (like interfaces) that message must pass through.

 

Although what I have just described may seem long and complex, it is really the basic structure of communication between any two objects (like people, animals, computers, etc.).

 

Now, what’s so important about understanding all this?  After all, the computer does all this for you, why concern yourself with it?  Well, if you understand how this works, then you aren’t limited to the standard protocols.  For example what if you had group of people that are isolated and the only data connection they have to the rest of the world if so slow, the only thing the reliably works is email, because it can be done in batch and at a slower pace.  How would you write an application for them that would allow them to work with data and still maintain that the data is reliable?  Well, if the standard protocols, you really can’t because users are not going to wait for a slow protocol.  But why couldn’t you use the email system as a protocol to communicate with the database.  Using the Disconnected Application design, this would work very well.  You could define XML as the language for the data; the wrapper would be an email address. Delivery is SMTP. All would need to do is write your own interfaces for each side. One to generate the email, and one to process any incoming email message and process the contents (the XML).  This design would not be hard to write.  For that matter, you could even use Faxes.  A Fax model and an OCR scanner on each end and away you go (although this would also require humans to transfer the fax to the OCR scanner).  A Fax may not be very practical, but it does demonstrate the power and options available to you for communication between layers.  How about short-wave radio as the delivery and Morris Code as the language?  Anything will work as long as both sides know what is expected to send and to receive data.

 

I hope you have enjoyed this 3-part article on application design.  The purpose of these articles is to define to basics of applications development, allowing you to manipulate these pieces to better fit your needs.  Just because someone developed a “piece” for applications, and everyone uses, does not mean that it’s the best fit for all needs.  If it’s not, don’t force it, create your own.