Algumas idéias, uma vez aceitas, influenciam radicalmente a forma como percebemos e reagimos ao mundo. Nesse exato momento, estou sendo previlegiado com uma dessas experiências.

Na última semana tive a honra e a oportunidade de ouvir Markus Cristen (com blog e perfis no facebook e twitter) falar sobre Enterprise Architecture. Fiquei impressionado a princípio e, voltando para casa, decidi que era hora de estudar mais sobre o assunto. Assim, resolvi começar a leitura de Enterprise Architecture as Strategy recomendado pelo Waldemir Cambiucci (blog e twitter) há quase um ano (o que posso dizer?! Sou lento para algumas coisas).

O que é Enterprise Architecture?

Uma boa definição formal é:

the organizing logic for core business process and IT infrastrucutre reflecting the standarization and integration of a company’s operating model.

Ou seja, é uma iniciativa que explicita a organização dos processos e infraestrutura de forma a suportar o negócio.

Embora tal relação pareça óbvia, é impressionante como parece negligenciada atualmente.Como destacado por Einstein:

The significant problems we face cannot be solved by the same level of thinking that created them.

Enterprise Architecture: TI ou Negócio?

Por que ficar preso na limitância do “ou”, quando podemos nos libertar na supremacia do “e”. Enterprise Architecture é uma disciplina de TI e Negócio.

Veja, Enterprise Architecture trata da integração dos processos de negócio e da padronização dos processos de negócio. Logo, não é objeto apenas de TI. É algo mais amplo – é objeto de negócio.

Qual é o papel do Enterprise Architect?

Veja:

In a business wrold that is changing faster than ever befor, the top-performing firms create a stable base – they digitize their core process and embed thos process into a foundation for execution. This stable foundation makes a company both more efficient and more agile than its competitors.

Essa descrição está perfeitamente alinhada com o que já vimos sobre Enterprise Architeture. Logo, o papel do “Enterprise Architect” é orquestrar as iniciativas de organização dos processos de negócio e infraestrutura de TI de forma a refletir a padronização e integração do modelo de operações de uma companhia.

Enterprise Architect é uma posição estratégica, pois Enterprise Architecutre é, fundamentalmente, uma das expressões da estratégia (recomendo ler “Algumas palavras sobre essa tal Estratégia”).

Relação entre “Enterprise Architecture” e vantagem competitiva

Considere:

Top-performing companies define how they will do business (an operating model) and design the processes and infrastrucutre critical to their current and future operations (enterprise architecture), which guide the evolution of their foundation for execution.

Dessa forma:

Top-performing companies can create a low-cost, high-quality core of stability and constancy in a turbulent world. With a strong digitized core, these companies slide smoothly into the next opportunity while their competitors stumble.

Há uma relação clara e consistentemente repetida entre a formação de vantagens competitivas e a existência de uma “Enterprise Architecture” (mesmo quando não reconhecida dessa forma). Embora não tenha causalidade efetivamente demonstrada (recomendo ler “Essa tal causalidade”), há indícios para tal.

Oportunidades

O papel de “Enterprise Architect” ainda está vago na maioria das organizações. Isso fica evidente pela forma “não profissional” como a Enterprise Architecture ainda é conduzida (quando é).

Na maioria das organizações, ainda há um descolamento evidente entre a institucionalização de infraestrutura de TI e processos com os objetivos do negócio. Muitas empresas tem seu departamento de TI “feature-driven” ou, pior, “vendor-driven” e, como esse ainda é o padrão dominante, não há consequências notáveis.

Entretanto, cada vez mais, TI está sendo percebido como custo. TI não é auto-remunerado, depende do negócio e este está ficando (pelo cenário competitivo) cada vez mais exigente.

O alinhamento entre IT e business é inevitável. IT Architecture precisa ser cada vez mais “value-driven” ou “strategic-driven”. Para atingir isso, é necessário institucionalizar a realização da “Enterprise Architecture”.

O trabalho de Enterprise Architect, além de ter poder de causar impacto real nos negócios, se aproxima muito da estratégia. Logo, é sabidamente melhor remunerado.

Enfim, oportunidades!

Em posts futuros, volto ao tema descrevendo mais as atividades relacionadas a formulação da “Enterprise Architecture” e, consequentemente, o papel do “Enterprise Architect” (Na exata medida em que eu internalize mais tais conceitos)

Era isso.

Dentre todas as coisas que não sei, a que mais sinto falta é escrever poesia. Não estou falando de versos simples, ou de frases de efeito, ou de desabafos bêbados (Esses, eu até tento escrever). Estou falando de poesia de verdade.

Peço licença aos amigos, mas vou tomar a liberdade de compartilhar algumas coisas que, honestamente, gostaria de ter escrito. Infelizmente, me falta competência para tal. Então, tomarei a liberdade de tomar posse de palavras que não são minhas.

Vez ou outra, quem sabe, farei posts como esse. Usarei essa tag! Caso não goste, ignore, por favor.

Vinícius de Moraes

Vinícius de Moraes explica magicamente o que é necessário ao poeta.

Eu sei e você sabe
Já que a vida quis assim
Que nada nesse mundo levará você de mim
Eu sei e você sabe
Que a distância não existe
Que todo grande amor
Só é bem grande se for triste
Por isso meu amor
Não tenha medo de sofrer
Que todos os caminhos
Me encaminham a você.

Assim como o Oceano, só é belo com o luar
Assim como a Canção, só tem razão se se cantar
Assim como uma nuvem, só acontece se chover
Assim como o poeta, só é bem grande se sofrer
Assim como viver sem ter amor, não é viver
Não há você sem mim
E eu não existo sem você!

E encontra magistralmente a descrição da fidelidade (Soneto da Fidelidade)

De tudo ao meu amor serei atento
Antes, e com tal zelo, e sempre, e tanto
Que mesmo em face do maior encanto
Dele se encante mais meu pensamento.

Quero vivê-lo em cada vão momento
E em seu louvor hei de espalhar meu canto
E rir meu riso e derramar meu pranto
Ao seu pesar ou seu contentamento

E assim, quando mais tarde me procure
Quem sabe a morte, angústia de quem vive
Quem sabe a solidão, fim de quem ama

Eu possa me dizer do amor (que tive):
Que não seja imortal, posto que é chama
Mas que seja infinito enquanto dure.

Mário Quintana

Quintana, fala de decepções com tanta leveza que parece ignorar a própria dor.

Da vez primeira em que me assassinaram,
Perdi um jeito de sorrir que eu tinha.
Depois, a cada vez que me mataram,
Foram levando qualquer coisa minha.

Hoje, dos meu cadáveres eu sou
O mais desnudo, o que não tem mais nada.
Arde um toco de Vela amarelada,
Como único bem que me ficou.

Vinde! Corvos, chacais, ladrões de estrada!
Pois dessa mão avaramente adunca
Não haverão de arracar a luz sagrada!
Aves da noite! Asas do horror! Voejai!
Que a luz trêmula e triste como um ai,
A luz de um morto não se apaga nunca!

Quando fala sobre o tempo, (Ah! Os relógios)

Amigos, não consultem os relógios
quando um dia eu me for de vossas vidas
em seus fúteis problemas tão perdidas
que até parecem mais uns necrológicos…

Porque o tempo é uma invenção da morte:
não o conhece a vida – a verdadeira –
em que basta um momento de poesia
para nos dar a eternidade inteira.

Inteira, sim, porque essa vida eterna
somente por si mesma é dividida:
não cabe, a cada qual, uma porção.

E os anjos entreolham-se espantados
quando alguém – ao voltar a si da vida –
acaso lhes indaga que horas são…

Chico Buarque

E por falar de relações, que tal “Mil Perdões”

Te perdôo
Por fazeres mil perguntas
Que em vidas que andam juntas
Ninguém faz
Te perdôo
Por pedires perdão
Por me amares demais

Te perdôo
Te perdôo por ligares
Pra todos os lugares
De onde eu vim
Te perdôo
Por ergueres a mão
Por bateres em mim

Te perdôo
Quando anseio pelo instante de sair
E rodar exuberante
E me perder de ti
Te perdôo
Por quereres me ver
Aprendendo a mentir (te mentir, te mentir)

Te perdôo
Por contares minhas horas
Nas minhas demoras por aí
Te perdôo
Te perdôo porque choras
Quando eu choro de rir
Te perdôo
Por te trair

Fernando Pessoa

Há como falar em texto bem escrito, sem mencionar Fernando Pessoa (Não sei quantas almas tenho)

Não sei quantas almas tenho.
Cada momento mudei.
Continuamente me estranho.
Nunca me vi nem acabei.
De tanto ser, só tenho alma.
Quem tem alma não atem calma.
Quem vê é só o que vê,
Quem sente não é quem é,
Atento ao que sou e vejo,
Torno-me eles e não eu.
Cada meu sonho ou desejo
É do que nasce e não meu.
Sou minha própria paisagem;
Assisto à minha passagem,
Diverso, móbil e só,
Não sei sentir-me onde estou.
Por isso, alheio, vou lendo
Como páginas, meu ser.
O que sogue não prevendo,
O que passou a esquecer.
Noto à margem do que li
O que julguei que senti.
Releio e digo: “Fui eu?”
Deus sabe, porque o escreveu.

Ponto-e-vírgula

Haveria muito mais para citar, mas acho que é um bom começo. Afinal, como diria Carlos Drummond,

A minha vontade é forte, mas a minha disposição de obedecer-lhe é fraca.

Por agora, era isso!

Nesse post, concluo uma relação de “Enterprise Integration Patterns” fundamentais. Se você está chegando agora, deve considerar ver posts anteriores relacionados:

1. Trocando mensagens (entre aplicações) usando MSMQ (com C#)
2. Ganhando Flexibilidade e Escalabilidade com Mensageria e “Pipes and Filters” (usando C#)
3. Encaminhamento condicional de mensagens com Message Router (usando C#)
4. Promovendo compatibilidade com Message Translator (usando C#)

Como pode notar, até aqui, mesclei alguma prática com teoria. Para a parte prática, usei fundamentalmente MSMQ. Entretanto, o contexto teórico é aplicável a outros serviços de mensageria, bem como o próprio Windows Azure.

Agora, vou deixar o código um pouco de lado.

O que é um Message Endpoint?

Pattern que garante baixo acoplamento entre aplicações e serviços/infraestrutura de mensageria. Observe:

Nesse diagrama, podemos perceber algums elementos importantes:

1. aplicações independentes enviando e recebendo mensagens;
2. sistema especialista de mensageria (nos exemplos, estou usando MSMQ);
3. Filtros executando algum tipo de processamento/direcionamento/conversão das mensagens.

Repare que esses elementos são “independentes” (não fazem parte do mesmo pacote).

Um Message Endpoint nada mais é que um componente interfaceando a aplicação e a infraestrutura de mensageria.

Entendendo melhor a relação infra de mensageria com nossos aplicativos

Um sistema de mensageria opera de forma semelhante a um servidor/serviço. Ele recebe e responde requisições.

Como “servidor”, sistemas de mensageria tem clientes. Nesse contexto, as aplicações que os utilizam.

Considere:

• O server provê uma API para que seus clientes possam interagir com ele;
• Essa API não é “application-specific”, e sim “domain-specific”;

Por que um Messaging Endpoint é importante?

O Messaging Endpoint é o “ponto-de-ligação” entre nossos aplicativos e a API do servidor de mensageria.

Adotando esse pattern, permitimos que o restante da aplicação saiba pouco sobre: formato de mensagens; canais; etc.

Message Endpoint encapsula o servidor de mensageria (e suas particularidades) do resto da aplicação. Assim se decidirmos  escolher outro mecanismo, bastará substituir esse componente preservando todo o resto.

Boas práticas na escrita de Message Endpoints

Message Endpoints devem:

• enviar mensagens (para o “servidor” de mesageria) ou receber. Nunca fazer as duas coisas;
• publicar mensagens em apenas uma Queue;

Logo, devem existir tantos endpoints quanto canais de comunicação e/ou operações.

Era isso!

Há quem defenda que a inovação é fundamental para a continuidade de qualquer organização. Concordo com isso! Mas, a pergunta que fica é: “Como inovar?!”

Há métodos, processos e tudo mais. Entretanto, penso que a adoção destes atrapalhe o começo da jornada. Para mim, a busca pela inovação começa pela formação do ambiente inovador.

Neste post, pretendo costurar uma série de crenças pessoais adquiridas com a experiência e com meus estudos. Não pretendo esgotar o assunto (isso seria impossível).

Este post é uma provocação. Meu objetivo é, com os feedbacks, entender o que outras pessoas pensam sobre o tema.

Conceituando Inovação (ou, Inovação não é criatividade)

Eis algo polêmico! Afinal, o que é inovação!? Existem diversas definições, muitas conflitantes, para esse termo tão importante.

Para mim:

Inovação é tudo aquilo que produz “dinheiro novo”!

Boas idéias que não conseguem gerar “dinheiro novo” são pouco mais que nada. Talvez, demonstrações de criatividade. Mas, com certeza, pouco inovadoras.

Nós, brasileiros, somos extremamente criativos. Precisamos ser mais inovadores.

Não concorda com essa definição? Proponha outra nos comentários.

O segredo está no ambiente

Somente pessoas podem produzir Inovação. Ou seja, a inovação é produção fundamentalmente humana.

Para inovar é preciso gente!

Infelizmente (ou felizmente), máquinas não podem inovar! Em consquência disso, da mesma forma como acontece com a motivação, penso que processos ou métodos acabem não sendo muito eficientes.

A gestão eficiente da inovação começa na criação de um ambiente favorável.

Da mesma forma,

O ambiente inovador depende de um esforço real para sua formação e continuidade.

Ou seja, o segredo para a inovação está no ambiente.

Como é um ambiente favorável a inovação?

Muita gente acredita que um ambiente inovador é aquele que:

• incentiva TODAS as pessoas a colaborar com idéias;
• premia o acerto, sem, necessariamente, condenar o erro;
• facilitam a realização de projetos novos e propensamente inovadores;

Concordo com tudo isso. Mas, acho que é insuficiente! Veja:

• Mesmo em empresas reconhecidamente inovadoras, as "melhores idéias” não saem do “banco de idéias”. Geralmente são combinados das áreas de Marketing e P&D;
• Nem todas as empresas “inovadoras” são tão tolerantes ao erro. A Apple, por exemplo, é famosa pela busca ao perfeccionismo (e baixa tolerância com a mediocridade);
• Projetos inovadores raramente conseguem conviver com a gestão da rotina. Na prática, quando “a coisa aperta”, todas as pessoas e recursos relacionados a projetos novos são realocados.

Para mim,

um ambiente favorável a inovação é aquele que permite a manutenção e combinação de insights. É aquele que depende da geração do “dinheiro novo”!

Boas idéias não surgem de uma hora para outra

Diferente do que costumamos reconhecer, a idéia genial, aquela que gera inovação, não surge de uma hora para outra.

Inovadores reconhecem que boas idéias são decorrentes de processos com dois, três, quatro anos! Aliás,

Boas idéias costumam ser resultado da combinação de insights mais antigos; maturados e especializados.

Perceba,

Geralmente, alguém tem “metade” de uma boa idéia. Apenas quando essa “metade” é combianda com outra é que surge o fundamento inovador.

Quando começamos algo, não temos a visão completa do que iremos realizar. Boas idéias, incluindo as inovadoras, precisam de tempo de incubação.

Voltando ao ambiente favorável a inovação…

Como já havia dito, um ambiente inovador é aquele que permite a combinação de insights. Por insight, quero dizer a “meia idéia”. Aquela porção inovadora que, sozinha, não é suficiente.

Um ambiente inovador é aquele que permite que as pessoas divulguem e compartilhem seus insights. Que tolera a maturação!

Queremos ambientes inovadores, temos que incentivar a formação de comunidades de prática. Ampliar a criatividade implica na intensificação da conectividade.

Ambientes inovadores aproximam gente boa! Pessoas realmente interessadas em conceber o melhor.

Logo,

Inovação não ocorre em função da quantidade, e sim da qualidade.

Por isso,

Grandes orçamentos destinados para a inovação não implicam em projetos inovadores.

Pois,

Por incrível que pareça, um time diferenciado custa menos que um time de medíocres.

Há os realizadores, pessoas que conseguem transformar boas idéias em realidade. Infelizmente, essas pessoas, geralmente, tem dificuldades para compreender e participar do processo criativo. A relação entre criativos e executores costuma ser conflituosa.

O conflito entre criativos e executores é alcançado pela comunhão de objetivos;

O que quero dizer por maturação?

Como falei no início, para mim, inovação sempre gera dinheiro novo.

Somos remunerados (ganhamos dinheiro) como pagamento relacionado a entrega de algum valor.

Logo,

Uma idéia inovadora implica na formação clara de uma “proposta de valor”.

Também sabemos que a relação entre dinheiro e valor é tensa! A “conversão” de valor entregue em dinheiro é chamada “monetização”.

Entretanto, para que possamos “entregar o valor”, precisamos definir e trabalhar um composto de pessoas, processos e recursos.

Assim, a inovação depende da definição e estabilização de:

• uma proposta de valor coerente;
• um formato de monetização adequado para a remuneração efetiva do capital e do trabalho;
• a determinação e constituição de uma estrutura com pessoas, processos e recursos adequados.

O problema, é que isso não ocorre de uma hora para outra. A definição de todos esses elementos é algo interativo (não é possível acertar de primeira).

Empresas grandes tem mais dificuldade em inovar

É claro e notório que empresas maiores tem mais dificuldade para inovar. Por quê? Penso que a resposta seja que elas raramente dependem da formação do dinheiro novo para a continuidade (imediata!) de suas operações.

Empresas novas carecem de uma proposta de valor. Por isso, é vital aproximar pessoas com insights que possam ser úteis para formação dessa proposta, bem como meios de monetização.

Empresas novas (e, consequentemente, menores) são mais tolerantes ao erro (por falta de opção) que empresas maiores. Além disso, há poucos vícios a superar.

Para uma empresa grande inovar, precisa voltar a funcionar com a agilidade de uma empresa pequena.

Concluindo..

Um ambiente inovador é aquele que permite que pessoas compartilhem seus insights (metades de boas idéias). Além disso, é um ambiente disciplinado (não burocrático) voltado a definição de uma proposta de valor clara, que se preocupa com monetização e execução. Se for uma empresa grande, talvez precise pensar em “separar” o negócio novo.

Inovação depende de tudo isso. E é só o começo…

Por agora, era isso.

E você, o que acha?!

Outro dia, falamos sobre como aumentar a flexibilidade de nossos sistemas usando “Pipes and Filters”. Também exploramos alternativas para aumentar integração e escalabilidade através de “Message Routers”

Nesse post, continuo explorando alternativas arquiteturais de integração (e mensageria) para EIP, através de “Message Translators”.

Este pattern também está descrito no excelente livro Enterprise Integration Patterns.

O que é um Message Translator?!

Um “Message Translator” é um tipo especial de filtro (veja Pipes and Filters) que converte mensagens representadas em um determinado formato para outro. Assim, ampliamos as possibilidades de integração enre aplicações.

Com alguma abstração, podemos assumir que este padrão é equivalente ao Adapter descrito pelo GoF. Veja:

Ou seja,

• temos uma Message Queue com dados em determinado formato;
• temos um “Filtro” (unidade de processamento);
• temos um “resultante”, a mensagem traduzida, sendo produzida pelo “translator” e encaminhada para uma Queue de destino.

Implementando

Como já disse, um Message Translator, na prática, é apenas um tipo especial de filtro. Por isso, a classe abstrata que definimos outro dia continua válida. Relembrando:

using System;
using System.Messaging;

namespace MSMQ.PipersAndFilters
{
    public abstract class Filter
    {
        readonly MessageQueue inputQueue;
        readonly MessageQueue outputQueue;

        public Filter(MessageQueue input, MessageQueue output)
        {
            this.inputQueue = input;
            this.outputQueue = output;
        }

        public void Start()
        {
            this.inputQueue.ReceiveCompleted += OnReceiveCompleted;
            this.inputQueue.BeginReceive();
        }

        void OnReceiveCompleted(object sender, ReceiveCompletedEventArgs e)
        {
            var source = (MessageQueue)sender;
            var message = source.EndReceive(e.AsyncResult);
            message.Formatter = new XmlMessageFormatter(new [] { typeof(T) });
            this.outputQueue.Send(Process(message));
            this.inputQueue.BeginReceive();
        }

        protected abstract Message Process(Message original);
    }
}

Para implementar um translator, nesse cenário, basta implementar o método Process adequadamente. Perceba:

using System;
using System.Messaging;

namespace MSMQ.PipersAndFilters
{
    public class ContertStringToRichDataFilter :
        Filter
    {
        public ContertStringToRichDataFilter(MessageQueue input, MessageQueue output) :
            base(input, output)
        {}

        protected override Message Process(Message original)
        {
            var s = (string)original.Body;
            return new Message(
                new RichData(s) 
                );
        }
    }

    public class RichData
    {
        private RichData()
        {}

        public RichData(string data)
        {
            this.Data = data;
            this.Length = data.Length;
        }

        public string Data { get; set; }
        public int Length { get; set; } 
    }
}

Era isso!

Depois de muitos posts em C#, alguma coisa em Javascript, voltemos a falar um pouco sobre C++.

Nesse post, mostro como definir structures. Se desejar, consulte os posts anteriores da série.

Structures?!

Um structure é um tipo que podemos definir usando a palavra-chave struct (por isso, muitas vezes, chamamos struct e não structure). Surgiu na linguagem C e foi incorporada e ampliada em C++.

Aliás, em C++, podemos utilizar, sem prejuízos, classes no lugar de Strucutures. Entretanto, devido a grande quantidade de código legado (principalmente programação Windows), ainda é amplamente utilizada.

Em uma structure, podemos combinar conjuntos de dados.

Definindo um struct (exemplo simples)

Definir um struct é muito simples. Veja:

struct PERSON
{
	char Name[50];
	int Age;
};

Simplificando (muito talvez), reunimos um conjunto de “declarações de variáveis” dentro de um bloco identificado como struct. Cada “variável” definida é chamada, dentro de um struct, de campo.

Inicializando um Struct

A forma mais simples de atribuir valores aos “campos” de um struct é em sua inicialização. Acessar esses dados é simples (principalmente se você já usa C#). Observe:

#include 

struct PERSON
{
	char Name[50];
	int Age;
};

void main(void)
{
	PERSON p = {
		"Elemar Jr",
		32
	};

	std::cout << "Hello World, " << 
		p.Name << 
		std::endl;
}

Perceba:

• os valores para os campos da struct são passados “um-por-um”, em sequência (a mesma dos atributos), entre chaves “{}”;
• para acessar o valor de um campo, usamos a notação <variável>.<campo>;

Se desejar, pode ignorar a inicialização e simplesmente atribuir valor para os campos:

#include 

struct RECTANGLE
{
	int Top;
	int Left;
	int Width;
	int Height;
};

void main(void)
{
	RECTANGLE r1 = {0, 0, 50, 200};
	RECTANGLE r2;
	r2.Top = 10;
	r2.Left = 40;
	r2.Width = 200;
	r2.Height = 300;

	std::cout << "R1 T:" << r1.Top 
		<< ", L: " << r1.Left
		<< ", H:" << r1.Height 
		<< ", W:" << r1.Width
		<< std::endl;

	std::cout << "R2 T:" << r2.Top 
		<< ", L: " << r2.Left
		<< ", H:" << r2.Height 
		<< ", W:" << r2.Width
		<< std::endl;
}

Structs e ponteiros

Structs, por default, são value-types. Observe:

#include 

struct RECTANGLE
{
	int Top;
	int Left;
	int Width;
	int Height;
};

void main(void)
{
	RECTANGLE r1 = {0, 0, 50, 200};
	RECTANGLE r2 = r1;

	std::cout 
		<< "R1 Address: " << &r1 << std::endl
		<< "R2 Address: " << &r2 << std::endl;
}

A execução desse aplicativo mostra que r1 e r2 ocupam posições diferentes na memória. Se desejarmos compartilhar o mesmo “valor”, usamos ponteiros (que tal dar uma olhada na parte 4?!). Observe:

#include 

struct RECTANGLE
{
	int Top;
	int Left;
	int Width;
	int Height;
};

void main(void)
{
	RECTANGLE r1 = {0, 0, 50, 200};
	RECTANGLE* r2 = &r1;
	(*r2).Top = 10;

	std::cout << "R1 T:" << r1.Top 
		<< ", L: " << r1.Left
		<< ", H:" << r1.Height 
		<< ", W:" << r1.Width
		<< std::endl;

	std::cout << "R2 T:" << (*r2).Top 
		<< ", L: " << (*r2).Left
		<< ", H:" << (*r2).Height 
		<< ", W:" << (*r2).Width
		<< std::endl;
}

A execução desse program mostra r1 e r2 compartilham o mesmo valor.

Era isso!

Continuando nossas discussões sobre mensageria, minha proposta para esse post é discutir mais um importante pattern: Message Router.

O fundamento desse pattern consiste em transferir mensagens de uma determinada Queue para outras segundo um critério, sem alterar as mensagens. Sua aplicação é ampla. Podemos considerar esse pattern tanto em sistemas mais simples de mensageria (usando MSMQ, por exemplo), quanto em sistemas mais robustos (em ambientes no Windows Azure).

Esse pattern pode ser combinado com “Pipers And Filters” (apresentei implantação no post anterior).

Cenário mais simples: Transferência de Queue (um-para-um)

O cenário mais simples para um Message Router é a transferência de uma mensagem de uma Queue para outra.

O ícone que estou usando na ilustração foi sugerido no livro Enterprise Integration Patterns na descrição desse padrão. Eis a implementação simples:

using System;
using System.Messaging;

namespace MSMQ.MessageRouters
{
    public sealed class SimpleMessageRouter
    {
        readonly MessageQueue inputQueue;
        readonly MessageQueue outputQueue;

        public SimpleMessageRouter(MessageQueue input, MessageQueue output)
        {
            this.inputQueue = input;
            this.outputQueue = output;
        }

        public void Start()
        {
            this.inputQueue.ReceiveCompleted += OnReceiveCompleted;
            this.inputQueue.BeginReceive();
        }

        void OnReceiveCompleted(object sender, ReceiveCompletedEventArgs e)
        {
            var source = (MessageQueue)sender;
            var message = source.EndReceive(e.AsyncResult);
            this.outputQueue.Send(message);
            this.inputQueue.BeginReceive();
        }
    }
}

Esse pattern ajuda quando precisamos “ampliar” sistemas legados. Movimentando mensagens entre Queues, podemos compatibilizar/integrar sistemas que não compartilhem a mesma estrutura.

Direcionamento condicional (If-Else)

Em sistemas mais complexos, podemos desejar que mensagens sigam fluxos de processamento diferentes. Podemos considerar desvios de acordo com o conteúdo da própria mensagem ou conforme determinadas condições do ambiente. Em qualquer um desses cenários, podemos associar um predicado as mensagens que, de acordo com sua realização, encaminhe-as para Queues adequadas. Observe:

Aqui, a implementação em C#.

using System;
using System.Messaging;

namespace MSMQ.MessageRouters
{
    public sealed class IfMessageRouter
    {
        readonly MessageQueue inputQueue;
        readonly Predicate condition;
        readonly MessageQueue ifTrueQueue;
        readonly MessageQueue ifFalseQueue;

        public IfMessageRouter(MessageQueue input, 
            Predicate condition,
            MessageQueue ifTrue,
            MessageQueue ifFalse
            )
        {
            this.inputQueue = input;
            this.condition = condition;
            this.ifTrueQueue = ifTrue;
            this.ifFalseQueue = ifFalse;
        }

        public void Start()
        {
            this.inputQueue.ReceiveCompleted += OnReceiveCompleted;
            this.inputQueue.BeginReceive();
        }

        void OnReceiveCompleted(object sender, ReceiveCompletedEventArgs e)
        {
            var source = (MessageQueue)sender;
            var message = source.EndReceive(e.AsyncResult);

            if (this.condition(message))
                SendTrue(message);
            else
                SendFalse(message);

            this.inputQueue.BeginReceive();
        }

        void SendTrue(Message message)
        {
            if (this.ifTrueQueue != null)
                this.ifTrueQueue.Send(message);
        }

        void SendFalse(Message message)
        {
            if (this.ifFalseQueue != null)
                this.ifFalseQueue.Send(message);
        }
    }
}

Perfeito. Continuando na linha de exemplos que mostrei nos post anterior, adiciono um condicional para que apenas mensagens começando com “A” sejam encaminhadas. Observe:

using System;
using System.Messaging;

namespace MSMQ.MessageRouters
{
    class Program
    {
         static void Main(string[] args)
        {
            Console.Title = "If Message Router";

            Predicate startsWithA = (message) =>
            {
                message.Formatter = new XmlMessageFormatter(new[] { typeof(string) });
                return (((string)message.Body).StartsWith("A")) ;
            };

            new IfMessageRouter(
                GetMessageQueue(@".\private$\sample_queue"),
                startsWithA,
                GetMessageQueue(@".\private$\sample_transformed"),
                null
                ).Start();

            Console.WriteLine("Press ENTER to exit");
            Console.ReadLine();
        }

        static MessageQueue GetMessageQueue(string name)
        {
            if (MessageQueue.Exists(name))
                return new MessageQueue(name);
           
            return MessageQueue.Create(name);
        }
    }
}

É um exemplo bem simples (lembre-se que mensagens raramente serão strings, como indicado aqui). Mas, dá para reproduzir facilmente.

Direcionamento condicional (Case)

Condicionals If-Else podem se tornar custosos. Principalmente, por poderem exigir etapas e Queues adicionais. A solução está em suportar Cases.

Agora, a implementação em C#:

using System;
using System.Messaging;
using System.Collections.Generic;

namespace MSMQ.MessageRouters
{
    public sealed class CaseMessageRouter
    {
        readonly MessageQueue inputQueue;
        readonly Func evaluationFunc;
        readonly Dictionary caseQueues;
        readonly MessageQueue defaultQueue;

        public CaseMessageRouter(
            MessageQueue input, 
            Func evaluationFunc,
            Dictionary caseQueues,
            MessageQueue defaultQueue
            )
        {
            this.inputQueue = input;
            this.evaluationFunc = evaluationFunc;
            this.caseQueues = caseQueues;
            this.defaultQueue = defaultQueue;
        }

        public void Start()
        {
            this.inputQueue.ReceiveCompleted += OnReceiveCompleted;
            this.inputQueue.BeginReceive();
        }

        void OnReceiveCompleted(object sender, ReceiveCompletedEventArgs e)
        {
            var source = (MessageQueue)sender;
            var message = source.EndReceive(e.AsyncResult);
            
            var key = this.evaluationFunc(message);

            if (this.caseQueues.ContainsKey(key))
                this.caseQueues[key].Send(message);
            else
                this.defaultQueue.Send(message);

            this.inputQueue.BeginReceive();
        }
    }
}

Era isso!

Tornar nossas aplicações escaláveis é um grande (e importante) desafio. A abordagem mais comum passa pela decomposição de grandes atividades em “tarefas” menores que possam ser executadas com independência de estado.

Um dos patterns arquiteturais mais comuns para esse desafio é o “Pipes and Filters” (que já foi discutido amplamente em outro post). A implementação desse pattern pode ser muito simplificada através da adoção de Message Queues (comuns para MSMQ e Azure), como pipes, e a implementação de “unidades de processamento”, como filters.

Endentendo um pouco mais o cenário

Imagine que você esteja processando solicitações de geração de mídia personalizada (como ocorre no site da Safari Books, por exemplo). A geração de um “pdf personalizado” incorre em diversas etapas de processamento que podem ser fracionadas. Observe:

Essa abordagem permite que essas etapas de processamento possam ser paralelizadas. Veja:

Como o “Process A” não precisa esperar que seus subsequentes concluam suas atividades, pode atender uma nova solicitação. Na próxima vez que concluir, precisa apenas colocar a atividade na  “sua” Queue de tarefas concluídas. Ela será processada assim que o processo relacionado estiver pronto.

A capacidade e “velocidade” de processamento tenderá para a do “Filter” mais lento (em atividades em “cadeia” a performance da corrente inteira é determinada pelo elo mais fraco). Sabendo disso, podemos escalar pontos específicos minimizando impactos e maximizando o resultado.

Sou fascinado pela Teoria das Restrições (você é?). Mas esse seria um tema para outro post.

Implementando um “Filter” abstrato usando MSMQ

Interagir com o MSMQ, como indicado no post anterior é muito simples. Entretanto, podemos generalizar (e facilitar) a criação de filters. Observe:

using System;
using System.Messaging;

namespace MSMQ.PipersAndFilters
{
    public abstract class Filter
    {
        readonly MessageQueue inputQueue;
        readonly MessageQueue outputQueue;

        public Filter(MessageQueue input, MessageQueue output)
        {
            this.inputQueue = input;
            this.outputQueue = output;
        }

        public void Start()
        {
            this.inputQueue.ReceiveCompleted += OnReceiveCompleted;
            this.inputQueue.BeginReceive();
        }

        void OnReceiveCompleted(object sender, ReceiveCompletedEventArgs e)
        {
            var source = (MessageQueue)sender;
            var message = source.EndReceive(e.AsyncResult);
            message.Formatter = new XmlMessageFormatter(new [] { typeof(T) });
            this.outputQueue.Send(Process(message));
            this.inputQueue.BeginReceive();
        }

        protected abstract Message Process(Message original);
    }
}

Basicamente, esse filtro permanece “ouvindo” a Queue “input” indefinidamente. Cada vez que uma mensagem é recebida, é processada e encaminhada para a Queue “output”.

Para criar um exemplo simples, considere que desejemos converter todas as mensagens colocadas na Queue para maiúsculo:

using System.Messaging;

namespace MSMQ.PipersAndFilters
{
    public class ToUpperFilter : Filter
    {
        public ToUpperFilter(MessageQueue input, MessageQueue output) :
            base(input, output)
        {}

        protected override Message Process(Message original)
        {
            var s = (string) original.Body;
            return new Message(s.ToUpper());
        }
    }
}

Bacana, não. Por fim, veja como é simples colocar esse filtro para funcionar:

using System;
using System.Messaging;

namespace MSMQ.PipersAndFilters
{
    class Program
    {
         static void Main(string[] args)
        {
            Console.Title = "Filter";

            new ToUpperFilter(
                GetMessageQueue(@".\private$\sample_queue"),
                GetMessageQueue(@".\private$\sample_transformed")
                ).Start();

            Console.WriteLine("Press ENTER to exit");
            Console.ReadLine();
        }

        static MessageQueue GetMessageQueue(string name)
        {
            if (MessageQueue.Exists(name))
                return new MessageQueue(name);
           
            return MessageQueue.Create(name);
        }
    }
}

Esse “filtro” interage perfeitamente com o exemplo do post anterior. Acho que você pegou a idéia.

Perceba que essa implementação não suporta transações (o que não é bom no mundo real). Mas, esse, é tema para outro post.

Por agora, era isso!

Integrar aplicações não é tarefa fácil. Há diversas alternativas. Entretanto, as mais atraentes envolvem a utilização de algum tipo de mensageria.

No “mundo Microsoft”, a alternativa mais comum é a utilização do MSMQ (Microsoft Messaging Queuing), que está na versão 5.0. Em .NET, a interface com essa tecnologia pode ocorrer tanto através de WCF quanto pela API disponível na DLL System.Messaging.

Este é apenas o primeiro de muitos posts que pretendo escrever sobre padrões de integração. Minha intenção é demonstrar todos aqueles descritos no excelente livro “Enterprise Integration Patterns” de Gregor Hohpe e Bobby Woolf.

Antes de começar

O MSMQ é forncecido como um “componente” do sistema operacional. Para utilizar este componente, antes, precisamos habilitá-lo apropriadamente.

Fazendo isso, poderemos “monitorar” (e interferir) no funcionamento do componente no “Management Console”

Pegando a idéia básica

O conceito básico do MSMQ envolve em aplicações trocando mensagens. Vejamos a explicação disponível no MSDN.

Message Queuing (MSMQ) technology enables applications running at different times to communicate across heterogeneous networks and systems that may be temporarily offline. Applications send messages to queues and read messages from queues. The following illustration shows how a queue can hold messages that are generated by multiple sending applications and read by multiple receiving applications.

A segurança e confiabilidade dessa solução a credencia como alternativa interessante para comunicação entre aplicações.

Pensando em Arquitetura

Em sua forma mais básica, a arquitetura de uma aplicação com suporte a mensageria se baseia no relacionamento de apenas três componentes:

1. Sending Application (Publisher)
2. Message Queue – fornecida completamente pelo MSMQ
3. Receiving Application (Subscriber)

Entretanto, podemos projetar soluções mais ricas. Entre as opções arquiteturais mais frequentes, encontramos:

• Múltiplos publishers;
• Múltiplos subscribers;
• Múltiplas Queues;
• Pipes e Filtros;
• Tratadores de falha (com filas de falha, inclusive);
• Roteadores;
• Tradutores (mudando o formato da mensagem);
• Adaptadores, Bridges e Bus;
• etc.

Cada uma dessas “opções” permite discussão rica que faremos com cuidado em momentos oportunos. Além disso, quase todos os padrões envolvendo Queues facilitam o desenvolvimento de soluções escaláveis.

Exemplo simples para envio de mensagens

Escrever um programa para enviar mensagens para uma Queue é algo bem simples. O exemplo que apresento aqui é uma aplicação console que envia toda digitação do usuário (após o Enter). Observe:

using System;
using System.Messaging;

namespace MessageSender
{
    class Program
    {
        const string queue_name = @".\private$\sample_queue";

        static void Main(string[] args)
        {
            Console.Title = "Sender";
            
            MessageQueue queue;
            if (MessageQueue.Exists(queue_name))
                queue = new MessageQueue(queue_name);
            else
                queue = MessageQueue.Create(queue_name);

            while (true)
                queue.Send(Console.ReadLine());
        }
    }
}

Consideremos:

• Para utilizar o suporte a Messaging do .NET (MSMQ), precisamos adicionar uma referência para System.Messaging;
• Precisamos criar (ou abrir) uma queue de trabalho. Para isso, precisamos informar a “máquina” onde ela deverá ser criada (Por agora, deixemos esse “detalhe” para uma discussão futura);
• Utilizamos o método Send para enviar mensagens. Podemos enviar (quase) qualquer objeto (precisa ser serializável) para a Queue;

Veja a execução:

No exemplo, enviei três mensagens para a Queue (que criamos). Consultando o Console Management, podemos confirmar isso. Observe:

Exemplo simples para recebimento de mensagens

Escrever programas para receber mensagens também é bastante simples. Observe:

using System;
using System.Messaging;

namespace MessageReceiver
{
    class Program
    {
        const string queue_name = @".\private$\sample_queue";
        static void Main(string[] args)
        {
            Console.Title = "Receiver";

            var queue = new MessageQueue(queue_name);
            queue.Formatter = new XmlMessageFormatter(new [] { typeof(string) });

            while (true)
                Console.WriteLine("Received: {0}", queue.Receive().Body);
        }
    }
}

Consideremos:

• Para utilizar o suporte a Messaging do .NET (MSMQ), precisamos adicionar uma referência para System.Messaging;
• Precisamos abrir uma queue de trabalho.
• O tipo do objeto no “corpo da mensagem” deverá ser informado em um Formatter que será utilizado pela infra para “recriar” objetos enviados na mensagem. No exemplo que estou apresentando, usamos string
• Utilizamos o método Receive para receber mensagens (retirando-as da Queue). Por default, esse método “interrompe” a execução até que uma mensagem esteja disponível. Há outras sobrecargas para esse método que permitem que informemos um tempo limite de espera. Há também o método Peek que não retira a mensagem da fila;

Executando esse programa, temos:

Monitorando o status da queue, percebemos que todas as mensagens foram retiradas.

Já temos um bom começo.

Era isso.

Há pouco tempo revisei uma de minhas crenças mais enraizadas: pessoas têm dificuldades em aceitar mudanças!

Durante muito tempo assumi que, se há uma mudança, há resistência. Se as pessoas conquistaram uma “zona de conforto”, não vão aceitar qualquer coisa que as retire dessa posição.

Lendo Dostoiévski, entendi que as pessoas se acostumam a tudo, até mesmo a viver mal. Mais que isso, as pessoas defendem esse “mal viver”.

Pensava tudo isso. Não penso mais! aceito que exista algum “fundamento” psicológico nessa linha de pensamento. Entretanto, penso que, com mais frequência do que gostaríamos de reconhecer, trata-se apenas de uma saída fácil para nossa dificuldade em articular e argumentar defesas de nossas idéias.

O problema da abordagem

Toda vez que pensamos em uma mudança que implique na alteração das rotinas/modelos mentais de outras pessoas, costumamos (pelo menos, eu), inicialmente, ser otimistas demais quanto a suas reações. Assumimos que basta apresentar a “qualidade” de nossas idéias para que essas sejam aceitas imediatamente.

Quando as pessoas apresentam obstáculos para realizar as mudanças, falamos que estão resistindo (e que isso é natural). Assim, vivemos em um ciclo vicioso de falsa aceitação da resitência alheia e tolerância para a nossa própria incompetência.

Atualmente, penso que há um problema sério na abordagem de nossas propostas de mudança. Para mim, é isso que precisamos rever.

O que costumamos ignorar?

Penso que o o otimismo demasiado com novas idéias é o principal obstáculo para suas realizações. Ou seja, quando apresentamos (e defendemos) nossas idéias, habitualmente, pensamos apenas nas vantagens/facilidades resultantes da mudança. Entretanto, penso que deveríamos pensar em, pelo menos, quatro perspectivas. São elas:

1. O que há de bom em mudar?
2. O que há de ruim em mudar?
3. O que haveria de bom em não mudar?
4. O que haveria de ruim em não mudar?

Perceba, defendo que pensemos nos aspectos positivos/negativos de mudar E de não mudar!

Além disso, para termos sucesso, penso que devemos tentar praticar um pouco de empatia. Assim, devemos tentar responder a essas questões conforme nossa “posição” e conforme a posição daqueles que desejamos/precisamos envolver nas mudanças. Dessa forma, conseguimos “firmar” nossa posição e achar boas respostas para o “Sim, mas…”.

Um exemplo prático (e, infelizmente, comum): adoção de testes de unidade automatizados

Apenas para ilustrar meu ponto de vista, considere esse cenário/rotina comum:

1. Programador vai a um evento e ouve falar sobre testes de unidade automatizados;
2. Superados os receios iniciais, absorvido nos excelentes argumentos de outros programadores mais experientes (!?), fica convencido de que conseguirá melhorar muito seu código escrevendo testes de unidade;
3. Programador volta para casa e “estuda um pouco” sobre como escrever testes;
4. Empolgado, programador tenta convencer a seus colegas e superiores das maravilhas da escrita dos testes de unidade;
5. Programador fica surpreso com a resistência dos colegas e superiores (maior resistência dos superiores, em teoria. maior resistência dos colegas, na prática);
6. Programador fica desanimado e desiste dos testes de unidade;
7. Programador reclama que seu chefe e/ou seus colegas não têm maturidade (senioridade) para implantar testes.

Por que será que isso ocorreu? Atualmente, penso que o problema esteja relacionado a uma abordagem errada. Talvez, o problema esteja em realçar demais “o que há de bom em mudar”. Mas, considere, será que estamos preparados para argumentar sobre:

• os aspectos (aparentemente) ruins da mudança, como, por exemplo:
• tempo/esforço/custo adicionais (aparentes, ou não), relacionados a escrever e manter mais código (os testes de unidade)?
• as dificuldades inerentes a garantir mais “testabilidade”, sobretudo em código legado?
• o esforço relacionado a “capacitação” adicional da equipe?
• os aspectos (aparentemente) bons de “não mudar”, como, por exemplo:
• a manutenção do estado (e processos) atuais;
• os aspectos (aparentemente) ruins em “não mudar” – consequências em manter as coisas como estão (quem sabe, pensar um pouco mais sobre entropia)

Além disso, será que praticamos um pouco de empatia? Consideramos falar em termos de custo para quem está interessado em maximizar o “retorno sobre o investimento”?

Enfim, penso que, contrariando o senso comum, as pessoas estão dispostas a mudar! O problema é que, talvez, estejamos sendo pouco esforçados/persistentes e abrangentes em nossas argumentações.

O que você acha?

Era isso!