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?
--SY
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,
--gp
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.
--AK
Rocky has a great post on this.
http://www.lhotka.net/WeBlog/PermaLink.aspx?guid=efa88d0a-2388-4909-bee1-c9bddb6e9868
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."
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.
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.
Thanks
Shekhar, Application Architect
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.
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.
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
http://today.java.net/jag/Fallacies.html
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
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/webapp/iis/iis6perf.mspx
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.
Regards,
Anjana
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.
Regards,
Anjana
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 )
Prasanth
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
http://cs.jaxdug.com/blogs/davidstrommer/
As you point out, Anjana, there are multiple hosts available. But Microsoft's mainstream application server is Windows Server itself.
http://www.microsoft.com/windowsserver2003/appserver/default.mspx
