Políticas de Nombrado
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.
Tipos de Políticas
Hay dos categorías de políticas.
- Políticas de nombres que especifican cómo nombrar los objetos en relación
de unos con otros y los nombres comunes a usar.
- Políticas de directorios, llamadas esquemass,
que especifican los atributos que los objetos del directorio debería tener y
los nombres y las síntaxis de dichos atributos.
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.
Políticas de nombres de la Plataforma Java 2 Enterprise Edition
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.
Tutoriales
