Friday, February 18, 2005
« Why we REALLY need stateless server clus... | Main | awk »

In a recent online discussion the question came up “If ‘the middle tier’ has no knowledge about the actual data it's transporting, then what value is it adding?”

 

The answer: database connection pooling.

 

Pure and simple, in most rich client scenarios the only reason for a "middle tier" is to pool database connections. And the benefit can be tremendous.

 

Consider 200 concurrent clients all connecting to your database using conventional coding. They'll have at least 200 connections open, probably more. This is especially true since each client does its own "connection pooling", so typically a client will never close its connection once established for the day.

 

Then consider 200 clients going through a middle tier "app server" that does nothing but ferry the data between the clients and database. But it has the code to open the connections. Now those 200 clients might use just 3-4 connections to the database rather than 200, because they are all pooled on the server.

 

Was there a performance hit? Absolutely. Was there a scalability gain? Absolutely. Is it more expensive and harder to build/maintain? Absolutely.

 

This middle tier stuff is not a panacea. In fact its cost is typically higher than the benefit, because most applications don't actually have enough concurrent users to make it worth the complexity. But people are enamored of the idea of "n-tier", thinking it requires an actual physical tier...

 

I blame it on Windows DNA and those stupid graphic representations. They totally muddied the waters in people's understanding the difference between n-layer (logical separation) and n-tier (physical separation).

 

People DO want n-layer, because that provides reuse, maintainability and overall lower costs. Logical separation of UI, business logic, data access and data storage is almost always of tremendous benefit.

 

People MIGHT want n-tier if they need the scalability or security it can offer, and if those benefits outweigh the high cost of building a physically distributed system. But the cost/benefit isn’t there as often as people think, so a lot of people build physical n-tier systems for no good reason. They waste time and money for no real gain. This is sad, and is something we should all fight against.

 

I make my living writing books and articles and speaking about building distributed systems. And my primary message is just say NO!

 

You should be forced into implementing physical tiers kicking and screaming. There should be substantial justification for using tiers, and those justifications should be questioned at every step along the way.

 

At the same time, you should encourage the use of logical layers at all times. There should be substantial justification for not using layers, and any argument against layering of software should be viewed with extreme skepticism.

 

Layering is almost always good, tiers are usually bad.


Friday, February 18, 2005 1:40:57 PM (Central Standard Time, UTC-06:00)
Wow... am I sensing a theme here? Between this post and the last you must have had one heck of a week! ;-) Did someone put your theory to too much practice? :-|

Leigh Kendall
Friday, February 18, 2005 3:39:16 PM (Central Standard Time, UTC-06:00)
No, though they are thematically linked they were inspired by separate conversations with separate people/groups.

This particular topic however, is one that I harp on every time I speak at conferences or user groups, because I think it is important to undo the damage done by Windows DNA whenever possible.
Thursday, February 24, 2005 7:16:50 PM (Central Standard Time, UTC-06:00)
What if I have the middle tier running as a COM+ application on the same computer as the database. Is that bad? Are you referring strictly to having one computer (or cluster) for the database and another computer (or cluster) for the middle tier objects?
Friday, February 25, 2005 8:44:12 AM (Central Standard Time, UTC-06:00)
In relation to this discussion on n-tiered solutions versus n-layered ones and when to apply, what is your take on Microsoft's Smart Client approach? If you do not need connection pooling is this a good architecture for distributing and maintaining rich client applications?
bret williams
Tuesday, March 01, 2005 12:58:48 PM (Central Standard Time, UTC-06:00)
Rocky,
I'm sorry I didn't see this before but I can think of at least one reason other than connection pooling to go with a middle tier rather than just a layer. That reason is database security. This applies to Window's Integrated Authentication (WIA) as well as SQL Server authentication.

WIA: You don't want to give individual user logins privileges to the database. Additionally you don't want any logins with privileges to the database to exist on client machines. With a middle tier the only place where that login exists is on the middle tier machine. No logins that exist on the client machines will have access to the database. If additional security is needed, the database can be locked down to only accept requests from the IP of the middle tier machine(s).

DB Security: You don't want connection and login information anywhere on the client machine. Without a middle tier the best you can do is encrypt/decrypt authentication information on the client and/or hide it relying on security by obscurity. With a middle tier, DB login information can be safely stored without the fear of any users viewing it and using it to log into the database directly. As with WIA, the database can be locked down to only accept requests from the IP of the middle tier machine(s).

Thanks,

Kevin
Kevin E. Ford
Comments are closed.