Hi Forum
Does it make any sense to build a design that supports more than one physical seperation.
I'm making a web application and I need to make it secure and scalable.
I can see an idea in making it possible to physically seperate the presentation layer from the business layer. You can put the presentation layer in a DMZ.
Does it make sense to make it possible to physically seperate the business tier from the data tier
What requirements would justify such a design
I'm making a web application that is to run on a web farm in a hosting center. There is not reqirement that the data tier is to run on there other side of the planet.
I'm thinking mostly about security. I know that making physical seperation has a performance penalty, but does it make sense to make it possible to seperate the data layer from business layer in order to gain more security Or to gain something else
Example:
| = firewall
Does this make sense
| Presentation | Business | Data
Or should I go for this
| Presentation | Business Data
I'm thinking of making the first option possible. I'm thinking of designing it so that you via configuration can have the business layer call a remote object instead of calling the data layer directly. This design has some cost so I only want to do it if it makes sense.
I'm a little unsure whether I'm going overboard with physical seperation.
I hope someone can help me down the right path.
Physical seperation of layers - business layer -> data layer?
Ajeeth Kumar
First regarding the terms you use note that layer is logical and tier is physical
Also you should be aware that It is not so simple to just move a layer to a different tier - you may want to look at a blog I wrote on the subject "Tier is a natural boundary" as well as a paper I wrote on the fallacies of distributed computing http://www.rgoarchitects.com/Files/fallacies.pdf
The way you describe your layers it seems that options 3 and 4 would be good options as well as an option to host all layers on the same server (depending on the loads you are expecting)
Arnon
Jeanvo
I completely argee with Arnon's views and its the first time, I have seen different names being used for (potentially) physical and logical boundaries ( Tiers and Layers). Life would be lot simpler if that was a standard.
The only exceptions to option 3/4 that I could think of is if your data store was not thread safe, where you could choose to put a thread safe data tier seperately.
Pranshu
Sandrina
Data Tier means different to different people. Some consider it to be the database, while some consider it to be the application layer where connections to the database are held or OR mapping is done.
I will take the liberty of assuming that you are talking about database. If so, it makes a lot of sense to keep the database machine seperate as the databases are scaled vertically (so you want a bigger machine) while application servers are scaled horizontally (adding more machines).
Although I am not a security expert, but I have seen that datacenters which have common database cluster serving multiple applications for different business units or different customers, tend to have a firewall in between App and DB. Not otherwise.
Pranshu
mrdolby
Hi Pranshu
Thank you for answering my post.
I'm sorry for not describing what I mean by data layer. The data layer in my application is not the database. It is a layer of objects wich expose methods for CRUD operations. The operations hold ADO.NET code for performing the operations on the database. Like using a Command objects to call a stored procedures. The business tier will be able to start a transaction and call mulitple operations on the data layer and then commit it.
Does it make any sense to physically seperate the two The idea of a DMZ is to not have a server exposed dicrectly to the internet which hold information on how to connect to the database. I'm guessing that I'm moving the location of the information even further away if I could actuall physically move the data layer to the database server.
Maybe I could ask another way. Does any of the solutions below not make sense.
| = Firewall
1.
| Web Server (Presentation tier) | Application Server (Business tier) | Database Server (Database + Data Tier)
2.
| Web Server (Presentation tier) | Application Server (Business tier) | Data Application Server (Data Tier) | Database Server (Database)
3.
| Web Server (Presentation tier) | Application Server (Business tier + Data Tier) | Database Server (Database)
4.
| Web Server (Presentation tier) | Application Server (Business tier + Data Tier) Database Server (Database)
I'm thinking of designing the application to support solution 1. But it will most likely be running as solution 3 or maybe 4 if the last firewall does not make much sense. I have a feeling that solution 2 would kill the application because of the overhead of all the physical seperation. But designing an application to support solution 1 - would that also be going overboard
jim_cool
Arnon, I agree with you with the tiers and layers and that how it gets configured depends on the load and many other parameters....
However, siteadm... if we talk about typical 3-tier applications as you mention.... the most common scenario is to have web servers hosting presentation layer and application servers hosting business and data layer.... like 3 or 4.
However in some cases solution 1 makes sense.... but those are some special cases.... for example when your data source is not a database.... but it is some resource that is not optimized to be accessed remotely (let's say filesystem for example or some other resource)
I hope you understand what I meant.
Rgds
Rodrigo
bond12
Hi Pranshu
In your blog http://pranshujain.wordpress.com/2006/09/02/ooad-for-project-managers-and-other-design-concepts/
i liked the way you put the pictures for OOP, Structured and sequential.
What about SOA, would you use the same picture of OO for SOA also.
Thanks,
Sailu