Como se mencionó anteriormente en esta lección, el JNDI está definido independientemente de cualquier implementación de servicio de nombres o directorios. Esto permite que se pueda acceder a una gran variedad de sistemas de nombres y directorios de una forma común. Sin embargo, para ofrecer verdadera independencia, se necesitan políticas comunes que especifiquen cómo deberían usarse los nombres y directiros. Sin estas políticas, podríamos usar el mismo API para acceder a los datos, pero la forma de encontrar y utilizar esos datos sería dependiente del directorio. La falta de política es un problema no sólo para sistemas de nombres y directorios múltiples, sino también para sistemas solitarios como es el LDAP. Sin un acuerdo general sobre cómo se organizan y utilizan los datos en el directorio, un sistema sencillo se puede deteriorar facilmente hasta llegar a ser un amasijo inmanejable. Por ejemplo, supongamos que dos aplicaciones necesitan asociar datos con un usuario en un enterprise. Si cada aplicación elige su propia política de cómo nombrar y representar un usuario en el directorio, entonces el directorio contendrá dos representaciones del mismo usuario. Además, los usuarios de cada aplicación tendrán que aprenderse cada representación y cómo nombrarla.

Hay dos categorías de políticas.

El LDAP define síntaxis de atributos (RFC 2252) y esquemas de relación de usuarios (RFC 2256). También están disponibles muchas otras proposiciones de esquemas específicos del dominio, como para mail y seguiridad. Además de los esfuerzos de estandarizar los esquemas a través de los diferentes sistemas de directorios (RFC 2307). Varios esquemas propietarios han emergido en el espacio LDAP de vendedores como Netscape y Microsoft. Algunas aplicaciones que están basadas en servidores de estos vendedores tienen dependencias de esquemas propietarios.

En el área de políticas de nombres, se han definido en el X.500. La mayoría de los sistemas LDAP siguen una convención de nombrado común en los niveles superiores del árbol de nombres (por ejeplo, cómo  nombrar países, organizaciones y departamentos). Existe menos acuerdo en los niveles inferiores. Sin embargo, algunos servidores, como el "Active Directory" de Microsoft, han definido sus propias políticas de nombres.

El DNS ha definido políticas de nombres en los niveles superiores del árbol de nombres. Se usa principalmente para nombrar máquinas y dominios en Internet e Intranet por eso las políticas de nombres para otras entidades son menos relevantes.

En términos de política de nombres mixtos, las URLs HTTP y FTP han configurado de echo el estándar. El primer componente de una URL nombra el host/dominio usando el DNS. Después del primer componente, hay un espacio de nombres propietario.

El JNDI no define una política de nombres por si mismo. Sin embargo, una plataforma importante si define un conjunto limitado de políticas de nombrado para usar JNDI es la Plataforma Java 2, Enterprise Edition (J2EE). Define un espacio de nombres lógico para que componentes de  aplicaciones (como Enterprise JavaBeans, servlets, y JavaServer Pages (JSP)) puedan usar recursos de nombres y otros datos. El espacio de nombres para un componente lo proporciona su contenedor, la entidad que ejecuta el componente. Normalmente, un componente tiene un descriptor de desarrollo que contiene, junto con otros datos, información sobre los nombres y tipos lógicos de los recursos y componentes que el componente necesita o referencia. Un administrador, usando información del descriptor de desarrollo, mapea el espacio de nombres lógico para unirlos con el espacio de nombres del entorno real dentro del que se está desplegando el componente. El contenedor usa este mapeo para presentar el espacio de nombres lógico al componente. Puedes ver la especificación J2EE para más detalles.

El espacio de nombres enterprise está enraizado en un contexto URL para el esquema URL java. Por ejemplo, podríamos usar un nombre como "java:comp/env/jdbc/Salary" desde el contexto inicial para nombrar la base de datos Salary. Los detalles sobre los contextos URL se describen en la lección URLs.

Usando un contexto URL, la política evita cualquier conflicto de nombres con nombres en el contexto inicial configurado por la propiedad de entorno Context.INITIAL_CONTEXT_FACTORY.

En la raíz del contexto del espacio de nombres hay una unión con el nombre "comp", que está unida a un subárbol reservado para uniones relacionadas con componentes. El nombre "comp" es la abreviatura de componente. No hay otras uniones en el contexto raíz. sin embargo, el contexto raíz está resevado para una expansión futura de la política, específicamente para recursos de nombres que no tratan con el propio componente sino con otros tipos de entidades como usuarios o departamentos. Por ejemplo, las políticas futuras podrían permitirnos nombrar usuarios y organizaciones/departamentos usando nombres como "java:user/alice" o "java:org/engineering".

En el contexto "comp", hay dos uniones: "env" y "UserTransaction". El nombre "env" está unido a un subárbol que está reservado para uniones relacionadas con el entorno, según los definido por el descriptor de desarrollo. "env" es la abreviatira de "environment" (entorno). El J2EE recomienda (que no exige) la siguiente estructura del espacio de nombres "env".

El contexto "env" también podría contener uniones para otros tipos de datos de configuración (como string y envolturas para tipos de datos primitivos) que los componentes necesitan, como se define en el descriptor de desarrollo del componente. No se recomienda o necesita ninguna política para estas uniones; pueden situarse en la raíz del contexto "env" o ser divididas en subárboles basándose en sus tipos o relaciones lógicas.

Por ejemplo, podríamos tener uniones para un string y un parámetro numérico que son nombrados usando "java:comp/env/CompanyName" y "java:comp/env/PrimeRate", respectivamente.

El nombre "UserTransaction" está unido a un objeto javax.transaction.UserTransaction. El componente que busque este objeto desde el espacio de nombres usando el nombre "java:comp/UserTransaction") puede usarlo para arrancar, enviar o abortar transaciones.