• Artículo

Elegir una estrategia de inicio

En este tema se describen las opciones para la activación de Service Broker.

Service Broker admite la mensajería asincrónica, en cola. Dado que las conversaciones pueden mantenerse días, meses o años, muchas aplicaciones utilizan la activación para escalar dinámicamente. En esta sección se describen algunas estrategias comunes para iniciar una aplicación que utiliza Service Broker.

Estrategias de inicio

Las estrategias para iniciar una aplicación entran en cuatro categorías amplias:

  • Activación interna

  • Activación basada en eventos

  • Tarea programada

  • Tarea de inicio

Cada estrategia de activación tiene diferentes ventajas. Una aplicación puede combinar estas estrategias. Por ejemplo, una aplicación puede utilizar la activación interna con un número pequeño de lectores de cola la mayoría del tiempo. Pero, en ciertos momentos del día, puede iniciar más lectores de cola.

Activación interna

Con la activación interna de Service Broker, un monitor de cola Service Broker activa directamente un procedimiento almacenado cuando es necesario. Éste es a menudo el enfoque más sencillo. Si se utiliza la activación directa de un procedimiento almacenado, no tiene que escribir el código adicional en la aplicación para administrar la activación. Sin embargo, la activación interna requiere que la aplicación se escriba como un procedimiento almacenado SQL Server. Al utilizar la activación interna, escribe la aplicación para salir cuando ya no quedan mensajes para procesar.

Activación basada en eventos

Algunas aplicaciones se ejecutan en respuesta a un evento concreto. Por ejemplo, puede ejecutar una aplicación cuando el uso de la CPU en el equipo cae por debajo de cierto nivel. También puede ejecutar una aplicación de registro cuando se crea una tabla nueva.

La activación externa de Service Broker es un caso especial de activación basada en eventos Para la activación externa, la aplicación se inicia en respuesta al evento QUEUE_ACTIVATION.

Para los eventos que pueden estar activados por notificaciones de eventos, la activación basada en eventos se puede combinar con la activación interna de Service Broker. En este caso, se utiliza la activación interna en la cola que recibe la notificación de eventos. El procedimiento almacenado de activación recibe el mensaje de notificación e inicia la aplicación.

Para otros eventos, puede utilizar el Agente SQL Server para iniciar los trabajos en el mismo equipo que el equipo en el que se ejecuta SQL Server. Puede escribir una aplicación que supervisa los eventos de Instrumental de administración de Windows (WMI) desde un equipo remoto. La aplicación puede iniciar una tarea cuando un evento WMI se produce en el equipo que ejecuta SQL Server.

Al utilizar la activación basada en eventos, una aplicación sale normalmente cuando no quedan más mensaje para procesar.

Tarea programada

Con una tarea programada, una aplicación se activa en una programación establecida. Esta estrategia resulta adecuada para las aplicaciones de procesamiento por lotes. Una aplicación que se ejecuta como tarea programada puede salir cuando ya no queden más mensajes para procesar; igualmente el programa puede salir en un momento determinado.

Por ejemplo, una aplicación que procesa los pedidos de un proveedor puede almacenar los mensajes durante el día y procesar los mensajes por la noche para generar un único pedido al proveedor. En este caso, la aplicación puede utilizar un trabajo de Agente SQL Server para iniciar la aplicación en un momento concreto cada noche.

Tarea de inicio

Algunas aplicaciones se inician en un momento determinado, normalmente cuando arranca el equipo o cuando SQL Server se inicia. Los ejemplos de estas tareas son un procedimiento almacenado de inicio en SQL Server, una aplicación en el grupo de inicio de Windows o un servicio de Windows. En este caso, la aplicación sigue ejecutándose y procesa los mensajes a medida que llegan. Una aplicación que se ejecuta continuamente no requiere un tiempo de inicio cuando un mensaje llega en la cola. Sin embargo, debido a que la aplicación no sale cuando no hay ningún mensaje, el programa consume los recursos incluso cuando no tiene trabajo que realizar.

Esta estrategia puede ser útil para una aplicación que procesa una secuencia constante de mensajes y que cuenta con un gran uso de recursos durante el inicio.