Home > Articles > Programming > Java

  • Print
  • + Share This
From the author of

J2EE Platform

The previous section described the core technology components of the J2EE platform, such as servlet, JSP, EJB, JDBC, and JMS. In this section, we take a look at the J2EE architecture model and describe other aspects of the J2EE platform that complete the platform definition.

J2EE Architecture

The J2EE architecture is a multitiered architecture. See Default ¶ Font.

Figure 2.1 J2EE architecture

The J2EE architecture consists of the following tiers:

  • Client tier—The client tier interacts with the user and displays information from the system to the user. The J2EE platform supports different types of clients, including HTML clients, Java applets, and Java applications.

  • Web tier—The Web tier generates presentation logic and accepts user responses from the presentation clients, which are typically HTML clients, Java applets, and other Web clients. Based on the received client request, The presentation tier generates the appropriate response to a client request that it receives. In the J2EE platform, servlets and JSPs in a Web container implement this tier.

  • Business tier—This tier handles the core business logic of the application. The business tier provides the necessary interfaces to the underlying business service components. The business components are typically implemented as EJB components with support from an EJB container that facilitates the component life cycle and manages persistence, transactions, and resource allocation.

  • EIS tier—This tier is responsible for the enterprise information systems, including database systems, transaction processing systems, legacy systems, and enterprise resource planning systems. The EIS tier is the point where J2EE applications integrate with non-J2EE or legacy systems.

Java 2 Standard Edition

J2SE is the underlying base platform for J2EE, hence a brief discussion on the J2SE platform is relevant to the J2EE platform. The J2SE platform includes two deliverables:

  • Java 2 SDK, Standard Edition (J2SE SDK)

  • Java 2 Runtime Environment, Standard Edition (JRE)

J2SE SDK, formerly the JDK, is the Java programming language's core API set. J2SE provides the Java language functionality as well as the core libraries required for Java development. The core libraries are the classes within the java.* packages. In addition, J2SE provides auxiliary interfaces and libraries as extensions. It makes these standard extensions available as javax.* packages.

J2SE includes tools and APIs for developing applications with graphical user interfaces (GUIs), database access, directory access, Common Object Request Broker Architecture (CORBA), fine-grained security, input/output functions, and many other functions. See Default ¶ Font.



Package Name

Graphical user interface

java.awt.*, javax.swing.*

Database access


Directory access








Default ¶ Font shows the various components of the J2SE platform.

Figure 2.2 J2SE platform

J2EE Application Components and Containers

The J2EE component container supports application components in the J2EE platform. A container is a service that provides the necessary infrastructure and support for a component to exist and for the component to provide its own services to clients. A container usually provides its services to the components as a Java compatible runtime environment.

The core application components in the J2EE platform are as follows:

  • Java application components—standalone Java programs that run inside an application container.

  • Applet components—Java applets that run inside an applet container, and which are usually supported via a Web browser.

  • Servlets and JSPs—Web-tier components that run in a Web container. Servlets and JSPs provide mechanisms for dynamic content preparation, processing, and formatting related to presentation.

  • EJB components—Coarse-grained business components that are run inside an EJB container (usually bundled in an application server product). EJB components, or enterprise beans, come in two types: session beans and entity beans. Session beans are enterprise beans that are suitable for processing or workflow. Session beans come in two flavors: stateful and stateless. A stateful session bean retains client state between method invocations. A stateless session bean does not retain client-specific state between client-invoked methods. Stateless session beans are used when no state needs to be stored between method invocations, and they may offer performance benefits over stateful session beans, which must be used when some state needs to be retained between invocations. Session bean instances pertain to a single user session and are not shared between users. Entity beans are used when a business component needs to be persisted and shared among multiple users. Entity bean persistence can be managed in two ways: bean-managed persistence (BMP) and container-managed persistence (CMP). BMP is used when the bean developer implements all mechanisms for persisting the state in the bean. CMP is used when the bean developer does not implement the persistence mechanisms in the bean. Instead, the bean developer specifies the necessary mapping between the bean attributes and the persistent storage and lets the container do the job.

The core focus of the J2EE patterns in this book is the design and architecture of applications using servlets, JSPs, and enterprise bean components.

Standard Services

The J2EE platform specifies the following standard services that every J2EE product supports. These services include APIs, which every J2EE product must also provide to application components so that the components may access the services.

  • HTTP—Standard protocol for Web communications. Clients can access HTTP via the java.net package

  • HTTP over Secure Socket Layer (HTTPS)—Same as HTTP, but the protocol is used over Secure Socket Layer for security.

  • JDBC—A standard API to access database resources in a vendor-independent manner.

  • JavaMail—An API that provides a platform-independent and protocol-independent framework to build mail and messaging applications in Java.

  • Java Activation Framework (JAF)—APIs for an activation framework that is used by other packages, such as JavaMail. Developers can use JAF to determine the type of an arbitrary piece of data, encapsulate access to it, discover the operations available on it, and instantiate the appropriate bean to perform these operations. For example, JavaMail uses JAF to determine what object to instantiate depending on the mime type of the object.

  • Remote Method Invocation/Internet Inter-ORB Protocol (RMI/IIOP)—Protocol that enables Remote Method Invocation (RMI) programmers to combine the benefits of using the RMI APIs and robust CORBA IIOP communications protocol to communicate with CORBA-compliant clients that have been developed using any language compliant with CORBA.

  • Java Interface Definition Language (JavaIDL)—A service that incorporates CORBA into the Java platform to provide interoperability using standard IDL defined by the Object Management Group. Runtime components include Java ORB (Object Request Broker) for distributed computing using IIOP communication.

  • Java Transaction API (JTA)—A set of APIs that allows transaction management. Applications can use the JTA APIs to start, commit, and abort transactions. JTA APIs also allow the container to communicate with the transaction manager, and allow the transaction manager to communicate with the resource manager.

  • JMS—An API to communicate with MOM to enable point-to-point and publish/subscribe messaging between systems. JMS offers vendor independence for using MOMs in Java applications.

  • Java Naming and Directory Interface (JNDI)—A unified interface to access different types of naming and directory services. JNDI is used to register and look up business components and other service-oriented objects in a J2EE environment. JNDI includes support for Lightweight Directory Access Protocol (LDAP), the CORBA Object Services (COS) Naming Service, and the Java RMI Registry.

J2EE Platform Roles

The J2EE platform uses a set of defined roles to conceptualize the tasks related to the various workflows in the development and deployment life cycle of an enterprise application. These role definitions provide a logical separation of responsibilities for team members involved in the development, deployment, and management of a J2EE application. See Default ¶ Font.

Figure 2.3 J2EE platform roles

The J2EE roles are as follows:

  • J2EE product provider—Provides component containers, such as application servers and Web servers, that are built to conform to the J2EE specification. The product provider must also provide tools to deploy components into the component containers. These tools are typically used by the deployer. In addition, the product provider must provide tools to manage and monitor the applications in the container. The system administrator typically uses these latter tools. This role is fulfilled by the product vendors.

  • Application component provider—Provides business components built using the J2EE APIs. These components include components for Web applications as well as for EJB applications. This role is fulfilled by programmers, developers, Web designers, and so forth.

  • Application assembler—Assembles, or puts together, a set of components into a deployable application. The assembler obtains the application components from the component providers. The application assembler packages the application and provides the necessary assembly and deployment instructions to the deployer.

  • Application deployer—Deploys the assembled application into a J2EE container. The deployer may deploy Web applications into containers—Web containers, EJB containers, and so on—using the tools provided by the J2EE product provider. The deployer is responsible for installation, configuration, and execution of the J2EE application.

  • System administrator—Has the responsibility of monitoring the deployed J2EE applications and the J2EE containers. The system administrator uses the management and monitoring tools provided by the J2EE product provider.

  • Tool provider—Provides tools used for development, deployment, and packaging of components.

Deployment Descriptors

An application assembler puts a J2EE application together for deployment, and at the same time provides the assembly and deployment instructions in special files called deployment descriptors. The J2EE specification defines deployment descriptors as the contract between the application assembler and the deployer. Deployment descriptors are XML documents that include all the necessary configuration parameters required to deploy the J2EE application or J2EE components. Such configuration parameters specify external resource requirements, security requirements, environment parameters, and other component-specific and application-specific parameters. The deployer may use a deployment tool provided by the J2EE product provider to inspect, modify, customize, and add configuration parameters in these deployment descriptors to tailor the deployment to the capabilities of the deployment environment.

Deployment descriptors offer flexibility for the development and deployment of J2EE application components by allowing changes to configurations and dependencies as needed during the different application phases: the development, deployment, and administration phases. Much of this flexibility is due to descriptors defining parameters in a declarative fashion, rather than having the parameters be embedded in the program code.

  • + Share This
  • 🔖 Save To Your Account