Compartir a través de

  • Artículo

Generar aplicaciones con Service Broker

Cualquier programa que pueda ejecutar instrucciones Transact-SQL puede utilizar Service Broker. Una aplicación de Service Broker puede implementarse como un programa que se ejecuta fuera de SQL Server o como un procedimiento almacenado escrito en Transact-SQL o en un lenguaje .NET.

Un programa que utiliza Service Broker suele constar de un número de componentes que funcionan juntos para realizar una tarea. Un programa que inicia una conversación crea y envía un mensaje a otro servicio. Este programa puede esperar una respuesta o salir inmediatamente y confiar en que otro programa procese la respuesta. En el caso de un servicio que es el destino de una conversación, el programa recibe un mensaje entrante de la cola del servicio, lee los datos del mensaje, realiza cualquier procedimiento necesario y, a continuación, crea y envía un mensaje de respuesta si procede.

Service Broker amplía Transact-SQL. Una aplicación no necesita un modelo de objeto especial ni una biblioteca para trabajar con Service Broker. En su lugar, los programas envían comandos Transact-SQL a SQL Server y procesan los resultados de estos comandos. Una aplicación puede estar activada por Service Broker, se puede ejecutar como un servicio en segundo plano o como un trabajo programado, o se puede iniciar como respuesta a un evento. Para obtener más información sobre las estrategias para iniciar una aplicación que utiliza Service Broker, vea Elegir una estrategia de inicio.

Para obtener información sobre la creación de aplicaciones con Service Broker, vea Ventajas de programar con Service Broker.

Información general de la aplicación de Service Broker

En la siguiente ilustración se muestra la interacción en una aplicación que utiliza Service Broker:

Relación y flujo de mensajes en conversaciones

Como se muestra en la ilustración, los tipos de mensajes SubmitExpense, AcceptDenyExpense y ReimbursementIssued se crean en primer lugar. El contrato ProcessExpenses se crea basándose en estos tipos de mensajes y proporciona un esquema para que una conversación finalice una tarea de reembolso de gastos. El contrato ProcessExpenses controla todas las conversaciones entre el servicio ProcessExpense y el servicio SubmitExpense. El contrato ProcessExpenses y los tipos de mensajes que utiliza deben existir en las bases de datos de todos los servicios que tienen conversaciones basadas en este contrato.

Service Broker almacena los mensajes enviados al servicio SubmitExpense en la cola de dicho servicio. El procedimiento almacenado ExpenseSubmission recibe mensajes de esta cola, los procesa y envía mensajes a otro servicio si se necesita respuesta.

Service Broker almacena los mensajes enviados al servicio ProcessExpense en la cola de dicho servicio. El procedimiento almacenado ExpenseProcessing recibe mensajes de esta cola, los procesa y envía mensajes a otro servicio si se necesita respuesta.

Una conversación entre estos dos servicios se estructuraría como se indica a continuación:

  • Un usuario envía una solicitud de reembolso de gastos a través de una interfaz de usuario. La aplicación ejecuta el procedimiento almacenado ExpenseSubmission, que crea un mensaje SubmitExpense. El servicio SubmitExpense inicia una conversación con el servicio ProcessExpense y, a continuación, envía el mensaje SubmitExpense al servicio ProcessExpense.

  • Service Broker recibe el mensaje SubmitExpense para el servicio ProcessExpense y coloca el mensaje en la cola ExpenseQueue. La cola ExpenseQueue activa el procedimiento almacenado ProcessExpense, que quita el mensaje SubmitExpense de la cola y lo procesa. El procedimiento almacenado ProcessExpense crea entonces un mensaje AcceptDenyExpense y lo envía al servicio SubmitExpense. Si el gasto se deniega, el procedimiento almacenado ProcessExpense finaliza la conversación.

  • Service Broker pone el mensaje AcceptDenyExpense para el servicio SubmitExpense en la cola del servicio. Si el procedimiento ProcessExpense ha finalizado la conversación, Service Broker coloca un mensaje EndDialog en la cola Expenses. La cola activa el procedimiento almacenado ExpenseSubmission, que quita el mensaje AcceptDenyExpense de la cola y lo procesa. Si el procedimiento almacenado ExpenseSubmission encuentra un mensaje EndDialog en la cola, el procedimiento finaliza la conversación.

  • Si el gasto se acepta, el servicio ProcessExpense crea y envía un mensaje ReimbursementIssued confirmando que se ha emitido el pago del gasto y, a continuación, finaliza la conversación. Service Broker coloca estos mensajes en la cola del servicio. La cola activa el procedimiento ExpenseSubmission, que procesa el mensaje ReimbursementIssued. A continuación, el procedimiento procesa el mensaje EndDialog y finaliza la conversación.