Responsabilidades del programador para el Service Broker

El programador de aplicaciones es responsable del diseño de la aplicación Service Broker y la creación de elementos que requieren la programación. El administrador del sistema es responsable de la configuración y administración de Service Broker. Los programadores y los administradores tienen que trabajar juntos al planear el sistema, para asegurarse de que se desarrolla y administra de manera óptima para sus fines empresariales y de entorno concretos.

Las tareas implicadas en la creación de una aplicación individual dependen de las necesidades de la aplicación. Lo siguiente es una secuencia común de tareas para programar una aplicación de Service Broker:

  1. Planee la aplicación. Cree un esquema de las tareas que debe lograr la aplicación. Describa las conversaciones que tienen lugar durante cada tarea. ¿Qué extremo necesita para proporcionar qué información y en qué orden? ¿Qué procesamiento debe tener lugar? ¿Qué prioridades deberían asignarse a las conversaciones? Toda la información posterior depende de este esquema.

  2. Determine el formato y la estructura de cada mensaje de cada conversación. Planee la secuencia esperada de intercambio para los mensajes y la manera en la que cada participante de la conversación debería responder a los errores y mensajes que se envían en un orden inesperado.

  3. Si la conversación usa mensajes XML, cree un esquema para cada mensaje XML. Use esquemas durante el desarrollo, las pruebas y la solución de problemas. Cuando su servicio está en producción, puede decidir quitar la validación del esquema de sus tipos de mensaje para mejorar el rendimiento.

  4. Cree un tipo de mensaje para cada mensaje de cada conversación.

  5. Cree un contrato para cada conversación. El contrato identifica los tipos de mensaje que se pueden usar por cada extremo de la conversación.

  6. Cree una cola para almacenar los mensajes que recibirá la aplicación.

  7. Cree un servicio para exponer la funcionalidad definida por el contrato e implementada por el procedimiento almacenado, que ha creado. Al crear un servicio, lo asocia a la cola que creó en el paso anterior. Al hacerlo, indica a Service Broker que todos los mensajes que llegan dirigidos a ese servicio se colocarán en la cola identificada.

  8. Revise los planes de prioridad que ha establecido en el paso 1. Cree prioridades de la conversación que traten todos los extremos de la conversación diseñados para usar niveles de prioridad distintos del valor predeterminado. Si se deberían usar niveles de prioridad cuando los mensajes se transmiten desde una base de datos, asegúrese de que la opción HONOR_BROKER_PRIORITY de dicha base de datos está establecida en ON.

  9. Cree una aplicación que implemente el patrón de intercambio de mensajes esperado y los requisitos de procesamiento identificados en el paso 1. Si la aplicación usa la activación interna, la aplicación es un procedimiento almacenado.

  10. Si la aplicación usa la activación interna, modifique la cola para habilitar la activación. Especifique el procedimiento almacenado creado en el paso 8 como el procedimiento almacenado de activación.

  11. Identifique los servicios que usan el servicio que acaba de crear. Si existe cualquiera de estos servicios fuera de la instancia de SQL Server local, cree rutas para ellos.

  12. Revise los servicios remotos que ha identificado en el paso anterior y determine los requisitos de seguridad para las comunicaciones con los mismos. Si es necesario, cree certificados para exigir estos requisitos y, a continuación, cree a usuarios de base de datos para los certificados. Asocie los certificados a estos inicios de sesión. Los administradores o los programadores de los demás servicios deben crear enlaces de servicio remoto para habilitar la seguridad de diálogo en el tráfico a este servicio.

  13. Durante el desarrollo y la prueba, a menudo es conveniente que una aplicación trabaje con los nombres de usuario que la aplicación usará en producción pero para asociar dichos nombres de usuario a certificados que se usan únicamente en el entorno de desarrollo y de prueba. Cuando la aplicación pase a la producción, use certificados creados para el entorno de producción. Al usar certificados diferentes, puede reducir el esfuerzo implicado en la implementación de la aplicación a la vez que se mantiene todavía la seguridad entre el entorno de desarrollo y el entorno de producción.