Before an application that is installed on an application server can start, all enterprise bean (EJB) references and resource references defined in the application must be bound to the actual artifacts (enterprise beans or resources) defined in the application server.
When defining bindings, you specify Java Naming and Directory Interface (JNDI) names for the referenceable and referenced artifacts in an application. The jndiName values specified for artifacts must be qualified lookup names. An example referenceable artifact is an EJB defined in an application. An example referenced artifact is an EJB or a resource reference used by the application. Binding definitions are stored in the ibm-xxx-bnd.xmi or ibm-xxx-bnd.xml files of an application. The xxx can be ejb-jar, web, application or application-client.
For EJB 3.0 modules,
you do not need to manually assign JNDI binding names for each of
the interfaces or EJB homes on your enterprise beans. If you do not
explicitly assign bindings, the EJB container assigns default bindings.
See EJB 3.0 application bindings overview.
This topic provides the following information about bindings:
You can define bindings at the following times:
An application developer can create binding definitions in ibm-xxx-bnd.xmi files using a tool such as an IBM Rational developer tool. The developer then gives an enterprise application (.ear file) complete with bindings to an application assembler or deployer. When assembling the application, the assembler does not modify the bindings. Similarly, when installing the application onto a server supported by WebSphere® Application Server, the deployer does not modify or override the bindings or generate default bindings unless changes to the bindings are necessary for successful deployment of the application.
An
EJB 3.0 module developer can create binding definitions in ibm-ejb-jar-bnd.xml files
using an XML editor or text editor.
An application assembler can define bindings when modifying deployment descriptors of an application. Bindings are specified in the WebSphere Bindings section of a deployment descriptor editor. Modifying the deployment descriptors might change the binding definitions in the ibm-xxx-bnd.xmi files created when developing an application. After defining the bindings, the assembler gives the application to a deployer. When installing the application onto a server supported by WebSphere Application Server, the deployer does not modify or override the bindings or generate default bindings unless changes to the bindings are necessary for successful deployment of the application.
An application deployer or server administrator can modify the bindings when installing the application onto a server supported by WebSphere Application Server using the administrative console. New binding definitions can be specified on the install wizard pages.
If the deployer or administrator selects to override any existing bindings or to generate default bindings during application installation, default bindings are assigned to the application and new bindings might need to be specified using the console.
Selecting Generate Default Bindings during application installation causes any incomplete bindings in the application to be filled in with default values. Existing bindings are not changed.
Restrictions: You
cannot define or override bindings during application installation
for the following modules:
You cannot specify JNDI names for EJB 3.0 modules on administrative console panels. To specify JNDI names for EJB 3.0 modules or update EJB 3.0 module bindings, edit the META-INF/ibm-ejb-jar-bnd.xml file. See Ways to update application files.
You must define bindings for application client modules during assembly and store the bindings in the ibm-application-client-bnd.xmi file.
After an application is installed onto a server supported by WebSphere Application Server, an application deployer or server administrator can modify the bindings by changing values in administrative console pages such as those accessed from the settings page for the enterprise application.
Before an application can be successfully deployed, bindings must be defined for the following components and references:
If a deployer chooses to generate default bindings when installing the application, the install wizard assigns EJB JNDI names having the form prefix/EJB_name to incomplete bindings. The default prefix is ejb, but can be overridden. The EJB_name is as specified in the deployment descriptor <ejb-name> tag.
During and after application installation, EJB JNDI names can be specified on the Provide JNDI names for beans panel. After installation, click > EJB JNDI names in the administrative console.
You cannot specify JNDI names for EJB 3.0 modules
on administrative console panels. To specify JNDI names for EJB 3.0
modules or update EJB 3.0 module bindings, you can edit the META-INF/ibm-ejb-jar-bnd.xml file.
You do not need to manually assign JNDI binding names for each of
the EJB 3.0 interfaces or EJB homes on your enterprise beans. If you
do not explicitly assign bindings, the EJB container assigns default
bindings. See EJB 3.0 application bindings overview.
An example JNDI name for a Store data source in a Store application might be store/jdbc/store. The binding definition is stored in IBM binding files such as ibm-ejb-jar-bnd.xmi. A deployer can also specify whether authentication is handled at the container or application level.
During and after application installation, data sources can be mapped to 2.x entity beans on the 2.x CMP bean data sources panel and on the 2.x entity bean data sources panel. After installation, click in the administrative console, then select 2.x CMP bean data sources or 2.x entity bean data sources. Data sources can be mapped to 1.x entity beans on the Map data sources for all 1.x CMP beans panel and on the Provide default data source mapping for modules containing 1.x entity beans panel. After installation, access console pages similar to those for 2.x CMP beans, except click links for 1.x CMP beans.
Specify the backend ID during application installation. You cannot select a backend ID after the application is installed onto a server.
To enable backend IDs for individual EJB modules:
During application installation, if you select Deploy enterprise beans on the Select installation options panel and specify a database type for the EJB deployment tool on the Provide options to perform the EJB Deploy panel, previously defined backend IDs for all of the EJB modules are overwritten by the chosen database type.
The default database type is DB2UDB_V81.
For EJB 3.0 modules,
you cannot enable the Deploy enterprise beans option
or access the Provide options to perform the EJB Deploy panel. The
EJB deployment tool does not run during installation of EJB 3.0 modules.
For information on backend databases, refer to EJB deployment tool. For information on EJB Deploy options, refer to The ejbdeploy command.
For each EJB 2.1 or earlier EJB reference, you must specify a JNDI name. An example JNDI name for a Supplier EJB reference in a Store application might be store/ejb/Supplier. The binding definition is stored in IBM binding files such as ibm-ejb-jar-bnd.xmi. When the referenced EJB is also deployed in the same application server, you can specify a server-scoped JNDI name. But if the referenced EJB is deployed on a different application server or if ejb-ref is defined in an application client module, then you should specify the global cell-scoped JNDI name.
If a deployer chooses to generate default bindings when installing the application, the install wizard binds EJB references as follows: If an <ejb-link> is found, it is honored. If the ejb-name of an EJB defined in the application matches the ejb-ref name, then that EJB is chosen. Otherwise, if a unique EJB is found with a matching home (or local home) interface as the referenced bean, the reference is resolved automatically.
During and after application installation, EJB reference JNDI names can be specified on the Map EJB references to beans panel. After installation, click EJB references in the administrative console.
> You cannot specify JNDI names for EJB 3.0 modules
on administrative console panels. However, you can have the product
assign default JNDI values for incomplete EJB 3.0 reference targets;
select Allow EJB reference targets to resolve automatically on
the Select installation options, Map EJB references to beans, or EJB
references console panels. To specify JNDI names for EJB 3.0 modules
or update EJB 3.0 module bindings, edit the META-INF/ibm-ejb-jar-bnd.xml file.
See information on AutoLink in EJB 3.0 application bindings overview.
For more information, refer to EJB references.
Resource reference type | Subcontext declared in |
Java DataBase Connectivity (JDBC) data source | java:comp/env/jdbc |
JMS connection factory | java:comp/env/jms |
JavaMail connection factory | java:comp/env/mail |
Uniform Resource Locator (URL) connection factory | java:comp/env/url |
For each resource reference, you must specify a JNDI name. If a deployer chooses to generate default bindings when installing the application, the install wizard generates resource reference bindings derived from the <res-ref-name> tag, assuming that the java:comp/env name is the same as the resource global JNDI name.
During application installation, resource reference JNDI names can be specified on the Map resource references to references panel. Specify JNDI names for the resources that represent the logical names defined in resource references. You can optionally specify login configuration name and authentication properties for the resource. After specifying authentication properties, click OK to save the values and return to the mapping step. Each resource reference defined in an application must be bound to a resource defined in your WebSphere Application Server configuration. After installation, click > Resource references in the administrative console to access the Resource references panel.
You cannot specify
JNDI names for EJB 3.0 modules on the Map resource references to references
or Resource references console panels. To specify JNDI names for EJB
3.0 modules or update EJB 3.0 module bindings, edit the META-INF/ibm-ejb-jar-bnd.xml file.
If a deployer chooses to generate default bindings when installing the application, the install wizard sets the virtual host to default_host for each .war file.
During and after application installation, you can map a virtual host to a Web module defined in your application. On the Map virtual hosts for Web modules panel, specify a virtual host. The port number specified in the virtual host definition is used in the URL that is used to access artifacts such as servlets and JSP files in the Web module. For example, an external URL for a Web artifact such as a JSP file is http://host_name:virtual_host_port/context_root/jsp_path. After installation, click > Virtual hosts in the administrative console.
During application installation using the administrative console, you can specify a listener port name or an activation specification JNDI name for every message-driven bean on the Bind listeners for message-driven beans panel. A listener port name must be provided when using the JMS providers: Version 5 default messaging, WebSphere MQ, or generic. An activation specification must be provided when the application's resources are configured using the default messaging provider or any generic J2C resource adapter that supports inbound messaging. If neither is specified, then a validation error is displayed after you click Finish on the Summary panel. Also, if the module containing the message-driven bean is deployed on a 5.x deployment target and a listener port is not specified, then a validation error is displayed after you click Next.
After application installation, you can specify JNDI names and configure message-driven beans on console pages under Choosing a messaging provider.
or under . For more information, refer toIf multiple message destination references are associated with a single message destination link, then a single JNDI name for an enterprise bean that maps to the message destination link, and in turn to all of the linked message destination references, is collected during deployment. At run time, the message destination references are bound to the administered message destinations in the target operational environment.
If a message destination reference and a message-driven bean are linked by the same message destination, both the reference and the bean should have the same destination JNDI name. When both have the same name, only the destination JNDI name for the message-driven bean is collected and applied to the corresponding message destination reference.
If a deployer chooses to generate default bindings when installing the application, the install wizard assigns JNDI names to incomplete message destination references as follows: If a message destination reference has a <message-destination-link>, then the JNDI name is set to ejs/message-destination-linkName. Otherwise, the JNDI name is set to eis/message-destination-refName.