So the latest and greatest technolgies are comming out and evryone is ranting and raving about J2EE or .Net and how there suposed to help on the enterprise level!
Here is my perspective on what me and my coleagues know and do things at work...
Our application is defenently an enterprise level application since it ranges from: Front End ASP tools(Active Server Pages), Back End C++ applications, databasses and reports.
All this has been built on a 2 tier system, where all applications: ASP, C++ and reports; access our databasses. So we have programmed maybe 90% or as much as we could all the business logic in stored procedures within the databasses.
The filosophy of our chief architect is that if we write generic enough stored procedures we can achieve some sort of modularity... How could a 3 tier system be used, where you have thin client apps, an app server and a data store? More over how can I convince him, that 3 tiers is a good concept?
Your chief architect is not 100% wrong. You can build a viable system with direct web server to stored procedure communication.
Here are some counter-arguments, though.
1. You web layer will be tightly tied to your database structure. If the database structure changes, you web code will have to be updated, and those updates will be scattered and hard to find.
2. The stored procedure environment is not object-oriented. If you want to get better re-use and maintenance through more sophisticated OO techniques, you will need an OO business object layer between your web layer and your database.
3. You only have one database. Any work done by the database will slow down the entire system. Being able to seperate business logic into a seperate middle-tier layer reduces the load on the database, thereby (possibly) improving overall application performance.
All of this depends on the needs of your application, though. If your application is pretty much report-oriented, a three-tier system may be overkill.
A lot of this depends upon the quality of your models. Presumably your stored procedure approach is not object-oriented, and that's OK - but what other modeling technique and architectural mechanisms are you using instead? For example, do you actually *have* SA/SD type models (DFD's and SD's as well as E-R diagrams)? And do you really have a model-driven architecture behind your database (i.e. are things modeled and properly documented before they are implemented?)
If you have all of these things then your house is largely in order, and your architect's decisions are defensible. If not, then you have an impending problem with maintenance and extensibility. That's where multi-tier O-O architectures are advantageous - they can be *somewhat* more forgiving when used with deficient or informal development processes.
Data tier comprises of tables and views, business logic tier comprises of stored procedures and triggers (disregarding that missing 10%, as it's hard to move all business logic into one physical layer anyway) and presentation tier is ASP and report tools. So you have modularity,
The real issue is, should all business logic be moved into some component technology (EJB, .NET assembiles...). If you have people skilled in writing and managing stored procedures, have no problems porting stored procedures between various DBMSes and don't need clustering for performance (or if your DBMS can load-balance stored procedures), then there is no need.
Current best practices dictate that client tier should access business tier in a through a "procedural-oriented" interface like a session facade. You do that with session beans in EJB, WebServices or .NET Remoting (I don't know wheter later supports object ala RMI or CORBA, but I suppose a session facade pattern is used even if it does support object), using Command pattern if you are crazy/bleeding edge enough to use Prevayler and so on. So from presentation layer's perspective there will be no gains in modularity.
Well our application is defenently not report oriented...
We have 5 ASP applications which 3 of them are mostly internal use and tools for managers and the other 2 have the potential of beeing used by hundreads of users. The last 2 ASP applications host the reports also...
Then we have our "Web Service" application (Server with XML, before even Web Services where a buz), which receives XML requests and inserts them into the database using a stored procedure.
Now depending on what that XML request contains the database calls other stored procedures which call others and so on... Eventually the stored procedures reach to a point where they forward the processed XML request to our back end C++ applications, using an extended stored procedure, which comunicates with our business partners. We have about 6-7 of these applications. These applications get a response back from our partners and reply back to the extended stored procedure where the result is finally returned to our "Web Service" which replies back to the connected client. Some of these applications communicate synchronously to our partners and return a response almost emmedialty. A few others batch the request and send them to our partners once a night.
As for diagrams etc... and models we have none! Plus if you donthave any models or diagrams how is OO goingto help it's going to make an even bigger mess!
O-O is meant to be model-driven and architecture-centric. If you do not invest in the production of some models up front, then you are right, you will have an even bigger mess.
I'd recommend documenting what you have as the first step. Once you have this documentation then it's re-engineering as a multi-tier architecture can be properly assessed and the risks of doing so qualified.
Ok how about when to use and when not to use "App Servers" (J2EE or .NET). The point I see is the fact that all applications could share a commun resource such as DB connection... And since the app server can be clustered it can be load balanced etc.. So it can take the load of multiple apps accessing that same resource.
That wouldn't take an app server, just a TP monitor. The selection of middleware should be addressed by an architectural risk assessment.
So bassically, J2EE and .NET are bloat and only good for JSP and ASP .NET I havent seen any one say anything good about EJBs and .NET remoting. Most probably because no one knows... Plus sometimes I see paterns as hacks around the pitfalls of these platforms... Though some paterns can be good for setting certain standards while programming in teams, then again how do you get the time to implement such thinsg with no experience and crazy deadlines! :P