Los nombres se explican m�s extensamente en la lecci�n �Qu� es un nombre?. Esta lecci�n explica en general c�mo un desarrollador de proveedores de servicio deber�a tratar los par�metros string y los nombres estructurados de los m�todos del interface Context y sus subinterfaces.
�Nombres String
Un nombre String es un nombre mixto. Incluso si la implementaci�n de contexto que estamos escribiendo no va a soportar federaci�n, seguir esta regla es una buena idea para que los usuarios de nuestro proveedor no tengan que tratar a nuesto proveedor de forma diferente en este aspecto.
Siguiendo esta regla, escribiremos las sobrecargas del interface Context y sus subinterfaces que aceptan un nombre java.lang.String como una simple envoltura alrededor de las sobrecargas que aceptan un Name. Como ejemplo, aqu� tenemos una definici�n de implementaci�n de contexto de Context.lookup():
Object lookup(String name) throws NamingException {
return lookup(new CompositeName(name));
}
�Nombres Mixtos
Un nombre estructurado est� representado por un objeto que implementa el interface Name. Puede representar un nombre mixto o un nombre compuesto. En cualquier caso, el par�metro nombre pertenece al llamador y no deber�amos modificarlo (puedes ver m�s detalles en la p�gina Par�metros y Valores de Retorno).
Un nombre mixto est� representado por un ejemplar de CompositeName. Si nuestra implementaci�n de contexto no soporta federaci�n, entonces puede crear nombres mixtos de dos formas. La m�s simple es para la implementaci�n de contexto que lanza una InvalidNameException cuando recibe un CompositeName. Sin embargo, esta aproximaci�n es Draconicana en que impide que la aplciaci�n pase un CompositeName, incluso si el CompositeName contiene s�lo componentes que pertencen al espacio de nombres de la implementaci�n de contexto. Una aproximaci�n m�s comprometida es para la implementaci�n de contexto que s�lo acepta CompositeNames que contienen componentes que pertenecen a su espacio de nombres. En esta aproximaci�n, la implementaci�n extrae los componentes que pertenecen a su espacio de nombres, y para los componentes que no pertenece, lanza una InvalidNameException.
Si nuestra implementaci�n de contexto soporta federaci�n, deber�a extraer los componentes del CompositeName que pertenecen a su espacio de nombres. Para componentes que no le pertenecen deber�a resolver sus propios componentes y pasar los componentes restantes al nns. (Se dar�n m�s detalles sobre esto en la lecci�n A�adir Soporte de Federaci�n.) Si la implementaci�n s�lo recibe componentes de su espacio de nombre, deber�a procesar la operaci�n solicitada.
Aqu� tenemos un pseudo-c�digo que ilustra el caso no-federado:
Object lookup(Name name) throws NamingException {
if (name instanceof CompositeName) {
{mine, theirs} = splitName(name);
if (theirs.size() == 0) {
// Find in internal tables
return impl.get(mine);
} else {
// Don't support federation
throw new InvalidNameException(name.toString() +
" has more components than I can handle");
}
} else {
// Process the compound name
...
}
}
�Nombres Compuestos
Un nombre compuesto puede estar representado por cualquier implementaci�n del interface Name excepto CompositeName o una de sus subclases. La forma m�s sencilla, aunque no la m�s eficiente, de hacer que una implementaci�n de contexto acepta un nombre compuesto es convertirlo en un nombre mixto.
Aqu� tenemos un ejemplo que mapea un nombre compuesto en un nombre mixto de un s�lo componente:
Object lookup(Name name) throws NamingException {
if (name instanceof CompositeName) {
// Process composite name
...
} else {
// Process compound name; turn it into single-component CompositeName
return lookup(new CompositeName().add(name.toString()));
}
}
Esta es la soluci�n m�s general. Normalmente una implementaci�n de contexto puede hacer esto mucho m�s eficientemente usando directametne la forma pre-analizada (ejemplar de Name) o el nombre compuesto "stringified". Por ejemplo, una implementaci�n podr�a usar el nombre compuesto "stringified" como una clave para una tabla interna.