- A Brief Perspective
- J2EE Platform
- J2EE Patterns and J2EE Platform
- Summary
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 tierThe 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 tierThe 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 tierThis 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 tierThis 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.
Table0-1
Function |
Package Name |
Graphical user interface |
java.awt.*, javax.swing.* |
Database access |
java.sql.* |
Directory access |
javax.naming.* |
CORBA |
javax.rmi.CORBA.* |
Security |
java.security.* |
Input/output |
java.io.* |
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 componentsstandalone Java programs that run inside an application container.
-
Applet componentsJava applets that run inside an applet container, and which are usually supported via a Web browser.
-
Servlets and JSPsWeb-tier components that run in a Web container. Servlets and JSPs provide mechanisms for dynamic content preparation, processing, and formatting related to presentation.
-
EJB componentsCoarse-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.
-
HTTPStandard 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.
-
JDBCA standard API to access database resources in a vendor-independent manner.
-
JavaMailAn 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.
-
JMSAn 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 providerProvides 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 providerProvides 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 assemblerAssembles, 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 deployerDeploys the assembled application into a J2EE container. The deployer may deploy Web applications into containersWeb containers, EJB containers, and so onusing the tools provided by the J2EE product provider. The deployer is responsible for installation, configuration, and execution of the J2EE application.
-
System administratorHas 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 providerProvides 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.