Home
J2EE Overview
A framework and set of specifications for designing, deploying, and managing portable Java-based distributed component software.
What is J2EE
The Java 2 Platform, Enterprise Edition defines a simple standard that applies to all aspects of architecting and developing multi-tier server based applications. J2EE defines a standard architecture composed of an application model, a platform for hosting applications, a Compatibility Test Suite (CTS) and a reference implementation.
The primary concern of J2EE is the platform specification - it describes the runtime environment for a J2EE application. This environment includes application components, containers, resource manager drivers, and databases. The elements of this environment communicate with a set of standard services that are also specified.
APPLICATION COMPONENTS AND CLIENTS
Application components
can be packaged in JAR files and include a deployment descriptor, giving platform independent information to the container that manages them

Application clients
are Java programs, such as a GUI, that executes on a desktop computer. They have access to all the facilities of J2EE as they run in a container and run in their own Java Virtual Machine (JVM).
An application client is packaged in a JAR file and may be used to run the presentation logic of an application.

Stand-alone applications or programs that do not fit in any of the other categories can be placed in this one.


Enterprise JavaBeans
are components deployed, managed and executed on a J2EE server. Their environment must support transactions. Enterprise beans usually contain the business logic for a J2EE application; they interact with the databases.
The Enterprise Java Bean architecture described in the EJB specification defines the contract enabling Java code written by multiple vendors to interoperate in a distributed programming environment. The reusable code components are referred to as Enterprise Java Beans. EJBs add the scalability and reliability aspects inherent in industrial strength server applications

Applets
An applet is a component that typically executes in a Web browser. It is a Java class that can also run in a variety of other applications or devices.

Servlets and JavaServer Pages
are components used to handle HTTP requests from Web clients. They generally process the presentation logic of an application. Servlets can also act as a controller of an application and provide several services such as session management.

A Servlet
is a Java program extending the capacities of a Web server. A Servlet interacts with a user through a request response paradigm and, basically, generates dynamic content.

JavaServer Pages
is a technology used to return dynamic content to a client (in its Web browser, for example). It uses HTML or XML elements, server-side Java objects, custom and scripting elements to process requests.

Servlets and JavaServer Pages are deployed, managed and executed on a J2EE server and are generally called
Web components”.

Enterprise Java Beans
EJB's incorporate several Java technologies to support scalable, secure client-server applications:
  • JDBC — database access
  • JNDI — Java Naming and Directory Interface
  • JTS — Java Transaction Service
  • JSP — JavaServer pages
  • Servlet
  • RMI — Remote Method Invocation
  • JMS — Java Message Service
Additional functionality is achieved via the use of
CMP (container managed persistence) and BMP (bean managed persistence) for entity beans. Similarly, session beans can be either
stateless
or stateful.
Since container-managed persistence transfers a great deal of the burden for transaction management and other enterprise concerns to the application server, CMP is considered to be a heavyweight implementation, and careful consideration should be given to when to make a Java Bean container-managed versus bean-managed..
Standard Services - J2EE components may use a set of
standard services to interact with each other.
HTTP and HTTPS
The HTTP protocol is the protocol used across the Internet to get objects from remote hosts.

A J2EE platform must implement this protocol: the client-side API is defined by the java.net package which provides the classes for implementing networking applications.

The server-side API is defined by the Servlet and JSP interfaces.

For HTTP layered over the Secure Socket Layer protocol (HTTPS), the same client and server APIs as HTTP are required to support this protocol.
Java Message Service (JMS)
This API defines a standard mechanism for the components to send and receive messages. The API is required to be available on a J2EE platform but not implemented. It enables the use of enterprise messaging systems (IBM MQSeries, for example).

JavaMail and JavaBeans Activation Framework (JAF)
The JavaMail API allows an application to send e-mail notifications.

JavaMail includes the JavaBeans Activation Framework API (JAF).
Java Naming and Directory Interface (JNDI)
This API allows the J2EE components to look up other remote objects that they may need to access. The JNDI API was designed to standardize access to a variety of naming and directory interfaces and has two parts:
  • An application-level interface: these APIs are used by the application
    components to access naming and directory services.
  • A service provider interface: this part of the API is used to attach a provider of a naming and directory service to the J2EE platform.
Java IDL
IDL stands for Interface Definition Language. This API allows J2EE application components to invoke external CORBA objects using the IIOP protocol. These
CORBA objects are completely independent of the J2EE application (they may not be Java objects) and may be used by other applications.

Java Transaction API (JTA and JTS)
The JTA API provides a way for J2EE components and clients to manage their own transactions. It also allows multiple components to participate in a single transaction. JTA is the API, and JTS is the implementation.
The application-level interface of the API is used by the container and the application components to demarcate transaction boundaries. The second part of the API defines an interface between the transaction manager and the resource manager used.
JTA does support two phase commit.



Remote Method Invocation — Internet Inter-ORB (IIOP) protocol
This API supports the use of the RMI APIs with the IIOP protocol. RMI-IIOP allows J2EE applications to access CORBA services defined by components living outside the J2EE product. This API will also be used to access Enterprise JavaBeans Components in an application.
Resource Managers and Databases
The last elements of a J2EE runtime environment are the resource manager drivers and the database. A resource manager provides access to a set of shared resources. From the J2EE point of view a driver will implement network connectivity to an external resource manager. This driver can extend the functionality of the J2EE platform by implementing one of the J2EE standard service APIs or by defining and implementing a resource manager driver for a connector to an external application system (MQ Series for example). The provision for connecting to a database is included in the J2EE architecture. This database is accessible through the JDBC API. Web components, enterprise beans and application clients may access the database (applets do not need to)
Java DataBase Connectivity (JDBC)
JDBC is the standard API that enables connectivity with database systems. An application’s components can use JDBC to handle data from relational databases and other repositories.

The JDBC API can also be divided into two parts,
- an application-level interface used by the components for accessing databases;
- a service-provider interface to attach a provider to the platform.

JDBC provides a loose coupling which allows easy replacement of the data store

ODBC - JDBC Comparison
There is a close mapping between both architectures because they are based on the same standards.
JDBC is easier to use than ODBC
They both share conceptual components -
  • Driver Manager,
  • Driver, Connection,
  • SQL Statement,
  • Metadata,
  • ResultsSet.
JDBC was built on ODBC but in addition provides all of the benefits of a pure Java API , portability being the key issue.
J2EE Containers
The J2EE Specification defines a container as being responsible for providing the runtime support of the application components There must be one container for each application client type in a J2EE application. The reason for having a container between the J2EE application components and the set of services is to provide a federated view of the APIs for the application components. A container provides the APIs to the application components in order to access the services and may handle security, resource pooling or state management. The container also has to deal with naming and transaction issues. These are the various containers and the services they perform:
  • Application client container:
    This container supports application client components. It must provide access to the set of services required by J2EE but is not required to manage transaction. Application clients have access to the Java API and are packaged in a JAR file.

  • Applet container:
    The applet container includes support for the applet programming model. Typically a J2SE (Java 2 Platform, Standard Edition) 1.2 compatible applet execution environment acts as a container. The Java plug-in may be added to the browser to obtain such a container. Applets communicate over HTTP if they run in a browser, but they can also communicate using serialized objects.

  • Web container:
    The Web container is used to run servlets and JSPs (referred as “web components”). It is responsible for providing a runtime environment with a set of services.
  • EJB container:
    The EJB container on the application server is where all deployed EJBs reside. The EJB specification defines a container contract for
    remote access to the bean, as well as specific container interaction, which may be implemented differently by various system vendors. In addition to the container contract, the EJB specification also defines EJB composition and deployment requirements.

    Each of these functional characteristics is supported by one or more APIs in J2EE.

NOTE: A Web container is not a Web server.

A Web container provides runtime environment for Web components (a Web component is a Servlet or a JSP) and services for these components: security, concurrency, life cycle management, transaction, deployment, etc.

A Web server is software that provides services to access the Internet; it hosts Web sites. It also performs certain functions for the Web container (such as message handling) and hosting.



DEPLOYMENT
The J2EE Specification gives instructions for packaging and deploying components to their runtime environment. It introduces the concept of deployment descriptors and specifies the content that can be grouped together.
Deployment and deployment descriptors

Application components can be packaged so that they can be deployed in many environments. Application components can be packaged independently; whereas, elements of an application client are packaged in a single JAR file.

Web components may be packaged in a WAR (Web Archive) file with other Web resources. Enterprise Beans can be packaged together as well. These packages will be used for deployment in the container dedicated to each application component.

Application components can also be packaged together to construct a J2EE application, that is to say, an application containing Enterprise Beans, Web components and eventually, an application client. The intent of the application is to provide for the possibility of deployment to several operating environments.

The deployment task generally consists of three steps: installation of the components on the server (or container), followed by configuration and execution of the application. Deployments descriptors assist in this deployment task.

A deployment descriptor is an XML file describing how to assemble and deploy a unit into a specific environment. It is provided with the application and specifies the required external resources, as well as the security requirements and environment parameters. The purpose of a deployment descriptor is to enable developers to create reusable components. These components can be customized to run in several environments.
Deployment Modules

There are four deployment modules:
  • EJB: EJBs are packaged in a J2EE module (a JAR file, for example). The EJB specification defines the DTD (Document Type Definition) of the
    deployment descriptor associated with this module.

  • Web application: A Web application also represents a J2EE module, containing servlets, JSPs and other resources.
    The Java servlet specification defines the DTD of the deployment descriptor for a Web application

  • Application client: An application client represents a J2EE module. It is packaged in a JAR file and contains a deployment descriptor.

  • J2EE application: A J2EE application is a set of J2EE modules with a J2EE deployment descriptor. It is packaged using the JAR file format into an Enterprise ARchive (EAR) file. This file has the .ear extension, it contains a deployment descriptor and one or more J2EE modules, each of these contains its own deployment descriptor.

J2EE Architecture
J2EE blueprints
Home
Copyright © 1997-2002  The InterNet Agency. All rights reserved.
We welcome your comments to the Webmaster