In a distributed application, components need to access other components and resources such as databases. For example, a servlet might invoke remote methods on an enterprise bean that retrieves information from a database. In the Java EE platform, the Java Naming and Directory Interface (JNDI) naming service enables components to locate other components and resources.
A resource is a program object that provides connections to systems, such as database servers and messaging systems. (A JDBC resource is sometimes referred to as a data source.) Each resource object is identified by a unique, people-friendly name, called the JNDI name.
For example, the JNDI name of the JDBC resource for the Java DB database that is shipped with the Application Server is jdbc/__default.
An administrator creates resources in a JNDI namespace. In the Application Server, you can use either the Admin Console or the asadmin command to create resources. Applications then use annotations to inject the resources. If an application uses resource injection, the Application Server invokes the JNDI API, and the application is not required to do so. However, it is also possible for an application to locate resources by making direct calls to the JNDI API.
A resource object and its JNDI name are bound together by the naming and directory service. To create a new resource, a new name-object binding is entered into the JNDI namespace.
For information on creating Java Message Service (JMS) resources, see Creating JMS Administered Objects (page 1076). For information on creating Java API for XML Registries (JAXR) resources, see Creating JAXR Resources (page 735). For an example of creating a JDBC resource, see Creating a Data Source in the Application Server (page 56).
You inject resources by using the @Resource annotation in an application. For information on resource injection, see the following sections of this Tutorial:
You can use a deployment descriptor to override the resource mapping that you specify in an annotation. Using a deployment descriptor allows you to change an application by repackaging it, rather than by both recompiling the source files and repackaging. However, for most applications, a deployment descriptor is not necessary.