EJB 3.0 and EJB 3.1 deployment overview

Learn about the Enterprise JavaBeans (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 your 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 your application classes, rather than generating code, but the end result is similar.

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

For more information about packaging your 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 your 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 your EJB module with your 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 that contain entity beans, the EJBDeploy tool is needed when you install the application on Application Server or before you install the application from the command-line tool or a development tool.

Just-In-Time (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 that is required for remote EJB invocations.

Effectively, this means that you do not need to process any EJB module, web module, or client module through the EJBDeploy tool before you run them in Application Server unless the module contains entity beans.

createEJBStubs tool

In most cases the Just-In-Time deployment feature can dynamically generate the RMI-IIOP stub classes that are required for invocation of remote EJB interfaces. There are some instances in which these stub classes are not dynamically generated. For EJB clients that are not running inside an EJB-enabled web container, EJB container, or client container, you must 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:
  • "Bare" Java Standard Edition (SE) clients, where a Java SE Java Virtual Machine (JVM) is the client environment.
  • Containers in Application Server environments prior to Version 7 that do not have the Feature Pack for EJB 3.0 applied.
  • Environments that are not WebSphere Application Server 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 that is 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 that contain 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:
  • javax.ejb.ConcurrentAccessException
  • javax.ejb.EJBAccessException
  • javax.ejb.EJBTransactionRequiredException
  • javax.ejb.EJBTransactionRolledbackException
  • javax.ejb.NoSuchEJBException

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.