Jms e MOM (Message Oriented Middleware)

1,512 views
1,374 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,512
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
33
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Jms e MOM (Message Oriented Middleware)

  1. 1. JMS e MOM (Message Oriented-Middleware)<br />Jônata Gabriel Teixeira Marcelino<br />José Salustiano Filho<br />
  2. 2. Sumário<br />MOM (Message Oriented-Middleware)<br />GlassFish Enterprise Server<br />JMS (Java MessagingService)<br />O objeto modelo JMS + Implementação<br />
  3. 3. Mom (Message oriented-Middleware)<br />
  4. 4. MOM (Message Oriented Middleware)<br />É uma infraestrutura de software/cliente servidor que cria uma camada entre as aplicaçõesde alto nível e as plataformas onde estão instaladas, por sistema de mensagens.<br />
  5. 5. MOM<br />Sua implementação fornece um conjunto de API’s<br />Aumenta a portabilidade<br />Interoperabilidade<br />Flexibilidade<br />Comunicação<br />Através de mensagens<br />Pela estrutura pura cliente/servidor (usando broadcast ou multicast)<br />Pilhas mantidas por gestores locais: mais poderosa em termos de aplicabilidade e versatilidade<br />
  6. 6. Descrição tecnológica<br />A MOM está presente em ambos os lados, tanto no cliente, quanto no servidor<br />Ligação peer-to-peer<br />Chamadas assíncronas (é possível adicionar sincronismo, usando RPC’s)<br />Tipos de mensagens compartilhadas<br />Persistente: armazenada em memória não volátil, assim caso de falha, os dados não são perdidos.<br />Não-persistente: armazenada em memória volátil<br />Tipos de dados compartilhados<br />Dados formatados (variáveis, strings)<br />Pedidos de execução (chamadas a funções)<br />Ou ambos<br />
  7. 7. Descrição tecnológica<br />As mensagens são transmitidas por gestores de pilhas (Message Queue Manager ou MQM).<br />Fornece um ambiente para aplicações que utilizem as pilhas de mensagem ou aplicações como MQI (Message Queue Interface)<br />Message Queue Interface<br />Providencia armazenamento fiável para as mensagens armazenadas nas pilhas<br />Administra concorrentes a dados<br />Garante segurança e autenticidade<br />Providencia funções especiais de emparelhamento de mensagens (por exemplo triggers).<br />
  8. 8. Descrição tecnológica<br />A forma de tomar as trocas mais fiável é usar tratamento de pilhas transacionais, o MQM envia várias mensagens para uma aplicação, se ela não conseguir receber, a parte ou o todo volta para a pilha para serem entregues depois<br />Se a aplicação que corre sobre MOM não estiver disponível, então elas são guardadas numa fila onde ficam à espera que a aplicação torne disponível<br />Por isso que a as implementações MOM são mais apropriadas para aplicações orientadas a eventos, ou objetos para a comunicação peer-to-peer<br />
  9. 9. Glassfish Enterprise server<br />
  10. 10. GlassFish<br />Servidor rápido e fácil de usar, baseado na plataforma Java e da tecnologia Enterprise Edition (Java EE) para o desenvolvimento e entrega de aplicações e serviços web.<br />Implementação de referência Java EE<br />Código aberto de nível corporativo, permitindo mais recentes padrões e inovações do setor<br />Melhor desempenho<br />Mais confiabilidade e produtividade<br />Facilidade de uso superiores a uma fração do custo de servidores de aplicações proprietários<br />
  11. 11. JMS (Java Messaginsservice)<br />
  12. 12. JMS<br />Permite a criação, envio, recebimento e leitura de mensagens<br />O receptor recebe a mensagem através do MOM<br />Alguns conceitos<br />Produtores e consumidores (para designar um cliente como produtor de mensagens e um componente EJB Message-DrivenBean por exemplo, como um consumidor de mensagens)<br />
  13. 13. A arquitetura JMS<br />São composta por cinco partes: Provedor JMS, que implementa as interfaces definidas na API JMS e provê recursos para administrar esse serviço; os clientes JMS que podem ser programas ou componentes que agem como produtores e consumidores de mensagens; as mensagens propriamente ditas que são objetos que transportam os dados do cliente para o receptor; os objetos de administração do serviço JMS que são utilizados pelos clientes para enviar as mensagens; e os clientes nativos que são clientes que usam produtos de Messaging nativos e não da API JMS.<br />
  14. 14. Mensagens Point-To-Point (Queue)<br />Conceito de enfileirar mensagens para serem consumidas.<br />
  15. 15. Mensagens Publish/Subscribe- Publica/Inscreve(Topic)<br />
  16. 16. O objeto modelo jms + implementação<br />
  17. 17. O objeto modelo JMS + Implemetação<br />ConnectionFactory<br />Cria conexão com um provedor JMS, ele suporta uso consecutivo e contém parâmetros de configuração de conexão que foram definidos por um administrador. Esta interface não define qualquer método e tem duas sub-interfaces diretas: TopicConnectionFactory e QueueConnectionFactory.<br />Destination<br />É um objeto administrado que encapsula a identidade do destino das mensagens, que é onde as mensagens são enviadas e consumidas. Pode ser uma fila ou um tópico. O administrador JMS cria estes objetos, e os usuários os obtém através de buscas na JNDI. Da mesma forma que as factories de conexões, o administrador pode criar dois tipos de classe de destino, fila (Queue) e tópico (Topic).<br />
  18. 18. O objeto modelo JMS + Implemetação<br />Connection<br />Um objeto Connection representa uma conexão ativa do cliente JMS com um provedor JMS. Tipicamente, ele é um soquete TCP/IP entre um cliente JMS e um provedor JMS. Os objetos Connection suportam uso consecutivo e são representados pela interface javax.jms.<br />Session<br />Um objeto Session é um contexto de sequenciamento único para produzir e consumir mensagens. Um objeto Session é representado pela interface Session.<br />transacted: Esse parâmetro indica se a sessão é transacionada.<br />acknowledgeMode: Esse parâmetro indica se consumidor ou o cliente reconhecerão mensagens que recebem. O seu valor pode ser um dos três campos da interface Session.<br />
  19. 19. O objeto modelo JMS + Implemetação<br />transacted: Esse parâmetro indica se a sessão é transacionada.<br />acknowledgeMode: Esse parâmetro indica se consumidor ou o cliente reconhecerão mensagens que recebem. O seu valor pode ser um dos três campos da interface Session.<br />AUTO_ACKNOWLEDGE: Automaticamente a sessão acusa o recebimento do cliente de uma mensagem ou, quando a sessão foi retornada com sucesso, de uma chamada a receber ou, quando o receptor de mensagem da sessão, chamado para processar a mensagem, retorna com sucesso.<br />CLIENT_ACKNOWLEDGE: O cliente acusa o recebimento de uma mensagem consumida, chamando o método acknowledge da mensagem.<br />DUPS_OK_ACKNOWLEDGE: Esse modo de acusar recebimento instrui a sessão para receber vagarosamente a entrega de mensagem.<br />
  20. 20. O objeto modelo JMS + Implemetação<br />MessageProducer<br />Um objeto MessageProducer é usado por um cliente JMS para enviar mensagens a um destino.<br />QueueSender: Você usa essa interface no domínio point-to-point.<br />TopicPublisher: Você usa essa interface no domínio Publish/Subscribe.<br />MessageConsumer<br />Um objeto é usado por um cliente JMS para receber mensagem de um destino.<br />QueueReceiver: Você usa essa interface no domínio point-to-point.<br />TopicSubscriber: Você usa essa interface no domínio Publish/Subscribe.<br />
  21. 21. O objeto modelo JMS + Implemetação<br />Message<br />Conteúdo a ser enviado para o destino<br />TextMessage: Uma mensagem contendo uma string.<br />MapMessage: Uma mensagem contendo pares nome/valor. Cada nome é um objeto string e cada valor é um tipo primitivo Java.<br />BytesMessage: Uma mensagem contendo uma corrente de bytes não interpretados.<br />StreamMessage: Uma mensagem contendo uma corrente de valores primitivos Java.<br />ObjectMessage: Uma mensagem contendo um objeto que pode ser em série.<br />

×