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:

• You want to make use of a standardized, industry-tested framework that provides support for transaction management, naming, security, remote connectivity, and database access.
• You require portability-the ability for your components to be deployed on your choice of J2EE-compliant server.
• You want to reuse your components or use purchased off-the-shelf components.
• You want to make use of your developers' architectural experience on the J2EE platform, using tried and true architecture and design patterns.
• Your system needs to be scalable to meet increased loads.
• You want to reduce development time by using powerful J2EE development and deployment tools.
• You want to easily integrate with back end systems.
• You want to take advantage of simple, powerful security features.

Each of these points is discussed in further detail in the rest of this section.

Standardized, Industry-Tested

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 Concept: Java Messaging Service (JMS).
• 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)

Portability

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 Concept: 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
• applet container
• Web container
• EJB container

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
• Concurrency
• Naming
• Persistence
• Transaction Management
• Security Management
• Lifecycle Management
• Database Connection Pooling
• Messaging

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 Concept: 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 Concept: 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.

Services (APIs) for J2EE Components

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.

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
• Web Component
• Enterprise JavaBean

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.

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:

• Component Development
• • J2EE Application Client Creation
  • Web Component Creation
  • Enterprise JavaBean Creation
  • J2EE Application Assembly
  • J2EE Application Deployment

  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