Business Logic Layer

There seem to be two lines of thought around business logic layer implementation:

• Logical: Where the presentation (templating & user session management) code is separated by an object layer to the actual business layer
• Physical: Where the presentation (templating & user session management) code is in a separate process/ thread/ machine

In the past I have worked mostly in the physical separation model of building applications. The solutions have been applied to:

• eCommerce and SaaS models of web applications
• High transaction volume and high configuration models of web applications
• In both Linux (Java/Tomcat -> C++/BEA Tuxedo -> RDBMS) and ASP.NET (C#/ASPX->C#/ASMX->RDBMS) frameworks

LAMP/ JEE Spring model of building applications are good examples of the logical separation model of building applications.

In my mind, physical separation model of building applications (though with a slight learning curve), is the more scalable way of building applications. Please note that I am assuming a stateless business logic layer.

The advantages are many:

• Physical clustering of like transactions (to increase throughput)
• External/ Internal API are the same
• Authentication and Authorization are more well thought through the application (and not slapped up on top)
• Leverages the interoperability of web services to provide a homogeneous view of the business logic layer
• Granular level caching is available
• Databases can be physically separated based on transaction groups
• Much more tuned towards Rich web client applications (Flex, Silverlight, Java FX, Ajax)
  

The disadvantages are:

• Every web request spawns into one more (assuming business logic layer is physically separate)
• Development & Operations infrastructure is a little more involved
  
• Time/ computing resources are spent in serializing and de-serializing web requests