What is the additional functionality incorporated in n tier architecture
Answers
The classic tiers included the client, middle (or business) and the database. However, I have seen a different breakdown that can include more than that as follows. Client, Web, Business, Integration, and Resource. The ‘Client Tier’ is meant to be things like your web browser (or application clients if they make requests against your Web or RESTful services). Perhaps some would call a React or Angular app another tier. The Web tier is for things like MVC frameworks—JSF, Struts, Spring MVC (Ruby / Rails?). Probably you could group RESTful interfaces here since they run in “servlet space” (servlets, interceptors, filters). The Business tier is going to be code that does things to synthesize the kind of data from the database and at the granularity that you need to hand off to the client. Classically this was EJBs or Spring. The lines could be blurred a bit if you use RESTful. But it may still be a good idea to put something behind RESTful services for a business tier. This tier is seen as API(s) to be used by the Web or Client tiers. The Integration tier is for adapters. At first blush these look like mere APIs since they will have stuff like JDBC libraries (or JPA/Hibernate). But they can include things like pooling of connections. Note: web, business and integration tiers are often co-located on a single server. However, they can also be moved vertically to other servers as needed. Beyond the adapters lies the “Resource” tier. This includes the database (classically a Relational Database Management System, but more and more this includes NoSQLs like MongoDB, Cassandra, graph databases, etc. This is also where something called an EIS (Enterprise Information System) such as PeopleSoft or SAP will reside. These tiers exist as a way to enable separation of concerns and scalability. You have different load characteristics in business vs web tiers so you tease that apart. You also get different frequency of change in web vs middle (usually) so separating them avoids having to change some parts of the code as often. For a small application with a few active pages, you probably won’t need all that: it can be burdensome to have to “cut holes” through multiple tiers if you want to add a new service. You also add overhead if you marshal things into different formats or transfer objects, or if you have to move things over a network to the next tier. It’s all about balance, and what works for your application.