+

Search Tips   |   Advanced Search

EJB 3.0 and EJB 3.1 deployment overview

During deployment, WebSphere Application Server generates code that encapsulates the EJB implementation classes, connecting them to the WAS EJB container. The EJB container hosts the enterprise beans and provide services to them. If our enterprise beans have remote interfaces defined, WAS generates additional code to provide the remote function.


EJBDeploy Tool

EJB deployment can be performed by the EJBDeploy tool, which is included with WAS and packaged with the development tools.

The EJBDeploy tool...

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 RMI-IIOP Object Request Broker, providing remote object support.

For modules previous to EJB 3.0, we ran the EJBDeploy tool when we installed the application on Application Server or before we 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, we 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, we 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 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:

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 WAS generated files (including stub and tie classes) removed prior to EJB deployment in the Application Server product.


Related:

  • EJB 3.x module packaging overview
  • EJB modules
  • Deploy EJB modules
  • Task overview: Using enterprise beans in applications