Java 2 Platform Enterprise Edition (J2EE) Overview

 

Topics

  1. Introduction

  2. Why Use J2EE?

  3. Multi-Tier Architecture

  4. J2EE Servers
  5. J2EE Containers

  6. J2EE Components

  7. Services (APIs) for J2EE Components
  8. Assembly and Deployment

  9. J2EE Application Development

  10. More Information

 

 

Introduction

To top of page

Java 2 Platform, Enterprise Edition (J2EE) provides 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:

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

To top of page

From an application developer's perspective:

 

Example

To top of page

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?

To top of page

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

To top of page

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:

 

Portability

To top of page

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

To top of page

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

To top of page

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:

For more information on the J2EE Platform, see http://java.sun.com/. Follow the links to J2EE > Blueprints.

 

Scalability

To top of page

J2EE supports scalability to increase performance or to meet increased loads in several ways:

 

Development and Deployment Tools

To top of page

Vendors have responded to the need for J2EE tools by providing excellent support for J2EE development in their Java Integrated Development Environments (IDEs) including:

 

Back End Integration

To top of page

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

To top of page

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

To top of page

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.

Diagram described in accompanying text.

Figure 1: J2EE Multi-tier Architecture

 

Client Tier

To top of page

Client tier components run in client containers. The client tier can be implemented in these ways:

 

Middle Tier

To top of page

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

To top of page

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

To top of page

Business tier components are EJBs.

 

EIS Tier

To top of page

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

To top of page

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

To top of page

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

To top of page

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

To top of page

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

To top of page

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

To top of page

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

To top of page

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

To top of page

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

To top of page

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

To top of page

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

To top of page

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

To top of page

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

To top of page

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

To top of page

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

To top of page

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

To top of page

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:

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

To top of page

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

To top of page

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

To top of page

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

To top of page

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

To top of page

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

To top of page

 

Java Servlets

To top of page

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

To top of page

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

To top of page

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

To top of page

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

To top of page

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

To top of page

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

To top of page

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

To top of page

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

To top of page

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.

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

    To top of page

    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

    To top of page

    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

    To top of page

    A J2EE module consists of a deployment descriptor for the module and a number of elements that make up the module, including:

    There are three kinds of J2EE modules:

     

    J2EE Application Client

    To top of page

    J2EE application client modules are packaged in .jar archives and contain:

     

    Web Component

    To top of page

    Web component modules are packaged in .war archives and contain:

    If the module is a web service, the .war archive contains:

     

    Enterprise JavaBean

    To top of page

    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:

    A Web Service Enterprise JavaBean module contains:

    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

    To top of page

    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

    To top of page

    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

    To top of page

    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

    To top of page

    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.