Mensajes, cargas y serialización

  • Artículo

Azure Service Bus controla los mensajes. Los mensajes llevan una carga y metadatos. Los metadatos tienen el formato de par clave-valor, describen la carga y ofrecen instrucciones de control a Service Bus y a las aplicaciones. En ocasiones, los metadatos por si solos son suficientes para transportar la información que el remitente desea comunicar a los receptores, y solo la carga permanece vacía.

El modelo de objetos de los clientes de Service Bus oficial para .NET y Java refleja la estructura de mensajes abstracta de Service Bus, que se asigna a y desde los protocolos de conexión que admite Service Bus.

Un mensaje de Service Bus consta de una sección de carga binaria, que Service Bus nunca controla de ninguna forma en el servicio, y dos conjuntos de propiedades. Las propiedades de agente están predefinidas por el sistema. Estas propiedades predefinidas controlan la funcionalidad en el nivel de mensaje en el agente o se asignan a los elementos de metadatos comunes y estandarizados. Las propiedades de usuario son una colección de pares clave-valor que la aplicación puede definir y establecer.

En la tabla siguiente se enumeran las propiedades de agente predefinidas. Los nombres se utilizan con todas las API de cliente oficiales y también en el objeto BrokerProperties JSON de la asignación de protocolo HTTP.

Los nombres equivalentes usados en el nivel de protocolo AMQP aparecen entre paréntesis. Aunque los nombres anteriores usan mayúsculas y minúsculas en formato Pascal, tenga en cuenta que los clientes de JavaScript y Python usarían para enlazar palabras, respectivamente, mayúscula en la primera letra de cada palabra excepto la primera y guiones.

Nombre de propiedad Descripción
ContentType (content-type) Opcionalmente, describe la carga del mensaje con un descriptor que obedece el formato de RFC2045, sección 5, por ejemplo, application/json.
CorrelationId (correlation-id) Permite que una aplicación especifique un contexto del mensaje con fines de correlación, por ejemplo, que refleje el elemento MessageId de un mensaje que se ha respondido.
DeadLetterSource Solo se establece en aquellos mensajes fallidos y posteriormente reenviados automáticamente de la cola de mensajes fallidos a otra entidad. Indica la entidad donde se encontraba el mensaje fallido. Esta propiedad es de solo lectura.
DeliveryCount

Número de entregas que se han intentado para este mensaje. El recuento se incrementa cuando expira un bloqueo del mensaje o si el mensaje lo abandona explícitamente el receptor. Esta propiedad es de solo lectura.

El número de entregas no se incrementa cuando se cierra la conexión AMQP subyacente.
EnqueuedSequenceNumber Para los mensajes que se reenvían de manera automática, esta propiedad refleja el número de secuencia que primero se había asignado al mensaje en su momento del envío original. Esta propiedad es de sólo lectura.
EnqueuedTimeUtc El instante en hora UTC en el que el mensaje se ha aceptado y almacenado en la entidad. Este valor puede usarse como un indicador de hora de llegada autoritativo y neutro cuando el receptor no desea confiar en el reloj del remitente. Esta propiedad es de sólo lectura.
Expires​AtUtc (absolute-expiry-time) Instante en hora UTC en el que el mensaje se marca para su eliminación y ya no está disponible para la recuperación de la entidad debido a su expiración. La expiración se controla mediante la propiedad TimeToLive y esta propiedad se calcula a partir de EnqueuedTimeUtc + TimeToLive. Esta propiedad es de solo lectura.
Label o Subject (asunto) Esta propiedad permite a la aplicación indicar el propósito del mensaje al receptor de modo estandarizado, similar a una línea de asunto de correo electrónico.
Locked​Until​Utc Para los mensajes que se recuperan en un bloqueo (modo de recepción de bloque de inspección, no liquidado previamente), esta propiedad refleja el instante en hora UTC hasta que el mensaje se mantenga bloqueado en la cola o suscripción. Cuando expira el bloqueo, la propiedad DeliveryCount se incrementa y el mensaje está disponible para la recuperación. Esta propiedad es de solo lectura.
Lock​Token El token de bloqueo es una referencia al bloqueo utilizado por el agente en el modo de recepción de bloque de inspección. El token puede usarse para anclar el bloqueo de forma permanente a través de la API Deferral y, con eso, sacar el mensaje del flujo de estado de entrega normal. Esta propiedad es de solo lectura.
Message​Id (message-id) El identificador del mensaje es un valor definido por la aplicación que identifica de forma única el mensaje y su carga. El identificador es una cadena de forma libre y puede reflejar un GUID o un identificador que se deriva del contexto de la aplicación. Si está habilitada, la característica de detección de duplicados identifica y quita el segundo y los siguientes envíos de mensajes con la misma clase MessageId.
Partition​Key En el caso de entidades con particiones, la configuración de este valor permite asignar mensajes relacionados a la misma partición interna, por lo que el orden de la secuencia de envío se registra correctamente. La partición la elige una función hash sobre este valor y no se puede seleccionar directamente. En el caso de entidades que tienen en cuenta la sesión, la propiedad SessionId reemplaza este valor.
Reply​To (reply-to) Este valor opcional y definido por la aplicación es un método estándar de expresar una ruta de acceso de respuesta al receptor del mensaje. Cuando un remitente espera una respuesta, establece el valor en la ruta de acceso absoluta o relativa de la cola o tema al que espera que se envíe la respuesta.
Reply​To​Session​Id (reply-to-group-id) Este valor aumenta la información de ReplyTo y especifica qué propiedad SessionId debe establecerse para la respuesta cuando se envió a la entidad de respuesta.
Scheduled​Enqueue​Time​Utc Para los mensajes que solo están disponibles para su recuperación después de un retraso, esta propiedad define el instante en hora UTC en el que el mensaje se va a poner lógicamente en cola, se secuenciará y, por tanto, estará disponible para la recuperación.
Sequence​Number El número de secuencia es un entero de 64 bits único asignado a un mensaje cuando el agente lo acepta y lo almacena, y funciona como su verdadero identificador. Para entidades con particiones, los 16 bits superiores reflejan el identificador de la partición. Los números de secuencia aumentan de forma continuada. Vuelven a 0 cuando se agota el intervalo de 48-64 bits. Esta propiedad es de solo lectura.
Session​Id (group-id) Para entidades que tienen en cuenta la sesión, este valor definido por la aplicación especifica la afiliación de sesión del mensaje. Los mensajes con el mismo identificador de sesión están sujetas al bloqueo de resumen y habilitan el procesamiento en orden exacto y la desmultiplexación. Para las entidades sin reconocimiento de la sesión, este valor se ignora.
Time​To​Live Este valor es la duración relativa tras la cual expira el mensaje, desde el instante en que se ha aceptado y lo ha almacenado el agente, tal y como se captura en EnqueueTimeUtc. Cuando no se establece explícitamente, el valor asumido es DefaultTimeToLive para la cola o tema correspondiente. El valor de TimeToLive en el nivel de mensaje no puede ser mayor que la configuración de DefaultTimeToLive de la entidad. Si es más largo, se ajusta silenciosamente.
To (destino) Esta propiedad está reservada para un uso futuro en escenarios de enrutamiento y actualmente la ignora el propio agente. Las aplicaciones pueden utilizar este valor en escenarios de encadenamiento de reenvío automático controlados por reglas para indicar el destino lógico previsto del mensaje.
Via​Partition​Key Si se envía un mensaje a través de una cola de transferencia en el ámbito de una transacción, este valor selecciona la partición de la cola de transferencia.

El modelo de mensaje abstracto permite que un mensaje se envíe a una cola a través de HTTPS y se puede recuperar a través de AMQP. En cualquier caso, el mensaje es normal en el contexto del protocolo respectivo. Las propiedades del agente se convierten según sea necesario, y las propiedades de usuario se asignan a la ubicación más adecuada en el modelo de mensaje de protocolo respectivo. En HTTP, las propiedades de usuario se asignan directamente a los encabezados HTTP y desde ellos; en AMQP se asignan al mapa de las propiedades de la aplicación o desde ellas.

Enrutamiento y correlación de mensajes

Un subconjunto de las propiedades de agente descritas anteriormente, en concreto To, ReplyTo, ReplyToSessionId, MessageId, CorrelationId y SessionId, se usan para ayudar a las aplicaciones a enrutar mensajes a destinos particulares. Para ilustrar esta característica, tenga en cuenta determinados patrones:

  • Solicitud/respuesta simple: el publicador envía un mensaje a una cola y espera una respuesta por parte del consumidor de mensajes. Para recibir la respuesta, el publicador es el propietario de una cola en la que se espera que se entreguen las respuestas. La dirección de esa cola se expresa en la propiedad ReplyTo del mensaje saliente. Cuando el consumidor responde, copia la propiedad MessageId del mensaje manipulado en la propiedad CorrelationId del mensaje de respuesta y entrega el mensaje al destino indicado por la propiedad ReplyTo. Un mensaje puede producir varias respuestas, en función del contexto de la aplicación.
  • Solicitud/respuesta multidifusión: es una variante del patrón anterior donde un publicador envía el mensaje a un tema y varios suscriptores pueden consumir el mensaje. Cada uno de los suscriptores puede responder en la manera anteriormente descrita. Este patrón se utiliza en escenarios de consolidación de llamada o de detección y el destinatario normalmente se identifica con una propiedad de usuario o en la carga. Si la propiedad ReplyTo señala a un tema, dicho conjunto de respuestas de detección se puede distribuir a una audiencia.
  • Multiplexación: esta característica de sesión permite multiplexar secuencias de mensajes relacionadas a través de una cola o suscripción, de forma que cada sesión (o grupo) de mensajes relacionados, identificadas por los valores de SessionId coincidentes, se enrutan a un receptor específico, mientras que el receptor retiene la sesión en un bloqueo. Obtenga aquí más información sobre los detalles de las sesiones.
  • Solicitud/respuesta multiplexadas: esta característica de sesión permite respuestas multiplexadas, lo que permite que varios publicadores compartan una cola de respuestas. Al establecer la propiedadReplyToSessionId, el publicador puede indicar a los consumidores que copien ese valor en la propiedad SessionId del mensaje de respuesta. La cola o tema de publicación no tiene que tener en cuenta la sesión. Cuando se envía el mensaje, el publicador entonces esperar una sesión con la propiedad SessionId especificada con el fin de materializarla en la cola al aceptar condicionalmente un receptor de la sesión.

El enrutamiento dentro de un espacio de nombres de Service Bus puede llevarse a cabo mediante el encadenamiento de reenvío automático y las reglas de suscripción de temas. El enrutamiento por los espacios de nombres se puede realizar con Azure Logic Apps. Como se indica en la lista anterior, la propiedad To se reserva para uso futuro y la puede interpretar el agente con una característica especialmente habilitada. Las aplicaciones que desean implementar el enrutamiento deben hacerlo en función de las propiedades de usuario y no depender de la propiedad To; sin embargo, si así se hace, no se producirán problemas de compatibilidad.

Serialización de carga

Cuando está en tránsito o almacenada en Service Bus, la carga siempre es un bloque opaco y binario. La propiedad ContentType permite que las aplicaciones describan la carga, con el formato sugerido para los valores de propiedad que son una descripción del tipo de contenido MIME según IETF RFC2045; por ejemplo, application/json;charset=utf-8.

A diferencia de las variantes de Java o .NET Standard, la versión de .NET Framework de la API de Service Bus admite la creación de instancias de BrokeredMessage pasando los objetos .NET arbitrarios al constructor.

El 30 de septiembre de 2026, retiraremos las bibliotecas del SDK de Azure Service Bus WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus y com.microsoft.azure.servicebus, que no se ajustan a las directrices del SDK de Azure. También finalizaremos la compatibilidad con el protocolo SBMP, por lo que ya no podrá usar este protocolo después del 30 de septiembre de 2026. Migre a las bibliotecas más recientes del SDK de Azure, que ofrecen actualizaciones de seguridad críticas y funcionalidades mejoradas, antes de esa fecha.

Aunque las bibliotecas anteriores todavía se pueden usar después del 30 de septiembre de 2026, ya no recibirán soporte técnico oficial ni actualizaciones de Microsoft. Para obtener más información, consulte el anuncio de retirada de soporte técnico.

Cuando se usa el protocolo SBMP heredado, los objetos se serializan con el serializador binario predeterminado, o con un serializador que se proporciona externamente. El objeto se serializa en un objeto AMQP. El receptor puede recuperar esos objetos con el método GetBody<T>() mediante el suministro del tipo esperado. Con AMQP, los objetos se serializan en un gráfico de AMQP de objetos ArrayList y IDictionary<string,object> , y cualquier cliente de AMQP puede descodificarlos.

El 30 de septiembre de 2026, retiraremos el soporte técnico del protocolo SBMP para Azure Service Bus, por lo que ya no podrá usar este protocolo después del 30 de septiembre de 2026. Migre a las bibliotecas más recientes del SDK de Azure Service Bus mediante el protocolo AMQP, que ofrecen actualizaciones de seguridad críticas y funcionalidades mejoradas, antes de esa fecha.

Para obtener más información, consulte el anuncio de retirada de soporte técnico.

Aunque esta magia de serialización oculta resulta cómoda, las aplicaciones deben tomar el control explícito de la serialización de objetos y convertir sus grafos de objetos en secuencias antes de incluirlos en un mensaje y realizar el proceso inverso en el receptor. Esto produce resultados interoperables. Aunque AMQP tiene un modelo de codificación binario eficaz, está ligado al ecosistema de mensajería de AMQP y los clientes HTTP tendrán problemas para descodificar tales cargas.

Las variantes de .NET Standard y la API de Java solo aceptan matrices de bytes, lo que significa que la aplicación debe administrar el control de la serialización de objetos.

Si no se puede deserializar la carga de un mensaje, se recomienda hacer que el mensaje produzca un error.

Pasos siguientes

Para más información sobre la mensajería de Service Bus, consulte los siguientes temas: