Each module which has been developed will be performing a unique responsibility. When a module is responsible for a single task, it will be called cohesive. The cohesiveness will make the module more maintainable. Also, it will be less frequently changed. A good design perspective is to try writing a module which will be highly cohesive.

The two modules developed separately will now need to have interaction. To make them interactive, we have to introduce them. This will be done by making them dependent on each other. This dependency is termed coupling. When the code size and number of modules are small, coupling won't be a problem. But in an enterprise application, the code size is huge. Any little change makes a difference and then all of its dependencies should be changed accordingly at a number of places. This makes the code unmanageable. So it's always recommended to have loosely coupled modules.

The pluggable component which can be easily integrated into the application will provide the solution to a particular problem. For example, we want an Eclipse to support Subversion (SVN) (one of the versioning tools). Now, we have two choices. One, to start the development of Eclipse again from scratch or, two, to develop an SVN application. If we choose the first choice, it's very time-consuming and we already have Eclipse in a working condition. Then why start it from scratch? Yes, it's a very bad idea. But it would be great to have an SVN solution to be developed separately which is an SVN plugin; this plug-in can be easily integrated into eclipse. See how easily the two modules— eclipse, which was in working and the new SVN module—have been integrated. As SVN is a separate module, it can be integrated with NetBeans (one of the IDEs). If we had developed it in eclipse, then it would not be possible to integrate it in any other IDE. When we develop any application, from our point of view, it's always the best. But being a good developer, we need to be sure of it. How to check whether the application we have developed is working fine for the aspects or not? Yes, we need to test it, whether each part is working correctly or not. But is it really so simple? No, it's not. Not just because of complicated logic but due to its dependency. Dependency is a factor which is not under the control of the developer. For example, we need to check whether my credentials are correct or not when I am trying to login. We don't want to test the tables where the data is stored, but we want to check whether the logic of tracking the data is correct or not. As we have developed a separate data access module, the testing becomes easy. In Java, a single functionality can be tested with JUnit.

Testing helps the developer to test an application which processes the data and provides an output. If we are getting the correct result, we do not have a problem, but what if the output is wrong? The process of finding bugs in a module is called debugging. The debugging helps us to find defects in an application. That means we need to track the flow and then find out where the problem started. It's quite difficult to find the defect if the system is without modules or if the modules are tightly coupled. So it's good programming practice to write an application which consists of highly cohesive, loosely coupled modules.

There is one more fact which we need to discuss here. Sometimes, when the actual main development is progressing, we come across a point where we actually want to add a new feature. This new feature was not added while the basic discussion was going on; here, we want to do parallel development. In this case, we don't want to replace the previous development but we want to support or enhance it. As our application consists of modules, a developer can go ahead as most of these modules are independent and can be reused.

An enterprise application where all the components reside on a single computer will be called as a one-tier application. These applications can also be called single-tier applications. So we can broadly say that these are the applications which get installed and run on a single computer.

For example, an Eclipse application as software. When we install eclipse and launch it, it will be running on our personal computer. It doesn't require any network. The presentation layer, that is, Swing GUI, business logic, and storing information in a filesystem will be done on the same computer.

A one-tier application

When the enterprise application gets divided over two computers, it will be called a two-tier application. Generally the data storage, that is, the database, will be moved onto a separate, dedicated computer. This will work as a database host machine or database server. The presentation layer and business logic layer will be residing in one location and data layer will be residing in another.

An example of this is the Oracle database management system. When we want to use an Oracle database, we will install Oracle on a dedicated machine which can be called as the Oracle server. Now, on the user's machine, we can install the Oracle client. Whenever we want to fetch data from the table in Oracle, we will use the client application, which will connect to the server and give the required data.

A two-tier application

When in an application, the presentation layer, business layer, and data layer will be running on their dedicated servers and interact with each other through a network, it will be called a three-tier application. The web server is dedicated to the presentation layer, the middleware server is dedicated to the business layer, and the database server is dedicated to the database layer. The middleware server can also provide services such as transaction and connection polling.

For example, any online shopping application can be considered a three-tier application. Let's see how. In this application, the products will be displayed on a browser in presentation pages. The business logic part, such as the calculation of discounts, the total amount which the buyer has to pay, and so on, using transaction or messaging services, will be provided by the application server. The buyer's information, product information, bank details, delivery address, and so on, will be saved in the tables on the database server for further reference. That means the presentation tier, application tier and data tier are the three tiers which play roles in this application.

A three-tier application

With the increase in the use of the Internet, it's very important for an application to be capable of serving many requests at the same time. This puts a burden on the server. In terms of performance, it's a better solution to take away the presentation layer from the business logic and deploy it separately. It can be deployed on one dedicated web server or may be on different servers. In the same way, the business logic and database layers can be separated on different servers partially or completely residing in one or more machines.

The client tier, presentation tier, business tier, and database tier are separated on separate machines. They interact with each other through a network and perform their services. This will be called an N-tier application.

An N-tier application

Now, these tiers which consist of layers will be used to create an enterprise application. But just by making parts of application, we cannot be sure of having a complete solution. Each application has its own challenges, but if we keenly observe them we will find that numerous functionalities are common, irrespective of their problem statement. That means instead of a new team of architect designers fighting for the solution to their problem every time, it will be good to have an answer which is a generic solution for reference. These references will be used to build applications called design patterns.

Christopher Alexander says, Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solutions to that problem, in such a way that you can use this solution a million times over without ever doing it the same way twice.

Each pattern provides a solution to a sort of problem and gives a result quickly. Let's have a quick overview of design patterns. The design patterns are normally classified as creational, structural, and behavioral patterns, which are subclassified as shown in the following table:

Frameworks such as Struts and Spring have been built upon these design patterns. Struts uses the front controller design pattern and Spring uses the MVC design pattern for ease of development. The use of frameworks has made the developer's life easy.

High performance, faster processing, and good look and feel are the keys to success for enterprise applications. Due to dedicated servers, the tasks of designing, developing, and data storing will be leveraged to handle specialized tasks, as discussed above in the N-tier applications section. In spite of providing just basic things, the N-tier enterprise application needs a bit more. Let's have a look into what else an enterprise application may need.

It's a festive season. The bank has consecutive holidays. I need to withdraw some amount from the ATM, say, for example, x amount. I enter the password and all other required details. Now I am just waiting for the money. I get a message of withdrawal on my mobile as well but… as the ATM doesn't have any money, I haven't received it. The money has been deducted from the account but not received by me. Now what??? Am I going to be in loss? Is there any way to revert what went wrong? Yes, certainly!! Here, we need to take into consideration transaction management. A transaction is a bunch of consecutive operations which take place one after another; either all of these should be completed successfully or none of them. The transaction helps the developer to maintain data integrity. Using this transaction management, the logic has been developed to rollback all such unsuccessful operations. Using this concept, the debited amount can be reversed and credited to my account again. Thank God, I got my money back!!!!

There are many such ATM centers in the city. And the same banking application will be used by many users at the same time. So the application will have multiple requests. All these requests have to be handled in sync. This is possible only if the application supports multithreading, which technically we call concurrency.

The ATM is one of the ways to perform banking operations, but today we can even use the Web for these tasks. On the Internet, the request will be sent to the server and further processing happens. As this is a remote process, authentication and authorization is important for recognizing that the user is genuine. This is normally done by using a unique username/password pair which the user enters. The sensitive data will now be transferred through the network; this can be hacked. So such applications should provide secure service layers, which are the URLS with the prefix https. We are doing all this to achieve a very important service, that is, security. Security helps to minimize hazardous attacks on the web application.

Do all such services have to be developed by the development team? Well, not completely: in N tier applications, we do have a middleware server. This server can also be called a container. This container will provide services such as transaction management, security, connection pooling, caching, and concurrency.

Enterprise architecture

As versioning has become a very important part of software development, there are many such tools available. These tools are basically divided in two categories:

The architecture of SVN

There are two consistent parts of Subversion: one is the repository which stores all of the versioned data and the other is the client program that manages the local reflections.

The architecture of Subversion

The repository

The central store where all the versioned data is stored is called the repository. The repository normally stores the data in the form of a filesystem tree. A number of clients can get connected with this repository to pass the data in the repository so as to make it available for other teammates. If any teammates want to get the data, they just have to read the repository and the data will be available. The repository keeps a record of each and every version of a file. The repository doesn't only give the reflection of the changes but helps the developer to check what changes have been made, who made them and when. Also, if they are interested in any specific version, they can read it from the repository.

So a version is nothing but a new state of the file where the changes took place.

The repository and the sharing of files

Now, we need to understand here the stages of a file.

If any developer creates a new file in his local system, it's not yet known to SVN. So the first task of the developer is to copy this file in SVN, which is called as svn add. Whenever we write the file (new or modified) to SVN, the process is called as committing. Once the file is committed, it's under SVN and now can be available to other team members. But to use this file, other team members have to take this file into their local system; this will be called as checkout. Once any developer gets their file, they are free to use it the way they want. Now, this local copy file will be known as a working copy.

The client program

We can use SVN through the command line. But then we need to remember all the commands for different operations. So instead of using the command line, a UI application can be used. This can be used to commit, checkout, and update the working copy. One such free application with an easy UI is Tortoise SVN, which has been implemented as a Windows shell extension. Using Tortoise SVN, developers can get rid of the command line. Tortoise SVN can easily be integrated in IDEs such as eclipse and Visual Studio.