O documento apresenta uma agenda de treinamento sobre HornetQ, abordando conceitos de mensageria, arquitetura do HornetQ, uso standalone e em ambientes JEE. O instrutor possui mais de 12 anos de experiência e ministra treinamentos sobre diversas tecnologias.

1. Treinamento HornetQ

2. Sobre o Instrutor
Waelson Negreiros
• Possui mais de 12 anos de experiência em TI.
• Ministra treinamento a mais de 7 anos sobre as mais variadas
tecnologias.
• Detém varias certificações de grandes players do mercado.
waelson@gmail.com

3. Agenda
•
•
•
•
Conceitos de Mensageria
Arquitetura do HornetQ
HornetQ como Standalone
Mensageria com JEE

4. Conceito de Mensageria
•
•
•
•
•
•
O que é Mensageria?
Vantagens da Mensageria
Modelos Arquiteturais
Modelos de Mensageria
API JMS
Anatomia de uma Mensagem JMS

5. O que é Mensageria?
“É a maneira de se resolver problemas
complexos de integração de sistemas, através da
comunicação indireta entre as partes
envolvidas.”
Waelson Negreiros

6. O que é Mensageria?
Não existe acoplamento
direto entre as aplicações.
Application A
Middleware
Application B

7. O que é Mensageria?
• São características da mensageria:
– Permitir o processamento de requisições de forma
assíncrona.
– Integrar sistemas desenvolvidos em tecnologias diferentes.
– Permite reduzir o grau de acoplamento entre os
componentes.

8. O que é Mensageria?
• Permitir o processamento de requisições de forma
assíncrona.

9. O que é Mensageria?
• Integrar sistemas desenvolvidos em tecnologias
diferentes.
APIs específicas
Application A
(Java)
Middleware
Application B
(.NET)

10. O que é Mensageria?
• Permite reduzir o baixo grau de acoplamento entre
os componentes.
Application A
Middleware
Application B

11. Vantagens da Mensageria
• Redução do Gargalo dos Sistemas
• Aumento da Escalabilidade
• Arquitetura Flexível e Ágil

12. Vantagens da Mensageria
• Redução do Gargalo dos Sistemas
• Gargalos ocorrem quando a capacidade ou performance
de um sistema tem seus componentes ou recursos
limitados.

13. Vantagens da Mensageria
• Aumento da Escalabilidade
• É uma maneira de reduzir gargalos.
• Pode ser alcançado através da inclusão de vários receivers
que podem processar várias mensagens em paralelo.
Receiver 1
Sender 1
Receiver 2
Middleware
Sender 2
Receiver 3
Receiver N

14. Vantagens da Mensageria
• Arquitetura Flexível e Ágil
• Habilidade capaz de responder rapidamente as constantes
mudanças do ambiente.
• Através do uso da mensageria para abstrair e desacoplar é
possível, responder as mudanças de:
– Software
– Hardware
– Negócio

15. Modelos Arquiteturais
• Enterprise Messaging
• É um conjunto de ferramentas capaz de empregar os
conceitos por trás da mensageria em um ambiente
corporativo.
• Exemplo de Ferramentas:
– Comerciais
» IBM Websphere MQ, Sonic MQ, Microsoft Message Queuing,
TIBCO, etc.
– Open Sources
» HornetQ, ActiveMQ, etc.

16. Modelos Arquiteturais
• Enterprise Messaging
• Junto com Service Oriented Architecture (SOA), nasce um
novo tipo de produto, conhecimento como Enterprise
Service Bus – ESB.
• ESBs além de suportar uma variedade de protocolos de
comunicação, tem suas estruturas baseadas em
mensagens.
• JBoss ESB é um exemplo

17. Modelos Arquiteturais
• Tipos de Arquitetura
• Centralizada
• Descentralizada
• Híbrida

18. Modelos Arquiteturais
• Tipos de Arquitetura - Centralizada
• Existe um servidor de mensagem central que interliga
todos os clientes e potenciais consumidores.

19. Modelos Arquiteturais
• Tipos de Arquitetura - Descentralizada
• Usa Multicat IP em nível de rede
• Alguma funcionalidades como persistência, transação e
segurança estão embutidas no cliente.
• Serviço de roteamento é delegado a camada de rede.
• Multicast permite que um ou mais IPs unam-se para
formar um grupo.
• A mensagem é distribuída entre os participantes do grupo.

20. Modelos Arquiteturais
• Tipos de Arquitetura - Híbrida
• Fabricantes podem mesclar arquiteturas combinando as
abordagens: Centralizada e Descentraliza.
Comunicação via
Multicast IP
Comunicação via
TCP/IP
Client
Deamon
Client
Client
Deamon
Deamon
Client
Deamon

21. Modelos de Mensageria
• Terminologias
• MOM – Middleware Oriented Message
– Infraestrutura client/server que substitui a comunicação direta entre
as aplicações.
• Message
– Pacote de dados utilizado para troca de informações.
• Sender ou Producer
– Programa que escreve e envia uma mensagem.
• Consumer ou Receiver
– Programa que recebe e ler (processa) a mensagem.
• Channel (Topic/Queue)
– Caminho lógico utilizado para conectar o programa ao MOM e
transmitir a mensagem.

22. Modelos de Mensageria
• Classificados em dois tipos:
• Point-to-Point
• Publish-and-Subscribe

23. Modelos de Mensageria
• Point-to-Point
• Também conhecido por P2P.
• Permite o envio de mensagem de forma síncrona e
assíncrona.
• Utiliza como canal (Channel) de comunicação a fila (Queue)
• A mensagem enviada à Queue será recebida por um e
somente um Receiver/Consumer.
• Baseia-se no conceito “Fire and Forget”.

24. Modelos de Mensageria
• Point-to-Point

25. Modelos de Mensageria
• Publish-and-Subscribe
• Também conhecido por pub/sub.
• Utiliza como canal (Channel) de comunicação o
tópico(Topic)
• A mensagem enviada ao Topic, ao contrário da
Queue, pode ser recebida por vários consumidores, nesse
caso conhecidos como Subscriber.
• Os Topics utilizam técnicas de broadcasting.

26. Modelos de Mensageria
• Publish-and-Subscribe

27. API JMS
• O que é?
• Foi o esforço da indústria juntamente com a Sun
Microsystems, para prover uma API padrão de
conectividade aos MOMs.
• Criada pela JSR-914.

28. API JMS
• Organização
• Dividida basicamente em três partes:
– API Geral
» Pode ser usada para receber mensagem tanto de uma Queue
quanto de um Topic.
– API Point-to-Point
» É usado unicamente para mensagens em Queue.
– API Publish-and-Subscribe
» É usado unicamente para mensagens em Topic.

29. API JMS
• API Geral
• Possui sete principais interfaces, são elas:
–
–
–
–
–
–
–
ConnectionFactory
Destination
Connection
Session
Message
MessageProducer
MessageConsumer
• As interfaces ConnectionFactory e Destination são obtidas
via JNDI, sendo as demais criadas através de métodos
fábricas (factory method) nas várias interfaces.

30. API JMS
• API Geral

31. API JMS
• API Point-to-Point / Publishe-and-Subscribe
• Ambas possuem também sete interfaces principais:
• Tem o funcionamento similar a API Geral.

32. API JMS
• API Point-to-Point
• API Publishe-and-Subscribe

33. API JMS
• JNDI – Relembrando
• Java Naming and Directory Interface é uma API para
acesso a serviços de diretórios.
• Ela permite que o cliente descubra (lookup) e obtenha
dados ou objetos através de um nome.

34. API JMS
• JNDI – Relembrando
Context ctx = new InitialContext();
//Ignorando configurações dos parametros
Queue fila = (Queue)ctx.lookup(“minhaFila”);
//Faz algo com o objeto fila

35. Anatomia de uma Mensagem JMS
• A Mensagem é a parte mais importante da API JMS
• Todos os dados e eventos são comunicados com
mensagem.
• Restante da API é utilizada para facilitar a transferência das
mensagens
• Mensagens são diferentes de chamadas RPC, pois não
executam comandos.
• Mensagem carrega dados e fala ao “ouvinte” (receiver)
que algo aconteceu (evento)

36. Anatomia de uma Mensagem JMS
• Organização
• Mensagens são divididas em três partes:
– Message Header
– Message Properties
– Message Body

37. Anatomia de uma Mensagem JMS
• Organização
HEADER
JMSDestination
JMSDeliveryMode
JMSMessageID
JMSTimestamp
JMSExpiration
JMSRedelivered
JMSPriority
JMSReplyTo
JMSCorrelationID
JMSType
PROPERTIES
BODY
Payload

38. Anatomia de uma Mensagem JMS
• Message Header

39. Anatomia de uma Mensagem JMS
• Header
• Parâmetros automaticamente atribuídos
–
–
–
–
–
–
–
JMSDestination
JMSDeliveryMode
JMSMessageID
JMSTimestamp
JMSExpiration
JMSRedelivered
JMSPriority

40. Anatomia de uma Mensagem JMS
• Atributos - Header
• JMSDestination
– Identificador do canal de destino (Queue ou Topic)
• JMSDeliveryMode
– São dois os tipos de modo de entrega, são eles: Persistent e
NonPersistent
» Persistent – Mesmo que o message system falhe a mensagem
será entregue quando ele se recuperar.
» NonPersistent – Em caso de falha do message system a
mensagem será perdida

41. Anatomia de uma Mensagem JMS
• Atributos - Header
• JMSMessageID
– Identificador único da mensagem, gerado de acorco com o
fabricante do message system.
• JMSTimestamp
– Definido automaticamente pelo message producer quando
método send() for invocado. Contém data e hora que o message
system recebeu a mensagem.
• JMSExpiration
– Usada pelo message system para previnir que a mensagem seja
entregue ao consumer depois de expirada.

42. Anatomia de uma Mensagem JMS
• Atributos - Header
• JMSRedelivered
– Indica que a mensagem foi reentregue ao consumer. Retorna um
valor booleano, onde true indica que o consumer não reconheceu
a entrega da mensagem anteriormente.
• JMSPriority
– O producer pode atribuir uma prioridade à mensagem, que por
sua vez será utilizada pelo message system para priorizar a
entrega. São classificadas em duas categorias:
» Prioridade Normal: 0 – 4
» Prioridade Alta: 5 - 9

43. Anatomia de uma Mensagem JMS
• Exemplo Atributos - Header
• JMSDestination
• JMSDeliveryMode
• JMSMessageID
• JMSTimestamp

44. Anatomia de uma Mensagem JMS
• Exemplo Atributos - Header
• JMSExpiration
//Configuração no producer
• JMSRedelivered
• JMSPriority
//Configuração no producer

45. Anatomia de uma Mensagem JMS
• Header
• Parâmetros atribuídos pelo desenvolvedor
– JMSReplyTo
– JMSCorrelationID
– JMSType

46. Anatomia de uma Mensagem JMS
• Atributos - Header
• JMSReplyTo
– Em algumas situações pode ser necessário que o consumer
responda uma mensagem, ele poderá utilizar o destination
(javax.jms.Destionario) aqui especificado.
• JMSCorrelationID
– Geralmente utilizada para marcar uma mensagem atual como
uma resposta de uma mensagem anterior, utilizando como base o
JMSMessageID.
– JMSType
• Parâmetro opcional, seu objetivo é identificar a estrutura da
mensagem e tipo do payload.

47. Anatomia de uma Mensagem JMS
• Exemplo de Atributos - Header
• JMSReplyTo
• JMSCorrelationID
• JMSType
–
Não mapeia o tipo da classe do payload, cada message system tem um tratamento
diferente.

48. Anatomia de uma Mensagem JMS
• Properties
• Usado como extensão do Header.
• Desenvolvedores podem adicionar informações extra a
mensagem.
• Também são utilizados como base para filtrar informações.
• A interface Message fornece métodos acessores e
configuradores (get/set) para leitura e escrita das
propriedades. Os valores podem ser
String, boolean, byte, double, int, long ou float.
• São divididos em três categorias, são eles: Específica da
Aplicação, Definidas pela API JMS e Especifica do Provider

49. Anatomia de uma Mensagem JMS
• Properties
• Específica da Aplicação
–
–
–
–
Qualquer propriedade definida pelo desenvolvedor da aplicação.
São configuradas antes da mensagem ser enviada.
O desenvolvedor é livre para configurar o que quiser.
Exemplo:

50. Anatomia de uma Mensagem JMS
• Properties
• Definidas pela API JMS
– Possue as mesmas características da anterior.
– Muitas delas são configuradas pelo Provider JMS quando a
mensagem é enviada.
– O Provider JMS pode optar por suportar todas ou nenhuma.
– Exemplo:

51. Anatomia de uma Mensagem JMS
• Properties
• Específica do Provider
– Vários Providers JMS podem definir um conjunto de propriedades
proprietárias que podem ser configuradas pelo cliente ou pelo
provider automaticamente.
– Deve iniciar com JMS_<propriedade>.
– O HornetQ utiliza o préfixo _HQ<propriedade>

52. Anatomia de uma Mensagem JMS
• Properties
• Lendo as Propriedades

53. Anatomia de uma Mensagem JMS
• Body
• O conteúdo da mensagem muitas vezes leva as
informações mais importantes.
• A API JMS define a interface Message, mas nenhuma
implementação.
• Existem 5 subinterfaces, são elas:
–
–
–
–
–
TextMessage
StreamMessage
MapMessage
ObjectMessage
BytesMessage

54. Anatomia de uma Mensagem JMS
• Body
• É comum trafegar informações de formato texto, utilizando
os protocolos JSON e XML como formato de intercambio.

55. Arquitetura do HornetQ
•
•
•
•
O que é o HornetQ?
Arquitetura baseada em POJOs
APIs de Comunicação
Persistent Journal

56. Arquitetura do HornetQ
• O que é o HornetQ?
– Projeto open source mantido pela JBoss.
– Características:
•
•
•
•
•
•
100% open source
Projetado com usabilidade em mente
Escrito em Java (roda com Java 6 ou superior)
Performático
Arquitetura baseada em POJOs
Suporta mecanismos de cluster e HA.

57. Arquitetura do HornetQ
• O que é HornetQ?
– O que significa arquitetura baseada em POJOs?
• Permite ser injetado dentro da aplicação
• Pode ser instanciado por vários frameworks de DI, como por
exemplo: JBoss Microcontainer, Google Guice e Spring

58. Arquitetura do HornetQ
• APIs de Comunicação
– Os clientes se comunicam com o HotnetQ através de duas
APIs, são elas:
• Core Client
– Conjunto de componentes fornecidos com o servidor, que permite a iteração
das aplicações com o MOM através das várias funcionalidades disponíveis.
• JMS Client
– Padrão JMS de comunicação.

59. Arquitetura do HornetQ
• APIs de Comunicação
Apenas faz a tradução para a
API nativa.

60. Arquitetura do HornetQ
• Persistent Journal
– A razão da alta performance no HornetQ está no seu
mecanismo de persistência