Why use an application server? RRS feed

  • Question

  • My boss wants me to explain to him the advantages of having an application server in our web app. Currently our web app talks directly to SQL Server.

    What are some of the pros and cons of having an application server in this type of application?


    Thursday, December 22, 2005 4:03 AM


All replies

  • There are several reasons why you want to separate your User Interface layer (Web) to your Data layer (SQL Server).

    For example from a scalabiltiy perspective, you could introduce notions of caching and/or you could pool the databases connections so that you can scale out your web farm without increasing the number of connections to the database.

    There are also security advantages, instead of having direct calls to your DB from the Web page which could be prone to SQL injections, you can have a distinct data access layer performing data validation and/or exposing business logic that will  make sure that the text entered on the web form is not used as is in the SQL call,

    There are also advantages in the maintenance and evolution of the code base. Evolution of the application can now be scoped to UI changes, independently from business logic changes, independently from data changes.

    There are many more. Here are a few links that will give you more information http://msdn.microsoft.com/practices/apptype/webapps/default.aspx?pull=/library/en-us/dnpag/html/diforwc.asp 



    Hope this helps,



    Thursday, December 22, 2005 9:56 PM
  • Keep in mind that while having a layered architecture is a great idea putting your business logic on a seperate application server is not always advisable.  You suffer a large performance penalty in doing so.  In general I would advise keeping your business logic on the web server unless there is a compelling reason to move it to a seperate app server. 
    Thursday, January 5, 2006 12:23 AM
  • There are two different concerns that you have to consider answering this question.

    #1 is whether or not it is advantageous to have a 3-layered logical architecture: Web server - application - SQL server.  The 3 (multi)- layered logical architecture is a well known pattern; and as gianpaolo mentioned the main advantage is the scalability and code maintenance.

    However, the implementation of the 3 layers does not necessarily need 3 computers.  The application may be running on the DB Server or Web server computer.  In fact, you can have all of them running on the same computer or have several computers for each layer.

    Issue #2.  Do you want to have all layers implemented on separate computers?  That basically depends on the size of the system.  If the design is done correctly, it will not be difficult to deploy the appliaction on the separate computer. Advantages? Well, the security concerns have been mentioned. Performance as well, and, again, maintenance.


    Thursday, January 5, 2006 12:55 AM
  • Rocky has a great post on this.


    from Rocky' post
    "Crossing a boundary is expensive. It is on the order of 1000 times slower to make a call across a process boundary on the same machine than to make the same call within the same process. If the call is made across a network it is even slower. It is very obvious then, that the more boundaries you have the slower your application will run, because each boundary has a geometric impact on performance."



    Thursday, January 5, 2006 11:13 AM
  • None of the reasons you mention require an additiona "physical" node.  They are all code asbtraction layers and not physical boundary layers.

    What you mention is just good general design principles, not reasons for having a separate Application Server.

    Friday, January 6, 2006 12:21 PM
  • When it comes to tiers and layers, most of the time I get it but then get confused over again in few cases. I want to go deeper and act dumb when it comes to layered architecture itself.

    In our design discussion for an application there were 2 aspect when it came to layers. The difference was in how many assemblies/projects should be built. The UI layer was not a problem. When It came to Bussiness Logic and Data Access, few insisted on having a single assmebly with the two layers as sperate set of classes, while others wanted both these layers to be seperate projects and assemblies. The former group said that the layers are there and it may a small performance hit to seperate them, while the latter saw a reason for reusability accross other applications and maintenence.

    My doubt in addtion to the exact definition of layers (which I am guessing doesn't refer to PEs) is does it make sense to prefer having seperate assemblies for each layer (in this case considering the Business layer and Data Access are on the same physical application tier) ?

    Also let me know if I am not explaning the scenerio correctly or have made incorrect assumptions.


    Shekhar, Application Architect


    Thursday, January 12, 2006 8:59 PM
  • The 2 primary reasons that I've encountered for having distinct "physical" tiers is:

    1. Additional tier for horizontal scaling - albeit there is some "affinity" between consumer and server.

    2. No code DMZ.

    Thursday, January 12, 2006 9:50 PM
  • My experience shows that having two separate projects (& hence assemblies) for business and data layers greatly promote code reuse and maintainability. I have reused the DAL project/assembly across applications without any change.

    Also, I have not come across any performance issues as such with this approach (when both BLL & DAL assemblies sit on the same server). One reason I could see for having both BLL & DAL in a single assembly is to reduce the number of deployable units.

    Friday, January 20, 2006 3:53 PM
  • Think "InProcess" vs. Out of Process; physics still rules in the electronic world.  Moving those "bits/electrons" between physical tiers, let alone cross-process marshalling, is a costly aspect of s performant application.

    And never forget the 8 Fallacies of Distributed Computing



    Friday, January 20, 2006 4:09 PM
  • Hi,

    It's expected that app server is very powerful to handle the business logic by providing services like security, statemanagement,application connectivity and many more of such services etc...

    And having a different app server for business logic, is a good way of layering your application for better performance, security,code management.

    But in a .NET world even the IIS on Windows server  works like an appserver (ISAPI extensions) . Chk the below link


    You can infact treat SQLserver itself as an app server, which you are already using in our app. So even if your webapplication talks directly to your SQLServer, you still happen to have an appserver because SQLServer offers lots of services expected from an App server.

    This is in contrast to the J2EE environment where we have separate app servers  like weblogic, websphere etc to store the business logic. In .net, we usually by default happen to work with  appservers each offering different services.









    Friday, January 20, 2006 4:24 PM
  • Hi ,

    Regarding having different physical servers for different layers, it would be wrong to directly conclude that it would have performance problems. It totally depends on the network.

    One of the reasons for going for different physical servers is usually to manage the load on a single server, so that performance can improve.

    However, as many have said... if the network is a wide , this would spoil the performance as well.

    So, we cannot generalise on this. We need to be judicious and decide based on your applciation requirements and the infrastructure available.




    Friday, January 20, 2006 4:31 PM
  • Hello,

    I am not sure if you would require an application server in this scenario.
    It looks great already.

    I think you should probably look at an application server when you get in to an excersise of remodelling the current application. This remodelling would be driven by business drivers for ex: exposing your functionality to a bigger set of users, allowing this application to be invoked via non-web interfaces etc...

    At a very high level, the benefits of an application server are
    - Mangebility
    - Fault Tolerance
    - Scalability
    - Exposing business components via different deployment wrappers such as RMI, CORBA, SOAP ...
    - Built in modules for dealing with a Persistence Store
    - Transaction Support

    If you look at the benefits, you would see that most of these are concerns that a client-server application or a web application would have and developers need to worry about them when designing systems. App-servers remove these concerns. (separation of concerns design pattern )


    Monday, January 23, 2006 8:23 AM
  • I know we are discussing logical/physical application layers but do not forget about BizTalk.  BizTalk can be used as an application/integration server and it makes sense to deploy it to it's own physical tier - workflow, BRE as well as easily exposing business components via different interfaces (SOAP, MQ, JMS, etc.).

    -Dave Strommer

    Tuesday, January 24, 2006 10:50 AM
  • As you point out, Anjana, there are multiple hosts available.  But Microsoft's mainstream application server is Windows Server itself.


    Wednesday, February 1, 2006 7:31 PM
  •  Steven York wrote:
    What are some of the pros and cons of having an application server in this type of application?

    If you consider the application server a logical wrapping of your business logic then, of course, you'd gain better modularity, testability, etc. But all that's true for having a separate layer as well. The application server concept is larger than that, having origins in the java realm.

    The general idea is that the application server hosts, or serves as a container for, your server side software providing it all sorts of services like transactions, object pooling etc. The ramifications of this include that the UI is now considered a different application that communicates with your app server, conceptually supporting multiple UIs, both Win and Web or Rich and Reach.

    There are cases where you may want users on the corporate network to access the same system but provide them with a much richer interface than available over the web. The app server would support them as well.

    The security issue has also been raised. While you may need to keep your web server in the DMZ, you'll want the app server on the corporate network to support the scenario above.

    Application servers were all the rage a couple of years ago in Java land before the POJO backlash. In a Windows world, you could view the CLR as your application server - or COM+ could also fit.

    Hope that helps.

    Wednesday, July 19, 2006 2:06 PM
  • I will just elaborate on the issues already mentioned:


    1) Network Security: You have a possibility of creating a DMZ by putting additional firewall between web and app servers. This is supposed to be a good thing from a netwok security perspective. For example if you connect with internal applications - you may not to allow a direct connectivity to it from the web server ( in case it gets compromised) , but you are willing to take the risk of allowing connectivity to it from application server (which will have a lower probablity of being comporomised)

    2) Scalability and resource usage: This is again a very "hardware" thing. We typically maintain sessions in the Web application. Typically, we donot use distributed sessions ( either we dont want to put a state server, or we tend to write a lot of things in the session, to make state management easy - hence leading to pathetic performance if we distribute session to the state server), hence we want the web server load balancer to have "sticky sessions" allowing the user to stay on the server you connected. This essentially means that some servers could be far more loaded than other servers leading to slow response for some , while other servers are completely idling.

    Now if we take the business logic and heavy processing out, put it in stateless layer and host that on seperate app servers - load balanced by "non sticky" load balancer - we get better resource usage!

    Extending this - if we have Rich clients or third party applications consuming our application as well - we expect those applications to do their own state management and can expose them the app servers directly.

    3) Maintainability: Having layered, architecture is a better design. This however doesnot translate to these layers being on different applications, app pools or machines - and hence doesnot justify a different machine.



    Cost of additional machine: If the usage is low, and security is well covered - why invest on the extra machine(s).

    Network Delay. I will hazard a number here - a previous benchmark which I did few years back , indicated that calling a new machine, behind a firewall but on the local network introduces 0.3 seconds of delay and most of that is attributed to IIS. So if your application design has a very "chatty" interface to the app-layer, you probably should not put it in a seperate machine. To put it the other way round - having a seperate app server - like web services - forces you to make coarse interfaces.

    Extra Code: You need to introduce Remoting or web service interface to talk to the app server on different physical machine, you need to have that configurable. you probably need two setups instead of one.

    Logging: The biggest casuality of this is Logging. If you debug the production problem by logs, you need to give a though on how you will associate a call on the web server to one or more calls on the app servers. You cannot rely on tying the messages together by a thread id - which you could if everything were on the same machine.  If you think about it - it is not a trivial problem and it could force you to pass something like a transaction id in all public method invocations between web- app server.


    Wednesday, July 19, 2006 3:09 PM