As we approach a new century, the Web continues its phenomenal growth rate, appealing in so many ways to diverse groups of people. With the maturation of Java, the Web will evolve from stateless HTML pages or cobbled-together HTML/CGI script solutions to true interactivity and context sensitivity. I have heard this next stage referred to as "the second Web."
To target the second Web, many people - application development tools vendors in particular - have concluded that traditional 2-tier, client/server architectures will not scale well because of the unpredictable number of user connections and data access and system administration issues.
To address the limitations of 2-tier architectures, many development groups are moving to 3-tier architectures. This is roughly defined as a presentation layer at the client tier, a server in the middle and a database of some sort on the back end. The idea is to offload the code bloat on the client or the database server, centrally manage business logic and get more flexibility out of working with the database instead of just stored procedures and triggers.
Within the last six months or so, a slew of software tools vendors have come out with 3-tier architecture development tools. However, it's becoming clear that not all 3-tier architectures are created equal.
Under the Hood
In analyzing the competition, we have looked at the various 3-tier tool offerings and have found some surprising characteristics. Many architectures are what we would call "2 1/2_ tier." We call it 2 1/2_ because the middle tier turns out not to be extensible at all: no APIs to add application logic exist. Essentially, the middle tier is just a database gateway. It offloads the database connectivity functions and perhaps does some database connection management producing several consequences. First, the client bears the load of initiating, querying and receiving results. Second, adding functional richness to the application adds to the size of the client.
This does not appear to be an improvement over the fat client problem, especially when we're talking about deploying the client portion of the application through browsers and over the Internet. Consider the download speeds of various client sizes over a 28.8K modem connection. In my opinion, an end-user's patience will be severely tested at 28 seconds and anything longer than a minute will probably not be tolerated. These numbers represent just the time it takes to get the client downloaded and initialized! Once the client is running, there is also the potential for large result sets that have to be cached onto the client and then processed. All of this results in poor performance for the end-user.
And finally, adding application logic (a.k.a. business rules) to the client tier exposes your company to unnecessary security risks: Someone could easily decode your bytecode and infer information about your company and the application. If you're building applications for a competitive advantage, you risk exposing some important intellectual property.
To support fast downloads of clients, protect the application logic behind the firewall and get good scalability for a Web deployable application, we need an extensible, multithreaded middle tier - the application server. Application logic would be built on top of the framework supplied by a vendor. With an extensible and scalable application server, you get the following benefits:
We have listed only a few of the advantages to be gained by using a true 3-tier approach. When you're in the market for a 3-tier application development framework or tools, follow the wise old adage: caveat emptor. Make sure "3-tier" is really 3-tier!
- Scalability: Multithreaded capability allows the server to scale well as you add more processing power, such as SMP machines and clustered systems.
- Thinner clients: By offloading processing such as database access and query results, clients can be simplified to deal only with display of information, user input and some data validation.
- Centralized application logic management: Some of this can be done with stored procedures and triggers but these have their limitations. The ability to keep business logic and business objects under a centralized group allows all clients to pick up the changes without any client administration.
About the Author
Tom Kim is the Product Manager of Java products at Rogue Wave. Prior to joining their marketing group, he worked for 12 years with IBM and Tandem Computers (6 years each) as a software engineer in the languages and tools area. Tom can be reached at at [email protected]