Read the first paragraph for Nostalgic reasons 🙂
I remember the days of FoxPro programming; usually there would be one Executable and numerous .DBF files. The business rules were built in the executable. Managing or distribution of any businessrules meant making coding changes and rebuilding the exe. Gone were those days, the world moved on to a truer-client/server architecture. We would write Delphi, Power Builder, Visual Basic, Oracle Forms (and even FoxPro) programs that interacted with the RDBMS hosted on a set of servers. The business rules were split between the client and server (in terms of Integrity constraints, stored procedures and triggers). Then came the concept of Application Server. More business rules were moved from the client to these servers.
Some of the business rules hosted by the database servers were also moved to the application servers. I understand the Enterprises’ need for a common business rules layer, and I think the concept of Application Server having the business rules is just a hype. I do not see many reasons that would require moving the rules to application server from the database server. I know the application servers are designed to handle many more things, and I am not sure how many of them really are necessary and useful that the OS and Database can not handle. The makers of application servers have made us feel the OS and Database are not adequate.
Ofcourse stored procedures and triggers do not always conform to Object Oriented principles. However, making coding changes and deployment is easy. With application server, having one more layer just adds one more point of failure. To integrate their systems Enterprises now need more resources (hardware, software andpeople). There is an issue of performance with myriad layers.
So, what do you think, are the business rules better implemented on the database or application server.