+

Search Tips   |   Advanced Search

EJB 3.0 and EJB 3.1 deployment overview

Learn about the EJB 3.0 and 3.1 deployment model, including Just-In-Time (JIT) deployment.

All Java Enterprise Edition (Java EE ) application server products have some form of EJB deployment phase in which the application is customized to run in that particular implementation of the application server. Typically, this is accomplished by a deployment tool that is specific to the application server and generates code to bridge your EJB interface and implementation code to the application server's implementation for an EJB container. Some application server products' deployment tools alter the bytecodes of the application classes, rather than generating code, but the end result is similar.

Application Server bridges the EJB interface with its implementation by generating code that encapsulates the EJB implementation classes, connecting them to Application Server's EJB container. This enables the EJB container to host the enterprise beans and provide services to them. If one or more of the enterprise beans has remote interfaces defined, Application Server generates additional code to provide the remote function.

For more information about packaging the EJB module, see the topic that covers the EJB 3.x module packaging overview.


EJBDeploy Tool

Historically, EJB deployment in the Application Server product has been performed by the EJBDeploy tool, which is included with WebSphere Application Server and packaged with the development tools for the WebSphere products.

The EJBDeploy tool introspects the external interfaces for the enterprise beans, generates the wrapper code as .java files, and compiles the code using the javac compiler to produce .class files that are packaged in the EJB module with the application code. The EJBDeploy tool also runs the rmic tool against the remote EJB interfaces in the application, producing additional stub and tie class files that interact with the Remote Method Invocation over Internet Inter-ORB Protocol (RMI-IIOP) Object Request Broker(ORB), providing remote object support.

For modules previous to EJB 3.0, you ran the EJBDeploy tool when you installed the application on Application Server or before you installed the application from the command-line tool or a development tool.


Just-In-Time (JIT) deployment

EJB 3.0 support in Application Server introduced a new feature called JIT deployment.

With JIT deployment, the EJB container dynamically generates the wrapper, stub, and tie classes in-memory when the application is running. Additionally, the web container and application client containers dynamically generate the stub class required for remote EJB invocations.

Effectively, this means that we do not need to process EJB 3.0 or 3.1 modules, web modules that invoke EJB 3.0 or 3.1 beans, or client modules that invoke EJB 3.0 or 3.1 beans through the EJBDeploy tool before running them in Application Server.


createEJBStubs tool

In most cases the Just-In-Time deployment feature can dynamically generate the RMI-IIOP stub classes required for invocation of remote EJB interfaces. There are some instances in which these stub classes are not dynamically generated. For EJB 3.0 or 3.1 clients that are not running inside an EJB 3.x enabled web container, EJB container, or client container, generate the stub classes with the createEJBStubs tool and ensure that the generated stubs are available in the client environment's class path. Typically, you would accomplish this by copying the generated stubs to the location where the client's business interface class resides.

The createEJBStubs tool must be used to generate client-side stubs for the following environments:


Interoperability

There can be unexpected results if a WebSphere stack product, or another product, that runs on a version of Application Server that does not support EJB 3.0 or 3.1 attempts to remotely invoke a method on an EJB 3.x compliant enterprise bean on a separate server running a version Application Server that supports EJB 3.0 or 3.1. If these products attempt to invoke a method through the enterprise bean's EJB 3.x remote business interface, they might encounter exceptions that were introduced in EJB 3.0 that will be pushed back to the environment that is not EJB 3.x compliant.

This scenario could also be an issue for an administrator of an environment that includes a combination of stack products containing a mixture of EJB 3.x compliant and non-compliant instances of Application Server.

The following is a list of the exception classes introduced in EJB 3.0:

Refer to the EJB module deployment step to address potential interoperability issues.


EJB 2.x Modules

EJB 2.x modules that have been converted to be EJB 3.0 or EJB 3.1 modules should have all WebSphere Application Server generated files (including stub and tie classes) removed prior to EJB deployment in the Application Server product.


Related concepts

  • EJB 3.x module packaging overview
  • EJB modules


    Related tasks

  • Deploy EJB modules
  • Task overview: Use enterprise beans in applications