Chapter 6 Enterprise JavaBeans Overview

EJB 1.1 differences from EJB 1.0

The main change in EJB 1.1 involves the packaging of components. EJB 1.1 uses an XML deployment descriptor, and allows abstraction of container-specific resource references used within the source code. In addition, there are minor changes to the Java interfaces and classes.

For more details, see the EJB 1.1 and 1.0 specifications from Sun Microsystems .

Component differences

JNDI names in deployment descriptors

The EJB 1.1 JAR file format does not specify JNDI names for deployed EJB components. Consequently, EJB 1.1 components imported into EAServer use the default JNDI name of package/component, where package is the EAServer package name and matches the display-name attribute of the EJB deployment descriptor, and component is the EAServer component name and matches the bean's ejb-name element in the deployment descriptor.

If you have an existing client application that invoke the component, you may have to change the component's JNDI name or the name used in client application.

For intercomponent calls from EJB 1.1 components, you can use the EJB References property to alias the JNDI name used in the bean to an installed component with a different JNDI name.

Environment properties

EJB 1.1 allows environment properties to be accessed using JNDI, and the EJBContext.getEnvironment method is now deprecated. Environment properties can also contain values of types other than String.

Environment properties used within a bean must be cataloged in the bean's deployment descriptor. For EJB 1.1 components installed in EAServer, you configure environment properties on the Environment tab in the Component Properties dialog box. See "Configuring environment properties"

You must call the JNDI Context.lookup method to access environment properties. To locate the naming context, create a javax.naming.InitialContext object for java:comp/env. In this example, the application retrieves the value of the environment property maxExemptions and uses that value to determine an outcome:

Context initContext = new InitialCopntext();
Context myEnv = 
   (Context)initContext.lookup("java:comp/env");

// Get the maximum number of tax exemptions
Integer max=(Integer)myEnv.lookup("maxExemptions");

// Get the minimum number of tax exemptions 
Integer min = (Integer)myEnv.lookup("minExemptions");

// Use these properties to customize the business logic
if (numberOfExemptions > max.intValue() ||
   (numberOfExemptions < min.intValue())
    throw new InvalidNumberOfExemptionsException();

EJB and resource references

EJB 1.1 allows components to use logical names to access database connections, JavaMail sessions, and the home interfaces of other components. These names must be catalogued in the bean's deployment descriptor. For components installed in EAServer, you configure references on the Resource References tab in the Component Properties dialog box. See these sections for more information:

Security access-control changes

The getCallerIdentity and isCallerInRole(java.security.Identity) methods in the EJBContext interface are deprecated in EJB 1.1. Instead of getCallerIdentity, call getCallerPrincipal. Instead of isCallerInRole(java.security.Identity), call isCallerInRole(java.lang.String).

In Jaguar Manager, you can configure role references for your component in the Component Properties dialog box. Role references allow you to map names used in isCallerInRole(java.lang.String) calls to role names that exist on the server. Role references allow your component to be deployed on servers that do not have the same security configuration.

Declarative access control for EJB 1.1 components uses method-level settings.

Role Membership folder does not apply to EJB 1.1 or 2.0 components The Role Membership folder for packages and components in Jaguar Manager does not apply to EJB 1.1 or 2.0 components. There are two ways to control which clients can call EJB component methods:

You can use the Permissions tab in the Method Properties dialog box to configure access declaratively for each method. To limit access to all of a component's remote interface methods, configure the permissions for the home-interface create and finder methods.
You can configure additional access control programmatically by calling the getCallerPrincipal and isCallerInRole methods in the component implementation. Programmatic access control enhances declarative access control, but does not replace it.

Configuring method permissions

Method permissions allow you to restrict access without writing code. Configure method permissions as follows:

If necessary, define new EAServer roles to be used by callers of the component.
Verify that J2EE roles are mapped to EAServer roles in the properties of the package where the component is installed; check the Role Mappings tab in the Package Properties window. You must map a J2EE role name for each role to be used in method permissions.
For each method that requires limited access, display the Method Properties dialog and highlight the Permissions tab. A check box displays for each mapped J2EE role in the package that contains the component. Select the check box by each role that can call the method.

Configuring role references

Role references are required if you call the isCallerInRole Java method to restrict access. Each reference maps a string used in isCallerInRole calls to a J2EE role that is configured in the package Role Mappings. To configure role references:

If necessary, define new EAServer roles to be used by callers of the component.
Verify that J2EE roles are mapped to EAServer roles in the properties of the package where the component is installed; check the Role Mappings tab in the Package Properties window. You must map a J2EE role name for each role to be used in role references.
For each component that calls the isCallerInRole method, display the Component Properties dialog and highlight the Role Refs tab. Add or modify roles as follows:
- To add a role, click Add and edit the new entry as described below.
- To modify a role, edit the Reference Name (used in isCallerInRole calls), and choose the mapped J2EE role (configured in the properties of the package where the component is installed).

Transaction isolation level

In accordance with the EJB 1.1 specification, you cannot set the transaction isolation level declaratively for EJB 1.1 components. The simplest way to configure the transaction isolation level is to configure the defaults on the databases that you access from your EJB components. If this is not possible, you must set the isolation level programmatically in the component implementation.

Client model differences

Except for the differences below, the EJB 1.1 client model is identical to the EJB 1.0 model:

Finder method return types Finder methods in EJB 1.1 clients can return java.util.Collection or java.util.Enumeration. Finder methods in EJB 1.0 must return java.util.Enumeration. The use of java.util.Collection is recommended for new development.
Configuring Java finder method return types You can specify the return type for finder methods that return multiple keys with an IDL directive, as described in "Specifying Java package mappings for IDL modules". If you import interfaces from an EJB-JAR file or EJB class files, these directives are created automatically.When generating EJB stubs, choose the Java version to specify the default return type for IDL finder methods that lack an EJB package directive. See "Generating EJB stubs" for more information.
Home interface serialization You can call the Home.getHandle method to serialize a home interface proxy in an EJB 1.1 client.
EJBMetaData enhancements The EJBMetaData interface, used by development tools to dynamically inspect EJB components, provides an isStatelessSession method that returns true if the component is a stateless session bean.