¿Qué significa JMS?
Es la forma plural de hermanas.
JMS
Categorías abiertas: programas, ordenadores, términos de red
JMS (Java Messaging Service) es una especificación técnica para middleware orientado a mensajes en la plataforma Java. Traducido al servicio de mensajes Java. JMS admite modelos de mensajería punto a punto y de publicación/suscripción.
Conceptos básicos de JMS
1. JMS (Java Message Service) es una API estándar para acceder a sistemas de mensajería empresarial, que facilita las aplicaciones Java en sistemas de mensajería
Los programas intercambian mensajes y simplifican el desarrollo de aplicaciones empresariales al proporcionar interfaces estándar para generar, enviar y recibir mensajes.
2. Funciones básicas de JMS
JMS es una interfaz de programa de aplicación que se utiliza para comunicarse con middleware orientado a mensajes. Admite dominios punto a punto y dominios de publicación/suscripción, y brinda soporte para los siguientes tipos: mensajería aprobada, entrega de mensajes transaccionales, mensajes de coherencia y soporte duradero para suscriptores. JMS también proporciona otra forma de integrar su aplicación con sistemas backend heredados.
3. Introducción a WebLogic JMS Server
WebLogic Server8.1 cumple con la especificación JAVA y está certificado por Sun Microsystems J2EE 1.3. Como parte de WebLogic, por supuesto también WebLogic JMS Server. Cumple totalmente con la especificación JMS, admite agrupación en clústeres y se puede aplicar a sistemas empresariales reales. La siguiente figura es la arquitectura del servidor WebLogic JMS. Como puede ver en la figura, los componentes principales de WebLogic JMS Server son: Servidores WebLogic JMS (. utilizado para comunicación de mensajes), cliente Java, JNDI (para búsqueda de nombres de dominio), almacén de respaldo (para almacenamiento de mensajes persistentes, basado en archivos o bases de datos JDBC).
Características de WebLogic JMS
. 1. Modelo de comunicación de mensajes
JMS admite dos modelos de comunicación de mensajes: el modelo punto a punto (PTP) y el modelo de publicación/suscripción (Pub/Sub). Excepto por las siguientes diferencias, los dos modelos de comunicación de mensajes son muy similares:
El modelo PTP estipula que un mensaje solo puede tener un receptor; el modelo Pub/Sub permite que un mensaje tenga múltiples receptores.
2. Composición del mensaje
El centro del sistema de mensajería es el mensaje.
Un mensaje se divide en tres componentes:
· El encabezado es un conjunto estándar de campos que tanto los clientes como los proveedores utilizan para identificar y enrutar mensajes.
·Las propiedades admiten la adición de campos de encabezado opcionales a los mensajes. Si su aplicación necesita catalogar y clasificar mensajes sin utilizar campos de encabezado estándar, puede agregar un atributo al mensaje para lograr esta catalogación y clasificación. Proporciona los métodos setlt;Typegt;Property(...) y getlt;Typegt;Property(...) para establecer y obtener propiedades de varios tipos de Java, incluido Object. JMS define un conjunto estándar de propiedades que un proveedor elige proporcionar.
· El cuerpo del mensaje contiene el contenido que se enviará a la aplicación receptora. Cada interfaz de mensajería es específica de los tipos de contenido que admite.
JMS proporciona sus propios tipos de mensajes para diferentes tipos de contenido, pero todos los mensajes se derivan de la interfaz de mensajes.
· StreamMessage: Contiene el flujo numérico básico de Java, que utiliza operaciones de flujo estándar para completar y leer secuencialmente.
· MapMessage: Contiene un conjunto de pares nombre/valor; el nombre es de tipo cadena y el valor es un tipo primitivo de Java.
· Mensaje de texto: Contiene una cadena.
· ObjectMessage: Contiene un objeto Java serializable; puede usar la clase de colección del JDK.
· BytesMessage: Contiene un flujo de bytes no interpretado: El cuerpo está codificado para que coincida con el formato del mensaje existente.
· XMLMessage: Contiene contenido XML. El uso de tipos extendidos TextMessage y XMLMessage hace que el filtrado de mensajes sea muy conveniente.
3. Modo de confirmación de mensajes
En una sesión no transaccional, la sesión creada por la aplicación tiene 5 modos de confirmación, mientras que en una sesión transaccional se ignora el modo de confirmación.
Descripción de cinco modos de confirmación:
· AUTO_ACKNOWLEDGE: Modo de confirmación automática. Una vez que la llamada al método de la aplicación receptora regresa del procesamiento del mensaje, el objeto de sesión acusa recibo del mensaje.
· CLIENT_ACKNOWLEDGE: Modo de confirmación del cliente. El objeto de sesión depende de que la aplicación llame a un método de reconocimiento () en el mensaje recibido. Una vez que se llama a este método, la sesión reconoce todos los mensajes recibidos desde el último reconocimiento. Este modo permite que una aplicación reciba, procese y reconozca un lote de mensajes en una sola llamada. Nota: En la consola de administración, si la propiedad Política de reconocimiento de la fábrica de conexiones está configurada en "Anterior" pero desea reconocer todos los mensajes recibidos para una sesión determinada, utilice el último mensaje para llamar al método de reconocimiento().
· DUPS_OK_ACKNOWLEDGE: Permitir modo de reconocimiento para réplicas. El objeto de sesión acusa recibo del mensaje una vez que la llamada al método de la aplicación receptora regresa del procesamiento del mensaje. Se permiten acuses de recibo repetidos. Este patrón es muy eficaz cuando es necesario considerar el uso de recursos. Nota: Debe evitar el uso de este patrón si su aplicación no puede manejar mensajes duplicados. Si el intento inicial de enviar un mensaje falla, se puede reenviar el mensaje duplicado.
· NO_ACKNOWLEDGE: Sin modo de confirmación. No se requiere confirmación de los mensajes recibidos. Después de enviar los mensajes a una sesión NO_ACKNOWLEDGE, WebLogic Server los elimina inmediatamente. En este modo, no será posible volver a adquirir los mensajes recibidos y puede ocurrir lo siguiente: 1. Los mensajes pueden perderse y/o alternativamente: 2. Puede ocurrir una duplicación si falla el intento inicial de enviar el mensaje. La situación en la que el mensaje se puede duplicar. mensaje fue enviado.
· MULTICAST_NO_ACKNOWLEDGE: No hay modo de reconocimiento en multidifusión IP, tampoco se requiere confirmación. Los mensajes enviados a una sesión MULTICAST_NO_ACKNOWLEDGE compartirán las mismas características que el modo de reconocimiento NO_ACKNOWLEDGE descrito anteriormente. Este modo admite aplicaciones que desean comunicar mensajes mediante multidifusión IP sin depender de la calidad del servicio proporcionada por el reconocimiento de sesión. Nota: Si su aplicación no puede manejar mensajes faltantes o duplicados, debe evitar utilizar este patrón. Es posible que se vuelvan a enviar mensajes duplicados si falla el intento inicial de enviar el mensaje.
Nota: Entre los cinco modos de confirmación en la tabla anterior, AUTO_ACKNOWLEDGE, DUPS_OK_ACKNOWLEDGE y
CLIENT_ACKNOWLEDGE están definidos por la especificación JMS, y NO_ACKNOWLEDGE y MULTICAST_NO_ACKNOWLEDGE son proporcionados por WebLogic JMS