Compartir a través de

Mensajes, cargas y serialización

Azure Service Bus controla los mensajes. Los mensajes llevan una carga y metadatos. Los metadatos están en forma de pares clave-valor. Describe la carga y proporciona instrucciones de control a Service Bus y a las aplicaciones. En ocasiones, esos metadatos solo son suficientes para llevar la información que el remitente quiere comunicar a los receptores, por lo que la carga permanece vacía.

El modelo de objetos de los clientes oficiales de Service Bus para .NET y Java refleja la estructura abstracta de mensajes de Service Bus. Esta estructura se asigna hacia y desde los protocolos de red 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 broker están predeterminadas por el sistema. Estas propiedades predefinidas controlan la funcionalidad a nivel de mensaje dentro del intermediario 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 broker predefinidas. Todas las API de cliente oficiales usan estos nombres. El BrokerProperties objeto JSON de la asignación de protocolo HTTP también usa estos nombres.

Los nombres equivalentes usados en el nivel de protocolo Advanced Message Queuing Protocol (AMQP) se enumeran entre paréntesis. Aunque los siguientes nombres usan mayúsculas y minúsculas en formato Pascal, los clientes de JavaScript y Python usan mayúscula en la primera letra de cada palabra excepto la primera y guiones como nexo, respectivamente.

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 a una aplicación especificar un contexto para el mensaje con fines de correlación; por ejemplo, reflejando el MessageId de un mensaje al que se va a responder.
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 el sistema intentó para este mensaje. El recuento se incrementa cuando expira un bloqueo de mensaje o el receptor abandona explícitamente el mensaje. Esta propiedad es de solo lectura.

El recuento de entregas no se incrementa cuando se cierra la conexión AMQP subyacente.
EnqueuedSequenceNumber En el caso de los mensajes que el sistema devuelve automáticamente, esta propiedad refleja el número de secuencia que el sistema asignó por primera vez al mensaje en su punto de envío original. Esta propiedad es de solo lectura.
EnqueuedTimeUtc El instante UTC en el que se acepta y almacena el mensaje en la entidad. Use este valor como indicador de hora de llegada autoritativa y neutral cuando el receptor no quiera confiar en el reloj del remitente. Esta propiedad es de solo lectura.
Expires​AtUtc (absolute-expiry-time) El instante UTC en que el mensaje está marcado para su eliminación y ya no está disponible para su recuperación desde la entidad debido a su expiración. La expiración se controla mediante la propiedad TimeToLive . El sistema calcula esta propiedad desde EnqueuedTimeUtc+TimeToLive. Esta propiedad es de solo lectura.
Label o Subject (subject) 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 bloqueo-inspección, no confirmado previamente), esta propiedad refleja el instante en hora UTC hasta que el mensaje se mantiene bloqueado en la cola o suscripción. Cuando expira el bloqueo, deliveryCount aumenta y el mensaje vuelve a estar disponible para su recuperación. Esta propiedad es de solo lectura.
Lock​Token El token de bloqueo es una referencia al bloqueo que mantiene el agente en el modo de recepción de bloqueo-inspección. Use el token para anclar el bloqueo de forma permanente a través de la API de Aplazamiento 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 complementa la información de ReplyTo y especifica qué SessionId se debe establecer para la respuesta cuando se envía 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 UTC en el que el mensaje será lógicamente encolado, secuenciado y, por tanto, estará disponible para su recuperación.
Sequence​Number El número de secuencia es un entero de 64 bits único asignado a un mensaje a medida que el intermediario lo acepta y almacena. Funciona como el identificador verdadero del mensaje. Para entidades con particiones, los 16 bits superiores reflejan el identificador de la partición. Los números de secuencia aumentan monótonamente y no tienen brechas. 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 sujetos al bloqueo coordinado, habilitando el procesamiento y la desmultiplexación en orden exacto. Para las entidades sin reconocimiento de la sesión, este valor se ignora.
Time​To​Live Este valor es la duración relativa después de la cual expira el mensaje, a partir del momento en que el agente acepta y almacena el mensaje, como se captura en EnqueueTimeUtc. Si no establece este valor explícitamente, el sistema asume DefaultTimeToLive para la cola o el tema correspondientes. 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, el sistema lo ajusta silenciosamente.
To (to) Esta propiedad está reservada para su uso futuro en escenarios de enrutamiento y en la actualidad no es tenida en cuenta por el broker. 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 mensajes abstractos permite que un mensaje se publique en una cola a través de HTTPS y se recupere a través de AMQP. En cualquier caso, el mensaje es normal en el contexto del protocolo respectivo. El sistema traduce las propiedades del intermediario según sea necesario. Las propiedades del usuario se asignan a la ubicación más adecuada en el modelo de mensajes de protocolo correspondiente. En HTTP, las propiedades del usuario se corresponden directamente con los encabezados HTTP. En AMQP, se asignan a y desde el mapa application-properties.

Enrutamiento y correlación de mensajes

Un subconjunto de las propiedades del agente descritas anteriormente, en concreto To, ReplyToReplyToSessionIdMessageIdCorrelationIdy SessionId, ayudan a las aplicaciones a enrutar mensajes a destinos concretos. 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 puede entonces esperar específicamente a que una sesión con el SessionId dado se materialice 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 está reservada para uso futuro y podría eventualmente ser interpretada por el corredor con una característica especialmente habilitada. Las aplicaciones que desean implementar el enrutamiento deben hacerlo en función de las propiedades del usuario y no se basan en la propiedad To ; Sin embargo, al hacerlo ahora no se producen 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 retiraremos el soporte del protocolo SBMP, por lo que ya no podrás 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.

Al usar el protocolo SBMP heredado, esos objetos se serializan mediante el serializador binario predeterminado o mediante un serializador que proporcione externamente. El objeto se serializa en un objeto AMQP. El receptor puede recuperar esos objetos mediante el GetBody<T>() método , proporcionando el 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.

Al controlar la deserialización de objetos desde la carga del mensaje, los desarrolladores deben tener en cuenta que los mensajes pueden llegar desde varios orígenes mediante diferentes métodos de serialización. Esta situación también puede ocurrir al evolucionar una sola aplicación, donde las versiones anteriores siguen ejecutándose junto con versiones más recientes. En estos casos, considere la posibilidad de tener métodos de deserialización adicionales para probar si se produce un error en el primer intento de deserialización. Una biblioteca que admita este enfoque es NServiceBus. Si se produce un error en todos los métodos de deserialización, coloque el mensaje en la bandeja de mensajes fallidos.

Pasos siguientes

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

  • Last updated on