Taller de Sistemas de Información 2

Transcripción

1 Taller de Sistemas de Información 2 Mensajeria 6 de Setiembre de 2012 Instituto de Computación Facultad de Ingeniería Universidad de la República de Uruguay

2 Messaging La comunicación que hemos visto hasta ahora, es sincrónica Un managed bean llama a un ejb El invocador y el invocado Deben estar en funcionamiento para que la comunicación se de Deben utilizar la misma tecnología Incluso en el caso de la comunicación asíncrona en EJBs Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 2

3 MOM Message Oriented Middleware Es un software que permite comunicacion asincrona entre sistemas heterogeneos Puede ser visto como un buffer entre sistemas que producen y consumen mensajes a su propio ritmo Es un mecanismo desacoplado, ya que no se conocen los participantes de la comunicacion Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 3

4 MOM Permite integrar sistemas existentes en una organizacion, de forma totalmente desacoplada, siempre y cuando se cumplan 2 supuesto Los participantes deben ponerse de acuerdo con el formato de mensaje a utilizar Los participantes deben ponerse de acuerdo con el destino intermedio (buffer) donde se almacenaran los mensajes Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 4

5 Arquitectura de un MOM Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 5

6 Terminologia Cuando un mensaje es enviado, el software que efectúa el envío y almacenamiento del mensaje, se denomina provider o broker El emisor del mensaje se denomina producer El lugar donde el mensaje es enviado, se denomina destination El receptor del mensaje se denomina consumer Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 6

7 Java EE En Java EE, el API que permite manipular los conceptos antes mencionados, se denomina JMS (Java Message Service) JMS es un API, no se encarga de transportar el mensaje, sino que brinda acceso a un proveedor que es el que transporta el mensaje Es una analogia muy similar a JDBC (driver + manejador de base de datos) Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 7

8 Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 8

9 Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 9

10 JMS En el ejemplo anterior, el productor genera un mensaje que el consumidor esta esperando para consumir Los destinos pueden ser de dos tipos: Colas de mensajes (queue, para comunicaciones punto a punto) Topicos (topics, para comunicaciones en modalidad publicacion/subscripcion) Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 10

11 JMS En los ejemplos anteriores, ConnectionFactory y Queue son obtenidos por JNDI Esto es porque son objetos administrados Deben ser creados en el MOM (En este caso, el servidor de aplicaciones) El código para la recepción del mensaje es muy similar Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 11

12 Arquitectura de JMS Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 12

13 Interfaces JMS utilizadas Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 13

14 Point to Point Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 14

15 Point to Point La clave de este modelo, es que JMS asegura que un mensaje, es consumido solo por un consumidor Consumir y Productor pueden funcionar a destiempo Si el consumidor no existe, los mensajes quedan almacenados en la cola Si el productor no existe, entonces ningun mensaje sera enviado al consumidor hasta que este aparezca Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 15

16 Publish - Subscribe Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 16

17 Publish - Subscribe En este modelo, el consumidor debe subscribirse a un topico (administrado por el provider) El mismo mensaje puede ser enviado potencialmente a muchos consumidores de un topico El topico mantiene los mensajes hasta que estos han sido consumidos por todos los topicos Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 17

18 JMS API Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 18

19 Inyeccion En caso de que el consumidor o productor resida dentro de un container, y que sea un componente administrado (EJB, Managed Bean, etc.), entonces podemos Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 19

20 Mensaje JMS Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 20

21 Headers Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 21

22 Headers Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 22

23 Headers Los valores de estos headers, pueden ser modificados y obtenidos a traves de la interfaz Message, para cada tipo posible de mensaje a intercambiar Por ejemplo: message.getjmscorrelationid(); message.getjmsmessageid(); message.setjmspriority(6); Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 23

24 Properties Ademas de los headers, los mensajes soportan el concepto de propiedad Son como headers, pero explícitamente creados por la aplicación Estos pueden ser seteados por la interfaz Message message.setfloatproperty("orderamount", f); message.getfloatproperty("orderamount"); Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 24

25 Body El cuerpo del mensaje es opcional, conteniendo los datos a enviar/recibir entre las partes Dependiendo de la interfaz utilizada, puede contener diferentes tipos de datos (ver tabla siguiente) Todas estas interfaces extienden a javax.jms.message Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 25

26 Body Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 26

27 Body Cuando un mensaje es recibido por el consumidor, el body del mensaje es solo read only (el consumidor solo puede leerlo) Dependiendo del tipo del mensaje, tendremos diferentes metodos de acceso textmessage.settext("this is a text message"); textmessage.gettext(); bytesmessage.readbyte(); objectmessage.getobject(); Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 27

28 Consumo de mensajes La mensajeria es inherentemente asíncrona, ya que no hay timing entre el envio y la recepcion de mensajes Sin embargo, el cliente puede consumir mensajes de dos formas, Síncrona: Explicitamente vamos a buscar el mensaje, bloqueandonos hasta que llegue (receive) Asíncrona: El receptor se registra como listener de un evento que se dispara cuando llega el mensaje Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 28

29 Consumo de mensajes Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 29

30 Consumo asincrono Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 30

31 Selectores Cuando un mensaje es enviado a multiples posibles receptores, es util establecer criterios para que solo ciertos clientes consuman los mensajes Un selector permite que el provider entregue solo los mensajes que cumplen con determinado criterio a los clientes especificos Un selector es un string que contiene una expresion Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 31

32 Selectores La expresion es un subconjunto del lenguaje SQL92 para las expresiones de las consultas Por ejemplo: session.createconsumer(topic, "JMSPriority < 6"); session.createconsumer(topic, "JMSPriority < 6 AND orderamount < 200"); session.createconsumer(topic, "orderamount BETWEEN 1000 AND 2000"); Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 32

33 Selectores Operadores lógicos y de comparación NOT, AND, OR, =, >, >=, <, <=, <> Operadores aritméticos +, -, *, / Operadores de pertenencia [NOT] BETWEEN, [NOT] IN, [NOT] LIKE, IS [NOT] NULL Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 33

34 Confiabilidad JMS brinda algunos mecanismos para determinar la confiabilidad del mensaje enviado Estos son: Tiempo de vida del mensaje Persistencia del mensaje Confirmación de recepción (ACK) Subscriptores persistentes Establecimiento de prioridades Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 34

35 Tiempo de vida Time to live MessageProducer producer = session.createproducer(topic); producer.settimetolive(1000); O sino producer.send(message, DeliveryMode.NON_PERSISTENT, 2, 1000); Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 35

36 Persistencia Message Persistence MessageProducer producer = session.createproducer(topic); producer.setdeliverymode(deliverymode.non_per SISTENT); O sino producer.send(message, DeliveryMode.NON_PERSISTENT, 2, 1000); Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 36

37 Confirmacion La confirmación del mensaje puede ser iniciada por el provider, o por el cliente, segun el modo de ACK Por ejemplo, un ACK iniciado por el cliente seria: Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 37

38 Confirmacion En el modo de confirmacion de cliente: // Producer connection.createsession(false, Session.CLIENT_ACKNOWLEDGE); producer = session.createproducer(topic); message = session.createtextmessage(); producer.send(message); // Consumer message.acknowledge(); Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 38

39 Subscriptores persistentes En un modelo pub/sub, el consumidor debe estar activo para recibir el mensaje, sino, el mensaje se pierde Si tenemos un subscriptor permanente, el provider mantiene el mensaje hasta que todos los consumidores (activos y subscriptos) han recibido el mensaje session.createdurablesubscriber(topic,"javaee6dura blesubscription"); Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 39

40 Prioridades Esto permite entregar mensajes importantes antes JMS define 10 niveles de prioridad (0 la mas baja, 9 la mas alta) MessageProducer producer = session.createproducer(topic); producer. setpriority(2); O sino producer.send(message, DeliveryMode.NON_PERSISTENT, 2, 1000); Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 40

41 Message Driven Beans Un MDB es un consumidor asincrono, el cual es invocado por el container ante la llegada de un mensaje Son parte de la especificacion EJB, ya que su modelo es muy similar a los Stateless Session Beans Por que usarlos? Aprovecha los beneficios del modelo EJB de trabajo Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 41

42 Message Driven Beans Son extremadamente simples de escribir, ya que son consumidores JMS, pero todos los aspectos relacionados con los objetos administrados, son resueltos automaticamente Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 42

43 Modelo para MDBs A diferencia de otros EJBs, este tipo de componente no implementa una interfaz local o remota Solo implementan javax.jms.messagelistener Soportan Ciclo de vida, inyeccion, interceptores, callbacks, transacciones, etc. En este sentido, son similares a los Session Beans Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 43

44 Requisitos para un MDB La clase debe estar anotada La clase debe implementar (directa o indirectamente) javax.jms.messagelistener La clase debe ser publica, no abstracta y no final La clase debe tener un constructor sin parámetros La clase no debe definir el método finalize() Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 44

45 @MessageDriven El formato de esta anotacion es: Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 45

46 @MessageDriven Algunas propiedades importantes mappedname Es el nombre JNDI de la destination a la que este MDB se conecta activationconfig Es usado para especificar un array de propiedades de Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 46

47 @ActivationConfigProperty Es de la forma Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 47

48 @ActivationConfigProperty Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 48

49 Algunas propiedades Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 49

50 Inyeccion de dependencias Como en el caso de otros EJBs, tambien se soportan inyecciones Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 50

51 MessageDrivenContext Metodos disponibles getcallerprincipal getrollbackonly gettimerservice getusertransaction iscallerinrole lookup setrollbackonly Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 51

52 Ciclo de vida Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 52

53 Transacciones El manejo transaccional en un MDB es muy similar al de un Session Bean Sin embargo, existen ciertas diferencias debido a la ausencia de un cliente para el componente En el caso de CMT, el container inicia una transaccion antes del comienzo del metodo onmessage, commiteando la misma al termino (a menos que se haya marcado para rollback) Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 53

54 Transacciones A pesar de que los MDBs son transaccionales, no pueden ser invocados en el contexto de la transaccion del cliente No existe un contexto transaccional que se propague desde el cliente al MDB Por lo tanto, solo se soportan 2 atributos transaccionales REQUIRED y NOT_SUPPORTED Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 54

55 Excepciones Cualquier operación en los elementos del API de JMS, en caso de error, propagara una javax.jms.jmsexception Importante: JMSException es una checked exception Por este motivo, el rollback de la transacción, si existiera, debe ser realizado manualmente usando el contexto Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 55

56 Excepciones Instituto de Computación Facultad de Ingeniería UdelaR Montevideo, Uruguay 56