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".
- Los Enterprise JavaBeans se sit�an bajo el sub�rbol "ejb". Por ejemplo, un EJB Payroll podr�a llamarse "java:comp/env/ejb/Payroll".
- Las referencias a factor�as de recursos se sit�an en sub�rboles
diferenciados por sus tipos de manejador de recurso. Aqu� tenemos algunos
ejemplos.
- "jdbc" para referencias a fuentes de datos JDBC
- "jms" para factor�as de conexiones JMS
- "mail" para factor�as de conexiones JavaMail
- "url" para factor�as de coenxiones URL
Por ejemplo, un base de datos JDBC Salary podr�a tener el nombre "java:comp/env/jdbc/Salary".
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.