¿No sabes por dónde empezar? Ayúdanos normalizando artículos.
¿Tienes experiencia? Crea alguno de estos artículos de actualidad.
Diferencia entre revisiones de «Java Message Service»
| (No se muestra una edición intermedia del mismo usuario) | |||
| Línea 1: | Línea 1: | ||
| − | + | ||
| − | + | <div align=justify> | |
{{Ficha Software | {{Ficha Software | ||
|nombre= Java Message Service | |nombre= Java Message Service | ||
| Línea 10: | Línea 10: | ||
|tamaño2= | |tamaño2= | ||
|descripción2= | |descripción2= | ||
| − | |creador= | + | |creador= Sun Microsystems |
|desarrollador= | |desarrollador= | ||
|diseñador= | |diseñador= | ||
| Línea 24: | Línea 24: | ||
|web= | |web= | ||
}} | }} | ||
| − | '''Java Message Service (JMS)''' | + | '''Java Message Service (JMS).''' Especificación que describe una forma para crear, enviar, recibir y leer mensaje en un entorno distribuido. |
== Modelos == | == Modelos == | ||
Esta solución hace posible la comunicación de manera síncrona y asíncrona en | Esta solución hace posible la comunicación de manera síncrona y asíncrona en | ||
ambos casos. Existen dos modelos de la [[API]] JMS, los cuales son: | ambos casos. Existen dos modelos de la [[API]] JMS, los cuales son: | ||
| − | '''Punto a Punto''' | + | '''Punto a Punto''': |
| − | + | este modelo cuenta con solo dos clientes, uno que envía el mensaje y otro que lo recibe. Este modelo asegura la llegada del mensaje ya que si el receptor no está disponible para aceptar el mensaje o atenderlo, de cualquier forma se le envía el mensaje y este se encola en una pila del tipo FIFO para luego ser recibido según haya entrado. | |
| + | |||
| + | '''Publicador/Suscriptor''': | ||
| + | este modelo cuenta con varios clientes, unos que publican temas(tópicos) o eventos, y los que ven estos tópicos, a diferencia del modelo punto a punto este modelo tiende a tener más de un consumidor. | ||
| + | |||
| + | ==Arquitectura JMS== | ||
| + | Una aplicación JMS consta de los siguientes elementos: | ||
| + | |||
| + | *Clientes JMSA, son plicaciones que envian o reciben mensajes a través de JMS. | ||
| + | |||
| + | *Mensajes, los mensajes que se intercambian. | ||
| + | |||
| + | *Objetos administrados, son el punto al que se comunican los clientes JMS para enviar o recibir mensajes, se denominan así por que los crea el administrador en la implementación. Implementan las interfaces JMS y se sitúan en el espacio de nombres para que los clientes puedan solicitarlos. | ||
| + | |||
| + | *Proveedor JMS,es el sistema de mensajería que implementa JMS además de las funcionalidades administrativas y de control requeridas para un producto de mensajería. | ||
| − | + | ==Características== | |
| − | + | Las características primarias o más fundamentales de la JMS son: | |
| + | *Las factorías de conexiones son usadas en JMS para crear conexiones a un proveedor especifico de JMS. | ||
| + | |||
| + | *Los modelos de Publish/Subscribe y Point-to-Point están implementadas y definidas por interfaces separadas para que los proveedores JMS no necesiten soportar a las dos. | ||
| + | |||
| + | *La JMS define el concepto de Topic o Queue como el blanco para un mensaje. Los Topic son usados en el modelo Publish/Subscribe y el Queue en el modelo Point-to-Point. | ||
| + | |||
| + | *Los códigos del proveedor están definidas por interfaces en JMS, librando a la implementación de limitaciones de subclases. | ||
| + | |||
| + | *Los proveedores JMS soportan transacciones distribuidas. | ||
| + | *La JMS es una interfaz pura. A la hora de transportar y enrutar mensajes, requiere una forma equivalente a un motor de mensajería. | ||
| + | |||
| + | *La especificación de la JMS no facilita la interoperabilidad entre diferentes implementaciones. Si la especificación no manda un protocolo de transporte, entonces no puede haber una interoperabilidad. | ||
== Ver además == | == Ver además == | ||
última versión al 14:16 17 ene 2012
| ||||
Java Message Service (JMS). Especificación que describe una forma para crear, enviar, recibir y leer mensaje en un entorno distribuido.
Modelos
Esta solución hace posible la comunicación de manera síncrona y asíncrona en ambos casos. Existen dos modelos de la API JMS, los cuales son:
Punto a Punto: este modelo cuenta con solo dos clientes, uno que envía el mensaje y otro que lo recibe. Este modelo asegura la llegada del mensaje ya que si el receptor no está disponible para aceptar el mensaje o atenderlo, de cualquier forma se le envía el mensaje y este se encola en una pila del tipo FIFO para luego ser recibido según haya entrado.
Publicador/Suscriptor: este modelo cuenta con varios clientes, unos que publican temas(tópicos) o eventos, y los que ven estos tópicos, a diferencia del modelo punto a punto este modelo tiende a tener más de un consumidor.
Arquitectura JMS
Una aplicación JMS consta de los siguientes elementos:
- Clientes JMSA, son plicaciones que envian o reciben mensajes a través de JMS.
- Mensajes, los mensajes que se intercambian.
- Objetos administrados, son el punto al que se comunican los clientes JMS para enviar o recibir mensajes, se denominan así por que los crea el administrador en la implementación. Implementan las interfaces JMS y se sitúan en el espacio de nombres para que los clientes puedan solicitarlos.
- Proveedor JMS,es el sistema de mensajería que implementa JMS además de las funcionalidades administrativas y de control requeridas para un producto de mensajería.
Características
Las características primarias o más fundamentales de la JMS son:
- Las factorías de conexiones son usadas en JMS para crear conexiones a un proveedor especifico de JMS.
- Los modelos de Publish/Subscribe y Point-to-Point están implementadas y definidas por interfaces separadas para que los proveedores JMS no necesiten soportar a las dos.
- La JMS define el concepto de Topic o Queue como el blanco para un mensaje. Los Topic son usados en el modelo Publish/Subscribe y el Queue en el modelo Point-to-Point.
- Los códigos del proveedor están definidas por interfaces en JMS, librando a la implementación de limitaciones de subclases.
- Los proveedores JMS soportan transacciones distribuidas.
- La JMS es una interfaz pura. A la hora de transportar y enrutar mensajes, requiere una forma equivalente a un motor de mensajería.
- La especificación de la JMS no facilita la interoperabilidad entre diferentes implementaciones. Si la especificación no manda un protocolo de transporte, entonces no puede haber una interoperabilidad.
