Planear el desarrollo de Service Broker
Revise lo siguiente conforme diseñe una aplicación de Service Broker:
Las métricas relativas al tipo y al volumen de entrada y salida que se esperan de su aplicación
Los requisitos para su aplicación propuesta.
Si entiende estos factores, puede programar un sistema que cumpla los objetivos empresariales.
Lista de comprobación en el diseño de una aplicación
Piense en las preguntas siguientes cuando planee la aplicación:
¿Qué función desempeña Service Broker en su aplicación?
La respuesta a esta pregunta le ayuda a planear los tipos de mensaje usados por la aplicación, la estructura de la misma, y las necesidades de almacenamiento y procesamiento de la aplicación.
Por ejemplo, su aplicación podría usar Service Broker para tratar con picos en la frecuencia de la llegada de mensajes almacenando los mensajes en colas hasta que los recursos estén disponibles para procesarlos. En este caso, los tipos de mensaje usados por la aplicación deberían coincidir en gran medida con la entrada y salida de la aplicación existente. Puede estimar las necesidades de almacenamiento y procesamiento para su aplicación, dependiendo de la carga de trabajo existente.
Por el contrario, si diseña una nueva aplicación, piense cuidadosamente en qué operaciones se pueden beneficiar la mayoría de Service Broker. El uso de Service Broker equilibra a menudo tiempos de procesamiento predecibles en el mejor caso a cambio de confiabilidad cuando se produciría un error completo en una aplicación convencional.
Por ejemplo, una aplicación de entrada de pedidos en línea podría no tener que procesar completamente el pedido y proporcionar confirmación final en el momento de envío del pedido. En su lugar, la aplicación podría enviar el pedido a un servicio que lo procesa y proporciona confirmación final a través del correo electrónico. Mediante este diseño, la aplicación de pedidos puede continuar aceptando los pedidos aunque los problemas de conexión de red eviten que la aplicación confirme el pedido. Cuando se resuelven los problemas de conexión de red, la aplicación procesa los pedidos. En este caso, las necesidades de almacenamiento y procesamiento de la aplicación dependen del número esperado de pedidos, del tamaño de cada mensaje del pedido y del tiempo que cada orden exige para su procesamiento.
¿Qué información se requerirá en una conversación para completar la tarea deseada? ¿Cuáles son los esquemas de los mensajes que intercambiarán los extremos para proporcionarse esta información entre sí?
La mayoría de los servicios intercambian información semiestructurada. Por tanto, la codificación XML es una buena opción. Una codificación binaria es útil para intercambiar archivos binarios como imágenes. Cuando un mensaje comunica sólo la llegada del mensaje, use un mensaje vacío.
Al seleccionar el tipo de mensaje correcto, tendrá menos probabilidades de tener que actualizar su aplicación posteriormente. Dependiendo de la codificación del tipo de mensaje, las actualizaciones pueden incluir cualquier cosa, desde tener que actualizar un archivo de esquema XML hasta tener que realizar cambios importantes en la codificación de su aplicación. Si hay elementos de datos que no necesita actualmente pero espera necesitar en el futuro, podría tener sentido incluirlos. Si define estos elementos en el esquema para comenzar con ellos, no tendrá que cambiar el esquema al admitirlos.
¿Dónde se ejecutará su lógica de procesamiento de mensajes?
Puede diseñar su aplicación como un procedimiento almacenado activado por Service Broker, como un servicio de fondo, como un evento programado o como una aplicación externa. La decisión final depende de la función que Service Broker desempeña en su aplicación. Por ejemplo, si su aplicación procesa una secuencia continua de mensajes que llegan a una velocidad predecible, podría usar un servicio de fondo. Si su aplicación se debe escalar dinámicamente basándose en el número de mensajes que llegan, puede usar un procedimiento almacenado activado por una cola. Si su aplicación contiene mensajes en una cola y procesa todos los mensajes en un momento fijo, puede usar un evento programado para iniciar la aplicación.
Puede usar una aplicación externa si su programa requiere acceso a los recursos que se encuentran fuera de la base de datos, como archivos o páginas web. El uso de una aplicación externa puede mejorar la escalabilidad de su aplicación, ya que el procesamiento se produce en los servidores de capa media en lugar de en el servidor de bases de datos. Es fácil de escalar una aplicación que usa Service Broker porque Service Broker proporciona acceso transaccional remoto a las colas. Cualquier aplicación que puede enviar los comandos Transact-SQL a la base de datos y procesar los resultados puede usar Service Broker.
Cada programa externo se aísla de otros programas que usan la cola. Por consiguiente, los programas externos no necesitan precauciones especiales para administrar el acceso a la cola. Además, si se produce un error en la conexión mientras la aplicación está procesando un mensaje, la transacción se revierte y Service Broker devuelve el mensaje a la cola. Los problemas de red no pueden hacer que la aplicación pierda un mensaje.
¿Qué tecnología planea para usar para implementar su aplicación?
Puede implementar una aplicación externa usando cualquier tecnología que puede conectar a la base de datos y ejecutar instrucciones Transact-SQL en SQL Server. Sin embargo, las aplicaciones se programan normalmente en un lenguaje compatible con .NET Framework y ADO.NET. Puede implementar un procedimiento almacenado en Transact-SQL o uno de los lenguajes compatibles con .NET Framework. Transact-SQL puede proporcionar el mejor rendimiento con el Database Engine (Motor de base de datos). Los lenguajes compatibles con CLR pueden proporcionar mejor flexibilidad, un mayor control del flujo de programa, un mejor rendimiento para las aplicaciones que usen el procesador de manera intensiva y acceso directo a .NET Framework.
¿Qué componentes de servidor usarán su aplicación con mayor frecuencia?
Trabaje con su administrador del sistema para asegurarse de que tiene recursos suficientes para lograr un rendimiento óptimo de la aplicación. Sepa qué componentes usará con mayor frecuencia. Por ejemplo, si su aplicación usa colas para igualar la carga de trabajo del procesamiento, o activa la retención de mensajes, asegúrese de que hay espacio en disco suficiente para que la cola crezca. Por el contrario, una aplicación que tenga altos volúmenes de mensajería pero tiempos de espera en cola inferiores podría usar más ancho de banda de red pero consumir menos espacio en disco.
¿Tendrás sus mensajes prioridades diferentes?
En sistemas muy cargados, las prioridades de conversación de Service Broker ayudan a asegurarse de que cantidades grandes de trabajo menos importante no bloquean el trabajo importante. Las prioridades de conversación también habilitan los diseños que admiten niveles diferentes de servicio.