Una factor�a de estado implementa el interface StateFactory o DirStateFactory.
StateFactory tiene un m�todo: getStateToBind().
public Object getStateToBind( Object obj, Name name, Context nameCtx, Hashtable environment) throws NamingException;
DirStateFactory es un subinterface de StateFactory y declara un m�todo adicional:getStateToBind():
public DirStateFactory.Result getStateToBind( Object obj, Name name, Context nameCtx, Hashtable environment, Attributes inAttrs) throws NamingException;
Este m�todo acepta como un argumento el objeto a unir (obj).
Los argumentos name y nameCtx se le proporcionan a la factor�a de estado en caso de que �sta requiera informaci�n adicional. El argumento env son las propiedades de entorno del contexto que est� usando la factor�a de estado. La versi�n DirStateFactory del m�todo acepta un argumento adicional inAttrs (Attributes), que contiene los atributos a unir con el objeto obj.
�StateFactory contra DirStateFactory
Deber�amos usar un StateFactory con un contexto que implemente el interface Context.
Usaremos DirStateFactory con un contexto que implemente el interface DirContext.
Por ejemplo, un proveedor de servicios de nombres COS s�lo implementa el interface Context. Como no se le van a pasar argumentos Attributes al proveedor de servicios, y consecuentemente tampoco a la factor�a de estado, el proveedor de servicio s�lo usara getStateToBind() como se define en el interface StateFactory. Por el contrario, el proveedor de servicio LDAP normalmente implementa el interface DirContext y usar� getStateToBind() como se define en el interface DirStateFactory.
�Accesibilidad
La clase de la factor�a de estado no s�lo debe implementar los interfaces StateFactory/DirStateFactory y proporcionar implementaci�n para los m�todos getStateToBind().
Tambi�n debe ser p�blica e tener un constructor p�blico que no acepte argumentos.
�Descripci�n del Trabajo
Normalmente, una factor�a de estado es bastante simple y peque�a. Su papel principal es realizar alguna transformaci�n de la entrada y producir un objeto (y/o atributos) capaces de ser almacenados por el proveedor de servicios. Por ejemplo, una factor�a de estado para un proveedor LDAP podr�a aceptar un objeto y algunos atributos y devolver un conjunto de atributos que sean la uni�n entre los atributos de entrada y los atributos que representan el objeto.
Una factor�a de estado para un proveedor de servicio de nombres COS, por ejemplo, acepta un objeto java.rmi.Remote y devuelve su objeto tie(v�nculo) CORBA.
En general, existe una relaci�n muy cerrada entre la representaci�n del objeto que es almacenado en el servicio de nombres o directorio subyacente y la factor�a de estado que hace la transformaci�n. Por ejemplo, si un objeto est� representado por un conjunto de atributos en un directorio, la correspondiente factor�a de estado deber�a devolver atributos para representar el objeto.
�Y si todo Falla
Una factor�a de estado normalmente es muy espec�fica con respecto a los tipos de transformaciones que maneja. Por ejemplo, una factor�a podr�a aceptar objetos CORBA, mientras que otra s�lo podr�a aceptar objetos que implementen un interface espec�fico. De echo, en muchos casos, como se esplica en la siguiente p�gina, el JNDI le pedir� a un factor�a de estado que intente la transformaci�n usando entradas que estaban pensadas para otras factor�as.
Es muy com�n que un s�lo proveedor de serivicios use m�ltiples factor�as de estado. Por lo tanto, si una factor�a encuentra que no soporta el tipo de entrada suministrado, deber�a devolver null. La factor�a s�lo deber�a lanzar una excepci�n cuando encuentre un error procesando la entrada que por otro lado deber�a haber aceptado. Lanzar una excepci�n evita que se puedan intentar otras factor�as de estados.