RabbitMQ Exchange

Introdução

    Este artigo vem complementar o rabbitMQ conceitos iniciais escrito recentemente. Como uma séries de artigos referente ao RabbitMQ que irei apresentar no PHPConference dia 04/12/2015

Exchange

    No modelo AMQP, um produtor de mensagem envia mensagens para um exchange, que distribui a mensagens para queues. A exchange é um algorítmo que determina qual queues deve receber a mensagem.

Tipos

    Existe 4 tipos de algorítmos diferentes, que se diferem pelo algoritimo utilizado

Fonout

    É o tipo mais simples. Envia cada mensagem para cada fila ligada a troca.

Direct Exchange

    O Producer identifica a mensagem com uma chave de roteamento, que nada mais é do que uma string que indica o tipo de mensagem. O algoritmo de roteamento se preocupa em levar a mensagem para as filas cuja chave de ligação corresponde exatamente a chave de roteamento da mensagem.

Default Exchange

    Utiliza o nome da fila como chave de ligação. Se um producer envia uma mensagem e a chave de identificação é o nome da fila, por padrão o exchange envia esta mensagem para esta fila. Toda exchange deve ter um nome. Caso ela não o tenha, ela é considerada exchange padrão.

Topic Exchange

    É semelhante a uma troca direta. Entretanto usa chaves separadas por um delimitador, que deve ser uma lista de palavras, delimitada por pontos. As palavras podem ser qualquer coisa, mas geralmente especifícam algumas características ligadas à mensagem. A chave deve estar limitada a 255 bytes.

    

    Estas chaves pode incluir caracteres curingas, como exemplo temos o '#' que substitui uma ou mais palavras; ou '*' substitui exatamente uma palavra.

Headers Exchange

    A AMQP fornece uma headers exchange, que permite consultas símples em headers de uma mensagem. A ligação contém uma lista headers name, propriedades, e argumentos especificando se 'all' (todos os campos de cabeçalho devem corresponder) ou "any" (se qualquer campo corresponder).
Cada AMQP 0-10 corretor contém uma predeclared cabeçalhos trocar amq.match nomeado. Trocas de cabeçalho adicionais podem ser declarados como necessário.
    A AMQP permite implementar tipos de exchange que não estão definidos na norma. Neste caso falamos de Intercâmbios personalizados, eles não são pré-declarados. Para isso, o MRG Messaging fornece um Exchange XML, que pode encaminhar mensagens XML com base em seu conteúdo. As ligações para uma troca XML usar um Xquery, que é aplicada ao conteúdo e cabeçalhos de cada mensagem para determinar se a mensagem deve ser encaminhada.

Veja também RabbitMQ na prática com PHP

Referências

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_MRG/1.1/html/Messaging_User_Guide/chap-Messaging_User_Guide-Exchanges.html

https://www.rabbitmq.com/tutorials/tutorial-three-python.html
https://www.rabbitmq.com/tutorials/tutorial-four-php.html

RabbitMQ Conceitos iniciais

Introdução

    Este artigo é o primeiro de uma série de artigos que pretendo fazer para complementar o material que será apresentado na PHPConference 2015

    O RabbitMQ é um gerenciador de fila assíncrono, seu intuito é basicamente separar os enviadores dos receptores e funcionar como um intermediário de mensagens, garantindo a sua entrega em formato de fila. A mensageria é uma técnica que soluciona a comunicação entre sistemas diferentes de forma confiável, e um Barramento de Mensagens é o mecanismo que coordena o envio e a recepção de mensagens em uma fila.

    AMPQ (Advanced Message Queuing Protocol): É um protocolo sobre o qual trabalha o rabbitMQ, este foi criado para tentar unificar todas as tecnologias envolvidas em um sistema de mensagens, funciona como um protocolo de comunicação em rede, similar ao HTTP.

    Mensageria: sistemas que trocam mensagens por intermédio de um servidor que em geral é chamado de message broker. A razão para sua existência é a baixa confiabilidade das redes que interligam computadores. Este sistema garante que o receptor receberá a mensagem enviada.

    Fila (Queue) - É um buffer que armazena as mensagens dentro do RabbitMQ para ser consumida posteriormente.

    Consumidor (Consumer) - É quem recebe as mensagens,que estão na fila.

    Producer: Aplicações responsáveis por publicar mensagens nos exchanges.

    Exchange: Sua tarefa é receber as mensagens do producer e encaminhar as mensagens para filas;

    Queues: Armazenam as mensagens e encaminham elas para os consumers;

Transmição

    Basicamente uma mensagem é transmitida por 5 passos:

• Create - O remetente cria a mensagem;
• Send - O remetente adiciona a mensagem para um canal.
• Deliver - O sistema de mensagens move a mensagem do computador do remetente para o computador do receptor, tornando-o disponível para o receptor.
• Receive - O receptor lê a mensagem a partir do canal.
• Process - O receptor extrai os dados da mensagem.

    Neste diagrama entendemos alguns conceitos:

• Send and forget: Quando o Seding Application envia a mensagem para o canal de mensagem, uma vez que o envio estiver completo, o remetente não se preocupa mais com a entrega.
• Store and forward: Ao receber esta mensagem o canal de mensagens grava esta mensagem na memória ou no disco, e disponibiliza ao receptor até que a mensagem chegue ao seu destino.

    Desta forma cada sistema tem sua responsábilidade podendo encapsular da melhor forma sua lógica. Sem ter de se preocupar se a etapa seguinte já aconteceu. Componentes com responsabilidades bem definidas implicam em melhor reutilização.

RabbitMQ

    É uma aplicação open source para troca de mensagens desenvolvida em Erlang, construído no protocolo AMQP, mas também compatível com outros protocolos como HTTP, MQTT e STOMP. O projeto responsável RabbitMQ teve início em 2007 pela empresa Rabbit Technologies Ltd. e, posteriormente, foi incorporado pela VMWare passando a fazer parte da iniciativa Pivotal. O RabbitMQ é composto por três componentes, além do produtor e do consumidor: O Exchange, a Queue e o binding.

Exchange: Sua tarefa é receber as mensagens do producer e encaminhar as mensagens para filas;

Queues: Armazenam as mensagens e encaminham elas para os consumers;

    O exchange recebe a mensagem de um producer e encaminha para as filas de acordo com um critério pré-definido. Esse critério é chamado de binding. O exchange é basicamente um sistema de rotas, que inspeciona a mensagem e usando sua tabela de critérios decide como a encaminhar as mensagens, seja para uma fila de mensagem ou para outro exchange.

    O Canal (Channel) faz a conexão da aplicação cliente com o broker através do protocolo TCP. As conexões usam autenticação e podem usar conexões SSL. Conexões via TCP custam caro para o sistema operacional e, por isso, os canais existem. Os canais, dentro do protocolo AMQP, são “conexões leves que compartilham a mesma conexão TCP”, é necessária apenas uma instância de conexão para executar múltiplas ações.

Continua em RabbitMQ Exchange

Referências

https://www.rabbitmq.com/features.html

http://www.gta.ufrj.br/ensino/eel879/trabalhos_vf_2014_2/leonardo/intro.html

http://blog.concretesolutions.com.br/2012/01/rabbitmq-conceitos-basicos/

http://www.devmedia.com.br/introducao-ao-amqp-com-rabbitmq/33036

http://blog.concretesolutions.com.br/2012/01/introducao-a-mensageria/

http://www.enterpriseintegrationpatterns.com/patterns/messaging/Introduction.html

http://blog.andreiabohner.org/post/1/usando-o-rabbitmq-com-o-symfony2

http://www.ime.usp.br/~reverbel/students/master_theses/thadeu_de_russo_e_carmo.pdf

http://www.devmedia.com.br/integracoes-robustas-com-jboss-rabbitmq-e-qpid/31538

http://lerta.com.br/alta-disponibilidade-no-rabbitmq-warren/

http://nelsonsar.github.io/2013/10/29/AMQP-building-blocks.html

http://nelsonsar.github.io/2013/11/07/RabbitMQ-exchange-types.html

TDD. O que é, e como inicio no PHP Parte II

TDD Conceitos Importantes

Introdução

    Em algumas postagens anteriores fiz a primeira parte desta série de artigos. A primeira praticamente ensinava uma das várias formas de instalação que para o phpunit e o xdebug. Agora vamos entender alguns conceitos do TDD

Argumentação para o TDD

    No TDD sempre devemos iniciar com os testes. Isso nos obriga a pensar exatamente o que desejamos que este pedaço do sistema execute. Acredito que uma boa forma de utiliza-lo é junto com alguma ferramenta ágil, como o scrum - por exemplo. O importante em dividir seu sistema em uma parte testável do dele, inicialmente criar o teste, e depois o código para que o teste passe. Resolvido esta parte podemos evoluir o código.
    Qualidade do código
    Um dos principais ensinamentos do TDD é que se algo não puder ser testado, este foi desenvolvido errado. Em pouco tempo utilizando testes começará a desenvolver de forma visivelmente diferente, ajudando o programador a desenvolver um código cada vez com mais qualidade. Pois, para atuar com o TDD, o programador é obrigado a forçar seu raciocínio de forma mais elevada para que o código tenha menos acoplamento e dependência.

    Documentação

    Os testes acabam sendo uma excelente documentação do software. Pois ao rodar o teste no modo verbose, uma "história" é contada do software que poderá ajudar a criar a documentação.

    Testes manuais custam caro

    Sem os teste unitários, a validação para garantir a integridade do software é praticamente impossível, pois o testes deveria testar todos os fluxos possíveis em diversas situações, para encontrar possíveis erros. Com os testes unitários, sobra apenas os testes mais práticos do fluxo que realmente foi alterado.

Passos do TDD
    O TDD baseia-se em três passos, vermelho, verde e refatora. O vermelho é o início, quando você apenas criou o teste, assim ainda não existe a classe a ser testada, e consequentemente o teste não passará. O verde é o momento em que a lógica criada passou no teste, assim o código já esta funcional, mas ainda carece de melhoras. Esta melhora ocorre na parte do refatoramento, que é a melhoria do código, onde se remove duplicações e o código vai ficando mais próximo de sua versão final. É importante em cada alteração do código, passar o teste, para garantir que a mudança não interferiu em seu funcionamento.
    Para o correto funcionamento é utilizado um conceito chamado baby steps ou passos de bebê, que consiste em realizar pequenos passos de um processo complexos. Para isso devemos utilizar os seguintes princípios:

• Os testes precisam ser rápidos;
• Devem ser isolados, devemos testar apenas uma unidade do sistema. O ideal é que os fatores externos não interfiram na unidade.
• Devem funcionar em qualquer ordem ou em qualquer valor. 
• Não deve ser interferido manualmente, devem funcionar sozinhos.
• O código deve ser desenvolvido após desenvolver o teste.

Conclusão

    Como vimos o Desenvolvimento baseado em testes é de vital importância para melhoria do código, refatoração sem erros, e facilitação da manutenção do sistema. Nos próximos artigos veremos como atuar mais na prática.

Domain Driven Design

        Diferenças entre Domain Driven Design e Model Drinven Design

Significa Projeto Orientado a Domínio e veio do livro escrito por Eric Evans. Como diz o Wikipedia é uma abordagem de desenvolvimento de software para as necessidades complexas, fechando a lacuna entre a realidade do negócio e o código.
A ideia principal do DDD é capturar o modelo para o código. Mantendo seu software voltado para o problema e não restrito à solução. Assim quando você procura algo importante sobre o domínio você saberá exatamente onde está.

Linguagem Ubíqua
É uma linguagem comum, com termos bem definidos, que fazem parte do processo de desenvolvimento. É importante para que todos falem a mesma língua, baseado na informação que puder conseguir do cliente. Como exemplo, se um cliente chama o dinheiro do caixa de numerário, sempre que nos referenciarmos ao dinheiro do caixa no software e nas reuniões, ele será numerário. Assim evita erros de interpretação.
É importante que todos os membros dentro do projeto estejam comprometidos com a linguagem Ubíqua, e tentar readequar sempre que for percebido que um termo tem mais de um significado.
Apenas desta forma poderemos ter o modelo abstrato como uma representação perfeita do domínio.

Model Driven Design (MDD)
A ideia por trás do MDD é a de que o seu modelo abstrato deve ser a representação perfeita do seu domínio. Seu processo de maturação deve ser contínuo. Este modelo servirá de guia para a criação do código e, ao mesmo tempo, o código ajuda a aperfeiçoar o modelo. Este contato contínuo trará aos programadores um insights para a refatoração.

Blocos de Construção do MDD
Precisamos isolar o modelo das demais partes. Essa separação sera feira utilizando-se de arquitetura em camadas:

• Interface de Usuário: É a parte de interação com o usuário e interpretação dos seus comandos;
• Aplicação: É uma camada sem lógica de negócio, responsável por conectar a interface as camadas inferiores
• Domínio: Responsável por toda a regra de negócio, Todo o foco do DDD esta aqui. 
• Infra-estrutura: Responsável por fornecer os recursos para suporte as camadas superiores. São as partes de dados e persistência em geral.

Conclusão
Diante desta introdução ao DDD percebe-se que a ideia que gira em seu turno, e montar sua aplicação baseada no que o cliente deseja. Compreendendo exatamente as funções do sistema, abrangendo esta compreensão inclusive na linguagem utilizada pelo cliente. Fica evidente também que o MDD (Model Driven Design) é a parte maior, e uma das camadas (a camada de lógica) é que abrange o DDD (Domain Driven Design)

Referências
http://www.agileandart.com/2010/07/16/ddd-introducao-a-domain-driven-design/
http://en.wikipedia.org/wiki/Domain-driven_design
http://www.agileandart.com/portfolio/mdd-model-driven-design/
http://msdn.microsoft.com/pt-br/magazine/dd419654.aspx
http://www.inf.ufsc.br/~ricardo/publications/Asoo97.pdf