 |
Añadir una dirección | Buscador | Cursos | Artículos | Foros | Formación |
 |
 |
Sistema de Nombrado en Java (JNDI) [Parte I] |
|
En esta página:
El Sistema de Nombres Actual
No importa si el proveedor de servicio soporta separación fuerte o débil, una vez que ha determinado los componentes de un nombre mixto que debe procesar, necesita procesarlos. Cómo hace esto depende de su participación en la resuolución del nombre como un sistema de nombres intermedio o como un sistema de nombres terminal.
Un sistema de nombres intermedio es un sistema de nombres que sólo está involucrado en la resolución de nombres mixtos. Es responsable de pasar la operación a su contexto fuente. El sistema de nombres terminal (o fuente) es el sistema que contiene el contexto en el que se lleva a cabo la operación.
En otras palabras, el sistema de nombres terminal es el sistema nombrado por la raíz de componentes de un nombre mixto. En el siguiente ejemplo de nombre mixto.
cn=homedir,cn=Jon Ruiz,ou=People/tutorial/report.txt
el directorio LDAP es un sistema de nombres intermedio y es responsable de resolver el nombre "cn=homedir,cn=Jon Ruiz,ou=People".
El sistema de ficheros UNIX es el sitema de nombres terminal o fuente y es el responsable de solicitar la operación de contexto sobre el nombre "tutorial/report.txt".
El procesamiento de un sistema de nombres terminal no es muy interesante. El proveedor simplemente lleva a cabo la solicitud de operación de contexto. Por ejemplo, si el método de contexto invocado fue Context.list(), el proveedor de servicio invocará a list(), usando sus componentes desde el nombre mixto, como si no fuera una federación y devuelve el resultado de list() a su llamador.
Por el contrario, procesar un sistema de nombres intermedio es mucho más interesante.. El trabajo del proveedor es determinar la referencia del siguiente sistema de nombres, o nns, dando sus componentes desde el nombre mixto. Esta referencia se llama puntero del siguiente sistema de nombres, o puntero nns. En el ejemplo anterior, el proveedor LDAP debe determinar el puntero nns del nombre LDAP "cn=homedir,cn=Jon Ruiz,ou=People".
Recuperar Punteros NNS
Un proveedor de servicio puede soportar recuperación de punteros nns de dos formas. La primera es usar explícitamente una llamada a puntero nns, también llamada junction. La segunda forma es un puntero nns implícito.
Junctions
Una junction es una unión de un nombre a un puntero nns; en el ejemplo anterior, "cn=homedir,cn=Jon Ruiz,ou=People" es una junction. Este nombre está unido a una referencia de un contexto de sistema de ficheros. Si realizamos un Context.lookup() sobre el nombre, no obtendremos una entrada LDAP sino un ejemplar de Context para un directorio (/tmp) en el sistema de ficheros.
Un contexto podría tener un número ilimitado de junctions. Además, una junction normalmente es indistinguible de otros nombres normales, aunque esto depende de la política de nombrado del sistema de nombres subyacente.
Punteros NNS Implícitos
Un proveedor de servicio trambién puede soportar recuperación de punteros nns implícitos. A un puntero nns implícito se le llama usando el separador de componente de nombre mixto ("/").
Supongamos que el nombre "corp.wiz.com" nombra un objeto en el sistema de nombres actual. Entonces el nombre "corp.wiz.com/" nombrará un puntero nns.
Un puntero nns implícito se usa cuando entradas de sistemas de nombres nativos no pueden o no deben usarse directamente para contener un puntero nns. Puede determinarse estáticamente o dinámicamente.
Un Puntero NNS Implícito Estático se construye usando datos encontrados en el sistema de nombres actual. Por ejemplo, supongamos que almacenamos punteros nns en el DNS usando registros TXT. Cuando el proveedor DNS procesa el nombre "corp.wiz.com/", usará los datos en el registro TXT de la entrada "corp.wiz.com" para construir el puntero nns.
Un Puntero NNS Implícito Dinámico puede determinarse basándonos en los tipos y contenidos del objeto unido en el sisterma de nombres actual. Es útil cuando el resultado de resolver los componentes de un nombre mixto en el sistema de nombres actual no indica niguna información nns.
La única conclusión que este proveedor de servicios puede dibujar es que la resolución se completó en el sistema de nombres actual y debería proceder al siguiente sistema de nombres.
Por ejemplo, supongamos que el nombre mixto "lib/xyz.zip/part1/abc" consta de dos partes: "lib/xyz.zip" y "part1/abc".
"lib/xyz.zip" nombra un fichero en formato ZIP, y "part1/abc" nombra una entrada del fichero ZIP. La resolución de "lib/xyz.zip" resulta en un objeto file y no indica que nns usar para continuar la operación sobre "part1/abc".
Para soportar punteros nns implíticos dinámicos, el JNDI define una Reference especial llamada referencia nns. Esta referencia tiene un tipo de dirección "nns" y un contenido de dirección que es el objeto resuelto. En el ejemplo del fichero ZIP, el objeto resuelto es el propio fichero ZIP y el proveedor del sistema de ficheros debería construir una referencia nns de esta forma.
Reference ref = new Reference("java.io.File",
new RefAddr("nns") {
public Object getContent() {
return theFile;
}
});
|
|
|
| Principio Página |
|
© 1999-2002, Programación en castellano, s.l. Contacto - Datos legales ReD Internet: Hospedaje Web | envio sms gratis | Salvapantallas | Fondos de Escritorio, famosas | melodias moviles gratis| Gratis |