WAS v8.5 > Deploy applications > Deploy EJB applications > Deploy EJB modules

EJB 3.0 and EJB 3.1 deployment overview

Java EE application servers have an EJB deployment phase, during which the application is customized to run in that particular application server.

Historically, EJB deployment in WAS has been performed by the EJBDeploy tool, included with WAS, and packaged with the development tools for the WebSphere products.

The EJBDeploy tool...

  1. Introspects the external interfaces for the enterprise beans
  2. Generates wrapper code as .java files
  3. Runs rmic to generate stub and tie code that interacts with the RMI-IIOP ORB, providing remote object support.
  4. Compiles code into .class files using the javac compiler
  5. Packages .class files into in custom EJB modules, along with the application code

For modules previous to EJB 3.0, we ran EJBDeploy when we installed the application on WAS, or before we installed the application from the command-line tool or a development tool. EJB 3.0 support in WAS introduced a new feature called JIT deployment. With JIT deployment, the EJB container dynamically generate wrapper, stub, and tie classes in-memory when the application is started. 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 WAS.


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, you must generate the stub classes with the createEJBStubs tool and ensure 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 that is running a version WAS 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 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 WAS generated files (including stub and tie classes) removed prior to EJB deployment in WAS.


Related concepts:

EJB 3.x module packaging overview
EJB modules


Related


Deploy EJB modules
Tasks: Using enterprise beans in applications


+

Search Tips   |   Advanced Search