Cargas de mensajes y serialización en Service Bus

Completado

Los mensajes llevan una carga y metadatos. Los metadatos tienen el formato de propiedades 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 oficiales de Service Bus para .NET y Java se asigna de forma bilateral entre 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 del agente están definidas 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 definidos y establecidos por la aplicación.

Enrutamiento y correlación de mensajes

Un subconjunto de las propiedades de agente, en concreto To, ReplyTo, ReplyToSessionId, MessageId, CorrelationId y SessionId, ayuda a las aplicaciones a enrutar mensajes a destinos particulares. Los siguientes patrones describen el enrutamiento:

• Solicitud/respuesta simple: un publicador envía un mensaje a una cola y espera una respuesta del consumidor del mensaje. El publicador posee una cola para recibir las respuestas. La dirección de esa cola se expresa en la propiedad ReplyTo del mensaje de salida. Cuando el consumidor responde, copia el MessageId del mensaje controlado en la propiedad CorrelationId del mensaje de respuesta y entrega el mensaje en el destino que indica 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. Si ReplyTo apunta a un tema, el conjunto de respuestas de detección se puede distribuir a una audiencia.

• Multiplexación: esta característica de sesión permite la multiplexación de secuencias de mensajes relacionados a través de una única cola o suscripción, de modo que cada sesión (o grupo) de mensajes relacionados, identificados por los valores de SessionId coincidentes, se redirige a un receptor específico mientras el receptor mantenga la sesión bloqueada. Obtenga aquí más información sobre los detalles de las sesiones.

• Solicitud/respuesta multiplexada: esta característica de sesión permite respuestas multiplexadas, de modo que varios publicadores pueden compartir una cola de respuestas. Al establecer ReplyToSessionId, el publicador puede indicar a uno o varios 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 esperar a que se materialice una sesión con el SessionId dado en la cola mediante la aceptación condicional de un receptor de sesión.

El enrutamiento dentro de un espacio de nombres de Service Bus usa encadenamiento de reenvío automático y reglas de suscripción de temas. El enrutamiento por los espacios de nombres se puede realizar con Azure Logic Apps. La propiedad To se reserva para uso futuro. 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 para .NET Framework de la API de Service Bus admite la creación de instancias de BrokeredMessage pasando objetos de .NET arbitrarios al constructor.

El protocolo SBMP heredado serializa los objetos con el serializador binario predeterminado, o con un serializador que se proporciona externamente. El protocolo AMQP serializa los objetos en un objeto AMQP. El receptor puede recuperar esos objetos con el método GetBody<T>() y proporcionar el tipo previsto. 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.

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 gráficos de objetos en secuencias antes de incluirlos en un mensaje y realizar el proceso inverso en el receptor. 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.