Proposing J2EE Based Architecture for Small/Medium Business Applications, Page 2
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
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.
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 firstname.lastname@example.org.
Page 2 of 2