|
Prerequisito:
Deber�as estar familiarizado con el modelo de eventos usado por el JNDI antes de leer esta secci�n. El modelo de eventos se cubre en la lecci�n Notificaci�n de Eventos. |
Normalmente un proveedor de servicio soporta notificaci�n de enventos cuando el servicio de nombres/directorio proporciona dicha caracter�stica. Sin embargo, un proveedor de servicio podr�a soportar notificaci�n de eventos incluso si el servicio subyacente no lo hace. Simplemente necesita hacer m�s trabajo y quiz�s ofrecer la caracter�stica obligando a cambiar el servicio subyacente.
�Introducci�n de la Arquitectura
La notificaci�n de eventos se puede implementar de varias formas diferentes. Abajo tenemos una arquitectura de ejemplo. Sin embargo, que una funcione con nuestro proveedor de servicio depender� de las caracter�sticas del servicio de nombres/directorio subyacente.
Para a�adir soporte de notificaci�n de eventos, necesitamos estos tres componentes:
- Bookkeeper.
Mantiene la lista de oyentes y es responsable de implementar los m�todos de registro/desregistro de los interfaces EventContext y EventDirContext. - Notifier.
Notifica un evento al oyente(s). Normalmente la ocurrencia de un evento la dispara un cambio as�ncrono en el servicio subyacente. El notificador detecta el cambio (por ejemplo, mediante un mensaje del servicio subyacente o mediante la obtenci�n de su estado) y pone un evento correspondiente en la cola de eventos. - Cola de Eventos.
Mantiene una cola de eventos que han ocurrido y dispara eventos a los oyentes registrados.
Para implementar la notificaci�n de eventos, nuestra implementaci�n de contexto debe implementar los interfaes EventContext o EventDirContext. El bookkeeper podr�a ser una parte de la implementaci�n de contexto o una utilidad usada por esta implementaci�n. Cuando un programa registra un oyente, el bookkeeper graba el oyente y el objetivo en el que est� interesado. Luego usa--crea o usa un thread de un almacen de threads-- un notifier para seguir el objetivo. Normalmente, el notifier es un thread que escucha los cambios del objetivo. Cuando el notifier detecta un cambio que lanzar� un evento, crea un evento que contiene la imformaci�n apropiada y lo pone en la cola de eventos. El notifier vuelve a escuchar los futuros cambios. La cola de eventos es monitorizada por un thread manejador de cola de eventos, cuyo trabajo es eliminar un evento de la cola y despacharlo a los oyentes apropiados.
�Trucos de Implementaci�n
Aqu� hay algunos trucos que debemos tener en mente cuando desarrollemos nuestra implementaci�n de contexto:
- Manejar el Registro de Oyentes.
El registro de oyentes est� asociado con un ejemplar Context no con la represetnaci�n del contexto en el servicio subyacente. Por ejemplo, supongamos que est�mos usando un servicio LDAP. No podemos esperar registrar un oyente con uno de los ejemplares Context y eliminarlo de otro ejemplar Context, incluso si �mbos representan la misma entrada LDAP. Por lo tanto nuestra implementaci�n deber�a mantener listas de oyentes separadas para ejemplares de Context diferentes. - Cu�ndo Des-registrar.
Algunos eventos causan un des-registro autom�tico. Si un oyente recibe una excepci�n o si se cierra el ejemplar Context con el que se han registrado, el oyente es des-registrado autom�ticamente y no recbir� m�s eventos. Nuestra implementaci�n del notifier deber�a prestar atenci�n a los eventos de excepci�n que genera y decirle al bookkeeper que des-registre a los oyentes que reciben dichas excepciones (s�lo despu�s de que hayan sido enviados los eventos de excepci�n). - Usar threads.
Sin importar si nuestra elecci�n sigue el ejemplo de arquitectura descrito en p�ginas anteriores, el soporte de notificaci�n de eventos requiere el uso de threads. Adem�s, estos threads manipulan datos compartidos como ejemplares de Context, colas de eventos y listas de oyentes. Debemos asegurarnos de tener un buen conocimiento del modelo de Threads en el lenguaje Java.