Ventajas de Service Broker

Integración de bases de datos

El diseño integrado de Service Broker proporciona ventajas para el rendimiento y la administración de la aplicación.

La integración con SQL Server permite la mensajería transaccional sin la sobrecarga y complejidad añadidas de un coordinador externo de transacciones distribuidas. Una aplicación recibe uno o más mensajes, los procesa y envía y responde a los mensajes con una sola transacción de base de datos. Si la transacción genera un error, todo el trabajo se revierte y el mensaje recibido se devuelve a la cola para que otro intento pueda procesarlo. No se lleva a cabo ninguna acción hasta que la aplicación confirma la transacción. La aplicación permanece en un estado coherente.

La administración es más sencilla cuando los datos, los mensajes y la lógica de la aplicación están en la misma base de datos, ya que la administración de la aplicación (recuperación de desastres, seguridad, copia de seguridad, etc.) se convierte en parte de la administración rutinaria de la base de datos y el administrador no tiene que administrar tres o cuatro componentes independientes.

Con los sistemas de mensajería tradicionales, el almacén de mensajes y la base de datos pueden volverse incoherentes. Por ejemplo, cuando un componente se restaura desde una copia de seguridad, también se debe restaurar otro componente de una copia de seguridad realizada al mismo tiempo; de lo contrario, la información del almacén de mensajes no coincide con la información de la base de datos. Dado que Service Broker mantiene mensajes y datos en la misma base de datos, la incoherencia no supone ningún problema.

Otra ventaja de la integración de bases de datos es contar con un entorno de desarrollo común. La parte de mensajería y la parte de datos de una aplicación pueden utilizar los mismos lenguajes y las mismas herramientas de SQL Server en una aplicación de Service Broker, aprovechando así el conocimiento del programador de las técnicas de programación de bases de datos para la programación basada en mensajes. Los procedimientos almacenados que implementan un servicio de Service Broker pueden escribirse en Transact-SQL o en uno de los lenguajes CLR (Common Language Runtime). Los programas externos a la base de datos utilizan Transact-SQL y conocidas interfaces de programación de bases de datos como ADO.NET.

Además, la integración de bases de datos permite la administración automática de recursos. Service Broker se ejecuta en el contexto de la instancia de SQL Server, por lo que supervisa todos los mensajes listos para transmitirse desde todas las bases de datos de la instancia. Esto permite a cada base de datos mantener sus propias colas mientras ayudan a Service Broker a administrar el uso de los recursos en la instancia de SQL Server.

Ordenar y coordinar mensajes

En los sistemas de mensajería tradicionales, la aplicación es la responsable de ordenar y coordinar los mensajes que pueden llegar sin orden. Por ejemplo, la aplicación A envía los mensajes 1, 2 y 3. La aplicación B recibe y confirma los mensajes 1 y 3, pero genera un error con el mensaje 2. La aplicación A reenvía el mensaje 2, pero ahora el mensaje se recibe después de los mensajes 1 y 3. En el pasado, un programador debía escribir la aplicación para que el orden de los mensajes no importara o debía almacenar temporalmente en la memoria caché el mensaje 3 hasta que llegara el 2 para que la aplicación pudiera procesar los mensajes en el orden correcto. Ninguna de las soluciones es directa ni sencilla.

Otro problema de los sistemas tradicionales ha sido la entrega duplicada. En el ejemplo anterior, si la aplicación B recibe el mensaje 2 pero se pierde el reconocimiento del mensaje en la aplicación A, la aplicación A reenvia el mensaje 2 haciendo que la aplicación B reciba el mensaje 2 dos veces. El código de la aplicación debía poder identificar o descartar el duplicado o volver a procesar el duplicado sin producir efectos negativos. De nuevo, ambos métodos eran difíciles de implementar.

Tradicionalmente, la coordinación de mensajes ha sido un problema difícil de controlar. Por ejemplo, una aplicación puede enviar cientos o miles de solicitudes a un servicio. El servicio procesa las solicitudes en paralelo y devuelve una respuesta tan pronto como el servicio acaba de procesar la solicitud. Como cada solicitud tiene una cantidad de tiempo de proceso distinta, la aplicación recibe respuestas en un orden distinto del orden en que la aplicación envió el mensaje saliente. Sin embargo, para procesar las respuestas correctamente, la aplicación debe asociar cada respuesta con el mensaje saliente correcto. En los sistemas de mensajería tradicionales, cada aplicación administraba esta asociación, lo cual agregaba el costo y la complejidad de desarrollar la aplicación.

Service Broker resuelve estos problemas controlando el orden de los mensajes, la entrega única y la identificación de conversación de forma automática. Una vez que se establece una conversación entre dos extremos del broker, una aplicación recibe cada mensaje sólo una vez y en el orden en el que se envió. La aplicación puede procesar mensajes exactamente una vez en orden sin ningún código adicional. Por último, Service Broker incluye de forma automática un identificador en cada mensaje. Una aplicación siempre puede deducir a qué conversación pertenece un mensaje determinado.

Acoplamiento flexible y flexibilidad de carga de trabajo

Service Broker proporciona un acoplamiento flexible entre la aplicación inicial y la aplicación de destino. Una aplicación puede enviar un mensaje en una cola y, a continuación, continuar con el procesamiento de la aplicación, confiando en que Service Broker se asegura de que el mensaje llega a su destino. Este acoplamiento flexible proporciona flexibilidad de programación. El iniciador puede enviar varios mensajes, y varios servicios de destino pueden procesarlos en paralelo. Cada servicio de destino procesa mensajes con su propio ritmo, dependiendo de la carga de trabajo actual.

Las colas también permiten a los sistemas distribuir el procesamiento de una forma más uniforme, reduciendo la capacidad máxima requerida por un servidor. Esto puede mejorar el rendimiento global en las aplicaciones de base de datos. Por ejemplo, muchas aplicaciones de base de datos tienen una sobrecarga en ciertos momentos del día, lo que incrementa el consumo de recursos y los tiempos de respuesta. Con Service Broker, estas aplicaciones no necesitan llevar a cabo todo el procesamiento de una transacción empresarial cuando se envía a la aplicación. En su lugar, la aplicación utiliza Service Broker para enviar información sobre la transacción a las aplicaciones que realizan el procesamiento en segundo plano. Estas aplicaciones procesan las transacciones de forma confiable en un período de tiempo, mientras que la aplicación de entrada principal continúa recibiendo nuevas transacciones empresariales.

Si el destino no está disponible inmediatamente, el mensaje se mantiene en la cola de transmisión para la base de datos de envío. Service Broker vuelve a intentar enviar el mensaje hasta que lo consigue o hasta que la vigencia de la conversación caduca permitiendo que una conversación confiable continúe entre dos servicios incluso si un servicio no está disponible temporalmente en algún momento de la conversación. Los mensajes de la cola de transmisión forman parte de la base de datos; Service Broker entrega el mensaje incluso si la instancia realiza una conmutación por error o se reinicia.

Bloqueo de mensajes relacionados

Uno de los objetivos más difíciles de conseguir en una aplicación de mensajería tradicional ha sido permitir que varios programas lean en paralelo en la misma cola. En los sistemas de mensajería tradicionales, los mensajes pueden procesarse sin orden cuando varios programas o subprocesos leen en la misma cola. Service Broker evita esta situación mediante el bloqueo de grupos de conversaciones.

Tome como ejemplo una aplicación de procesamiento de pedidos tradicional. En la cola se reciben el mensaje A, que contiene instrucciones sobre la creación del encabezado del pedido, y el mensaje B, que contiene instrucciones sobre la creación de elementos de línea de pedidos. Si ambos mensajes se quitan de la cola por instancias de aplicaciones independientes y se procesan al mismo tiempo, puede que se intente confirmar en primer lugar la transacción de elementos de línea de pedidos; esto generaría un error, ya que el pedido aún no existe. El error provoca que la transacción se revierta y que el mensaje vuelva a la cola y se vuelva a procesar, con el consiguiente gasto de recursos. Tradicionalmente, los programadores resolvían este problema mediante la combinación de la información del mensaje A y el mensaje B en un único mensaje. Si bien este enfoque es sencillo para dos mensajes, no se adapta eficazmente a los sistemas que implican la coordinación de docenas o cientos de mensajes.

Service Broker resuelve este problema al asociar conversaciones relacionadas en un grupo de conversación. Service Broker bloquea automáticamente todos los mensajes del mismo grupo de conversación para que sólo puedan recibirse y procesarse por una instancia de la aplicación. Mientras tanto, otras instancias de la aplicación pueden continuar extrayendo de la cola y procesando mensajes de otros grupos de conversación. Esto permite que varias instancias de aplicación paralelas trabajen de forma confiable y eficaz sin necesitar un código de bloqueo complicado en la aplicación.

Activación automática

Una de las características más útiles de Service Broker es la activación. La activación permite que una aplicación se amplíe de forma dinámica para coincidir con el volumen de mensajes que llegan a la cola. Service Broker proporciona características que permiten a los programas que se ejecutan dentro y fuera de la base de datos utilizar la activación. Sin embargo, Service Broker no requiere que una aplicación utilice la activación.

Service Broker supervisa la actividad de una cola para determinar si una aplicación recibe mensajes de todas las conversaciones que tienen mensajes disponibles. La activación de Service Broker inicia un nuevo lector de cola cuando hay trabajo para él. Para determinar cuándo hay trabajo para un lector de cola, Service Broker supervisa la actividad de la cola. Cuando el número de lectores de cola coincide con el tráfico entrante, la cola alcanza periódicamente un estado en el que la cola está vacía o en que todos los mensajes de la cola pertenecen a una conversación que está procesando otro lector de cola. Si una cola no alcanza este estado durante un período de tiempo, Service Broker activa otra instancia de la aplicación.

Las aplicaciones utilizan métodos de activación distintos para los programas que se ejecutan dentro de la base de datos y los programas que se ejecutan fuera de la base de datos. En los programas de la base de datos, Service Broker inicia otra copia del procedimiento almacenado especificado por la cola. En los programas que se ejecutan fuera de la base de datos, Service Broker genera un evento de activación. El programa supervisa este evento para determinar cuándo se necesita otro lector de cola.

Service Broker no detiene un programa iniciado mediante la activación. En su lugar, las aplicaciones activadas se escriben para cerrarse automáticamente después de un período de tiempo determinado sin que haya mensajes que recibir. Una aplicación diseñada de esta forma puede permitir que el número de instancias de aplicación aumente y disminuya de forma dinámica a medida que varía el tráfico del servicio. Además, si el sistema se cierra o se reinicia, las aplicaciones se inician automáticamente para leer los mensajes de la cola cuando se reinicia el sistema.

Los sistemas de mensajería tradicionales carecen de este comportamiento y suelen acabar con un número excesivo o insuficiente de recursos dedicados a una cola determinada en un momento dado.

Vea también

Otros recursos