Chapter 2.
Overview Of J2EE Technology and Concepts
The Java 2 Enterprise Edition (J2EE) is a multitiered architecture for implementing enterprise-class applications and web based applications. This technology supports a variety of application types from large scale web applications to small client server applications. The main aim of J2EE technology is to create a simple development model for enterprise applications using component based application model. In this model such components use services provided by the container, which would otherwise typically need to be incorporated in application code. Note this may not be ideal in all scenarios: for example, a small scale application might be a better fit for a light-weight Java technology solution (e.g. Servlets, JSPs, etc.).
J2EE Components :
J2EE applications are made up of different components. A J2EE component is a self-contained functional software unit that is assembled into a J2EE application with its helper classes and files and that communicates with other components in the application. The J2EE specification defines the following J2EE components:
Application clients and applets are components that run on the client.
Java Servlet and JavaServer Pages technology components are Web components that run on the web server.
Enterprise JavaBeans components (enterprise beans) are business components that run on the application server.
All these J2EE components are assembled into a J2EE application, verified to be well formed and in compliance with the J2EE specification, and deployed to production, where they are run and managed by the J2EE application server.
In addition to these primary components, it includes standard services and supporting technologies which are :
Java Database Connectivity (JDBC) technology provides access to relational database systems.
Java Transaction API (JTA) or Java Transaction Service (JTS) provides transaction support for J2EE components.
Java Messaging Service (JMS) for asynchronous communication between J2EE components.
Java Naming and Directory Interface (JNDI) provides naming and directory access.
Note : All J2EE components are written in the Java programming language
J2EE Clients :
There are normally two types of J2EE client: a Web client and an Application client as shown above in figure.
A Web client consists of two parts, dynamic Web pages containing various types of markup language (HTML, XML and others), which are generated by Web components running in the Web tier, and a Web browser, which draws the pages received from the server. Another category of web clients are sometimes called as thin client. Thin clients usually do not do things like query databases, execute complex business rules, or connect to any legacy applications. When we use a thin client, heavyweight operations like these are handled by enterprise beans executing on the J2EE server where they can leverage the security, speed, services, and reliability of J2EE server-side technologies.
A Web page received from the Web tier can include an embedded applet. An applet is a small client application written in the Java programming language that executes in the Java virtual machine installed in the Web browser. However, client systems will need the Java Plug-in and possibly a security policy file in order to execute applets successfully in the Web browser. Web components are often a preferred API for creating a Web client program because no plug-ins or security policy files are needed on the client systems. Moreover this allows cleaner and more modular application design because they provide a means to separate application logic from Web page design.
An Application client runs on a client machine and provides a way for users to handle tasks that require a richer user interface than can be provided by a markup language. It normally has a graphical user interface (GUI) created using the Swing or Abstract Window Toolkit (AWT) APIs. Application clients directly access enterprise beans running in the business tier. But if there is need for a web client it can open an HTTP connection to establish communication with a servlet running in the Web tier.
Note: If required, a command line interface can be used.
Web Components :
J2EE Web components can be either servlets or JSP pages. Servlets are Java programming language classes that dynamically process requests and construct responses. JSP pages are text-based documents that execute as servlets but allow a more natural approach to creating static content. HTML pages and applets are bundled with Web components during application assembly, but are not considered Web components by the J2EE specification. Similarly, server-side utility classes can also be bundled with Web components like HTML pages, but are not considered Web components by the J2EE specification. Shown below in figure is Web components communication.
The Web tier might include a JavaBeans component to manage the user input and send that input to enterprise beans running in the business tier for processing as shown above in the figure..
Business Components :
Business code, which is logic that solves or meets the needs of a particular business domain such as banking, retail, or finance, is handled by enterprise beans running in the business tier.
The figure above shows communication with business components, where an enterprise bean receives data from client programs, processes it (if necessary), and sends it to the enterprise information system tier for storage. An enterprise bean also retrieves data from storage, processes it (if necessary), and sends it back to the client program.
There are three kinds of enterprise beans: session beans (stateless and stateful), entity beans (bean managed and container managed), and message-driven beans. A session bean represents a transient conversation with a client. When the client finishes executing, the session bean and its data are gone. In contrast, an entity bean represents persistent data stored in one row of a database relation/table. If the client terminates or if the server shuts down, the underlying services ensure that the entity bean data is saved. A message-driven bean combines features of a session bean and a Java Message Service (JMS) message listener, allowing a business component to receive JMS messages asynchronously.
Note : Java Beans are not considered J2EE components by the J2EE specification as JavaBeans are different from Enterprise Beans. JavaBeans component architecture can be used in both server and client tiers to manage the communication between an application client or applet and components running on the J2EE server or between server components and a database, whereas Enterprise JavaBeans components are only used in the business tier as a part of the server tier. JavaBeans have instance variables and has an accessor and mutator methods to access properties of bean or say, accessing the data in the instance variables which simplifies the design and implementation of JavaBeans components.
Enterprise Information System Tier :
The enterprise information system tier handles enterprise information system software and includes enterprise infrastructure systems such as enterprise resource planning (ERP), mainframe transaction processing, database systems, and other legacy information systems. J2EE application components might need access to enterprise information systems for database connectivity.
J2EE Containers :
J2EE containers provide access to the underlying services of the J2EE Server environment via containers for different types of components. Traditionally, application developers have to write code for handling transaction, state management, multithreading, resource pooling etc. Now the J2EE container provides these services allowing you to concentrate on solving business problems.
Containers are the interface between a component and the low-level platform-specific functionality that supports the component. For example, before a Web, enterprise bean, or application client component can be executed, it must be assembled into a J2EE application and deployed into its container.
The assembly process involves specifying container settings for each component in the J2EE application and for the J2EE application itself. Container settings customize the underlying support provided by the J2EE server, which includes services such as Java Naming and Directory Interface, security, transaction management etc.
The J2EE server provides Enterprise JavaBeans (EJB) and Web containers. EJB container manages the execution of enterprise beans for J2EE applications, whereas Web container manages the execution of JSP page and servlet components for J2EE applications. Other than these two containers there are an Application client container and Applet container, which are not part of J2EE server as these reside on the client's machine as shown below.
An Application client container manages the execution of application client components whereas an Applet container manages the execution of applets. These are typically the JRE (Java Runtime Environment) and a Java-enabled Web browser respectively.
Packaging :
In order to deploy a J2EE application, after developing different components, it is packaged into special archive files that contain the relevant class files and XML deployment descriptors. These XML deployment descriptors contain information specific to each bundled component and are a mechanism for configuring application behavior at assembly or deployment time. These are bundled into different archive types for different component types.
Web components are archived in Web Archive (.war) file which contains servlets, JSP and static components such as HTML and image files. The .war file contains classes and files used in web tier along with a Web component deployment descriptor.
Business components are archived in Java Archive (.jar) file which contains an EJB deployment descriptor, remote, and object interface files along with helper files required by EJB component.
Client side class files and deployment descriptors are archived in Java Archive (.jar) file which make up the client application.
J2EE application is bundled in an Enterprise Archive (.ear) file which contains the whole application along with deployment descriptor that provides information about the application and its assembled components.
J2EE Platform Roles :
Building the different components of a J2EE application involves various roles in the development, deployment and management of an enterprise application.
The application component provider develops the reusable components of J2EE application, which can be Web components, enterprise beans, applets, or application clients for use in J2EE applications.
The application assembler takes all building blocks from the application component provider and combines them into J2EE applications.
The deployer is responsible for the installation/deployment of components in a J2EE environment or J2EE server.
The system administrator is responsible for configuration and administration of computing systems in an enterprise.
The tool provider is a vendor used to develop, package and deploy J2EE applications.
Note : All these above mentioned roles can be assigned to a person or an organization.
Distributed Architecture in J2EE :
All the J2EE applications implement a distributed architecture. In this an object is associated with a name, where names are provided by naming service, by advertising to various components and resolving client references to these service components as shown in figure below.
As a result of that, object references are obtained, by looking up for an object by its advertised name, once found, reference is obtained, and then carry out the necessary operations on that object using the host's services. A remote object advertises its availability with the name service using a logical name and the name service translates the name to the physical location of the object in the J2EE environment. Once the client request obtains a reference to a remote component, it can send requests to the remote component. The runtime system system handles the distributed communication between the remote objects, which includes serialization and deserialization of parameters.
Note : Various naming services used in distributed systems are RMI (for Java-only implementations), CORBA naming services, LDAP, DNS, NIS. The JBOSS application server uses RMI as its naming service.
Serialization and Deserialization are the same as marshalling and unmarshalling for those familiar with RPC terminology.
Java Naming Directory Interface (JNDI) Architecture :
J2EE uses the JNDI API to generically access naming and directory services using Java technology. The JNDI API resides between application and a naming service and makes the underlying naming service implementation transparent to application components.
A client can look up references to EJB components and other resources in a naming service as mentioned above. The client code remains unchanged, regardless of what naming service is used or what technology it is based on, as this doesn't make any difference to clients locating remote objects via the JNDI API.
