SOA, Simples Assim!

Em 1926, George Taylor, um economista americano,  formulou a teoria do “Hemline Index“. A teoria correlaciona o comprimento dos vestidos da mulheres com a saúde da economia: quanto mais curto o vestido/saia, mais forte a economia.

Nos anos 40-50 a moda eram saias longas, até o tornozelo. A exuberância dos anos 60 veio com os mini-vestidos e o surgimento das mini-saias. A recessão e a crise do petróleo nos anos 70 aumentou o comprimento da roupa feminina, que diminui novamente no início dos anos 80. Na recessão que iniciou em 1987, fez com que a moda das longas saias e vestidos aumentasse novamente, até serem reduzidas novamente nos anos 90. No mínimo é uma estranha coincidência, certo?

Esta teoria foi validada e revista por Terry Pettijohn, um professor de psicologia na universidade da Carolina (EUA) e por vários outros pesquisadores e institutos de pesquisa de comportamento de consumo. Um resumo muito interessante está resumido neste artigo do jornal New York Times, de agosto de 2008. Desmond Morris utilizou esta teoria como base do seu livro “The Naked Ape“.

Nosso comportamento muda muito de acordo com a situação econômica. Isto já é um fato comprovado. A venda ou não de alguns itens só pode ser explicado por estes “up” e “down” da economia.

O que isto tem a ver com java?

Rod Johnson é um dos líderes da comunidade Java e Java EE. Ele é autor de livros importantes como “Expert One-on-One J2EE Design and Development (2002)“, “J2EE without EJB (Julho 2004, com Juergen Hoeller)“, “Professional Java Development with the Spring Framework (Julho, 2005)”.

Mais um detalhe. Ele é o idealizador do Spring Framework, indiscutivelmente, um dos melhores frameworks Java.

Foi ele quem apresentou um o gráfico ao lado que, utilizando o “Hemline Index“, expõe seu ponto de vista na tentativa de explicar, porque a plataforma Java tornou-se tão complexa.

Veja como temos uma tendência a complicar as coisa – como o comprimento longo das saias femininas -, quando a economia vai mau. E a complexidade diminui nas crises, como esta de 2008/2009.

Ele apresentou suas idéias durante o evento QCon, London 2009. É uma palestra de  pouco mais de 1 hora onde ele explica, com exemplos, alguns motivos que inseriram complexidade na plataforma Java.

Uma das razões é a abordagem de decisão por comitês, utilizado na JCP, que precisa “dar a benção” em toda mudança na linguagem.

Antes de mais nada, eu concordo com o ponto de vista colocado na apresentação. Não leve em conta minha opinião, ou mesmo do autor da apresentação: veja os fatos, os argumentos e tire suas próprias conclusões.

Meus R$ 0,10 na discussão. Como tudo na vida, a decisão por comitês (innovation by committee) é um processo de “trade-off“: ao controlar e burocratizar todo o processo de mudança, eu estou permutando estabilidade por uma menor inovação. É assim com as decisões do JCP e de todo comitê que você criar na sua empresa para controlar mudança.

Veja que isto não é necessariamente ruim. O ponto da discussão não é este. Existem épocas em que as saias são longas e em outros elas são curtas. Mas, tudo tem seu preço. No caso da plataforma Java, o preço foi o incremento de uma complexidade desnecessária.

Você quer saber algumas das razões?

Assisti a palestra do Rod Johnson e fiz um resumo. Se você se interessa pelo assunto, assista a palestra (1h 3min) ou leia meu resumo a seguir.

Que lições podemos tirar dos últimos 10 anos de desenvolvimento da linguagem Java?

Foi assim que R. Johnson iniciou sua palestra. Vou resumi-la em forma de bullets para simplificar a leitura.

Que lições podemos tirar dos erros no desenvolvimento da plataforma Java nos últimos 10 anos?

Dois fatores se destacam:

- O poder que os desenvolvedores tiveram com Java
- Flutuações na economia
- Java iniciou como uma linguagem fácil (ao contrário do que muitos acham), era como “C++–”. Mesmo hoje ainda é simples.
- O DNA de Java é a simplicidade
- O problema não é a linguagem em si. A complexidade foi introduzida ao longo do caminho

Um dos erros foi trazer o “Enterprise” para a linguagem. À esta palavras, em qualquer abordagem, está associada a complexidade. Quem se lembra das “Entity Beans”?

- A complexidade da indústria. Grandes companhias, como IBM, terem “abraçado” Java também tem pontos negativos. “É simplesmente impossível IBM adotar uma tecnologia e não complica-la”, de acordo com R. Johnson
- Abordagem “No pain no gain” (convenhamos, isto é uma falácia)
- Era legal ser complexo. Como desenvolvedor sou diferenciado (isto valeu no início)

Como J2EE evolui para Java EE

- Nos anos 90 Java começou a migrar para o servidor.
nota do autor do blog: Você já programou um “Applet”? Eu já! E utilizava o Notepad! (como sofremos…)
-Não existia muita “regulamentação” para a linguagem (nem havia muitas razões para)
-Ambiente de muita competição: ToLink, Apple WebObjects etc

O Bom e o Ruim

- Muita inovação, muitas opções (bom)
- Mercado de “server-side” era muito fragmentado (bom)
- Risco de ficar “preso” a um fornecedor (ruim)
- Muitas soluções caras (preço da inovação, ruim)

1999 – 2003

- Especificações começam: JCP
- Non-standard não podiam competir com uma plataforma J2EE padronizada:
- ORM versus EJB entity beans
- Velocity versus JSP
- WebObjects versus web tier

1999 – 2003: Bom e Ruim

- Cria-se um grande mercado
- Fornecedores com opções fechadas diminuiram, mas não foram eliminados
- Controle (JCP) estrangula a Inovação
- Idéia de que todos os business objects (EJB) deveriam ser distribuídos
- 2003: início de aplicações Java “leves” (lighter-weight solutions). Exemplo: a adoção em massa do Tomcat
- Os projetos open-source ajudaram a definir o futuro da plataforma e trouxeram inovação: Eclipse, Spring, AspectJ

As “armadilhas” ou Ideas que trouxeram complexidade no J2EE

- Design by committee: tudo precisava ser padronizado. JCP fala de forma privada; composto de grandes fornecedores de software
- Ferramentas que traziam excessiva complexidade
- Não abertura para outras plataformas, a abordagem “Java puro sangue”
- “Desenvolvedores são estúpidos e devem ser controlados”
- “Soluções complexas são melhores”
- “Eu preciso de uma solução que habilite minha arquitetura corporativa”

Os comitês queriam padronizar tudo em Java. Uma verdadeira obsessão do JCP. Citando, Jim Waldo, um engenheiro da Sun:

Reverenciando tudo de bom que os padrões nos trazem, eu acredito que, de certa forma, trazem um grande dano para nossa indústria e a ciência. Ele transforma discussões técnicas em debates políticos. Isto gerou um problema de entendimento do verdadeiro significado dos padrões. Pior de tudo, nos levou a fazer escolha tecnológicas absurdas, que nunca haviam sido implementadas e que não eram a escolha adequada para os problemas que tínhamos em nossas mãos

Exemplos do que foi dito acima:
- CORBA (1990s)
- CMP entity beans
- Muitos ignoraram o sucesso do “TopLink”

O bom exemplo do Linux

Linux é um exemplo de inovação que não fica restrita aos processos de padronização, que são restritos ao Kernel. Na minha opinião, se o processo de desenvolvimento do Linux fosse semelhante ao do Java não teríamos uma distribuição como o Ubuntu.

Qual deveria ser o papel do JCP?

Criar um “mercado” onde as inovações podem ser desenvolvidas a partir dos padrões. Inovação a partir de comitês (innovation by committee), historicamente, produzem resultados medíocres.

Por que a complexidade é “boa”?

- Temos uma tendência natural de achar que “sem dor não haverá ganhos”, ou o adágio “no pain no gain”
- Síndrome da “Nova Roupa do Imperador”, ou seja, “não entendi muito bem, é muito complexo, então deve ser bom!”

“É a economia, estúpido!”

[nota do autor do blog: você já leram várias vezes esta frase aqui. E ela é citada por Rod Johnson como um dos motivos de mudanças no horizonte da complexidade. Veja o post sobre a versão 6 da plataforma Java]

- Em um cenário de pós-recessão temos que repensar os investimentos. Economia, economia.
- “Hemline Index”
Economista americano, George Taylor (1926). Relacionou a “exuberância irracional” de nossas ações (pessoas e empresas), com a exuberância da economia.

Inovações da comunidade que fizeram diferença

- Spring
- Hibernate
- Ruby on Rails
- Django
- Grails

Da comunidade open-source para simplificar a vida dos desenvolvedores!

Previsões

- Não teremos um retrocesso para um sistema com complexidade desnecessária
- Portfolio complexos não tem mais espaço. Foco na agilidade, simplicidade. Economia, economia.
- Processo Ágeis vieram para ficar
- Desenvolvedores ainda terão, e precisarão ter mais poder e mais responsabilidades
- Ainda é necessário termos uma plataforma Java que permita uma maior produtividade
- Tradicionais aplicações residentes no servidor cairão em desuso

Resumo

- A pessoa-chave para as mudança é o desenvolvedor
[nota do autor do blog: o desenvolvedor, o arquiteto tem que exercitar o Pensamento Crítico e não aceitar a complexidade simplesmente porque algum comitê, mesmo que seja o JCP, assim o definiu]
- Veja as alternativas, simplifique, estude e tire suas próprias conclusões. Não utilize uma solução porque alguém decidiu que esta é “a” solução

Este post traz duas boas notícias para o mundo da “Cloud Computing”. A primeira é o anúncio da empresa de soluções SOA open-source, WSo2, já citada várias vezes neste blog, e a outra vem da Microsoft e de sua plataforma de Cloud, Azure.

WSo2 Lança sua Plataforma de “Cloud Computing”

Para quem não conhece, a WSo2 é uma companhia que desenvolve soluções para a arquitetura orientada a serviços (SOA) no modelo open-source. Tem escritório no longíquo Sri Lanka (terra natal do seu fundador) e nos EUA e Europa.

A plataforma de “Cloud Computing” que eles lançaram permite que as empresas criem sua própria “nuvem”, as chamadas “Private Clouds“, com um custo (direto) de software bastante reduzido.

A solução de Governance as a Service é um dos serviços já disponíveis para serem utilizados (veja restrições abaixo).

A idéia é que sua empresa possa fazer o setup de uma solução de Governança para o ambiente SOA (SOA Governance Registry) diretamente na “nuvem” da WSo2.

Veja o que é possível implementar:

- Armazenar services, WSDLs, Schemas e policies, facilitando a descoberta (discovery) dos serviços e suas restrições

- Gerenciar o ciclo de vida dos serviços
- Manter múltiplas versões dos serviços

- Acompanhar as dependências e associações entre os WSDLs e os Schemas

- Dar permissões apropriada para os usuários

As restrições para utilização são:

• até 5 usuários
• não mais do que 100 recursos armazenados
• não mais do que 100 recursos acessados / dia
• cada recurso pode ter, no máximo, 1 MB

E estão preparando o lançamento do 2o. produto: “Indentity as a Service”!

Importante: como informou esta notícia da InformationWeek USA, o WSO2 suporta o uso de seu produto como uma “Amazon Machine Image“, o formato de máquina virtual do EC2/Amazon Cloud. É compatível também com “VMware ESX Server virtual machine” e, claro, no open source Linux KVM virtual machine.

A Cloud da Microsoft, Azure, agora pode rodar “Ruby on Rails”

A notícia vem do blog da Mary-Jo Foley. No final de Novembro (25/11/2009) o arquiteto da Microsoft, Simon Davies, anunciou que já tinha um exemplo do “Ruby on Rails” rodando em uma “nuvem” do Microsoft Azure (veja aqui “ao vivo”).

Em um movimento acertado, a Microsoft tem feito um esforço para que sua “nuvem” tenha compatibilidade com vários produtos e soluções open-source. Alguns exemplos de “Azure compatible” são:

• Ruby
• PHP e ferramentas baseada no Eclipse
• MySQL
• MediaWiki
• MemCached
• Tomcat
• SugarCRM tem sua versão para o Azure (!)

e claro, o seu “Service Bus and Access Control services”, antes conhecido como “.NET Services”, agora roda diretamente no Windows Azure e é chamado agora de “Windows Azure platform AppFabric Service” (nome nada fácil…). Mais detalhes aqui e aqui.

Como na discussão levantada no post da Mary-Jo, não imagino que exista motiva de desconfiança por trás desta iniciativa da Microsoft em suportar soluções open-source em sua “nuvem”.

No meu ponto de vista, não importa para o usuário, e até mesmo para o desenvolvedor, em que “nuvem” sua sua aplicação baseada no “Ruby on Rails” ou seu open-source SugarCRM, está sendo executado.

O que você acha?

Os produtos da Apple tem um design e uma interface de causar inveja a seua concorrentes, que tentam imitá-la desesperadamente. No caso do iPhone e iPod Touch, além do design, o fato de ter uma loja virtual com centenas de aplicações e da facilidade de adquiri-las, transformou o produto em um sucesso mundial.

Aqueles que tentam imitá-la, esquecem que competência estratégica não se copiam. Ou você desenvolve, ou você não tem.

Isto ajuda a explicar o fato de que usuários do iPhone gastam muito mais, por exemplo, com a compra de filmes: 73% contra 48% que utilizam outros smartphones.

Design, qualidade e interface amigável estão no sangue da companhia. Seu CEO, Steve Jobs, é obcecado pelos detalhes. Ele mandou os engenheiros voltarem para a prancheta até que o mecanismo da fonte do MacBook, que serve para enrolar o cabo de força, tivesse o som do “cliq” que ele queria ouvir. Você conhece algum CEO tão micro-gerente quanto este? Quando se trata de design ele contratou o mestre, o guru, Jon Ive.

Voltando para a nossa realidade

A simplicidade e facilidade de navegar em um sistema pode fazer toda a diferença na aceitação que ele terá entre os usuários. Se sua equipe não se preocupa com isto porque é um “problema para os designers”, e o sistema vai ser “empurado” para seus usuários de qualquer jeito, eu penso que cabe uma reflexão.

Sobre este assunto, um texto interessante vem do “97 Things” (“97 Things Every Software Architect Should Know“). Um dos axiomas é: Para o usuário final, a Interface É o sistema. Para quem faz a arquitetura e para aqueles que implementam a solução parece que não faz sentido algum nesta afirmação. Mas faz toda a diferença quando você é o usuário.

Alguns pontos importantes:

• Existem excelentes produtos “escondidos” atrás de péssimas interfaces (com o usuário final)
• É através da interface que o usuário vai ter toda a experiência (boa ou ruim) com todo o sistema; se esta experiência for ruim, não interessa se você está utilizando o estado da arte da arquitetura, os melhores patterns etc etc. Se a interface é ruim, o sistema é ruim (do ponto de vista de quem utiliza)
• Interface é um assunto quase sempre negligenciado pelos times de arquitetura. Adicione na sua lista: usabilidade, simplicidade, disponibilizar apenas a informação estritamente necessária
• Tenha interações e conversas com seu usuário final, veja como ele “opera” o sistema, dê importância à opinião dele. Sem ele, seu sistema não tem razão de existir

Abcs!

“The only real mistake is the one from which we learn nothing“

– John Powell, The Secret of Staying in Love (1990), p. 85

Se você se interessa por arquitetura de software, mais precisamente, sobre questões de escalabilidade de sistemas e soluções (software), o blog Highscalability.com é leitura obrigatória.

Algum tempo atrás eu li no blog acima um post muito interessante sobre a arquitetura de software do Twitter. O título é “Scaling Twitter: Making Twitter 10000 Percent Faster” e além da discussão de como foi a solução de arquitetura que permitiu que o Twitter ficasse 1,000% mais rápido (o post é de 27/06/2009), descreve detalhes de linguagem, tecnologias, problemas e soluções, enfim, uma aula de como funciona o “coração” de software do Twitter (lá quase tudo é open-source).

Não vou reproduzir em detalhes aqui, a leitura é interessante e valem os 10 minutos. O que me chamou a atenção na época foram as lições aprendidas em cada um dos projetos, que o autor apresenta no final do texto.

Estas informações são valiosas, priceless! Como afirmou John Powell (citado acima): “O único erro de fato é aquele do qual nada aprendemos“.

Você tem uma reunião de “lessons learned” no seu projeto? Não? Você e sua equipe estão perdendo uma excelente oportunidade de evoluir, de aprender com os erros e acertos e, principalmente, de não repetir os mesmos erros. Um conselho de amigo: invista alguns minutos com o grupo ao final de cada etapa do projeto e documente todas as abordagem que deram certos e aquelas que não devem ser repetidas (erros).

Vamos ao que interessa. Abaixo, bem resumido, reproduzo algumas “lessons learned” de dois projetos famosos: Twitter e Google Talk.

Twitter: Lições Aprendidas

1. Compartilhe idéias com outros (comunidade). Não se esconda e tente resolver o problema sozinho. Muitas pessoas brilhantes estão dispostas ajudar (você precisa pedir)
2. Encare seu planejamento de escalabilidade como um plano de negócio. Reuna um time de experts para ajudar você
3. Construa o que você precisa. O Twitter investiu muito tempo tentando soluções de terceiros que pareciam funcionar, mas não eram adequadas. Quando você mesmo desenvolve pelo menos você tem o controle e pode adicionar as funcionalidades que precisar
4. Pense em mecanismos de detecção de usuários com intenção de “derrubar” o sistema. Coloque limites de utilização de forma que nenhum deles, isoladamente, coloque seu sistema “no chão”
5. Não utilize o banco de dados como única alternativa de armazenamento. Nem tudo necessita de um “SQL join” gigante. Cache é a palavra mágica. Pense em formas alternativas de chegar no mesmo resultado, disponibilize dados em memória. Veja detalhes de como o Twitter fez isto neste link
6. Faça com que sua aplicação seja “modularizada” ou “particionável” desde o início. Você vai entender porque quando precisar escalar a mesma
7. Otimize o banco de dados: indexe tudo, faça um tunnig das queries, desnormalize
8. Teste tudo. Twitter tem agora uma suite de testes completa de forma que se ocorrer um problema de cache eles detectam o problema antes da nova versão ser liberada
9. Muitos problemas de performance não vem da linguagem, mas de como a aplicação foi projetada
10. Transforme o serviço do seu website em uma API aberta. Grande parte do sucesso do Twitter é graças à sua API. Isto permite que a comunidade crie inúmeros serviços e aplicativos com os quais será difícil para os concorrentes copiarem. Amazon e Google também fazem isto. Você nunca poderá fazer todo o trabalho sozinho, a criatividade do seu time tem limites.

Google Talk: Lições Aprendidas

1. Identifique corretamente o que deve ser mensurado. No caso do Google Talk, a questão principal não é saber quantos Instant Menssages (IMs) o sistema entrega ou quantos usuário ativos o sistema suporta. Por exemplo, uma parte complicada de um IM é como exibir o status de todos os usuários conectados. A conta não é linear: UsuáriosOnLine x ListaDeAmigos x MudançaDeStatusOnline. Uma grande lista de amigos (“buddy list”) é um problema a ser endereçado, a quantidade de IMs não é o problema
2. Simulação em “ambiente real”. Testes em ambiente controlado são bons mas não dizem muita coisa. Simule mudança de status por semanas e meses
3. Planejamento contra problemas operacionais. O que acontece quando os servidores são reinicializados e o sistema retorna com o cache vazio?
4. Um sistema “escalável” é um sistema distribuído. O que o Google fez foi adicionar tolerância a falhas em todo componente do sistema. Tudo pode falhar.

Alguns meses atrás, eu preparei a arquitetura simplificada acima para um trabalho no meu MBA no IBMEC São Paulo/INSPER. É apenas um exemplo de como uma arquitetura orientada a serviços (SOA) pode auxiliar em diversas aplicações de RFID. O objetivo foi apresentar uma solução para o rastreamento de cargas e bagagens aéreas utilizando tags RFID. Este tipo de solução já é utilizada em vários aeroportos e companhias aéreas no mundo. Veja um exemplo da United Airlines (Chicago, EUA) e da Air New Zealand (Nova Zelândia).

O Mercado mundial

A International Air Transport Association (IATA) estima que, por ano, as companhiam aéreas perdem US$ 3 a 4 bilhões/ano devido aos custos por extravio de bagagens. Em um cenário de pressão por redução de custos nas passagens, concorrência acirrada, reclamação dos clientes das longas filas nos balcões de check-in, eficiência operacional etc, fica claro que alguma ação precisa ser tomada para diminuir estes custos. É um investimento perdido e, pior, com “retorno negativo”, porque além dos problemas causados aos passageiros que tiveram sua bagagem extraviada, as empresas correm o risco de não ver nunca mais aquele passageiro em seus aviões.

Números, números…:

• IATA estima que quase 33 milhões de malas são extraviadas todo ano
• Este número representa algo próximo a 1.4% de todas as bagagens
• Custo médio por bagagem extraviada: $100

A presão por redução de custos operacionais é tão grande que lá fora as empresas cobram de US$ 15 a US$ 100 adicionais simplesmente para despachar a bagagem dos seus clientes. Se esta moda pega por aqui…

Uma das soluções pode ser a utilização de RFID. Na minha opinião os custos iniciais podem até serem relativamente altos, porém os ganhos em eficiência, confiabilidade e até mesmo retenção de clientes são enormes. Você volta a utilizar os serviços de uma companhia aérea se, frequentemente, sua bagagem é extraviada? Pouco provável, certo?

Importante: não se trata apenas de imprimir tags RFID e colocar nas bagagens (sim, hoje temos impressoras que imprimem as etiquetas de RFID). Existe todo um ambiente de sistemas tais como ERP, CRM, despacho de bagagens, que precisam ser integrados e em tempo real.

As tecnologias e decisões de arquitetura para estas situações envolvem o uso de:

• SOA
• CEP (Complex Event Processing)
• Event Stream Processing (ESP)
• Event-driven Architecture

Não se assuste com a “sopa de letras” acima. Todas as tecnologias são correlatas, se complementam para a construção de um “meio-ambiente” que permita operar de forma eficiente uma solução baseada em eventos.

Investimentos: o case da Air Zealand

A Air Zealand foi além do simples controle. Ela implantou kiosks (vide foto acima) onde os passageiros despacham suas bagagens devidamente identificada com tags RFID.

O investimento foi US$ 16.5 milhões. Com este valor a empresa:

• instalou 112 kiosks como este e
• mais 84 gate scanners que são os “leitores” de etiquetas dispostos em vários locais por onde é realizado o transporte e triagem das bagagens
• tudo isto foi implantado em 26 aeroportos onde a empresa opera

Com isto ela foi a 1a. companhia aérea a oferecer RFID-enabled self-scanned check-in. Você prefere isto ou enfrentar a fila nos balcões? Isto influenciaria a escolha da sua companhia aérea? Quanto tempo você economizaria?

Como SOA ajuda

A questão central é o controle mais eficiente das bagagens e cargas, agilidade, integração dos vários sistemas, e uma grande redução de custos. Todos ganham no processo, a companhia aérea, a empresa que administra os aeroportos mas, principalmente, o cliente.

Existem middlewares utilizados em arquitetura SOA que são específicos para tratar centenas de milhares de eventos como estes gerados por etiquetas RFID. SOA é uma abordagem ideal para tratar de eventos complexos e integração de ambientes heterogêneos, com custo relativamente baixo, sem necessidade de reescrever o legado. Por tudo isto SOA é uma excelente escolha.

No próximo post vou tratar dos middlewares que são específicos para tratamento de CEP em uma arquitetura SOA. Não perca!

Se você é familiar com os produtos da JBoss/Red Hat, já deve ter ouvido falar do JBoss Messaging (v 1.x). Como o nome diz é um middleware orientado a mensagens (ou MoM – Message-oriented Middleware), que era a solução de mensageria padrão do JBoss Enterprise Application Platform, JBoss SOA Platform e JBoss Application Server version 5.0.

O produto evoluiu e a versão 2.x ficou tão diferente do projeto original que eles decidiram dar um novo  nome para o produto: HornetQ.

Principais características

• como o projeto original do qual é originado, o HornetQ é open-source (Apache v 2.0 licence)
• roda em qualquer plataforma Java 5.x ou superior
• suporta JMS 1.1 API, apesar de ter uma API de mensagens proprietárias (que a JBoss alega que tem uma performance superior)
• provê sistema de mensagens persistentes com performance de MoM que trabalha com mensagens não persistentes (em memória)
• pode ser integrado com o JBoss Application Server ou com com outro Java server/container
• pode ser “empacotado”(embed) em sua própria aplicação (!)
• opção de alta disponibilidade (server replication e client failover)
• permite a criação de clusters (load balance, distribuição geográfica dos seus MoMs etc)
• “core” do produto baseado em Plain Old Java Objects (POJO)
• etc..

Arquitetura (high-level view)

Documentação

• Guia rápido (PDF), recomendo!
• Manual do Usuário (PDF)

MoM – Definição

Por fim, mas não menos importante, vamos a uma definição básica de um Message-oriented middleware (MOM).

Basicamente é uma solução de infraestrutura de software que recebe e envia mensagens. A arquitetura destas soluções tem um grande foco em questões relacionadadas a confiabilidade da entrega/envio das mensagens, interoperabilidade (“conversam” com vários protocolos) e portabilidade (ambientes altamente heterogêneos).

Na minha opinião, do ponto de vista de arquitetura de software, são soluções “elegantes” que reduzem a dependência e a complexidade das suas aplicações e/ou componentes. Como arquiteto(a), por exemplo, você não precisa se preocupar como uma mensagem vai sair do ambiente mainframe, ser persistida, transformada e roteada para, finalmente, ser entregue no formato de um SMS para seu cliente. Isto permite que você mantenha o foco no desenho, na arquitetura da solução, que é o mais importante.

Tudo indica que Mensageria será um dos elementos-chave em Cloud Computing. A JBoss sabe disto e lançou o HornetQ com este objetivo ambicioso: ser o provedor de mensagens preferido no ambiente de cloud computing.

Boa sorte!

Jackie Wheeler é a responsável pela publicações técnicas da MuleSource.org. Em um anúncio nesta Segunda, 10 de Junho, 2009, ela informa da disponibilidade do SAP Transport for Mule 2.

Segundo a documentação disponível, agora é possível enviar para o SAP uma mensagem XML (que é equivalente a um request de uma função BAPI) e receber uma resposta no mesmo formato.

O SAP Transport for Mule 2 possibilita conectividade com SAP ERP 6.0. A solução foi desenvolvida pela Osaka Gas Information System Research Institute Co., Ltd (OGIS), um parceiro da MuleSource do Japão.

Para quem ainda não conhece o Mule, recomendo uma leitura no meu post “Mule continua liderando no Open-Source ESB“.

Abaixo um resumo de como funciona o SAP Transport for Mule 2:

Você vai precisar instalar a partir dos códigos-fontes, uma vez que ainda não existe um binário disponível para download. Veja os pré-requisitos abaixo e mão na massa! Boa sorte.

Uma discussão recorrente no mundo da arquitetura orientada a  serviços (SOA) é como o Business Intelligence (BI) se integra neste cenário e, no caso da empresa onde trabalho (operadora telecom), como disponibilizar dados em tempo real para o BI.

Antes de mais nada sabemos que o Business Intelligence não tem a premissa de tratar dados em tempo real. Utilizamos para consolidar dados de várias fontes, gerar gráficos e relatórios para os vários níveis da empresa (operacional, tático e estratégico), como um dashboard para os tomadores de decisão etc, mas quase nunca como uma ferramenta de análise de dados em real time.

BI

Falando em BI, em uma pesquisa realizada alguns anos atrás, mostrou os principais motivadores que levavam as empresas a adotar esta solução:

• Aumentar a satisfação e a retenção de clientes: 62%
• Dimunição de Custos: 53%
• Aumento de Receita: 48%
• Aumento de Lucratividade: 41%
• Aumento de Market-share: 37%
• Ferramenta de redirecionamento de produto: 30%

(fonte: http://www.information-management.com/issues/20040201/8034-1.html)

Análise de Dados em Tempo Real

Soluções do tipo BAM (Business Activity Monitoring), e mesmo os já conhecidos BI, podem demandar a apresentação de dados e gráficos de dados com uma latência menor. Alguns exemplos simples: vendas realizadas na última hora, ligações telefônicas completadas com sucesso nos últimos 45 minutos, lotes produzidos nas últimas 2 horas, transações com cartão de crédito no últimos 5 minutos etc.

Se o volume for considerável, milhões de transação no caso de uma operadora de telecom ou de cartão de crédito, é um desafio disponibilizar estas informações através do BI ou BAM. Não apenas estes dois mercados, mas todas as operações onde temos eventos em real-time que precisam ser capturados, correlacionados e apresentados para monitoramento em tempo real.

Estes cenários são típicos de Complex Event Processing (CEP) e Event-driven Architecture (EDA). Detalhes adicionais neste link.

Oracle e Integração de Dados em Tempo Real

Ontem (23/Jul/2009) a Oracle anunciou a compra da GoldenGate, uma empresa de San Francisco, Califórnia, que possui uma solução de integração de dados em tempo real. Veja a imagem abaixo que consta na apresentação oficial da Oracle:

Verifique que a solução da GoldenGate alega que extrai e disponibiliza os dados em “tempo real” para vários “consumidores”, entre eles: Message Bus típicos de arquitetura SOA/EDA e o que eles denominam “Operational BI“.

Veja uma arquitetura simplificada de onde como a solução da GoldenGate disponibiliza dados em tempo real para ferramentas de análise e BI:

A apresentação detalha ainda alguns cases de sucesso da implantação solução da empresa de San Francisco. Mesmo sendo um material com viés promocional de como os produtos da Oracle serão integrados com o da GoldenGate, a leitura vale a pena.

Por ocasião do 2o. SOA International Symposium (Holanda, Outubro/2009), será lançado oficialmente o “SOA Manifesto“.

Nas palavras de Thomas Erl, um dos líderes do movimento “Towards and SOA Manifesto”, SOA já atingiu um nível de maturidade em que seus princípios, intenções e objetivos por trás da filosofia de orientação a serviços, já podem ser formalizados em um Manifesto.

The service-oriented architectural model and the service-orientation paradigm have reached a stage of maturity where the principles, intentions, and ambitions that embody their underlying philosophy and goals can be expressed in a formal manifesto. On October 23, 2009 at this year’s 2nd International SOA Symposium in Rotterdam, the “Towards and SOA Manifesto” working group will be following in the footsteps of the agile community by announcing the SOA Manifesto for the first time

Reproduzo parte do web site http://www.soa-manifesto.com/ :

No início de Maio/2009, na cidade de Scottdale, AZ, ocorreu a versão 2009 do SOA Summit. O evento é realizado pela gigante de software, Software AG.

As apresentações (em formato PDF) realizadas no evento estão disponíveis para download (sem necessidade de informar nada, apenas clicar e baixar o PDF).

Algumas delas são muito interessantes, como o case de automação de força de vendas usando SOA, apresentado pelo diretor de tecnologia de uma dos maiores canais de distribuição da Coca-cola nos EUA.

Outra recomendação: veja as apresentações com foco em arquitetura do analista da ZapThink, Jason Bloomberg. Estas são mais do que recomendadas.