Application bindings

 

+

Search Tips   |   Advanced Search

 

Overview

Before an application that is installed on an application server can start, all EJB and resource references defined in the application must be bound to the actual artifacts (EJBs or resources) defined in the application server.

When defining bindings, you specify 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 in the application in the following files...

ibm-ejb-jar-bin.xmi
ibm-web-bin.xmi
ibm-application-bin.xmi
ibm-application-client-bin.xmi

 

Times when bindings can be defined

We can define bindings at the following times:

  • During application development

    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 WAS, 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.

  • During application assembly

    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 WAS without selecting to override the bindings or generate default bindings unless changes to the bindings are necessary for successful deployment of the application.

  • During application installation

    An application deployer or server administrator can modify the bindings when installing the application onto a server supported by WAS 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.

    Select 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.

  • During configuration of an installed application

    After an application is installed onto a server supported by WAS, 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:

EJB JNDI names

For each enterprise bean (EJB), specify a JNDI name. The name is used to bind an entry in the global JNDI name space for the EJB home object. An example JNDI name for a Product EJB in a Store application might be...

store/ejb/Product

The binding definition is stored in the file..

META-INF/ibm-ejb-jar-bnd.xmi

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 | appname | Provide JNDI Names for Beans

...in the administrative console.

Data sources for entity beans

Entity beans such as CMP beans store persistent data in data stores. With CMP beans, an EJB container manages the persistent state of the beans. You specify which data store a bean uses by binding an EJB module or an individual EJB to a data source. Binding an EJB module to a data source causes all entity beans in that module to use the same data source for persistence.

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 | appname

...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.

Backend ID for EJB modules

If an EJB .jar file that defines CMP beans contains mappings for multiple backend databases, specify the appropriate backend ID that determines which persister classes are loaded at run time.

Specify the backend ID during application installation. We cannot select a backend ID after the application is installed onto a server.

EJB references

An enterprise bean (EJB) reference is a logical name used to locate the home interface of an enterprise bean. EJB references are specified during deployment. At run time, EJB references are bound to the physical location (global JNDI name) of the enterprise beans in the target operational environment. EJB references are made available in the java:comp/env/ejb Java naming subcontext.

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, one 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 | appname | Map EJB references to beans

...in the administrative console.

Resource references

A resource reference is a logical name used to locate an external resource for an application. Resource references are specified during deployment. At run time, the references are bound to the physical location (global JNDI name) of the resource in the target operational environment. Resource references are made available as follows:

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. We 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 WAS configuration. After installation, click...

Applications | Enterprise Applications | appname | Map resource references to resources

...in the administrative console to access the Map resource references to resources panel.

Virtual host bindings for Web modules

You must bind each Web module to a specific virtual host. The binding informs a Web server plug-in that all requests that match the virtual host must be handled by the Web application. An example virtual host to be bound to a Store Web application might be store_host. The binding definition is stored in IBM binding files such as WEB-INF/ibm-web-bnd.xmi.

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, one 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 | appname | Map virtual hosts for Web modules

...in the administrative console.

Message-driven beans

For each message-driven bean, specify a queue or topic to which the bean will listen. A message-driven bean is invoked by a Java Messaging Service (JMS) listener when a message arrives on the input queue that the listener is monitoring. A deployer specifies a listener port or JNDI name of an activation spec as defined in a connector module (.rar file) under WebSphere Bindings on the Beans page of an assembly tool EJB deployment descriptor editor. An example JNDI name for a listener port to be used by a Store application might be StoreMdbListener. The binding definition is stored in IBM bindings files such as ibm-ejb-jar-bnd.xmi.

If a deployer chooses to generate default bindings when installing the application, the install wizard assigns JNDI names to incomplete bindings.

During application installation using the administrative console, one 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: V5 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, one can specify JNDI names and configure message-driven beans on console pages under...

Resources | JMS Providers

...or under...

Resources | Resource Adapters

Message destination references

A message destination reference is a logical name used to locate an enterprise bean in an EJB module that acts as a message destination. Message destination references exist only in J2EE 1.4 artifacts such as--

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

 

See Also


Enterprise application settings