Clasificación de mensajes
Para algunas aplicaciones de mensajería asíncrona, el orden de los mensajes es importante, esto es, es importante consumir los mensajes en el mismo orden en que el productor los envía. Si este tipo de orden de mensajes es importante para la aplicación, su diseño debe tenerlo en cuenta.
Por ejemplo, una aplicación de mensajería que procesa reservas de asientos puede tener componentes de productor y un componente de consumidor. Un componente de productor envía un mensaje al componente de consumidor cuando un cliente reserva un asiento. Si el cliente cancela la reserva, entonces el productor (o probablemente un productor diferente) envía un segundo mensaje. Generalmente, el componente de consumidor debe procesar el primer mensaje (que reserva el asiento) antes de procesar el segundo mensaje (que cancela la reserva).
Algunas aplicaciones utilizan un patrón asíncrono (petición-respuesta) en el que el productor espera una respuesta a cada mensaje antes de enviar el mensaje siguiente. En este tipo de aplicación, el consumidor controla el orden en el que recibe los mensajes y puede garantizar que es el mismo orden con el que los productores lo envían. Otras aplicaciones utilizan un patrón asíncrono (activar y olvidar) en el que el productor envía mensajes sin esperar respuestas. Incluso en este tipo de aplicación, generalmente el orden se conserva, esto es, un consumidor puede esperar la recepción de los mensajes en el mismo orden en el que los productores los envían, especialmente cuando pasa una cantidad de tiempo significativa entre el envío de mensajes consecutivos. No obstante, el diseño debe considerar factores que pueden interrumpir este orden.
El orden de los mensajes se interrumpe si la aplicación envía mensajes con prioridades diferentes (los mensajes con prioridad más alta pueden superar a los mensajes con prioridad más baja) o si la aplicación recibe de forma explícita un mensaje que no sea el primero especificando selectores de mensajes. El proceso paralelo y el proceso de errores o de excepciones también pueden afectar el orden de los mensajes.
Proceso paralelo
- Varios destinos
- Cuando un productor envía un mensaje a un destino y luego envía un segundo mensaje a un destino diferente, es posible que el segundo mensaje llegue a su destino antes de que el primer mensaje llegue a su destino. Esto puede suceder incluso si el productor envía los dos mensajes dentro de la misma transacción (la transacción garantiza que o bien los dos envíos fallan o bien los dos se completan; no garantizan el orden de entrega). Si este es un problema para su aplicación, entonces evite el uso de más de un destino para dicha aplicación.
- Varios productores
- Cuando un productor envía un mensaje a un destino y luego un segundo productor envía un segundo mensaje al mismo destino, es posible que el segundo mensaje llegue al destino antes que el primer mensaje. Esto puede suceder incluso si el segundo productor se sincroniza con el primer productor, por ejemplo, esperando una señal del primer productor antes de enviar su mensaje (el segundo mensaje). También puede suceder incluso si los productores son transaccionales (el que se complete una transacción no significa que el o los mensajes estén en el destino; la integración de servicios puede completar en primer lugar una transacción y posteriormente entregar el o los mensajes). Si este es un problema para su aplicación, entonces evite utilizar más de un productor para dicha aplicación. Del mismo modo, evite el uso de un productor individual que ejecuta múltiples hebras paralelas.
- Varios consumidores
- Cuando dos mensajes llegan a un destino de tipo de cola, en el que hay varios consumidores, es posible que un consumidor reciba el primer mensaje y otro reciba el segundo. Si los consumidores se pueden ejecutar en paralelo, entonces el consumidor que recibe el segundo mensaje puede procesarlo antes de el consumidor que recibe el primer mensaje. Asimismo, si un consumidor recibe un mensaje de forma transaccional y luego retrotrae la transacción, el mensaje se devuelve al destino en el que otro consumidor puede recibirlo; mientras que este otro consumidor puede haber recibido y procesado ya otros mensajes (posteriores). Si esto significa un problema para su aplicación, entonces evite el uso de más de un consumidor para dicha aplicación. Del mismo modo, no permita que se produzcan múltiples invocaciones de beans controlados por mensajes (MDB) simultáneamente por punto final (consulte Configuración del soporte del regulador de MDB para el proveedor de mensajería predeterminado). Alternativamente, puede utilizar el orden de mensajes estricto; consulte la sección Orden de mensajes estricto para los destinos del bus.
- Agrupación en clúster y destinos particionados
- Cuando un destino de tipo de cola se asigna a un miembro del bus del clúster con más de un motor de mensajería, entonces cada motor de mensajería contiene una partición del destino (esto es, uno de los puntos de cola del destino); la integración de servicios puede entregar diferentes mensajes para dicho destino en particiones diferentes. Esta configuración de destino de tipo de cola puede proporcionar una disponibilidad, escalabilidad y equilibrio de carga avanzados, pero generalmente no resulta adecuada para las aplicaciones en las que el orden de los mensajes es importante. La integración de servicios no garantiza el orden de los mensajes enviados a las diferentes particiones del mismo destino. Asimismo, un motor de mensajería puede fallar mientras hay mensajes en la partición del destino que contiene; estos mensajes no estarán disponibles para los consumidores hasta que se reinicie el motor de mensajería. No obstante, la integración de servicios puede continuar entregando mensajes más recientes a otras particiones (en otros motores de mensajería) y los consumidores pueden recibir y procesar estos mensajes más recientes antes que los mensajes más antiguos en la partición del motor de mensajería que ha fallado. En la sección Carga de trabajo compartida con destinos de colas se proporciona una información más detallada acerca de este tipo de configuración y también se describe cómo puede utilizar la opción Afinidad de mensajes que le puede ayudar a mantener el orden de los mensajes entre un productor individual y un único consumidor dentro de un clúster (aunque no si el clúster está en un bus de integración de servicios diferente).
- Publicación y suscripción
- Para la mensajería de publicación/suscripción, la integración de servicios no garantiza el orden de los mensajes que reciben las diferentes instancias de una suscripción, incluidas las diferentes instancias de una suscripción duradera creada con la propiedad Compartir suscripciones duraderas establecida de modo que se permita compartir.
Condiciones de error y de excepción
- Calidad de servicio
- La calidad de servicio de un mensaje determina cómo las condiciones de error y de excepción pueden afectar a la entrega del mensaje (consulte la sección Niveles de fiabilidad de mensajes - modalidad de entrega JMS y calidad de servicio de integración de servicios). Dependiendo de la calidad de servicio, una condición de error o de excepción puede hacer que la integración de servicios entregue el mensaje con fiabilidad (exactamente una vez) o con menos fiabilidad (más de una vez, o ninguna). Por ejemplo, con la calidad de servicio Express no persistente, es posible que las secuencias de mensajes se vuelvan a entregar después de una anomalía. No obstante, siempre se mantiene su orden subyacente, de modo que es posible que los mensajes lleguen en la secuencia: 1, 2, 3, 2, 3, 4. De forma más general, la integración de servicios no garantiza el orden de los diferentes mensajes enviados con diferentes calidades de servicio. Si esto es un problema para su aplicación, asegúrese de que selecciona una calidad de servicio adecuada y evite combinar diferentes calidades de servicio en los mensajes dirigidos al mismo destino.
- Destinos de excepciones
- Bajo determinados escenarios de anomalía, la integración de servicios puede entregar un mensaje a un destino de excepción o entregar un mensaje a un destino y posteriormente transferir el mensaje a un destino de excepción. La integración de servicios no garantiza el orden de los mensajes que envía o transfiere a un destino de excepción. Si esto es un problema para la aplicación, entonces puede configurar el destino de modo que no utilice un destino de excepciones (consulte la sección Destinos de excepciones). Si el productor y el destino están en buses diferentes, entonces puede configurar el o los enlaces entre estos buses de modo que no tengan un destino de excepción (consulte la sección Buses foráneos y la sección Configuración del proceso de destino de excepciones para un enlace a un bus foráneo.
- Retrotracción de la transacción
- La especificación de activación de un bean controlado por mensajes (MDB) puede especificar un retardo entre los reintentos de mensajes anómalos. Este retardo concede un período de tiempo para la recuperación de la condición que ha ocasionado la retrotracción antes de que el mismo mensaje vuelva a controlar el MDB. No obstante, mientras un mensaje se retrasa de este modo, otro mensaje (posterior) puede controlar el MDB (consulte la sección Protección de una aplicación MDB frente problemas de recursos del sistema). Si esto es un problema para su aplicación, entonces puede limitar el número máximo de anomalías secuenciales a una (consulte la sección Especificación de activación JMS [Valores]) o puede utilizar el orden estricto de mensajes (consulte la sección Orden de mensajes estricto para los destinos del bus).
- Resolución de transacciones dudosas
- Durante el proceso de compromiso en dos fases, una aplicación puede fallar mientras el estado de una operación de envío o recepción de JMS sea dudoso. Cuando esto sucede, es posible que la aplicación se reinicie antes de que se resuelva el estado dudoso, de modo que uno o varios mensajes son "invisibles" cuando la aplicación se reinicia pero pasan a estar "visibles" posteriormente. Los otros mensajes del destino no resultan afectados. Una aplicación consumidora puede recibir un mensaje (por ejemplo, el mensaje 2) que lógicamente es posterior al mensaje "invisible" (por ejemplo, el mensaje 1); posteriormente, cuando ya se ha resuelto la transacción dudosa, la aplicación recibe el mensaje "invisible" anterior (el mensaje 1). De este modo, es posible que la aplicación reciba y procese mensajes en el orden erróneo. Si esto es un problema para su aplicación, puede utilizar el orden de mensajes estricto, consulte la sección Orden de mensajes estricto para los destinos del bus.