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. 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 files of an application. The xxx can be ejb-jar, web, application or application-client.
Times when bindings can be defined
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 a deployer. When assembling the application and then installing it 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 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 assembling an application. After defining the bindings, the deployer can install the application onto a server supported by WebSphere Application Server without selecting to 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.
Note: Bindings can be defined or overridden during application installation for all modules except application clients. For clients, 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.
Required bindings
Before an application can be successfully deployed, bindings must be defined for references to the following artifacts:
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 Applications > Enterprise Applications > application_name > Provide JNDI Names for Beans in the administrative console.
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. If a deployer chooses to generate default bindings when installing the application, the install wizard generates the following for incomplete bindings:
The generated bindings provide default connection factory settings for each EJB 2.x .jar file and default data source settings for each EJB 1.1 .jar file in the application being installed. No bean-level connection factory bindings or data source bindings are generated.
During and after application installation, data sources can be mapped to 2.x entity beans on the Map data sources for all 2.x CMP beans panel and on the Provide default data source mapping for modules containing 2.x entity beans panel. After installation, click Applications > Enterprise Applications > application_name in the administrative console, then select Map data sources for all 2.x CMP beans or Provide default data source mapping for modules containing 2.x entity beans . 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.
For each EJB reference, 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 Applications > Enterprise Applications > application_name > Map EJB references to beans in the administrative console.
| 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, 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 Applications > Enterprise Applications > application_name > Map resource references to resources in the administrative console to access the Map resource references to references panel.
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 Applications > Enterprise Applications > application_name > Map virtual hosts for Web modules 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 panel Provide Listener Ports or activation specification JNDI name for messaging beans . 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 Resources > JMS Providers or under Resources > Resource Adapters. For more information, refer to Using asynchronous messaging.
If 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 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.
Other bindings that might be needed
Depending on the references in and artifacts used by your application,
you might need to define bindings for references and artifacts not listed in this article.
Related tasks
Configuring an application
Assembling applications
Editing deployment descriptors
Deploying and administering applications
Related reference
Enterprise application settings