J2EE is an open, standard-based, development and deployment platform for building n-tier, web-based and server-centric, and component-based enterprise applications. The evolution of enterprise application framework starts from single-tier mainframe based model in the beginning, moved to first phase of distributed framework, two-tier client server model, then three tier model.

Within the three-tier model, there are two communication models.  First one is  based on RPC (Remote Procedure Call) model in which non-object-based procedures are invoked by the client.  The other model  incorporates the concept of object in which remote object is accessed by the client. When the Internet took off, the three tier model takes a very radical transformation in which HTML browser talks to a Web server, which then talks to backend database or enterprise information systems.

The next two phases are advent of the concept of application server, first, app server based on proprietary architecture and API and the next phase is where we are today with open standard based app server architecture, which is what J2EE is all about.

Now if you think about the things that make up a typical enterprise application, they include presentation logic, business logic, data access logic, and system services.

The presentation logic deals with how to present information to the end-users. The business logic includes the business logic of the application.  And the data access logic deals with accessing data in the back-end database. The system services includes security, caching, logging, transaction, and other services that typical enterprise application would use. Now the way the enterprise application framework evolves reflects how flexibly you want to make changes in the presentation logic, business logic and data access and data models.  The other factor reflects how the system services are provided by the framework.

Single Tier (Mainframe-based)‏

In the beginning of computing era, the model is pretty much a single tier model in which dumb terminals are directly connected to a mainframe.  Here the mainframe is centralized point of computing intelligence in which presentation, business logic, and data access are all intertwined in a single monolithic mainframe application.


  • No client side management is required
  • Data consistency is easy to achieve
  • Functionality (presentation, data model, business logic) intertwined, difficult for updates and maintenance and code reuse


The next evolution phase is two-tier model. The two tier model appears along with the advent of personal computer, which was increasingly used as client platform of choice replacing dumb terminals. In two-tier model,  fat clients are talking to backend database by using some database access protocol such as SQL. The clients are called “fat” clients because the clients have to maintain presentation logic, business logic, and have to have detailed  understanding on data model of the backend data and how to access it.

  • DB product independence (compared to single-tier model)‏
  • Presentation, data model, business logic are intertwined (at client side), difficult for updates and maintenance
  • Data Model is “tightly coupled” to every client: If DB Schema changes, all clients break
  • Updates have to be deployed to all clients making System maintenance nightmare
  • DB connection for every client, thus difficult to scale
  • Raw data transferred to client for processing causes high network traffic

Three-Tier (RPC based)‏

The “difficult to upgrade clients”  problem of two-tier model triggers the advent of next one, three-tier model. The most distinguishing characteristic of three tier model is that now there is a separation between presentation logic from the other two.  That is, the presentation logic is handled at the client while business and data access logic are handled at the middle tier server.  In this sense, the clients of three-tier model is thinner than the ones in two-tier model.  And the changes of business logic and data model can be done more flexibly than two-tier model because the only place the changes need to be reflected are at the middle-tier server not at the clients. The three tier model, however, introduces an interesting problem of its own.  Now because the middle-tier server receives service requests from many clients at the same time, the middle-tier now has to deal with various system level issues such as concurrency control, threading, transaction, security, persistence, multiplexing, performance, and so on.

 Now as mentioned before, the three tier model can be further divided into RPC-based and Remote object based.  In  RPC based model, the clients and the middle-tier server are more tightly coupled than the object model because they have to agree upon on the implementation level (rather than interface level of remote object based model.)‏

  • Business logic can change more flexibly than 2-tier model
  • Most business logic reside in the middle-tier server
  • Complexity is introduced in the middle-tier server
  • Client and middle-tier server is more tightly-coupled (than the three-tier object based model)
  • Code is not really reusable (compared to object model based)‏

Three-Tier (Web Server)‏

Now a completely different three-tier model  has emerged as the browser has become one of the most pervasive form of user interface at the client platform.  In this model, the browser basically provides common presentation logic.  And the browser and the server communicates using a standard protocol, HTTP.  And the business logic and data model are captured in dynamic contents generation technologies such as CGI, servlet/JSP, or ASP.  These technology components in turn talk to backend database or enterprise information system.

  • Ubiquitous client types
  • Zero client management
  • Support various client devices
  • J2ME-enabled cell-phones
  • Complexity in the middle-tier still need to be addressed


J2EE 1.4 APIs and Technologies

The ones in red color are newly added features while the ones in blue color are the ones whose functionality is enhanced from the previous version.

Servlet & JSP

Servlet is a Java object  that extends the functionality of HTTP server by providing the capability of dynamic contents generation. It generates dynamic contents. Servlets are better alternative to CGI.

Servlets are
  • Efficient
  • Platform and server independent
  • Session management
  • Java-based

JSP, Java Server Pages, was introduced as a follow-on technology to the Servlet.  Even though the Servlet solves many problems associated with CGI for dynamic contents generation, it has one downside. The downside is that, under Servlet, the presentation, typically HTML pages,  has to be generated as part of the servlet Java code, for example, using printf statement.  What this means is that whenever you have to make some change to the presentation, the Java code has to be changed and then recompiled, redeployed. This in turn result in maintenance problem of your applications.  Also it makes web-page prototyping effort rather a difficult task.

JSP technology is built over servlet.  In fact, JSP pages when deployed get converted into servlet first.  Because it is built over servlet, it maintains all the benefits of servlet.  For example, all the ready-to-use objects in a servlet such as session objects can be also available to JSP page designers and custom tag developers.

Enterprise Java Beans

Enterprise Java Beans (EJB) is a server-side component technology, which enable the easy development and deployment of Java-based enterprise applications in the form of components that have to be enterprise-quality, meaning they are transactional, distributed, multi-tier, portable, scalable, secure, and reliable.

EJB leverages the benefits of component-model on the server side. It separates business logic from system code. It provides framework for portable components, over different J2EE-compliant servers, over different operational environments. It also enables deployment-time configuration.

Java Message Service (JMS)

Messaging systems (MOM) provide de-coupled communication and asynchronous communication. It plays a role of centralized post office. Benefits of Messaging systems are flexible, reliable, scalable communication systems. It is based on Point-to-Point, Publish and Subscribe architecture. JMS defines standard Java APIs to messaging systems.

Java Authentication and Authorization Service (JAAS)

JAAS addresses both authentication and authorization.  So let’s talk about authentication aspect of JAAS first. JAAS provides pluggable authentication framework.  It is expected that different business organizations would employ different authentication schemes.  Examples of authentication schemes they might use  include  userid/password based authentication, smartcard, Kerberos, or Biometric authentication.

The idea of JAAS pluggable authentication framework is to allow Java application that performs the authentication to be portable regardless of the underlying authentication schemes.  So JAAS provides authentication scheme independent API that can be used by the Java application.  There is also login configuration file that contains information on the authentication schemes that are deployed for a particular operational environment. And this login configuration file will be read by JAAS runtime.


Java Naming and Directory Interface utilized by J2EE applications to locate resources and objects in portable fashion. Applications use symbolic names to find object references to resources via JNDI. The symbolic names and object references have to be configured by system administrator when the application is deployed.


Provides standard Java programming API to relational database. It Uses SQL. Vendors provide JDBC compliant driver which can be invoked via standard Java programming API. There are lots of stuff available on JDBC, so we’ll not discuss it here anymore.

J2EE is an end to end Architecture

J2EE Application Development Lifecycle

The development life cycle of J2EE application is not that much different from the one of other Java application except that there are certain J2EE specific aspects such as deployment descriptor.

  1. First, as a component developer, you write and compile component code.  The component code again can be servlet, JSP, EJB.
  2. Then, you a write deployment descriptor again as a component developer.  As mentioned previously, deployment descriptor is an XML file that describes your J2EE components.
  3. Then these J2EE components will be assembled into a ready-to-deployable package.
  4. Then the package gets deployed over J2EE platform.

The Deployment Descriptor

Deployment descriptor is an XML file that specifies runtime instruction to the container regarding how system services are to be handled, for example, transaction, security, life-cycle, state management, persistence, and so on. It is called declarative customization because you are specifying the instruction in the XML file rather than in the code.

J2EE Application Anatomies

  • 4-tier J2EE applications – HTML client, JSP/Servlets, EJB, JDBC/Connector
  • 3-tier J2EE applications – HTML client, JSP/Servlets, JDBC
  • 3-tier J2EE applications – EJB standalone applications, EJB, JDBC/Connector
  • B2B Enterprise applications – J2EE platform to J2EE platform through the exchange of JMS or XML-based messages

Question arises which form of J2EE application should I build? The answer is “it depends”.  It depends on the requirements of application or even non-technical factors such as availability of EJB tier or availability of developer  resource.


Tagged with: JAVA

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>


Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!

Related News Feeds

Set your Twitter account name in your settings to use the TwitterBar Section.