How many tiers do you need?

We have a web-app that consists of web-tier (PHP), app-tier (Java) and DB (mysql). web-tier communicates with app-tier AND with DB to retrieve some data. One of our clients 开发者_如何学Pythoninsists on separating each tier with a firewall and blocking traffic from web-tier to DB. They claim that this is insecure and app-tier needs to have the "get data" function that will be used by web-tier instead of reading data directly from DB.

It seems like a real waste to tunnel data through app-tier when it can be easily accessed by web-tier directly from DB. Read-only data can come from highly-optimized views and can be presented as-is. This greatly simplifies the design and removes additional problems like paging. The technique is known as Fast-Lane-Reader and advocates retrieving tabular read-only data directly from DB. For updates the app-tier is used where business rules are applied.

So my question is whether this 3-tiered firewall-isolated topology can be adjusted and allow direct traffic from web to db tiers?

Thanks in advance, Philopator.

I'm not so sure I buy the whole security angle, but I do think it is wise to limit/eliminate direct chatter between the presentation tier (web app) and the data tier (database) to clearly delineate the separation of concerns.

For one thing, it encourages code re-use and encapsulating business logic rather than spreading it out throughout the application. For example, if you ever had multiple front ends (desktop, web, mobile) the duplication of logic would be minimized.

Secondly, it helps to future proof your application somewhat. For example, if you went from PHP to ASP.NET or a Mobile OS front end it would minimize the work involved to the relevant parts to display the data.

All in all, it is probably a good idea anyway. If there are some benefits in terms of the security architecture. Bonus.

I would suggest you explain to your client how you define "value" and let them explain to you how they define it. My guess is you are not on the same page. It sounds like you value fast and cheep over quality (of design). Does your client agree with this approach? It sounds like they are more concerned with quality of design than fast and cheep. If this is the case, I'd listen to your client (since they are paying you, - and they should be willing to pay for that quality). Maybe after a conversation about defining value your customer will see it your way. Maybe not.

There are valid reasons - namely maintainability and extensibility - for keeping your PHP layer away from the DB layer (and only accessing data via the Java middle tier).

Just think of the maintainability reason:

A middle tier such as your Java layer acts as a facade. The database schema can be changed (for whatever reason) at any time, and your PHP layer does not need to care about that (meaning you don't need to update anything in your PHP code). Only the Java layer needs to be updated. The Java layer maintains a consistent interface (for your PHP code to write against).

Now, if you change the DB schema while both the Java and PHP layers access it directly, BOTH layers will have to be updated. This is a brittle design (a maintenance nightmare), and especially bad if you are not in charge of both the Java application layer AND the PHP layer.

Philopator, I would say the point is not in having firewalls to block communication between FrontEnd (PHP) and DataLayer (MySql), even without any firewall it is usually not good to have a direct link UI -> Database.

In your case you even have a nice middle-tier done in Java, I would definitely tunnel everything through the java layer in order to fully decouple UI and Database.

Don't be afraid in performance issues normally there aren't any or could be addressed, and I do think you can do everything like accessing views or stored procedures, paging sorting an so on having your calls started from the java component instead of the php presentation layer.

To give a real-world, "today-proofing" benefit of going through the app layer, think of it like encapsulation. You should only have one way of setting/getting a particular piece of data, because you only want validation/formatting/filtering in one place.

Imagine you have a WidgetService.addWidget() service method in your java code. You want to make sure all widgets are of types the current user is allowed to work with, so addWidget() checks the permissions for that. Now if your PHP code tries to add a widget to the database directly, it bypasses those checks.