3-Tiered Web Architecture: Are Layers on Separate Machines Beneficial?

A client I'm working for has a standard in which they require the data layer of new applications to be wrapped into a web service, and placed a machine separate from where the business/presentation layer will be hosted. Could someone tell me what the benefits of doing this are? It seems to me that this causes more problems than it solves:

• Causes mu开发者_JAVA百科ch more traffic/CPU time - generating the XML soap requests/responses opposed to directly connecting to the database
• Difficult to debug - Need to debug two seperate projects opposed to one

I'm guessing it's potentially due to security concerns (where the presentation machine(s) are exposed to the Internet, and the data layer machine is not); however, I can't see how that's any more secure than connecting directly to the database: the account logging into the database shouldn't have anymore access than the web service wrapper would.

Am I missing something?

I think the reason behind is the same as it has been for wrapping domain and business logic into stored procedures. To provide safe access to the data to multiple application and clients running on different platforms while enforcing data integrity checks and other rules down there in the data layer.

The idea actually makes sense but the implementation idea is not perfect. If the data layer takes heavy traffic, then serializing and deserializing data would have huge costs in terms of performance and equipment requirements.

Like so many architectural questions, it can be a balancing act.

Certainly one benefit of having a 3-tiered web application split into having each tier on separate machines is that you can now potentially load-balance, separately, the various parts of the application. For example, you could have 3 web servers serving up only the GUI, this "cluster" would connect to a "cluster" of 3 application servers, all nicely load balanced and seen as a single "instance" to the web servers. Likewise, a similar situation with the DAL (Data access layer).

Separating the tiers in this way also allows a certain level of "decoupling" of the layers of the overall application. This allows each layer to be setup differently (i.e. could use different hardware or different OS etc.) and so long as the interface remains consistent, there shouldn't be a problem if any of the separate layers are changed around.

This invariably will have an impact on the software development, since the DAL/BLL/UI will now be separate assemblies (probably separately compiled DLL's or equivalent) and truly separate tiers, rather than merely structuring the code into separate layers within one application/project.

I have, in the past, exposed the Business Layer of a web application as a web service, and the web GUI was entirely written against that service. This allowed the company to sell the product as a hosted web-based solution that clients could use whilst also selling access to the very same product as a web service, thereby allowing clients to integrate the product's functionality into their own internal applications (ala vertical market solution).

Of course, there's the balancing act. Separating the tiers onto separate machines will introduce some complexity into the overall architecture of the system. You correctly point to a couple of potential issues, such as the traffic between the machines which will now add some level of overhead that would not be there if the communicating tiers were on the same machine. There's also the marshalling of data between each tier which also adds overhead. Certainly in the case of a web-service, serializing and deserializing complex objects can add significant overhead and negatively impact performance, especially if there's very heavy traffic.

Depending upon what is actually exposed to the users of the overall application, security on the "lower" tiers may or may not required. If you're only exposing the web GUI, the lower tiers should be configured to be inaccessible (other than via the web server), however, if you are exposing the "business layer" as well as the web GUI layer, then you will have an additional burden of securing multiple potential attack "surfaces" of you application.

Ultimately, though, if you know you're not going to need to load balance the separate tiers, and you know you're not going to need to switch out one tier, or expose the business logic separately from the web UI, it may well be more effort than it's worth.

Apart from the usual advantages of modular software with well defined interfaces, the three-tier architecture will independently allow any of the three tiers to be upgraded or replaced as requirements or technology change. Also you can have many front end servers for load balancing.

For example, a change of operating system in the presentation tier would only affect the user interface code.

Look at the banking industy your web access to account information still comes from a COBOL system.

I think it is quite odd to wrap communicate with the data layer via web services and I would not recommend that.

1. There are established standards to access a database (I guess you mean a database if you talk about a data layer) which access also remote databases (e.g. JDBC, ODBC, ...). So there is no real need to use web services.

2. If you use web services you get a ton of new problems, e.g. time outs, message integrity, message security, or reliable messaging which you have to deal with. This are all potential error sources.

3. Webservices have a huge overhead both in terms of latency and message size. To get a fast overall solution the webservices have to be coarsely grained. E.g. a webservice has to be the front end for an entire process like enroll a student (to keep the number of message exchanges low), but not fine grained like save the student's data, then append a program of study to the student's data, then append a new bill for some fees to the student's data, etc. (these are all a individual message exchange, but this is also a common granularitywhen accessing a data layer).

So I would really go for JDBC / ODBC communication with the data layer. Web services might really make more sense between the business layer and the presentation layer or third party applications (application integration).

Yes, this is common pattern for secure applications.

  - Database Node
        | (database access protocol)
  - Data Access Layer/Business Logic Layer Node
        | (web services/RMI/CORBA/other protocol)
  - Presentation Layer Node     

Usually web server is exposed in DMZ, so BLL/DAL need to be placed in another machine (node). Web services are used as "connection protocol". It's hard to break into DAL sever by web services and data are secured by another node. With web services exposed presentation layer might be implemented in free-form (Java, .NET, web client or desktop application).

So it sounds like you have the Web and Business logic on one server, and the Data Access code on a second server. That is unusual as the the business logic is generally seperate from teh web server and with the Data Access code on a separate server. The benefit to this is that all of your code logic (business) would live in the secure zone (not on a public facing web server) with your data access code. Your existing web services would then expose an API to the business logic, not just the data access code.