Creamos una federaci�n de una de estas dos formas:
- Mediante administraci�n expl�cita
- Mediante composici�n din�mica
En la primera forma, unimos expl�citamente la referencia de un sistema de nombres dentro de un contexto de otro sistema de nombres. Por ejemplo, podr�amos grabar informaci�n de referencia sobre el sistema de nombres LDAP departamental local dentro de un sistema DNS cuyas aplicaciones puedan resolver subsecuentemente un nombre mixto que contiene un nombre DNS y un nombre LDAP. En la �ltima forma, tenemos la federaci�n creada din�micamente como la resoluci�n de procesar un nombre mixto. Por ejemplo, un sistema de ficheros contiene diferentes tipos de ficheros. Algunos de esos ficheros podr�an tener formato ZIP. Podemos crear una federaci�n usando un nombre mixto que contenga el nombre del fichero y su entrada dentro del fichero ZIP. De esta forma, la federaci�n se crea din�micamente sin asistencia externa y puede modificarse seg�n los tipos de ficheros y sus correspondientes proveedores de servicio.
Una uni�n expl�cita consta de un nombre y una referencia. Dependiendo del sistema de nombres al que est� unida la referencia, la referencia real podr�a tener diferentes formas. Por ejemplo, un sistema de nombres LDAP departamental podr�a estar unido dentro de un DNS mediante un registro DNS SRV que contiene las direcciones IP y los DNs de los servidores LDAP. O, la referencia JNDI de un sistema de nombres de aplicaci�n podr�a unirse a un sistema LDAP. Tambi�n un sistema de nombres podr�a representarse de forma diferente en un sistema de nombres superior. Por ejemplo, el mismo sistema de nombres podr�a unirse usando diferentes datos en el DNS y en el LADP. Sin importar su formato de almacenamiento, una referencia se representa eventualmente de forma program�tica mediante un objeto Reference. La lecci�n Objetos Java y el Directorio describe c�mo se puede transformar una Reference desde y ha su representaci�n real.
Desde la perspectiva de un desarrollador de proveedores de servicio es una buena idea definir una referencia para la implementaci�n de contexto. Esto asegura a los usuarios del proveedor el uso de una referencia consistente cuando se refieran a contextos en la implementaci�n y cuando unan contextos de la implementaci�n dentro de sistemas de nombres externos.
�Referencia
Una referencia de contexto deber�a contener los datos necesarios para crear un ejemplar Context. Si el contexto representa estado sobre un servidor de nombres o directorio, entonces su referencia deber�a como m�nimo contener informaci�n sobre c�mo contactar con el servidor y c�mo identificar su estado dentro del servidor. Algunas veces esta tarea es complicada por el hecho de que el acceso al servidor podr�a est� controlado y requerir autentificaci�n. Te hemos advertido de no situar informaci�n sensible de seguridd como passwords dentro de una referencia. Mejor todav�a, la referencia deber�a ser gen�rica y la informaci�n de autentificaci�n del contexto ignorada.
Si el proveedor de servicio ya tiene una implementaci�n de contexto URL y una factor�a para la implementaci�n de contexto, podremos influenciar en el dise�o de la referencia de contexto. Por ejemplo, simplemente podemos hacer que la referencia contenga la URL(s) del contexto. Esto no s�lo hace m�s consistente el acceso al contexto, sino que simplifica significativamente la implementaci�n de la correspondiente factor�a de objetos.
�Factor�a de Objetos
Una vez que hemos definido el formato de la referencia para nuestra implementaci�n de contexto, podemos escribir una factor�a de objetos para ella. As�, las aplicaciones podr�n acceder a nuestra implementaci�n de contexto mediante referencias en vez de nombres.
Abajo hay un ejemplo de una factor�a de objetos escrita para usar la factor�a de objetos URL de la misma implementaci�n de contexto. Por ejemplo, supongamos que nuestra implementaci�n de contexto soporta el esquema URL foo y que tiene la factor�a de contexto URL tut.foo.fooURLContextFactory. La correspondiente factor�a de objetos FooCtxFactory podr�a parecerse a esto:
public class FooCtxFactory implements ObjectFactory {
public FooCtxFactory() {
}
public Object getObjectInstance(Object ref, Name name, Context nameCtx,
Hashtable env) throws Exception {
if ((ref instanceof Reference) &&
myClassName.equals(((Reference)ref).getFactoryClassName())) {
// Create a URL context factory
ObjectFactory factory = new tut.foo.fooURLContextFactory();
// Extract the URL(s) from the Reference
String[] urls = getURLs((Reference)ref);
// Ask the URL context factory to process the URL(s)
return factory.getObjectInstance(urls, name, nameCtx, env);
}
// This is not meant for this factory
return null;
}
}
getURLs() es una utilidad que extrae el string URL desde la direcci�n de la referencia.
�Referenciable
Para unir el contexto no es necesario una relaci�n sim�trica. Simplemente porque podamos buscar un contexto desde un sistema de nombres externo no significa necesariamente que podamos unir program�ticamente (la referencia del) mismo contexto dentro de un sistema de nombres externo. La uni�n podr�a haber sido a�adida administrativamente a trav�s de herramientas espec�ficas para ese sistema de nombres externo.
No importa, podemos planear el soporte para uniones program�ticas haciendo que nuestra implementaci�n de contexto sea referenceable. Para hacer esto, hacemos que la implementaci�n implemente el interface Referenceable. Tambi�n, proporcionamos una implementaci�n para getReference(). Este m�todo deber�a devolver una referencia que pueda ser alimentada a la factor�a de objetos del proveedor.