Concepts: Java 2 Platform Enterprise Edition (J2EE) Overview
Topics
Introduction
In today's fast-paced e-business world of complex distributed applications,
it's critical that your enterprise applications be brought to market quickly.
This means your project team can't afford to spend time developing system-level
services, such as remote connectivity, naming, persistence, security, or transaction
management. Your project team needs to develop and make use of portable, reusable
components; you don't want to spend any time reinventing tried and true architectures.
The Java™ 2 Platform, Enterprise Edition (J2EE™) addresses this
need by providing a well-documented, standards-based framework for developing
and running distributed, multi-tier, component-based Java applications. This
framework handles much of the low-level complexity of the application, such
as remote connectivity, naming, persistence, security, and transaction management,
leaving developers free to concentrate on the business logic of the application.
The J2EE platform consists of:
- A set of standards for J2EE components and the J2EE platform on which the
components run.
- A blueprint for application development that describes the J2EE platform
in detail, giving industrial-strength, best-practice information on how to
develop J2EE applications.
- A reference implementation of the J2EE platform, provided by Sun Microsystems
Inc. as a standard against which commercial J2EE products can be measured.
The reference implementation includes fully developed sample applications.
- A compatibility test suite for testing and evaluating commercial J2EE implementations
against the J2EE standards.
The J2EE platform is analogous to the services provided by your computer's
operating system-using programming tools, the operating system provides
standard services on top of which you can develop and execute applications,
without being concerned about low-level management of disk access, memory, video
output, networking, and so forth. You're concerned with the details of your
application, not the details of the underlying system. The J2EE Platform provides
a sophisticated operating system for enterprise applications.
By using the J2EE platform, you simplify your development effort so that your
project team can focus their energy on the actual business logic of the application,
instead of spending critical development time solving system-level issues. A
project team that can focus on what the application does, rather than focusing
on how to deliver all of the underlying services needed by the application,
is much more likely to deliver an on-time, bug-free system that meets your user's
requirements.
For more information, see Sun's J2EE Platform overview at http://java.sun.com/. Follow the links to Products
& APIs > Java™ 2 Platform, Enterprise Edition (J2EE™) >
Overview.
J2EE Development in a Nutshell
From an application developer's perspective:
- You purchase a commercial J2EE platform, in the form of a J2EE-compliant
server. The J2EE server's behavior is specified by the J2EE standard.
- You develop or purchase off-the-shelf J2EE components.
- You deploy and execute your J2EE components on your J2EE-compliant
server, which provides all of the services needed by your J2EE components.
Example

A simple example of a J2EE application is an e-commerce site, where a client
(user) uses a Web browser to remotely access a J2EE server. The J2EE server
provides Web tier and business
tier services, and interacts with an Enterprise Information
Systems (back end) tier that provides RDBMS access.
Why Use J2EE?
You'll want to use the J2EE platform for developing your Java e-commerce or
Enterprise application if any of these statements apply:
Each of these points is discussed in further detail in the rest of this section.
Standardized, Industry-Tested
Framework
J2EE components run in J2EE containers,
typically provided as part of a J2EE-compliant server. These containers provide
a set of standard services (APIs) used by the J2EE components. The APIs are:
- J2SE 1.4
- JDBC
- Java IDL
- Remote Method Invocation with CORBA's Internet Inter-ORB Protocol (RMI-IIOP)
- Java Naming and Directory Interface (JNDI)
- Java Authentication and Authorization Service (JAAS)
- Java Transaction API (JTA)
- JavaMail
- Java Message Service (JMS).
For more information on JMS, see Concepts: Java Messaging
Service.
- JavaBeans Activation Framework (JAF)
- Enterprise JavaBeans (EJB)
- Java Servlet
- Java API for XML Processing (JAXP)
- Java Connector (Note: not supported prior to J2EE 1.3)
- JavaServer Pages (JSP)
- Web Services for J2EE (Note: not supported
prior to J2EE 1.4)
- Java API for XML-based RPC (JAX-RPC) (Note:
not supported prior to J2EE 1.4)
- SOAP with attachments API for Java (SAAJ) (Note:
not supported prior to J2EE 1.4)
- Java API for XML Registries (JAXR) (Note: not
supported prior to J2EE 1.4)
- J2EE Management (Note: not supported prior
to J2EE 1.4)
- Java Management Extensions (JMX) (Note: not
supported prior to J2EE 1.4)
- J2EE Deployment (Note: not supported prior
to J2EE 1.4)
- Java Authorization Service Provider Contract for Containers
(JACC) (Note: not supported prior to J2EE 1.4)
J2EE components and applications are portable across J2EE-compliant servers,
with no code modifications necessary, so you can deploy your application to
the J2EE-compliant server of your choice simply by updating server-specific
deployment information contained in eXtended Markup Language (XML) deployment descriptor files.
The standardization of the J2EE specification has led to industry competition-you
have a choice of J2EE-compliant servers according to your needs and budget.
Reusable Components
Because they conform to the J2EE standard, J2EE components can be bought off-the-shelf
and plugged into your J2EE application as required, saving development (especially
debugging and testing) effort.
If you develop a component, you can reuse it in another application or deploy
it to different J2EE-compliant servers, as required.
Tried and True
Architecture and Design Patterns
The J2EE platform defines a well-structured, multi-tiered application architecture. By
leveraging off the J2EE architecture, your developers can quickly get on with
developing the actual business logic of the application.
J2EE documentation includes:
- A blueprint for application development that describes the J2EE platform
in detail and gives best-practice information on how to develop J2EE applications.
- Well-documented J2EE patterns-industry best practices-that describe
solutions to common J2EE architectural and design problems.
For more information on the J2EE Platform, see http://java.sun.com/.
Follow the links to J2EE > Blueprints.
Scalability
J2EE supports scalability to increase performance or to meet increased loads
in several ways:
- Performance enhancement features in the J2EE container - such
features include resource pooling (database connection pooling, session bean
instance pooling, and thread pooling), asynchronous message passing, and efficient
component lifecycle management. For example, opening a database connection
is slow. Also, database connections could be a scarce resource due to, for
instance, licensing restrictions. The J2EE platform manages this using database
connection pooling-the J2EE container keeps a pool of open connections
that can be assigned to a component as required, resulting in fast and efficient
connections.
- Load balancing can be achieved by clustering - deploying the
same components to multiple servers on different machines. The load to each
of the servers can then be balanced as required; for example, according to
a round-robin algorithm or according to server load. The J2EE platform specification
does not require load balancing capability in a J2EE server, but does suggest
that a high-end server would have it. J2EE server vendors offer various load-balancing
solutions.
- Application partitioning - logically distinct parts of an application
can be deployed to different servers; for example, deploying an online mail
order application's inventory and accounting subsystems to separate servers.
Development and Deployment
Tools
Vendors have responded to the need for J2EE tools by providing excellent support
for J2EE development in their Java Integrated Development Environments (IDEs)
including:
- Wizards for servlet creation
- Wizards and dialogs for EJB creation and maintenance
- Deployment descriptor generation and maintenance
- EJB object to database mapping (including generation of deployment descriptor
information for container-managed relationships)
- Integration with a Web container for testing Web services
- Seamless in-IDE deployment, debug, and testing of EJBs by integration with
a J2EE EJB container and its deployment tools
- Automatic generation of J2EE test clients
- Integration with UML modeling tools
Back End Integration
The back end refers to the enterprise information system (EIS) tier of the
application. Back end systems can be, for example, RDBMS, legacy systems, or
enterprise resource planning systems (ERPs).
J2EE supports transactional access to RDBMS EISs using the JDBC and JTA APIs.
In addition, EJB containers support container-managed persistence, in which
transactional RDBMS connection and access is handled automatically by the container.
J2EE's Connector Architecture Service Provider Interface (SPI) defines a standard
for connecting non-RDBMS EIS resources to a J2EE container. An EIS-specific
resource adapter (supplied by the EIS vendor) is plugged in to the J2EE container,
extending the container so that it provides transactional, secure support for
that EIS. Components in the container can then access the EIS through the J2EE
Connector Architecture SPI.
Note: J2EE's Connector Architecture SPI is not supported prior to J2EE
1.3.
Security
J2EE provides simple, powerful security features. Security information for
J2EE components is defined in their deployment descriptors. This information
defines what security roles are authorized to access a particular URL
and/or methods of a component. A security role is merely a logical name for
a grouping of users; for example, an organization's management team members
could all be assigned a role named "managers".
Since the security information is declared in the deployment descriptor, the
security behavior can be changed without an expensive code update-debug-test
cycle.
Multi-Tier Architecture
J2EE is a multi-tier distributed application architecture-consisting of
a client tier, middle tier, and
EIS or back end tier.
Figure 1 shows the multi-tier architecture of the J2EE platform, as well as
the various J2EE containers supporting J2EE components.

Figure 1: J2EE Multi-tier
Architecture
Client Tier
Client tier components run in client containers. The client tier can be implemented
in these ways:
- Standalone Java applications - usually
a GUI (also known as a "thick client"). Such a Java application
must be installed on every client machine. A Java application can access the
EIS tier or middle tier through APIs such as JDBC.
- Static HTML pages - provide a limited GUI
for an application.
- Dynamic HTML - generated by JSP pages or servlets.
- Applets - run in a Web browser. Applets are
embedded in an HTML page and are typically used to provide a GUI.
Middle Tier
The middle tier consists of the Web tier and business tier. Web tier components run in a J2EE Web
server that provides a Web container. Business
tier components run in a J2EE application server
that provides an EJB container.
Web Tier
Web tier components include servlets and JSP pages, which manage the interaction with the
client tier, insulating the clients from the business and EIS tier. Clients
make requests of the Web tier, which processes the requests and returns the
results to the client. Client requests to components in the Web tier generally
result in Web tier requests to components in the business tier, which, in turn,
might result in requests to the EIS tier.
Business Tier
Business tier components are EJBs.
- They contain the application business logic.
- They make requests to the EIS tier according to the business logic, typically
in response to a request from the Web tier.
EIS Tier
The EIS tier represents the application's stored data, often in the form of
an RDBMS. The EIS tier might also consist of legacy systems or ERPs, accessed
through the J2EE Connector Architecture API.
For more information on the J2EE Connector Architecture API, see http://java.sun.com/. Follow the links to
Products & Technologies > J2EE > J2EE
Connector Architecture.
For more information on J2EE's standard deployment configurations, see Concepts: J2EE Deployment Configurations.
J2EE Servers 
J2EE servers are commercial products that implement the J2EE platform. Examples
of commercial J2EE servers are BEA WebLogic, Borland Enterprise Server, IBM
WebSphere, and iPlanet.
Usage of the terminology "J2EE server" is somewhat loose. Usually,
what's meant is "a J2EE server that supports both a Web container and an
EJB container". Using tighter terminology, a J2EE Web server (such as the
J2EE reference Web server implementation Tomcat) supports a Web container; a
J2EE application (or EJB) server supports an EJB container.
J2EE Containers 
J2EE components run in, or are hosted by, J2EE
containers generally provided as part of a commercial J2EE server. Containers
provide a run-time environment and standard set of services
(APIs) to the J2EE components running in the container, in addition to supporting
the standard J2SE APIs.
J2EE defines the following types of containers:
Application Client Container
A J2EE application client
runs in an application client container, which supports these J2EE APIs: JDBC,
JMS, JAXP, JAAS, JavaMail, JAF, JSR, JAX-RPC, SAAJ, J2EE Management and JMX.
Practically, application client containers consist of
the standard J2SE installation. The application client container must support
the JAAS callback handler interface to satisfy the security constraints of the
rest of the enterprise application in the Web and EJB containers.
Applet Container
An applet runs in an applet container,
which supports the applet programming model and supports standard J2SE APIs.
Practically, applet containers are supplied as the Java plug-in to a Web browser.
Web Container
Web components (JSP
pages and servlets) run in a Web container
provided as part of a J2EE server or provided as a standalone J2EE Web server.
A Web container supports the following J2EE APIs and packages: JDBC, JMS, JAXP,
JAX-RPC, JAXR, JAAS, Java Mail, JAF, J2EE Connector Architecture, JTA, JSR,
SAAJ, J2EE Management, Java Servlet, and JSP.
EJB Container
EJB components run in an EJB container,
which is provided as part of a J2EE server.
An EJB container supports the following J2EE APIs and
technologies: EJB, JDBC, JMS, JAXP, JAX-RPC, JAXR, JAAS, Java Mail, JAF, JTA,
JSR, SAAJ, J2EE Management, and J2EE Connector Architecture.
The following subsections summarize the key functionality supported by EJB
containers:
Remote Communications

EJB containers hide the complexity of remote communications from developers
by using container-provided classes (generated by container tools when the EJB
is compiled, along with RMI stub classes for the use of clients) that implement
the EJB interfaces. These implementation classes are remote Java objects that
a client can access using Java RMI. From the client's perspective, the client
simply calls methods on the EJB interface, without any consideration of remote
communications.
Concurrency

EJB containers transparently manage concurrent requests from multiple clients.
Clients can act as if they have exclusive access to the EJB. For example, if
two clients request the same entity EJB, the container provides each of them
with their own instance and manages synchronization internally without the client's
knowledge.
Naming

The EJB container provides a JNDI name space for locating EJBs deployed in
the container. EJB clients can look up EJBs to obtain a Home interface. The
Home interface for an EJB provides methods to find and create EJB instances.
As long as the JNDI naming context is available from their location, clients
can access the EJBs.
Persistence

EJB developers have the choice of two schemes for the storage of entity EJB
persistent data: Container Managed Persistence (CMP) and Bean Managed Persistence
(BMP). CMP delegates the responsibility for implementing the data access code
to the container, whereas BMP leaves the EJB developer responsible for implementing
that code. CMP allows the EJB developer to use a standard implementation for
access to persistent storage simply by declaring container-managed fields in
a deployment descriptor.
Transaction Management
A transaction is a sequence of operations that succeeds or fails atomically-so
that if any operation in the sequence fails, no change is made to the system
state. For example, say you want to issue air tickets: you would validate a
customer's credit card account, debit that account, and then issue the tickets.
This sequence of operations should occur in a single transaction, so that if
any operation fails, no change is made to the customer's credit card account
and no tickets are issued.
EJBs can use either bean-managed
transaction demarcation or container-managed transaction
demarcation, which is described in the next two headings.
Bean-managed transaction
demarcation
In bean-managed transaction demarcation, you use a simple API to demarcate
transaction boundaries. This is the Java Transaction API (JTA), which you use
to programmatically control transaction demarcation; for example, by calling
the begin() , commit() , and rollback()
methods of the JTA UserTransaction interface. The developer is responsible for
coding rollback logic for transaction exception conditions, as the container
does not handle this automatically.
Note: Entity EJBs cannot use bean-managed transaction demarcation-they
can only use container-managed transaction demarcation.
Container-managed
transaction demarcation
In container-managed transaction demarcation, you don't supply code to begin
and end transactions. Instead, you supply transaction attribute information
in the EJB deployment descriptor for each method of your EJB. The transaction
attribute (one of Required, RequiresNew, NotSupported, Supports, Mandatory,
or Never) tells the container what transaction scope to use for the method.
For example, if a client is running within a transaction and it calls a method
of your EJB for which the transaction attribute is set to Required, then the
method will be called within the scope of the existing transaction.
Use container-managed transaction demarcation rather than bean-managed transaction
demarcation whenever possible, so that you don't have to add, debug, and test
transaction demarcation code in your component. Instead, the transaction behavior
of each of your EJB methods is specified at deployment time, in the deployment
descriptor. This means that the transaction behavior can be changed without
an expensive code update-debug-test cycle.
Distributed transactions
A distributed transaction is a transaction that must be coordinated across
multiple databases and/or multiple applications. This is in contrast to a centralized
transaction, such as a single J2EE application server committing transactions
to a single database.
A two-phase commit is necessary in distributed transactions; for example,
where there is more than one database being updated. Some EJB containers (such
as BEA WebLogic Server 6.0) supply support for two-phase commit, using Open
Group's XA protocol. The application programmer does not need to write any code
to handle the two-phase commit; the EJB container manages it.
Security Management
EJB security is handled by the EJB container, using security information in
the deployment descriptor. In the deployment descriptor, you declare a set of
roles and, for each EJB method, you declare the roles that are authorized
to call the method.
At run-time, each client of the EJB is assigned to a role, and the EJB container
manages access to the EJB's methods by checking that the client role is authorized
to call that method.
Since the security information is declared in the deployment descriptor, the
security behavior can be changed without an expensive code update-debug-test
cycle.
Lifecycle Management
EJBs move through a series of states during their lifecycle in response to
client requests. The EJB container is responsible for managing this lifecycle.
At container startup, the container creates a pool of EJB instances in a resource
pool (to save startup time when the EJB resource is needed). When an EJB client
requests the creation of an EJB, an instance is assigned from the pool. The
client can now make requests of the EJB. When an EJB client requests removal
of an EJB, that instance is returned to the pool.
The container notifies an EJB instance of various events in the EJB lifecycle,
using a set of standard callback methods such as:
ejbCreate() - called by the container after the EJB instance
is created
ejbRemove() - called by the container when the EJB instance
is about to be deleted
ejbActivate() - called by the container after the EJB
instance is restored from a passive state
ejbPassivate() - called by the container when the EJB
instance is about to be passivated
ejbStore() - called by the container when the EJB instance
is about to be written to a database
ejbLoad() - called by the container after the EJB instance
fields are loaded from the database
Each EJB is required to implement these callbacks although the EJB's implementation
of the callback method is often empty. For example, the container calls the
EJB's ejbRemove() method to notify the EJB that the EJB is about
to be removed (there has been a client request to remove the EJB). In the EJB's
ejbRemove() method, you would code any operations necessary before
the EJB can be removed, such as releasing any resources held by the EJB.
EJBs can be passivated-state information is saved and the EJB instance
is freed up for use by the resource pool-as required by the container.
A passivated EJB will be activated-state information restored-by
the container if a client request to that particular EJB object is received.
Database Connection Pooling
Opening a database connection is slow. Also, database connections could be
a scarce resource, due to, for example, licensing restrictions. The EJB container
manages this expense through database connection pooling-the container
keeps a pool of open connections that can be assigned and unassigned to an EJB
as required, resulting in fast and efficient connections.
For entity EJBs using CMP, database connections are handled automatically.
No connection or SQL code needs to be written-you simply specify the JNDI
name of the JDBC data source in the EJB deployment descriptor and use container-specific
deployment tools to generate the connect routines for you. The container manages
the database connection pool.
For entity EJBs using BMP or for session EJBs, you need to write connection
code to connect to a JDBC data source and write SQL code to access the database.
The JDBC data source is still managed by the container-the JDBC data source
actually uses a database connection pool maintained by the container.
Messaging 
EJB containers are required to provide messaging
support for the asynchronous exchange of
messages. JMS, or other messaging types, can be used by message-driven EJBs
process delivered messages. Because of the JMS's
involvement with EJBs, they must support transactional access from Web and EJB
container components like servlets, JSP pages, and EJBs.
J2EE Components
The following section gives a brief discussion of all of the types of J2EE
components. J2EE components include applets, application clients, Web
components, and Enterprise JavaBeans.
J2EE components run in J2EE containers.
Applets 
Applets are small programs that can be sent along with a Web page and execute
in a Web browser. They could also execute in other environments that support
the applet programming model.
Applets are primarily used for implementing user interfaces and can greatly
extend the capabilities of HTML pages.
Application Clients 
Application clients are Java applications. They have access to the facilities
of the J2EE middle tier and EIS tier. They are typically desktop applications
that provide a user interface. They might be used to implement a "thick
client" as described in Concepts: Distribution Patterns.
Web Components
Java Servlets 
Java Servlet technology allows a Web server to handle requests from a Web client
and provide responses containing dynamic content. A Java servlet can interact
with other Web and EJB components to produce this dynamic content. The generated
content can take the form of any text-based document including HTML and XML.
Java Servlet can also be used as web services endpoint in collaboration with
JAX-RPC API.
Note: The usage of Servlet as web services endpoint
is a new feature of J2EE 1.4 (JAX-RPC 1.1) and so not supported on previous
versions.
For more information on J2EE servlets, see http://java.sun.com/.
Follow the links to J2EE > Blueprints.
JavaServer Pages 
JavaServer Pages (JSP) technology is based on Java Servlets, but it's text-based
instead of code-based. A JSP page processes requests and generates responses
like a servlet, but its logic is primarily presentation-driven. A JSP page contains
mostly static HTML that defines the format for the presentation of the data
obtained from other sources like JavaBeans and EJBs. A Web component developer
can create custom tag libraries to extend JSP to add new capabilities.
For more information on JSP, see http://java.sun.com/.
Follow the links to J2EE > Blueprints.
HTML Pages 
HTML pages can be used to support user interfaces. They might be defined as
static Web pages, or could be generated by servlets and JSP pages. The J2EE
specification requires that J2EE Web clients support the display of HTML pages.
JavaBeans 
The JavaBeans API defines an architecture for creating simple reusable components.
These components can be edited and assembled using application builder tools.
Regular Java code is used to implement JavaBeans, so that the implementation
remains readable to other programmers, who might use these components, as well
as to the tools.
JavaBeans is not a J2EE technology, but is used by J2EE technologies. For example,
EJBs can use JavaBeans as value objects. For differences between JavaBeans and
Enterprise JavaBeans, see the section titled Comparing JavaBeans and EJBs.
For more information on JavaBeans, see Concepts: JavaBeans.
Enterprise JavaBeans 
The Enterprise JavaBeans specification stipulates an architecture for the development
and deployment of component-based, transactional distributed business applications.
The components defined by the EJB specification are called Enterprise JavaBeans
(EJBs). EJBs are server-side Java components in which you implement the business
rules of your application.
EJBs are deployed to, and run in, an environment called an EJB container, described
previously under the heading EJB Container,
which provides services such as transaction
management, database connectivity,
and security. By concealing such complexities,
the EJB architecture enables component developers to focus on business logic.
An Enterprise JavaBean (EJB) is a collaboration of Java interfaces, an EJB
implementation class, and an XML deployment descriptor. The EJB interfaces and
implementation class must conform to rules defined by the EJB specification,
such as implementing certain interfaces and providing certain callback methods.
The EJB interfaces include home interfaces that provide methods to find and
create EJB instances, and component interfaces that provide the business methods
for a particular EJB instance. These can be remote interfaces, meaning that
they can be invoked across the network, or local interfaces, which means the
caller must be in the same process (or more precisely, in the same Java Virtual
Machine). The EJB interfaces are implemented by EJB container classes that delegate
methods to the EJB implementation class. An exception is a finder method of
a container-managed entity EJB, which is handled by the container class.
There are three types of EJBs: session beans,
entity beans, and message-driven
beans.
For more information on EJBs, see http://java.sun.com/.
Follow the links to J2EE > Blueprints.
Session Beans 
A session bean component provides services that implement client-specific business
logic. A single client can access each session bean instance through local or
remote interfaces. Session beans can save data to a database, but usually call
upon entity beans representing business objects to save data. Session bean instances
can maintain a transient conversational state.
A session bean might have a method getAllCustomers() that returns
a collection of all of the customers in the database. This bean would obtain
its information from the Customer entity bean and deliver the results to the
client.
Stateless session beans can be used as web services endpoint
as defined in the JSR and EJB specification.
Note: The usage of stateless session beans as
web services is a new feature of J2EE 1.4 (JSR 109 and EJB 2.1) and so not supported
on previous versions.
For more information on session beans, see the Enterprise
JavaBeans Specification, Version 2.1 at http://java.sun.com/.
Follow the links to Products & Technologies > J2EE > Enterprise
JavaBeans.
Entity Beans 
An entity bean component provides services that implement business object-specific
logic. Multiple clients can access an entity bean instance concurrently through
local or remote interfaces. Entity beans save business object data to databases,
and the persisted data can survive container or client crashes.
An entity bean could represent a customer, which might be stored as a row in
the customer table of a relational database. The EJB developer chooses the method
of persistence, in this case a relational database.
There are two types of entity bean persistence: bean-managed persistence (BMP)
and container-managed persistence (CMP). BMP entity beans must implement the
data access code, whereas CMP entity beans have this ability implemented by
the container. CMP container implementations are usually provided for relational
database persistence, although other types of persistence (object database,
file-based persistence, and so forth) are also possible.
For more information on entity beans, see the Enterprise JavaBeans Specification,
Version 2.1at http://java.sun.com/.
Follow the links to Products
& Technologies > J2EE > Enterprise JavaBeans.
Message-Driven Beans 
A message-driven bean component provides a service that implements message
processing-specific business logic. Only the container
can call this service; the client cannot directly call this service through
remote or local interfaces. Instead, when a message arrives at a destination
or endpoint serviced by the bean, the container calls an instance of the message-driven
bean assigned as MessageListener to the destination. Message-driven bean instances
do not maintain a conversational state, but can maintain instance variables
with resource references (for example, database connection) across method calls.
Note: Message-driven beans are not supported prior
to EJB 2.0. The support of messaging types different from JMS is a new feature
of the EJB 2.1 specification and so they are not supported on previous version.
For more information on message-driven beans, see the
Enterprise JavaBeans Specification, Version 2.0 at http://java.sun.com/.
Follow the links to Products & Technologies > J2EE > Enterprise
JavaBeans.
Comparing JavaBeans and EJBs
Although similar in name, EJBs are much more complex than regular JavaBeans.
Both define architectures for reusable components, but EJBs add the required
support for the creation of distributed, multi-user services. Both types of
components can be assembled using application builder tools, but EJBs need to
be deployed to an EJB container to execute.
J2EE containers support all of the J2SE standard APIs, as well as a subset
of J2EE APIs depending on the container type. Components within a container
can access this available subset. The following table gives a brief description
of each API and lists the J2EE containers where they are available.
Name |
Description |
J2EE Containers,
where APIs are available |
EJB 2.1 |
The EJB specification defines
a component model for EJBs-business tier components that automatically
support services such as remote communications, transaction management,
security and persistence.
For more information on EJB, visit http://java.sun.com/
and follow the links to Products & Technologies > J2EE >
Enterprise JavaBeans. |
EJB
Application client*
Web*
* client API only |
JAAS |
Java Authentication and Authorization Service
(JAAS) provides services for authentication and authorization of users
to ensure they have permission to perform an action.
For more information on JAAS, visit http://java.sun.com/
and follow the links to Products
& Technologies > J2SE > Core Java >
Java Authentication and Authorization Service (JAAS). |
Application client
Web
EJB |
JAF 1.0 |
JavaBeans Activation Framework
(JAF) provides services to identify data and instantiate a JavaBean
to manipulate that data.
For more information on JAF, visit http://java.sun.com/
and follow the links to Products & Technologies > J2SE >
Desktop Java > JavaBeans > JavaBeans Activation Framework. |
Application
client
Web
EJB |
JAXP
1.2 |
Java API for XML
Processing (JAXP) provides an abstract interface for XML document
processing that can be used with compliant parsers and transformers
that use DOM SAX or XSLT.
For more information on JAXP, visit http://java.sun.com/
and follow the links to Products & Technologies > J2EE
> Java API for XML Processing (JAXP). |
Application client
Web
EJB |
JAX-RPC
1.1 |
The JAX-RPC specification
defines client APIs for accessing web services as well
as techniques for implementing web service endpoints.
For more information on JAX-RPC, visit http://java.sun.com/
and follow the links to Products &
Technologies > J2EE > Java API for XML-based RPC
(JAX-RPC). |
Application client
Web
EJB |
Web
Services for J2EE 1.1 |
TheWeb
Services for J2EE specification (JSR-109) defines the capabilities
a J2EE application
server must support for deployment of web service endpoints.. .
For more information on Web Services for J2EE,
visit http://jcp.org/aboutJava/communityprocess/final/jsr109/index.html |
Application
client
Web
EJB |
SAAJ
1.2 |
The SSAJ API provides
the ability to manipulate SOAP messages. .
For more information on JAXP, visit http://java.sun.com/
and follow the links to Products &
Technologies > J2EE > SOAP with Attachments API for
Java (SAAJ). |
Application client
Web
EJB |
JAXR
1.0 |
The JAXR specification
defines APIs for client access to XML-based registries such
as ebXML registries and UDDI registries.
For more information on JAXP, visit http://java.sun.com/
and follow the links to Products & Technologies > J2EE
> Java API for XML Registries (JAXR). |
Application client
Web
EJB |
JavaMail 1.3 |
The JavaMail API provides a framework that
can be extended to build Java-based mail applications.
For more information on JavaMail, visit http://java.sun.com/
and follow the links to Products & Technologies > J2EE
> JavaMail. |
Application client
Web
EJB |
JDBC 3.0 |
Java Database Connectivity (JDBC) is an
API for accessing tabular data sources such as SQL databases, spreadsheets,
and flat files.
For more information on JDBC, visit http://java.sun.com/
and follow the links toProducts
& Technologies > J2EE >
JDBC. |
Application client
Web
EJB |
JMS 1.1 |
Java Message Service (JMS) provides asynchronous
messaging services for the transfer of data and notification of events.
With JMS, it is possible to use message-driven EJBs to asynchronously
process messages delivered to JMS topics and queues.
For more information on JMS, visit http://java.sun.com/
and follow the links to Products &
Technologies > J2EE > Java Message Service. |
Application client
Web
EJB |
JNDI |
Java Naming and Directory Interface Specification
(JNDI) provides naming and directory services to register and lookup
distributed components and resources. Clients only need to know the
registered JNDI name for the component or resource and don't need
to know their actual network location.
Example: EJBs are registered in the enterprise directory at deployment
time, using the deployment descriptor ejb-name field.
J2EE clients look up an EJB using the JNDI lookup-all clients
need to know is the name by which the EJB was registered in the directory.
The JNDI lookup returns a reference to the EJB?s home object.
For more information on JNDI, visit http://java.sun.com/
and follow the links to Products
& Technologies > J2SE >
Core Java > Java Naming and Directory Interface
(JNDI). |
Application client
Web
EJB |
JTA 1.0 |
Java Transaction API (JTA) defines interfaces
for managing distributed transaction services between transaction
manager, resource manager, application server, and application.
For more information on JTA, http://java.sun.com/
and follow the links to Products
& Technologies > J2EE >
Transactions. |
Web
EJB |
J2EE Connector
1.5 |
J2EE Connector Architecture Service Provider
Interface (SPI) defines a standard for connecting EIS resources to
a J2EE container-an EIS-specific resource adapter (supplied by
the EIS vendor) is plugged in to the J2EE container, extending the
container so that it provides transactional, secure support for that
EIS. Components in the container can then access the EIS via the J2EE
Connector Architecture SPI.
For more information on J2EE Connectors, visit http://java.sun.com/
and follow the links to Products
& Technologies > J2EE >
J2EE Connector Architecture. |
Web
EJB |
JSP 2.0 |
JavaServer Pages technology provides Web
developers with the ability to create and maintain dynamic Web pages.
JSP pages are text-based and use XML-like tags to perform business
logic and generate custom content. JSP technology allows business
logic to be delegated to other components so that only the presentation
logic needs to be embedded in the JSP page.
For more information on JSP, visit http://java.sun.com/
and follow the links to Products
& Technologies > J2EE >
JavaServer Pages. |
Web |
Servlet 2.4 |
Java Servlets extend the capabilities of
the Web server to help build Web-based applications. Servlets are
often used in interactive Web applications where the Web server responds
to user requests with dynamically generated content obtained from
existing business systems.
For more information on Java Servlets, visit http://java.sun.com/
and follow the links to Products
& Technologies > J2EE >
Java Servlet. |
Web |
RMI-IIOP |
Remote Method Invocation technology run
over Internet Inter-Orb Protocol (RMI-IIOP) allows Java components
to communicate with legacy CORBA components written in other languages
like C++ or Smalltalk.
For more information on RMI-IIOP, visit http://java.sun.com/
and follow the links to Products and APIs > RMI-IIOP. |
Application client
Web
EJB |
J2EE
Management 1.0 |
The J2EE Management
API provides APIs for management tools to query a J2EE
application server to determine its current status, applications deployed,
and so on..
For more information on RMI-IIOP, visit http://java.sun.com/
and follow the links to Products
& Technologies > J2EE >
J2EE Management Specification. |
Application client
Web
EJB |
JMX
1.2 |
The JMX API is used
by the J2EE Management API to provide some of the
required support for management of a J2EE product.
For more information on RMI-IIOP, visit http://java.sun.com/
and follow the links to Products
& Technologies > J2SE > Core Java
> Java Management Extensions (JMX). |
Application client
Web
EJB |
J2EE
Deployment 1.1 |
The J2EE Deployment
API defines the interfaces between the runtime environment
of a deployment tool and plug-in components provided by a J2EE application
server.
For more information on J2EE Deployment, visit
http://java.sun.com/ and follow
the links to Products
& Technologies > J2EE >
J2EE Deployment Specification. |
|
JACC
1.0 |
The JACC specification
defines a contract between a J2EE application server and an
authorization policy provider.
For more information on JACC , visit http://java.sun.com/
and follow the links to Products
& Technologies > J2EE >
Java Authorization Contract for Containers. |
Application client
Web
EJB |
Assembly and Deployment 
J2EE applications are composed of the application deployment descriptor (application.xml)
and one or more J2EE modules that make up the application. The modules are reusable,
portable components. J2EE applications are packaged in .ear archives.
Deployment Descriptors 
Deployment descriptors are XML files used in J2EE applications and J2EE modules.
They provide configuration information that the J2EE server reads at the time
of deployment. This configuration information allows the server to customize
the J2EE application or module declaratively without changing the source code
or classes.
There is a generic deployment descriptor type for each J2EE application or
module. Generic deployment descriptors, like the EJB module's ejb-jar.xml, define
information that applies to the EJB regardless of the server upon which it is
deployed. Server-specific deployment descriptors specify information that is
only meaningful to a particular server. Server-specific deployment descriptors
have names that reflect the server for which they are meant.
J2EE Modules 
A J2EE module consists of a deployment descriptor for the module and a number
of elements that make up the module, including:
- Non-Java elements deployed on the Web server (JSP pages, image files, static
HTML pages); in other words, virtual directory elements
- Java elements deployed on a Web server (servlets, JavaBeans, Java classes)
- Elements deployed on an EJB server (EJBs and supporting Java classes)
There are three kinds of J2EE modules:
J2EE Application Client
J2EE application client modules are packaged in .jar archives and contain:
- application-client.xml deployment descriptor
- application client implementation .class files
Web Component
Web component modules are packaged in .war archives and contain:
- web.xml deployment descriptor and server-specific deployment descriptors
- JSP pages
- HTML pages
- Images (for example, .gif and .jpg)
- Servlet Class files
If the module is a web service, the .war archive contains:
- webservices.xml deployment descriptor
- Servlet Class files
- WSDL files
Enterprise JavaBean
A single Enterprise JavaBean JAR archive might contain a number of EJBs, but
their deployment information is stored in one set of deployment descriptors
(ejb-jar.xml plus any server-specific deployment descriptors).
A standard Enterprise JavaBean module contains:
- ejb-jar.xml and server-specific deployment descriptors
- EJB implementation Class files
A Web Service Enterprise JavaBean module contains:
- webservices.xml deployment descriptors
- EJB implementation Class files
For more information on J2EE packaging and deployment, see http://java.sun.com/.
Follow the links to Docs & Training > J2EE Platform, Enterprise Edition
> Java Blueprints Program.
J2EE Application Development 
The J2EE application development process defines several roles and stages.
The following sections define the development
roles provided by the J2EE specification and the development stages in which these
roles participate.
J2EE Application Development
Roles
The application development roles are summarized in this table.
Role Name |
Description |
J2EE Product Provider
|
A J2EE product provider is the supplier of a J2EE platform implementation,
also known as a J2EE product. J2EE product providers include BEA, IBM,
and Sun. These organizations typically play to their existing strengths
in delivering an implementation of the J2EE platform. For example, the
BEA implementation builds upon BEA's highly successful Tuxedo transaction
processing monitor. A J2EE product provider also supplies the tools
required to support application deployment and management.
|
Application Component Provider
|
The application component provider actually encompasses a number of
roles, such as EJB developers and HTML document designers. These roles
are responsible for producing the J2EE application components using
the tools provided.
|
Application Assembler
|
The application assembler creates a J2EE application from J2EE application
components using the tools provided. The J2EE application is delivered
as an Enterprise Archive (EAR) file. The application assembler also
describes any external dependencies of the J2EE application. The deployer
resolves these dependencies when actually deploying the J2EE application.
|
Deployer
|
The deployer is responsible for deploying a J2EE application and the
application components from which it is comprised into the operational
environment. The first stage of deployment is to install the various
application components within the relevant J2EE containers. The second
stage of deployment is to configure any external dependencies that have
been declared so that they can be resolved. For example, security roles
that have been defined are mapped onto user groups and accounts in the
operational environment. The third stage of deployment is to execute
the new application so that it's ready to receive requests.
|
System Administrator
|
The system administrator is responsible for the run-time infrastructure,
which includes any deployed J2EE applications. This role uses the appropriate
tools provided by the J2EE product provider to accomplish this task.
|
Tool Provider
|
The tool provider provides tools to support developing and packaging
application components. These tools often correspond to the different
types of application component produced, and include IDEs such as IBM
VisualAge for Java and Borland JBuilder.
|
System Component Provider
|
The System Component
Provider provides different system level components such as resource
adapters or authorization policy provider.
|
These roles are not exclusive and a single person could take on more than one
role, especially on small development teams or in a prototyping situation.
J2EE Application Development
Stages 
This section describes the different stages of J2EE application development,
as stipulated in the J2EE specification. The development stages are:
A J2EE application must contain at least one J2EE module, so at least one of
the component development stages is required. The final two stages are always
necessary since all J2EE applications must be assembled and deployed.
The following table summarizes the development stages for J2EE applications.
J2EE Development Stage |
Tasks |
Performed by (J2EE Role) |
Results in (Deliverable) |
J2EE Application Client Creation
|
- Writes client code and compiles classes
- Creates the application-client.xml deployment descriptor
- Creates a JAR file archive containing the Class and XML files
|
Application Component Provider
(software developer)
|
A JAR file containing the J2EE application client
|
Web Component Creation
|
- Writes servlet code and compiles classes
- Writes JSP and HTML pages
- Creates the web.xml deployment descriptor
- Creates a Web Application aRchive (WAR) file archive containing
the Class, .jsp, .html, and XML files
|
Application Component Provider
(software developer: servlets; Web designer: JSP pages, HTML pages)
|
A WAR file containing the Web component
|
Enterprise JavaBean Creation
|
- Write EJB code and compile classes
- Create the ejb-jar.xml and server-specific deployment descriptors
- Create a JAR file archive containing the Class and XML files
|
Application Component Provider
(software developer)
|
A JAR file containing the Enterprise JavaBean
|
J2EE Application Assembly
|
- Create the application.xml deployment descriptor
- Create a EAR file archive containing the EJBs (JAR), Web components
(WAR), and XML files
|
Application Assembler
|
An EAR file containing the J2EE application
|
J2EE Application Deployment
|
- Add the J2EE application (EAR) to the J2EE server environment
- Edit the application.xml deployment descriptor with local environment
configuration
- Deploys the J2EE application to the J2EE server
|
Deployer
|
Installed and configured J2EE application
|
Each stage of the development process produces a deliverable that is used in
the next stage. The components created in the Component Development stages are
used in the J2EE Application Assembly stage to produce the J2EE application
EAR archive. In the J2EE Application Deployment stage, the EAR archive is deployed
to the J2EE server.
The deliverables for each stage are portable and need not be performed by the
same people or even on the same environment, as long as the environment satisfies
the J2EE Platform requirements.
For more information on J2EE packaging and deployment, see http://java.sun.com/.
Follow the links to J2EE > Blueprints.
More Information 
Additional information regarding J2EE can be found in the Sun J2EE Blueprints.
You can access it at http://java.sun.com/.
Follow the links to J2EE > Blueprints > Guidelines: Designing Enterprise
Applications with the J2EE Platform, Second Edition.
A copy of this document is also included within the Rational
Unified Process.
The chapters within the Sun J2EE Blueprints for information on specific topics
is summarized in this table.
J2EE Concept |
J2EE Blueprints Chapter |
J2EE Platform Technologies
|
Chapter 2
|
Enterprise JavaBeans
|
Chapter 5
|
Transactions
|
Chapter 8
|
Security
|
Chapter 9
|
Servlets
|
Chapter 4
|
JavaServer Pages
|
Chapter 4
|
Deployment and Packaging
|
Chapter 7
|
|