| |
| 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 |
|
|
