A framework and set of specifications for designing, deploying, and managing portable Java-based distributed component software.
What is J2EEThe 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|
can be packaged in JAR files and include a deployment descriptor, giving platform independent information to the container that manages them
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.
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
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.
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.
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|
several Java technologies to support scalable, secure client-server
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
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:
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 -
|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:|
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.
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.
There are four deployment modules: