Proposing J2EE Based Architecture for Small/Medium Business Applications
We are not able to think of the name of a single enterprise in this modern information technology era that does not have different applications (ranging from simple to vastly complicated) implementing its internal processes and exposing them to their partners (buyers, suppliers, customers, and so forth). To survive in this competitive environment, enterprises have to perform their processes and deliver products/solutions efficiently, at lower prices. By automating various processes within the enterprise, one can be cost-effective with higher qualities of its services/solutions/products in the market.
The aim of this article is to introduce small/medium size Web-based applications and propose a simple J2EE-based architecture. We will also explore the feasibility and limitations of this architecture in different scenarios.
Introduction to Small/Medium Size Web-Based Applications
Just consider an enterprise environment, where all of its internal departments want to automate their processes and systems in a very simplified manner. The most common core requirements of the resulting automated system are as follows:
- System should be accessed over the intranet/Internet.
- System should be secured enough.
- System should be able to handle 15-20 concurrent users (typically for small size application).
- System should not be expensive.
- System architecture should be flexible enough to be upgraded to medium-/large-size system.
- System should perform optimally.
The readers can visualize this enterprise scenario by viewing Figure 1:
Figure 1: Enterprise View
This figure depicts an enterprise boundary, which has various departments. Each department has different applications running in its boundary. The enterprise is exposed to its customers and partners. Please note that we have shown only internal applications running in a department of the enterprise; there may be various other applications running across the boundaries of departments (this way, departments communicate with each other). Similarly, there may be applications running inside a department and talking to each other and sharing information.
The applications of this sort are basically of small/medium size, unless they are really running at multiple sites and accessed by a very large number of users.
Our intention of showing these kinds of applications is to bring the readers in the context of applications we will be addressing and to prove the feasibility and limitation of the architecture we are going to propose.
Proposing J2EE-Based Architecture
Based on some of the above-mentioned requirements, we can visualize our system/application being accessed by different clients for different purposes. For each purpose, our application will have business functionalities/rules/logic. For storing information, application will also have a database (might be a file system or any other data store).
We hope, now, that the readers have the following solution components in their minds:
- Different clients
- Application having the following layers:
- Presentation logic
- Business logic
- Database access logic
Now, let us translate all the preceding components in J2EE-based solution architecture; see Figure 2:
Figure 2: J2EE-Based Architecture
Please note that the people designing or architecting a system such as this have the flexibility of inserting layer(s) in this architecture according to their requirements. This proposed architecture is for their reference on which they can build the systems.
To understand the architecture, let us go in detail for each one of the layers: