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
- Database
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:
1. Presentation Layer
This layer is made up of Java Server Pages (JSP). JSP are basically HTML files with special tags having Java codes to provide dynamic content to the clients. Java Server Pages run on a Web server in a JSP servlet engine. JSP codes the presentation logic and takes care of client HTTP sessions. HTTP sessions have the information about clients sending requests to the Web server. Good programmers use HTTP sessions effectively to store and retrieve client information. Thus, clients do not have to send their identities to the server in each request as they are carried in HTTP sessions.
Please look at JSP at http://java.sun.com/products/jsp/.
2. Business Logic Layer
JavaBeans are the core of Business Logic Layer. JavaBeans bring component technology to the Java platform. With the JavaBeans API, you can create reuseable, platform-independent components. Using JavaBeans-compliant application builder tools, you can combine these components into applets, applications, or composite components. The purpose of JavaBeans in our architecture is to code business logic in them. Business logic is the implementation of various processes of an enterprise.
Please look at JSP at http://java.sun.com/products/javabeans/.
3. Data Access Logic Layer
The Data Access Logic Layer is composed of simple Java classes known as Data Access Objects (DAO). This layer is provided to separate the business logic and data access logic. DAOs use the Utility Layer’s connection pooling feature (discussed in the next section) to communicate with the database. Data is retrieved from database, bundled in proper Java objects, and sent back to JavaBeans for implementing business logic. This layer is vital from a performance point of view; the database connectivity and database operations are resource-intensive, so they should be managed with great care.
4. Utility Layer
As you see in the Figure 2, the Utility Layer spans all other layers. It has the vital features of connection pooling, security, and so forth.
Connection pooling is used by the Data Access Logic Layer (DAOs) and is responsible for maintaining a pool of connections to the database. Pooling is created when the first request comes from a client; thereafter, database connections are taken from the pool by DAOs. After the completion of the database work, DAOs return the connections to the pool for reuse.
The Security feature takes care of role-based access for the clients. The clients have to be authenticated and then authorized (depending on their roles) to get access to the system. To provide more features, which may be used by a different layer, implement them in the Utility Layer.
Feasibility of Proposed Architecture
The above-proposed architecture vastly suits small- to medium-size business applications. We prefer this kind of architecture for applications running in the boundary of an enterprise (on intranet) and concurrently used by 15-25 people. The applications should not be transaction-intensive (although lightweight transactions can be handled in the Utility Layer) because this requirement asks for more reliable and fail-over features from the architecture. Applications accessed by a large number of users should be handled by more scalable systems.
The best thing about our proposed architecture is that it can be extendable to sui above-mentioned large applications as well. For that, the designers and architects should look for features of J2EE application server (Enterprise Java Beans, Transaction, Messaging, Security, Clustering, and so on) and plug them into this architecture. For instance, Enterprise Java Beans can replace DAOs and implement transactions features. Security and Connection Pooling features of Utility Layer are already present in a J2EE application server. Various instances of application server can be run at multiple sites as part of a cluster to provide scalability and fail-over features to the system.
Summary
This article discussed the concepts of the enterprise environment and various applications that implement business processes in an enterprise.
We, then, proposed J2EE-based solution architecture, detailing its layers. This proposed architecture may not fit into all the system environments, so a brief feasibility study has also been provided.
About the Author
Manoj Seth is a senior software engineer at Hewlett-Packard, India. He is a Post Graduate from the Indian Institute of Information Technology, Bangalore.
Manoj has been involved in designing and developing J2EE-based solutions over various platforms in the domains of Financial/Banking and Middleware for more than two years. He has good exposure to Web Services and their emerging standards in development/deployment and management space. He can be contacted at manojseth_2000@yahoo.com.
