Despite the attention that developers tend to focus on overall system issues, most developers and system architects agree that the system ultimately fails or succeeds based on how well the middle tier (a.k.a. the business object tier) performs.

It’s fairly simple and quick to fix problems in the presentation or data tier. Most business’ tier problems, however, are endemic to the system, and, therefore, don’t lend themselves to simple or quick fixes. Only good system design can save you from massive recoding headaches suffered by many n-tier application development cycles.

So what are the telltale signs of poor middle tier designs?
Last week’s column, “Developing efficient n-tier applications,” focused on overall system issues that can affect your company’s ability to develop n-tier applications and offered suggestions to improve n-tier system development.
Multilevel, over-designed object hierarchies
The first time one of your developers stands up in a meeting and announces that this system will be the purest implementation of an object-oriented system in the history of the company, you should either:

  1. Double the size of the budget and assume you’ll be writing the system twice, or
  2. Fire the developer.

Developers who are object-oriented purists consider the design of a class hierarchy as the “holy grail” of a designed system. In the real world, instantiating large numbers of objects and requiring them to interact constantly with the data store in a constant process of population and persistence will result in applications that will not be scalable or will not perform well.

Many system designers assume incorrectly that designing for the middle-tier is the same as designing a traditional object-oriented application designed to run on a fat client. In order for middle-tier objects to perform efficiently, they should be designed with as few levels of hierarchy as possible and with more of a concern for limiting access to external storage than for object purity.

Minimizing the creation and destruction of objects will also yield better performance because the objects won’t be constantly forcing the underlying operating system to manage small blocks of memory.

Data-centric work performed in the middle tier
The middle tier should be used exclusively to execute business logic. Where database access exists, it should be focused only on managing persistence and not munging data.

For example, it’s bad n-tier system design to retrieve multiple data sets from different tables and then join, sort, or search the data in middle-tier objects rather than using database facilities.

Many of these bad habits were developed from years of development work performed with Visual Basic on the front end and using underpowered, back-end, file-system based databases like Access or FoxPro.

If there are circumstances that require additional system processing due to the nature of the data store, then these processes should be separated into data tier objects and moved as close to the database as possible. In general, as much processing as possible should happen in the database before the dataset is returned to the middle tier.

This means that developers need to be intimately familiar with the back end processing features of your standard database engine. Many CIOs and development managers assume that their developers will be able to pick up years of back-end design and coding skills from a book on SQL Stored Procedures. This is simply unrealistic.

You need to invest in either a SQL back-end development class with a qualified, experienced instructor or engage a firm who has demonstrated expertise in developing n-tier systems using your standard database. If you look at the underlying database access code in even your most current systems, you’ll see many telltale signs of inefficient database usage:

  • Making multiple queries when one stored procedure call would do
  • Retrieving data one row at a time instead of grabbing the set of data needed all at once
  • Explicitly locking data when it isn’t necessary to do so ultimately impacting the scalability and concurrency of the system

Maintaining a stateful middle tier
Developers who’ve spent any significant time studying or developing n-tier systems understand that maintaining state in components is a bad thing to do. But a surprising number of projects still attempt to do it.

You will hear some authors and trainers contend that you can’t use stateful components (a component that tracks the state of interaction, usually through values in a storage field) in the middle tier of an n-tier application. Of course that is not true. However, to achieve scalability and performance, you shouldn’t use stateful components.

There are additional issues that developers need to consider when writing n-tier, Web-enabled applications. The most important—and most overlooked—are the specific issues related to attempting to maintain state with objects instantiated by a specific Web session.

Once you’ve attached a specific instance of an object to a specific client session, you’ve lost the ability to load balance an application across multiple servers. This is because the object used by the session is in the memory of the server that instantiated it and cannot be transferred to another server on a round trip.

If you force clients to attach to a specific server for the life of a session, you severely limit your ability to scale a server farm. Moving state away from the object—either to the client in the form of cookies, hidden fields, or URLs or to a back-end database as a data record or XML string—allows the returning session to use any available server to continue.

Fixing problems before they happen
Most of these problems are easily corrected, but the solution is not one that’s welcomed by most CIOs or developers: Develop a program specification BEFORE you write the code.

A solid program specification reviewed by either senior internal consultants or qualified external consultants will most likely result in an n-tier system developed in time and on or below budget. Unfortunately, the need to develop on “Internet time” has led too many managers to approach development problems like “Dirty Harry” approaches criminal activity: “Code (shoot) first and ask questions later.”

And unfortunately, the victims of these crimes are the customers and the stockholders.

Tim Landgrave is the founder, president, and CEO of Vobix Corporation, an application service provider based in Louisville, KY.

What do your developers do to ensure that your middle-tier will perform well? Post a comment below or send us an e-mail.