An Introduction to J2EE

Posted on
Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone

The Java 2, Enterprise Edition (J2EE) platform has been a global market-leading enterprise platform for the past several years. But like any large technology, J2EE requires a significant time investment to learn.

While no single article can provide exhaustive coverage of this huge technology base, by the time you’re through reading, you’ll know the “lay of the land,” understand the basics of the system design and be ready to explore the topic in more depth.

Design Goals
J2EE was designed to be an integrated, extensible framework for enterprise software development. Specific goals affect the design of all of its technologies, including:



  • Platform vendors compete on implementation, not on design. J2EE is not a software product. Instead, it is a set of related specifications that describe in detail the interfaces that a J2EE system must provide. Platform vendors and experts collaborate to develop the specifications that lay out the minimum functionality required for each technology. The vendors then compete to provide the best implementations of the specifications. This arrangement helps customers because it minimizes vendor lock-in.
  • Create a market of software components. Many key J2EE technologies are explicitly designed as software components that can run in any platform implementation that conforms to the specifications. Packaging, distributing and installing components as components allow third parties to sell servlets and other J2EE components as drop-in solutions for anyone with a J2EE platform implementation.
  • Integrate with existing and future technologies. J2EE interfaces are extensible. As new technologies become available, new interfaces can be created, and old interfaces can be extended and revised.
  • Run on any hardware. The portable Java runtime decouples applications from hardware, letting customers choose hardware to fit budget and business needs. Component providers can distribute the same binary to all of their clients.
  • Let developers focus on application logic. A J2EE platform implementation provides a much higher level of service than an operating system can provide. The platform implementation handles such everyday but complex tasks as checking permissions, managing threads, load balancing, persisting data and so on. This lets the application and component developer focus on writing code that solves business needs.
  • Provide availability, security, reliability and scalability. The technology specifics all address one or more of these goals.


Tiers & Technologies
The J2EE platform provides a layer of enterprise application services on top of the Java 2, Standard Edition (J2SE). So J2EE requires a J2SE runtime installation.

The basic J2EE programming model is component-based. A J2EE application is simply a collection of intercommunicating components that together support business processes. J2EE programmers create business logic components, package them in a “deployment unit” (essentially a ZIP file with a defined structure and file extension), and then deploy the components to a server using tools provided by the platform vendor.

Each component type in J2EE corresponds to a specific application tier. Sun Microsystems’ best-practices program for Java technology defines four tiers:



  • The client tier contains the programs employed directly by users to interact with the system.
  • The Web tier contains components and services that process HTTP requests.
  • The EJB tier contains distributed business logic components called Enterprise JavaBeans (EJBs).
  • The EIS (Enterprise Information Systems) tier contains databases, legacy business data and systems, and adapters that provide data access to the other tiers.


J2EE simplifies development by defining the concept of a component “container” for each tier. A container is a set of interfaces that components use to access system services. Each tier has a different set of components and a corresponding container. The container for that tier hosts the component instances and manages access to them. Component object instances “live inside” a container, meaning that the container creates and destroys the instances as needed. The container is the runtime environment of a component. Any external service needed by the component is provided by the container.

A container controls how clients access components. All access to the component by its clients is mediated by the container, allowing the container to add functionality like security, logging and transactions to the components it hosts.

Imagine you wanted to serve HTTP requests dynamically. You consider using a CGI program, but then you realize that you’ll have to write code to support load balancing, session state maintenance, security, internationalization, cookie management, query string parsing and several other tedious things. So instead, you choose a J2EE Web server. You decide to write your HTTP request handler as a servlet, which is a Web-tier J2EE component that services HTTP requests from within a J2EE-enabled Web server. Your servlet code looks like this:


public class YourServlet extends HttpServlet {


   public void doGet(HttpServletRequest req,


           HttpServletResponse res)


                throws ServletException, IOException {


   String yourName = req.getParameter(“yourName”);


       PrintWriter out = res.getWriter();


       out.println(“Hi, ” + yourName + “!”);





Your servlet subclasses HttpServlet, a class that is defined by the server. Since the class implements the doGet() method, the servlet can handle HTTP GET requests.

The servlet component relies on the Web container for all information or services it needs. The container receives HTTP requests, parses GET query strings or POST variables, and dispatches method calls to servlet instances to handle the reques

Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone


Posted in Archive|