Ricardo Ferreira's Blog

Enabling HPC (High Performance Computing) with InfiniBand in Java™ Applications

2011-10-28T13:37:00.000-07:00

Publiquei recentemente em meu blog da Oracle um artigo sobre como habilitar aplicações Java para usufruir de computação de alta performance (do inglês, High Performance Computing) usando a tecnologia InfiniBand. Este artigo pode ajudar você a migrar aplicações existentes ou que estão sendo contruídas para sistemas projetados que utilizam a tecnologia InfiniBand, como é o caso de produtos como o Oracle Exalogic. Fazendo isso, você pode chegar a niveis altíssimos de performance e escalabilidade que somente a tecnologia InfiniBand pode oferecer. Caso você tenha interesse de conferir este artigo na sua íntegra, clique aqui.

Getting Started with Oracle Tuxedo: Creating a COBOL-based Application

2011-10-12T07:46:00.000-07:00

Publiquei recentemente em meu blog da Oracle um artigo bem interessante que fala sobre a utilização da linguagem de programação COBOL para a construção de aplicações distribuídas, usando como middleware o Oracle Tuxedo, o monitor transacional líder de mercado e mais maduro do mundo. Se você programa na linguagem de programação COBOL ou, é responsável pela manutenção de aplicações escritas nesta linguagem mas que precisam ser alteradas para usufruir de características como transações distribuídas, segurança centralizada, federação de domínios, alta performance e escalabilidade, então esse artigo possa lhe ser interessante. Confira esse artigo clicando aqui.

Elastic Data Caching usando Oracle Coherence

2011-07-27T09:30:00.001-07:00

Você parou pra refletir se está preparado pra criar arquiteturas de software emergentes? Arquiteturas estas que devem poder suportar o crescimento e a diminuição da utilização dos recursos (poder computacional) sem a necessidade de mudar os componentes internos do software ou mesmo mudá-los toda vez que novos recursos são adicionados ou removidos na camada de infraestrutura. Vemos a cada dia mais e mais casos onde aplicações para web no estilo do Facebook, Twitter ou Linkedin são cada vez mais comuns, deixando arquitetos e desenvolvedores de software com um problema complexo pra resolver na hora de construir tais softwares. A demanda por softwares que necessitam suportar mais e mais usuários simultâneos e manter o SLA e o tempo de resposta sempre no nível adequado está maior, e isso é um reflexo natural de como as organizações atuais precisam expressar sua competitividade, sua capacidade de dar respostas rápidas a seus clientes e parceiros, bem como a capacidade de atender, de forma exclusiva e dedicada, seus clientes mais importantes e fiéis.

Para saber se você está preparado para construir arquiteturas de software emergentes, é necessário que você faça uma reflexão sobre como você lida com a peça fundamental de um sistema baseado em computador: Os dados. O processamento dos dados, termo que não se usa mais hoje em dia mas que ainda cabe e utilização, é o item mais complexo pra se resolver quando se projeta arquiteturas de software que tenham caracteristicas como resiliência, elasticidade, segurança e alta performance. Tudo gira em torno dos dados. Em especial, a análise da quantidade versus o tamanho dos dados trás uma diferença significativa em como seu software irá funcionar.

Quanto de banda de rede terei que ter entre o servidor X e o servidor Y se a quantidade ou o tamanho dos dados aumentar? Qual a capacidade de storage será necessária pra suportar 10 anos de processamento de folhas de pagamento? Quanto de memória terei que ter caso o número de usuários envolvidos num pregão eletrônico e que estejam dando seus lances aumentar? E se a janela de tempo para dar um lance, diminuir de 10 minutos para apenas 1 segundo, quanto lances a mais o software irá ter que suportar? Todas estas perguntas vão remeter você, arquiteto ou desenvolvedor de software num dilema clássico e recorrente: Como faço para processar os dados sem que a infraestrutura tenha que ser previamente definida e sem que as camadas do software e os seus componentes tenham que ser modificados a cada vez que essa infraestrutura ou sua topologia porventura mudem?

Neste artigo, irei mostrar como o conceito de "Elastic Data Caching" pode ser usado para resolver alguns destes problemas, bem como quais alternativas no mercado temos para a implementação deste conceito. Na sequência, irei mostrar na prática, como o Oracle Coherence pode ser usado para a implementação deste conceito, mostrando detalhes deste sua instalação até sua implementação usando a plataforma Java. Em resumo, este artigo abordará os seguintes temas:

Condutores Arquiteturais para Cache e suas Implicações
Elastic Data Caching: O que é e por quê é tão importante?
Principais Ofertas de Elastic Data Caching e seus Players
Oracle Coherence: Visão Geral da Tecnologia e Aplicações
Demonstração do Oracle Coherence na prática usando Java
Aprofundando no Oracle Coherence: Vídeos e Documentação

Condutores Arquiteturais para Cache e suas Implicações

Como é de meu costume, gosto sempre de abordar neste blog tecnologias do ponto de vista de seus condutores arquiteturais. Isso é importante porque somente a partir da avaliação dos condutores arquiteturais é que podemos chegar a uma arquitetura de software que reflita os reais requisitos (ou motivadores) paras as tecnologias que deverão ser utilizadas. Sem isso, você fatalmente vai incorrer seus projetos no que chamamos de arquiteturas acidentais, ou seja, arquiteturas de software que introduzem tecnologias e soluções sem nem ao menos refletirem sobre o real problema ou suas causas. A avaliação dos condutores arquiteturais também ajuda na eleição do melhor estilo arquitetural (ou conjunto de estilos combinados) para o seu projeto. Se você achar interessante a leitura deste artigo e achar relevante o uso de soluções de cache, não esqueça de avaliar se seu projeto realmente demanda um problema que mereça tal solução.

Quando você precisa projetar uma arquitetura de software que tenha como característica o baixo tempo de resposta para o processamento de um ou um conjunto de dados, então você terá seu principal condutor arquitetural para usar um cache. Soluções de cache são interessantes porque ajudam a construir software que possa lidar com a impedância de recursos críticos como redes e acesso ao disco. Se o seu software precisa acessar com frequência recursos que necessitam da rede para acesso, ou que dependam da leitura de um disco e que envolva intenso I/O, então um cache é fundamental para o aumento da performance. Não somente rede e acesso a disco podem ser evitados com o uso de cache, mas também o uso intenso da CPU. Imagine por exemplo uma página web que para ser renderizada (ter seu código HTML gerado) precisa realizar uma série de cálculos e passar por um determinado conjunto de etapas de processamento. Se estes cálculos puderem ser feitos uma única vez e estas etapas de processamento também forem imutáveis, então é interessante colocar esta página num cache deste a primeira vez que alguém a acessa. Da próxima vez que esta página for acessada, os ciclos de uso da CPU necessários para a computação da página serão evitados.

Soluções de cache também podem ser interessantes não só para evitar o uso (ou desperdício) de recursos de infraestrutura, mas também para ajudar no processamento de dados em massa. Aplicações que precisam lidar com fluxos de dados contínuos para análise de identificação de padrões também podem fazer bom uso de soluções de cache. É o caso por exemplo, de aplicações baseadas em CEP (Complex Event Processing) onde uma grande quantidade e contínua de eventos (estruturas de dados) precisam ser avaliadas na procura de padrões temporais ou comportamentais, possibilitando a identificação de situações e a tomada de ações em tempo real. A baixa latência e o fator "tempo real" aqui só serão possíveis se você puder avaliar contínuamente os eventos, e isso se torna mais fácil quando estes eventos estão num cache.

Mas o que implica usar uma solução de cache? Vamos pensar por um instante no tamanho dos dados. Soluções de cache tornam eficiente o acesso aos dados porque na maioria das vezes utilizam a memória como componente de armazenamento. Apesar da memória ser eficiente para a leitura e recuperação rápida dos dados em comparação aos discos, ela é menor e mais limitada. Se porventura você tiver que lidar com volumes de dados grandes ou quantidades pequenas mas que tenham um enorme footprint de armazenamento, então você poderá comprometer sua infraestrutura com esta questão de tamanho. Outra questão importante é a coerência [do inglês, Coherence :D] dos dados. Os dados num cache são porventura atualizados e removidos com frequência pelos diversos usuários conectados na aplicação. Se estes dados são modificados, então é necessário manter a versão única da verdade destes dados independente de onde eles estejam na infraestrutura. Outra questão relevante quanto aos dados armazenados em cache e em memória é quanto a tolerância falhas. Se os dados estão em memória, então eles são voláteis por natureza. E se o servidor sofrer uma falha e tiver que ser desligado? O que irá acontecer com os dados que estavam em cache? Poderão ser recuperados de forma que não comprometam as transações dos usuários conectados?

A avaliação dos fatores que decorrem da utilização de soluções de cache é particularmente importante quanto você precisa adquirir uma solução que ofereça isto. Na grande maioria das vezes, você não irá optar por apenas uma solução de cache, mas sim várias. Cada solução de cache irá cobrir um conjunto de problemas e será aplicado a uma parte ou área de sua arquitetura ou infraestrutura. Um bom exemplo é se você estiver pensando em aplicar cache para sua camada de visão e seus recursos de apresentação como páginas estáticas e arquivos de imagens. Um proxy reverso pode ser uma solução interessante para este caso, mas nem tanto para resolver o problema de cache de segundo nível de suas entidades que são armazenadas num banco de dados. Quanto maior o conjunto de recursos e facilidades encontrados numa solução de cache, aliado a questão de que ela seja ampla o suficiente para acomodar não apenas um, mas diversos tipos de cenários e camadas de sua arquitetura, vai fazê-lo avaliar não diferentes soluções de cache, mas uma única plataforma que ofereça tudo isso e que acomode todas as implicações que discutimos anteriormente. Neste momento, você irá começar a avaliar uma solução de Elastic Data Caching.

Elastic Data Caching: O que é e por quê é tão Importante?

Diferentemente de soluções de cache locais, que residem no mesmo espaço de endereço da aplicação, soluções de Elastic Data Caching (EDC) são implantados em dois ou mais servidores (no caso de aplicações como Facebook ou Amazon em centenas deles), usualmente em um cluster dedicado apenas a cache. Isso faz com que você insira um componente de cache em sua arquitetura de software, situado normalmente antes e depois do seu cluster de servidores de aplicação ou infraestrutura de middleware. De acordo com o Forrester:

"Elastic Data Caching is a software infrastructure that provides application developers with data caching services that are distributed across two or more server nodes that 1) consistently perform as volumes grow; 2) can be scaled without downtime; and 3) provide a range of fault-tolerance levels"

As vantagens do uso de EDC são inúmeras, mas todas estas vantagens giram em torno de uma única palavra: elasticidade. A capacidade de ser elástico quer dizer que a infraestrutura de cache pode aumentar e principalmente diminuir sob demanda, sem causar mudanças ou redesenho nas aplicações que fazem uso dos serviços de cache. Essa característica torna soluções de EDC extremamente atraente, uma vez que a exata previsão sobre capacidade da infraestrutura não deve ser facilmente determinada, e mesmo que fosse, ela jamais seria estática. Como as aplicações atuais precisam lidar com a sazonalidade do número dos usuários, em especial se tais aplicações forem baseadas na web, então o crescimento não preditivo e exponencial do número dos usuários vai ocorrer. Sua infraestutura de cache precisa estar preparada para a inserção de mais servidores no cluster de cache. E da mesma forma que a inserção de mais servidores no cluster de cache não deverá acarretar mudanças nas aplicações, a remoção de tais servidores quando estes não forem mais tão necessários devido a diminuição da demanda, também não deverá acarretar em mudanças ou impactos nas aplicações. Isso é elasticidade. Poder aumentar e diminuir quando necessário, e quantas vezes for necessário.

Mas porque a capacidade de diminuir os recursos é mais importante do que a de aumento destes? A um tempo atrás, as aplicações eram projetadas para poderem oferecer transparência de localização, de forma que quando novos servidores fossem inseridos num cluster, a aplicação pudesse ser executada independente de onde estes servidores estiverem. Isso é interessante e poderoso, mas nos dias de hoje, isso não deve ser a unica preocupação. Inserir novos servidores em um cluster remete as organizações a investiram capital em hardware e máquinas, e isso do ponto de vista contábil não é nada interessante, pois, contabilmente falando, manter um servidor na organização é um custo contínuo e que sempre deprecia, tornando-o menos valioso ao longo do tempo. Se a organização que mantêm esse custo contínuo não for uma organização cujo fim é TI ou serviços de TI, então o problema se torna maior ainda, pois qualquer valor de capital investido em servidores e máquinas é visto como despesa e não como investimento. E todos sabemos que orçamento pra TI diminui a cada ano que passa. Para lidar com isso e usufruindo do que a tecnologia de virtualização hoje nos propcia, a indústria de cloud computing oferece a oportunidade de organizações utilizarem servidores e máquinas virtuais como um serviço, não implicando em custo de aquisição e manutenção. Neste caso, os servidores podem ser usados para atender uma demanda específica, e depois que esta demanda acabar eles podem ser "devolvidos" para o fornecedor da Cloud. Para usufruir desta capacidade, sua arquitetura precisa oferecer características de elasticidade.

Agora que vimos o que é Elastic Data Caching e porque isso é tão importante para a construção de arquiteturas de software emergentes, é hora de dedicar um tempo na avaliação de quais ofertas existem atualmente para isso, e com isso, conhecermos e avaliarmos quais são os fabricantes de software que estão disponíveis para avaliação e contratação.

Principais Ofertas de Elastic Data Caching e seus Players

As ofertas para soluções de Elastic Data Caching não poderiam ser melhores. Os principais fabricantes de software do mundo possuem pelo menos uma oferta nesta categoria. Alguns fabricantes porventura possuem mais de uma oferta, que podem ser combinados para compor uma solução mais abrangente. Dentre os principais fabricantes, encontram-se Oracle, GigaSpaces, IBM, Software AG e VMware. Querendo entrar nesta lista seleta de fabricantes constam também Microsoft, TIBCO e Red Hat, com ofertas interessantes mais ainda não tão maduras ou não disponíveis ainda como produtos para os clientes. A figura abaixo, retirada de um relatório do Forrester de Q2 de 2010, sintetiza os principais fornecedores e como suas soluções estão posicionadas:

Como o relatório é de 2010, ele acaba não refletindo a atual situação de fabricantes como a Terracota, que foi adquirida pela Software AG em 2011, e da GemStone Systems, que foi adqurida pela VMware em 2010. Os demais fabricantes permanecem até o presente momento. A figura mostra que Oracle, IBM, GigaSpaces e Software AG lideram a categoria, e que a Oracle com o seu Coherence possui maior base instalada de clientes sendo portanto a solução mais utilizada e madura.

Oracle Coherence: Visão Geral da Tecnologia e Aplicações

O Oracle Coherence é um produto para implementação de um grid de dados distribuído, ou seja, uma plataforma de distribuição (particionamento) dos dados em cima de um protocolo de peer-to-peer que suporta clusterização e altamente escalável. Isso possibilita que os dados sejam distribuídos num cluster de servidores formando uma grande e elástica área virtual de memória, garantindo assim que não existirá nenhum único ponto de falha, pois os dados podem ser recuperados de qualquer servidor do cluster. Quando um servidor entra na rede, o Coherence automaticamente detecta sua presença e passa a contar com ele em sua estratégia de grid. Quando um ou mais servidores sofrem falhas e param de responder, o Coherence também automaticamente detecta-os e expurga-os do cluster para que a área de memória virtual (o grid) não seja comprometido com a utilização de um servidor defeituoso. Os servidores "saudáveis" do grid assumem a responsabilidade dos servidores defeituosos. A figura abaixo mostra esta relação do grid e o processo de leitura de um dado mesmo quando um dos servidores do cluster sofre falha.

Uma característica do Coherence que o distingue e o melhor posiciona perante seus concorrentes é que nele, não existe de fato nenhum ponto de falha. Isso significa que tudo no Coherence é um grande grid formado por servidores num cluster que conhecem a localização de cada participante. Não existe um sistema de registro que cataloga os participantes do grid e também não existe um agente que controla o processo de atualização e de replicação dos dados no cluster. Todos os participantes do cluster sabem fazer esse trabalho, e eles colaboram entre si para que o processo seja feito sempre, garantindo assim a integridade e coerência dos dados. A maioria das soluções concorrentes apresentam componentes de registro e de lookup dos dados, e tais componentes controlam toda a arquitetura do grid de memória. Isso torna tais soluções inadequadas porque eles terão sempre um ponto de falha. Se porventura o componente responsável pelo registro dos servidores falhar, todo o grid irá parar de funcionar. E mesmo que esse componente de registro possa ser clusterizado, o seu processo de cluster será finito, e você sempre terá uma margem pra falhas se todas as cópias (backups e backup dos backups) falhar. Ou seja, cadê a elasticidade? No Coherence, tudo é 100% feito pelos participantes do cluster, de forma sincronizada, eficiente e atômica.

Outra particularidade que torna o Coherence atraente é sua simplicidade. Não só o fato de que você o pôe pra funcionar em poucos minutos (conforme será visto no próximo tópico) a sua API de manipulação também é muito trivial. Um cache para o Coherence nada mais é do que uma especialização da interface java.util.Map, implementada na API do Coherence como com.tangosol.net.NamedCache. Esta implementação de mapa é controlada internamente pelo Coherence, e em cima dela é feito todo o trabalho sujo de replicação e particionamento dos dados, sincronização das atualizações feitas, recuperação dos dados através de listeners e demais características do Coherence. Para interagir com um cache do Coherence, um programador Java simplesmente recupera uma instância de um com.tangosol.net.NamedCache e realiza suas operações de leitura, escrita, atualização ou remoção dos dados. O trecho de código abaixo mostra como solicitar um cache do Coherence conhecido como "clientes" e insere um objeto do tipo cliente usando seus CPF como chave da informação:

A API do Coherence está disponível tanto para Java quanto para C++ e também para .NET. Neste caso, usando qualquer uma destas linguagens você pode realizar o mesmo conjunto de operações e contando com as mesmas características já citadas. Para saber mais sobre como o Coherence dá suporte a demais linguagens que não Java, leia a documentação do produto que está disponível on-line no site da Oracle.

A Oracle disponibiliza o Coherence como um produto de Elastic Data Caching, ou integrado com os demais produtos da linha Fusion Middleware. Em especial, o Coherence já vem previamente integrado e configurado no servidor de aplicações WebLogic, dando ainda mais diferencial a este produto que já é fantástico. A partir desta integração, clientes do Oracle WebLogic podem usufruir das facilidades e características do Coherence sobre replicação e particionamento de dados, tendo por exemplo os principais componentes de um servidor de aplicação Java EE como sessões HTTP, JNDI Tree's, Servlets, JSF Managed Beans, Stateful e Stateless Session Beans controlados pelo grid do Coherence. Isso possibilita alta disponibilidade e performance em aplicações Java EE, além de possibilitar que desenvolvedores de componentes de Servlets ou EJB's possam usufruir também do Coherence, pois os seus cache's se tornam disponíveis através de JNDI ou através de injeção de dependência via anotação @Resource. Isso permite que as aplicações que porventura façam uso do cache do Coherence mantenham sua interoperabilidade com demais servidores de aplicações do mercado, uma vez que todo o acesso aos recursos é feito usando abordagens suportadas pela especificação do Java EE.

Finalmente, o Coherence possui um forte esquema de integração com outras tecnologias que não da Oracle, em especial com o JPA, Hibernate, Spring e o WSRP. Isso faz com que o Coherence possa ser embarcado em diversos tipos de aplicações e possa resolver diferentes tipos de demandas de cache. Esteja você criando uma aplicação Java simples e rodando num servidor Jetty ou mesmo numa aplicação standalone, o Coherence pode ajudar. Esteja você tentando melhorar a performance de suas entidades JPA ou Hibernate, o Coherence pode ajudá-lo na implementação de um cache de segundo nível. Esteja você querendo usar recursos de cache em aplicações baseadas em contêiners leves como Spring, o Coherence também poderá ser utilizado.

Demonstração do Oracle Coherence na Prática usando Java

Agora que criamos uma boa visão sobre o que é Elastic Data Caching e aprendemos um pouco sobre o que é o Oracle Coherence, é hora de nos aventurarmos em aprender como podemos utilizá-lo na prática. Irei mostrar agora como instalar e colocar o Coherence pra funcionar, e realizar alguns testes nele usando suas ferramentas internas e criando alguns programas em Java do tipo standalone. Vamos começar com o processo de instalação.

A primeira coisa a se fazer é realizar o download do produto no site da Oracle. Para isso, clique aqui para realizar o download. Para este artigo, utilizei a versão 3.7 do Coherence, que na época da escrita deste artigo era a mais atual. Você deverá ter uma conta de usuário no portal do Oracle Technology Network para poder realizar o download. O software pode ser utilizado gratuitamente para fins de aprendizado e testes no seu ambiente, mas lembre-se que se você planejar colocá-lo em produção em algum projeto, você deverá entrar em contato com a Oracle e providenciar seu licenciamento.

Quando você concluir o download, o que você terá em mãos um pequeno arquivo do tipo Zip. Descompacte este arquivo em um diretório de preferência do seu computador. Para este artigo, eu pûs o diretório descompactado no raiz do meu disco principal. Feito isso, você deverá providenciar algumas configurações relacionadas ao ambiente. A primeira coisa a se fazer é configurar a variável de ambiente JAVA_HOME. Se você é um desenvolvedor Java, você não deverá ter dificuldades quanto a isso. Para este artigo, usei um JDK versão 1.6 da Sun e não tive problemas. Lembre-se de colocar a pasta "bin" do seu JAVA_HOME na variável PATH. Isso será utíl principalmente pra utilizar os recursos de console e querying do Coherence.

Agora vá para o diretório de instalação do seu Coherence, e estando nela, entre no diretório "bin". Neste diretório, você encontrará vários arquivos do tipo shell e batch. Dentre eles, abra o arquivo cache-server.cmd (ou cache-server.sh se você estiver no Unix/Linux) para edição. Este arquivo cria uma instância do Coherence, que irá atuar tanto como cliente e como servidor dele mesmo. Quando você abrir este arquivo, você deverá editar a linha que define a variável COHERENCE_HOME. Faça com que esta variável aponte para o local onde você instalou seu Coherence, algo como "set COHERENCE_HOME=C:\coherence". Depois que você editar esse arquivo, você poderá executar um servidor do Coherence pela primeira vez em seu computador. Execute esse arquivo e veja no console qual será a saída apresentada. Se tudo estiver funcionando corretamente, você terá uma saída como a listagem abaixo:

O Coherence possui uma ferramenta bem poderosa de querying para que você possa remotamente administrar cache's e porventura alterar os valores que neles constam. Essa ferramenta chama-se "query" e pode ser encontrada dentro do diretório "bin" da instalação do seu Oracle Coherence. Para que possamos utilizá-la, é necessário realizar algumas configurações simples. A primeira coisa a fazer é realizar o download do framework JLine, que simplifica bastante a utilização de instruções do tipo shell. Descompacte o JLine em algum diretório do seu computador. Depois isso, edite o arquivo query.cmd (ou query.sh se você estiver no Unix/Linux) e edite o arquivo de tal forma que você defina as variáveis COHERENCE_HOME e JLINE_HOME, para que apontem para o local de instalação do Coherence e do JLine, respectivamente.

Pronto, agora temos tudo devidamente configurado para realizarmos nosso primeiro teste. Para começar os testes, execute uma instância do Coherence através do script "cache-server", encontrado no diretório "bin" do local de instalação do seu Coherence. Agora vá novamente ao diretório "bin" do local de instalação do Coherence e execute o script "query". Este script vai carregar um console do tipo schell para que você possa controlar atividades de criação e manipulação de cache's. O console deverá ser parecido com a figura abaixo:

Vamos criar um cache no Coherence e realizar algumas operações em cima deste cache. Para criar o cache, entre com a seguinte instrução no prompt e depois pressione a tecla "Enter":

create cache "teste"

Depois que você pressionar a tecla "Enter", você verá algumas mudanças no console do script "cache-server". O que irá acontecer é que o Coherence irá detectar que um novo agente quer participar do grid de dados e irá contar com este agente para delinear a memória do grid, formando o primeiro cluster. Tudo isso será feito automaticamente, pois o Coherence realiza todas estas operações através de broadcast na rede, usando seu robusto protocolo de peer-to-peer. A partir deste momento, ambos os agentes do cluster poderão manipular o cache "teste", e os dados que forem postos nele serão compartilhados por ambos os agentes. Vamos fazer um teste para verificar isso. Volte ao console de "query" e entre com a seguinte instrução e pressione "Enter":

insert into "teste" key "SP" value "Sao Paulo"

Isso irá inserir um valor dentro do cache conhecido no Coherence como "teste". Para verificar se a entrada foi corretamente adicionada no cache, você pode realizar uma consulta. Como você já deve ter notado, a linguagem de manipulação do Coherence se assemelha muito com a linguagem SQL, e a consulta não poderia ser diferente. Para ler os valores do cache "teste", entre com a seguinte instrução e pressione a tecla "Enter":

select key(), value() from "teste"

Será que os valores que entramos no cache "teste" está realmente dentro do grid e dados do Coherence? Vamos responder esta pergunta. Execute uma nova cópia do script "query". Feito isso, digite a instrução abaixo e pressione a tecla "Enter":

create cache "teste"

Quando você fizer isso, repare nas janelas dos consoles anteriores. Todos eles irão detectar o novo membro do cluster, e atualizar o grid de dados com este membro. Não se preocupe, a instrução que você acabou de digitar não vai "matar" o cache que já foi criado. Ao invés disso, ele irá notificar ao grid que um novo agente gostaria de manipular o cache "teste". O Coherence irá ver que já existe um cache com este nome, e ao invés de criar um novo ele irá devolver este cache existente. Existe uma instrução formal para remoção de um cache do grid. Agora, estando no novo console que você acabou de abrir, entre com a seguinte instrução e pressione a tecla "Enter":

select key(), value() from "teste"

Como você já deve imaginar, o resultado apresentado será a cidade de São Paulo, que foi inserido anteriomente no cache. Isso prova que, no Coherence, o cache é algo virtual, em que é distribuido entre todos os participantes do cluster. Toda operação feita no Coherence é executada contando com todos os participantes do cluster, por padrão. Você pode claro, configurar o Coherence para que certas operações sejam feitas apenas entre aguns membros. Para isso, você pode criar um grupo, ou como prefiro dizer, uma "sala de bate papo" particular. Neste caso somente os membros que estiverem nesse grupo irão trocar as informações.

Para fazer com que os consoles de "query" saiam do grid do Coherence, basta digitar a instrução "bye" e pressionar a tecla "Enter". Quando você fizer isso, repare que os demais consoles irão detectar a saída do membro, e passarão a não contar mais com aquele membro no cluster. Desta forma, toda nova instrução dada será de interesse apenas dos membros que sobrarem. Para terminar o console que contêm o script "cache-server", basta pressionar a combinação de teclas "Ctrl + C", como você faria com qualquer outro tipo de shell. Para conhecer mais sobre esta linguagem de manipulação e gerenciamento de dados, sugiro que você realiza os passos descritos na seção de instalação da documentação do Coherence, clicando neste link. Vamos agora tornar as coisas mais interessantes e verificar como podemos usar o Coherence dentro e através de uma aplicação Java.

Para começar nossos testes do Coherence em aplicações Java, use um IDE de sua preferência para realizar a codificação e execução dos programas. Eu usarei neste artigo o Eclipse, que pode ser baixado gratuitamente neste link. Baixe uma versão do Eclipse compatível com a JVM que você está utilizando. Após baixar o Eclipse, execute-o pela primeira vez configurando o workspace, ou seja, o local onde será armazenado os projetos. Quando o Eclipse for iniciado, você deverá criar uma biblioteca (library) que contenha a dependência do Coherence. Para isso, vá até o menu "Window" e clique na opção "Preferences". Na janela de preferências, acesse a opção "Java - Build Path - User Libraries". Na janela que aparece, Clique no botão "New" para adicionar uma nova biblioteca. Chame esta biblioteca de "Coherence37" e deixe marcado o checkbox "System library (added to the boot class path)". Clique em "OK" para confirmar a criação da biblioteca.

Depois de criar a biblioteca, clique no botão "Add JARs..." para adicionar a dependência do Coherence. A dependência será o arquivo JAR encontrado em $COHERENCE_HOME/lib/coherence.jar. Clique em "OK" para terminar o processo de criação da biblioteca. Como você pode perceber, o Coherence adiciona um footprint de dependências muito baixo as suas aplicações Java, além de ser extremamente simples de embarcar nas aplicações, por tratar-se de apenas uma dependência. Dependendo dos recursos que você precisar utilizar, pode ser necessário o uso de outras dependências, mas para as operações padrões do Coherence como o caso do grid de dados, apenas a sua biblioteca principal é necessária.

Vamos criar um projeto para exercitar a API do Coherence para Java. Para isso, crie um novo projeto do tipo Java no Eclipse, e dentre as configurações necessárias para o projeto, adicione a biblioteca "Coherence37" ao classpath. Para não perder o costume e as origens, chame esse projeto de "coherenceHelloWorld" :P

Uma vez criado o projeto, vamos criar um primeiro programa Java que irá criar um cache no Coherence, e inserir um valor neste cache. Para isso, crie uma classe Java chamada de "GravarPIUsandoCoherence.java" e implemente-a conforme a listagem abaixo:

O programa Java acima é simples de ler e acredito que seu código não mereça tanta explicação, exceto pela chamada de método "CacheFactory.ensureCluster()". Esta chamada na verdade realiza um broadcast na rede usando as configurações padrões do arquivo de configuração do Coherence (falaremos mais sobre ele adiante) a procura por outros membros que já formem um grid. Ao encontrar um, ele passa a fazer parte deste grid. Caso ele não encontre, como será o caso deste programa, ele irá criar o grid e se candidatar como primeiro membro. O restante do código apenas cria um cache e insere um valor dentro, que será lido posteriormente por outro programa Java. Para garantir que este programa "dure" até o momento que o outro programa leia a variável inserida, usamos uma instrução de espera, para que o programa fique aguardando pelo período de um minuto. Depois disso, o programa irá terminar, e irá sair do grid que foi montado a partir dele. Outros programas que permanecerem em execução e ainda conectados no grid irão perpetuá-lo até que eles se encerrem, do contrário, o grid inteiro irá ser finalizado.

Execute este programa Java e veja o resultado no console do Eclipse. Em verdade, nada de muito interessante irá acontecer, uma vez que este programa apenas grava num cache do Coherence uma variável que nunca será lida. Mas você deverá perceber pelo console que algumas saídas serão escritas, saídas estas semelhantes aos testes que fizemos usandos os scripts que acompanham a instalação do Oracle Coherence. Para completarmos nosso exemplo, é necessário que você crie outro programa Java. Crie uma nova classe Java no projeto, e chame-a de "LerPIUsandoCoherence.java", e implemente-a conforme a listagem abaixo:

Depois que terminar de implementar o programa Java acima, é hora de fazer o real teste usando o Coherence. Para isso, você deverá executar o primeiro programa Java, e esperar até que ele termine de montar o grid. Depois disso, você terá um minuto para executar esse segundo programa Java, que ao terminar sua execução deverá apresentar uma saída conforme a listagem abaixo:

Você deve estar se questionando: "OK, vi que o programa funcionou e leu a variável corretamente, e vi também que o Coherence é muito simples pois não precisei fazer nada para que o grid fosse montado e o cache fosse compartilhado". Mas imagino que justamente por estar pensando isso é que você possa estar incomodado com o fato de que tudo foi automático demais, certo?

Agora é hora de desvendar alguns mistérios. Quando você embute a API do Coherence dentro de um programa Java, a saber, o arquivo coherence.jar que usamos no classpath do projeto, você acaba embutindo também alguns arquivos de configuração que determinam o comportamento do Coherence quanto a montagem e/ou participação de um grid bem como o comportamento de particionamento e replicação no cluster. Esses arquivos de configuração estão dentro deste arquivo coherence.jar, no root do classpath do arquivo. Se você abri-lo com um programa de compactação como Winzip ou Winrar, você poderá ver e abrir tais arquivos de configuração.

Se você quiser usar seu próprio arquivo de configuração com as suas diretrizes de comportamento no Coherence, você deverá informar ao programa Java explicitamente que outros arquivos de configuração serão utilizados. Para fazer isso, basta que você crie os arquivo de configuração XML e grave-os no raiz do classpath. Se você estiver criando um programa Java e empacotando-o num arquivo JAR executável, então esses arquivos de configuração deverão estar no raiz deste arquivo JAR. Se você estiver criando uma aplicação Java EE pra Web, então os arquivos de configuração do Coherence deverão estar dentro da pasta WEB-INF/classes, exatamente no raiz deste diretório. A listagem abaixo mostra um exemplo de configuração do Coherence que sobreescreve as diretrizes padrões do Coherence:

Aprofundando no Oracle Coherence: Vídeos e Documentação

Este artigo mostrou alguns dos principais recursos do Oracle Coherence, mas é claro que o produto possui muito mais recursos e features do que os mostrados aqui. Para aprender mais sobre o Coherence, principalmente maiores detalhes sobre sua arquitetura, demais recursos e mecanismo de execução, recomendo fortemente você a assistir este vídeo abaixo. Este vídeo, é na verdade uma apresentação feita no evento Google Tech Talks, apresentada por nada mais nada menos do que Cameron Purdy, o criador e CEO da Tangosol, empresa adquirida pela Oracle em 2007 e criadora do Coherence.

Também hospedados no Youtube, a Oracle mantêm um canal dedicado exclusivamente a discussão e apresentação das novidades e recursos do Coherence. Recomendo você a assistir estes vídeos, que poderão dar a você maior insight sobre o produto e as possibilidades que ele abre, principalmente se você estiver em busca de soluções de Elastic Data Caching.

Boas Integrações ;)

Como Justificar uma Arquitetura Baseada em Cloud?

2011-06-04T07:01:00.000-07:00

Começar a usar uma nova tecnologia nunca é fácil. Além da evidente dificuldade que equipes de desenvolvimento de software enfrentam quando inserem novos "ingredientes" em suas estratégias de implementação, existem as barreiras culturais, econômicas e políticas que a decisão de trazer uma nova forma de fazer as coisas pode acarretar. Trabalhei como arquiteto de software numa grande fábrica de software durante quatro anos e meio, e este foi o período da minha vida onde aprendi bastante sobre tecnologia, mas acima de tudo, sobre como justificar o emprego de novas tecnologias nos projetos que eu estive alocado. A cada vez que começava um projeto e introduzia uma nova tecnologia, precisava desprender várias horas discutindo e convencendo meus gerentes de projeto e meus clientes sobre a decisão de uso da tecnologia. Fábricas de software são empreendimentos interessantes sobre como produzir software em larga escala, e segundo estudos do SEI documentados no livro Software Product Lines: Practices and Patterns, um ingrediente chave sobre como criar softwares em massa garantindo previsibilidade de prazos, custos e escopo, é o uso repetido e controlado de arquiteturas pré-testadas, provadas e que as equipes das fábricas tenham experiência, afinidade e agilidade.

Quando você e sua equipe decidem inserir uma nova tecnologia ou estilo arquitetural para desenvolver um novo projeto, você está, segundo a ótica de fábricas de software ou mesmo de organizações que estejam investindo na elaboração de algum software, inserindo uma chance grande de fazer com que o projeto tenha seus principais atributos de medição e qualidade (a saber, prazo, escopo e custo) comprometidos. E isso deixa-os bastante preocupados. É sempre bom, ao ser argumentado negativamente sobre suas decisões, se colocar no lugar da pessoa que o está argumentando e tentar entender suas motivações. Em grande parte dos casos, a argumentação negativa será resultado de FUD. É seu papel saber justificar o emprego de mudanças no jeito de fazer as coisas, e balancear claramente as vantagens e desvantagens dessa decisão. A introdução não comprometida de novas "complexidades" em projetos de software é um erro grave e deve, em minha opnião, ser reflexo sim de insatisfação por parte de seus gerentes, líderes ou clientes. Na visão deles, você está usando o dinheiro deles pra brincar com novas tecnologias, e isso não soa muito bem se você olhar com mais cuidado. Você deve mostrar que o uso da tecnologia possui razões responsáveis e bem pensadas, e que esteja engajado ao máximo na resolução dos requisitos do projeto.

O que fazer então nesses casos? A boa prática de arquitetura de software diz que você deve justificar suas decisões de uso de tecnologias e estilos arquiteturais baseado na avaliação minuciosa de requisitos funcionais e não-funcionais. Esses deverão ser os principais fios condutores que deverão ser usados para delinear sua arquitetura de software, conforme documentado no livro Evaluating Software Architectures: Methods and Case Studies. Jamais use uma tecnologia apenas por achá-la interessante ou porque será legal tê-la em seu currículo. Lembre-se: Alguém está pagando seu salário ou bônus para que você faça o que você está fazendo. O trabalho de elaboração de uma arquitetura de software começa com a elicitação explícita dos requisitos funcionais e não-funcionais de um projeto a ser desenvolvido. Para cada requisito elicitado, você deve associar um mecanismo de análise apropriado que resolva claramente aquele requisito. A partir deste mecanismo de análise, você deve criar ou associar um mecanismo de desenho que resolva tecnicamente o mecanismo de análise (que origianalmente apenas endereça o escopo do requisito) e, por fim, crie ou associe um mecanismo de implementação que satisfaça usando pilhas de software o que foi acordado no mecanismo de desenho. A figura abaixo, retirada do excelente artigo Capturing Architecture Requirements da IBM, mostra as relações e dependências sobre requisitos de software e suas estratégias de implementação.

Cloud Computing é uma abordagem relativamente nova (na verdade, com maior relevância e evidência nos dias de hoje) que promete resolver diversas das complexidades encontradas no desenvolvimento, implantação e execução dos softwares atuais. Mas tal como qualquer outro paradigma, estilo arquitetural ou nova tecnologia, você precisará se armar de bons argumentos na hora de justificar a sua introdução numa organização ou na elaboração de um software funcional que um cliente demande. Agora que você sabe como funciona a cabeça das pessoas que pagam seu salário para que você crie soluções usando software, e sabe também quais são as técnicas usadas em arquiteturas de software para propor mecanismos de implementação (ou seja, as tecnologias) que resolvam os requisitos de um projeto, você precisará entender quais são as vantagens e motivadores que uma arquitetura baseada em Cloud pode trazer para seus clientes e às organizações. Sem dúvida, elas são muitas, mas é necessário que você as compreenda claramente e saiba também quais são suas implicações de uso, pois como toda tecnologia, ela trás consigo diversas vantagens como também a introdução de novos problemas. Cabe à você, arquiteto de software, balancear adequadamente os pontos positivos e negativos e tomar uma sábia decisão.

Quando iniciar sua discussão sobre justificar arquiteturas baseadas em Cloud, comece realizando as perguntas abaixo. Estas perguntas deverão ser feitas para que seus stakeholders comecem a refletir sobre os benefícios (principalmente os financeiros) da abordagem. Depois disso, comece a discorrer como a arquitetura baseada em Cloud irá endereçar seus requisitos funcionais e não-funcionais.

Pergunta 1: Como você lida com o aumento da capacidade e necessidade de mais hardware?

Capacity planning é sem dúvida um assunto muito importante na arquitetura de qualquer sistema que depende de recursos de hardware. Mas quando você prefere utilizar seu próprio hardware para rodar suas aplicações, você passa a enfrentar dois problemas clássicos. Primeiro, o que acontece se você estimar pra mais ou pra menos a quantidade de hardware necessária para acomodar seu sistema? Isso pode implicar em perda de capital ou em insuficiência de recursos para execução do sistema. Outro ponto importante é sobre a previsão de orçamento para hardware. E se você não tiver recursos monetários suficientes para comprar novo hardware e servidores assim que eles se fizerem necessários?

Quando você resolve usar sua própria infraestrutura de hardware, você deve ter capital em caixa para poder adquirir cada novo Storage Area Network (SAN) ou cada novo servidor que você precisar. E o ponto é, você nunca vai saber exatamente quando isso vai acontecer, pois isso é algo ditado pela velocidade e temperatura do seu negócio. Além disso, mesmo que você tenha capital para compra de novos recursos, você precisará de um tempo para poder tornar tais recursos operacionais dentro de sua infraestrutura, afinal de contas, o recurso precisa ser instalado, configurado e suas aplicações precisam ser instaladas ou configuradas pra ele.

Pergunta 2: O que acontece quando ocorre um problema em sua infraestrutura?

Uma prática comum utilizada ao longos dos anos é a redundância de servidores. Todo bom servidor possui uma cópia escrava que é utilizada em casos onde o servidor principal apresenta problemas. Mas o servidor é uma grande caixa que possui outros recursos internos dentro. Se um destes recursos falha, como por exemplo, um dos discos de um array RAID, você precisará de alguem técnico para poder fazer a troca do disco defeituoso por um novo. E este técnico (recurso humano) possui um custo mensal. Claro, existem hoje infraestruturas inteligentes que fazem esse tipo de coisa automática, robôs inteiros que podem substituir estes recursos humanos, mas isso implica em um custo atualmente muito alto. E pra quê ter esse tipo de automação quando você nunca vai saber quando eles serão realmente utilizados. Você pode usufruir deste alto investimento apenas uma vez no ano.

Pergunta 3: O que acontece quando ocorre um desastre?

Se um servidor inteiro falha, a não ser que você tenha uma infraestrututura de alta-disponibilidade, você acabará com um desastre em mãos e seu time deverá correr para se recuperar daquele desastre. Com muita sorte, se você estiver com seus backups em dia, você poderá sua infraestrutura pronta e operacional o mais rápido possível. Porém este processo é quase certo que seja 100% manual, e, portanto, levará um certo tempo. Além disso, a cobertura de incidentes como desastres de servidores pode acarretar em custos altos com mão de obra e horas extras dos seus técnicos em plantões. Estes custos indiretos também devem ser considerados quando você preferir gerir sua própria infraestrutura.

Pergunta 4: E quando você não precisar mais de um servidor?

Pode ser que mesmo que você tenha acertado a mão no seu capacity planning e investido nos recursos certos necessários para uma dada carga e demanda, você não tenha essa carga e demanda, pois, mais uma vez, isso depende da velocidade e temperatura do seu negócio. Neste caso, você poderá acabar com servidores que estarão inutilizados. Mesmo que você doe os servidores para servidor à outras aplicações, esses servidores precisarão de um tempo até serem preparados para novo uso, implicando portanto no aumento do tempo de preparação dos servidores. Pior ainda, se você não tiver onde usar aquele grupo de servidores, você terá um conjunto de capital investido e parado dentro da sua organização, tornado-a portanto, ineficiente e cara quanto a utilização de seus recursos capitais.

Pergunta 5: E quanto ao gerenciamento e uso de energia elétrica?

Quando você prefere utilizar sua própria infraestrutura (ou que você tenha um ou mais racks dentro de um data center), você poderá estar tendo um custo com eletricidade que efetivamente não reflete as reais necessidades. Em grande parte das vezes, você pode estar tendo um custo com eletricidade que poderia ser muito mais otimizado se você tivesse seus servidores virtualizados e utilizados sob demanda, ou seja, somente na hora em que estes fossem utilizados.

Faça-os pensar sobre como lidar positivamente com as situações usando Cloud

Usando arquiteturas baseadas em Cloud, você pode adicionar maior capacidade em sua infraestrutura a medida que você precisar, quando você precisar, e não, antes que você realmente precise. Neste caso, você não precisa de capital associado a recursos de hardware. Você não precisará planejar orçamento para infraestrutura de aplicações, uma vez que os recursos em uma arquitetura baseada em Cloud são utilizados sob demanda, assim que eles se tornam necessários. Quando eles não são mais necessários, os recursos não serão mais cobrados, e você não precisará lidar com situações de capital parado ou recursos inutilizados. Acima de tudo, você terá sempre os recursos no momento que você precisar, em questão de minutos e não horas.

Outro ponto muito importante sobre arquiteturas baseadas em Cloud é que, você nunca precisará se preocupar com que tipo de plataforma ou sistema que sustenta sua infraestrutura. Você não precisa saber a marca do storage, a versão do sistema operacional, o tipo de gerenciamento de disco utilizado, e com isso, você também não precisara ter times capacitados em determinadas tecnologias. Na verdade, você não precisará ter times capacitados nem presentes, pois este custo com pessoas será de responsabilidade do provedor do seu Cloud. E mesmo que você seja seu próprio provedor (No caso de optar por Cloud's privadas), isso pode ser perfeitamente terceirizado por uma empresa parceira ou um departamento isolado.

Licensiamento de softwares também costuma ser outro ponto positivo com arquiteturas baseadas em Cloud. Ao invés de ter que ter contratos de licenças ou subscrições de software, você pode apenas usar seu cartão de crédito corporativo e comprar o serviço do software a medida que você precisar. Isso se torna mais atraente ainda quando você precisa atualizar seu software. E quando sair novas versões, você precisa ter contratos de manutenção ativos pra isso? Utilizado o software como um serviço (SaaS), você embute este custo de atualização em seu investimento.

Finalmente, é importante considerar as implicações financeiras do uso de arquiteturas baseadas em Cloud. Esta na verdade é a meu ver o maior ponto positivo do Cloud Computing. A abordagem "Pagar a medida que você utilizar" é realmente bem atraente para qualquer organização que deseja escalar seu negócio a patamares mais ousados e nunca vislumbrados. Financeiramente falando, arquiteturas baseadas em Cloud permite que você tenha menos gastos com CAPEX, sigla em inglês para Capital Expenditures ou simplesmente, despesas de capital.

Despesas de capital é todo investimento financeiro que você faz antes mesmo que esse investimento entre em operação. Se você compra um servidor, isso é uma despesa de capital pois você deve pagar adiantado e ter os benefícios deste investimento em um tempo que vai de dois a três anos. Pegue o exemplo da compra de um servidor que custa R$ 50.000,00 e gasta R$ 4.000,00 para configurar e colocar este servidor em operação. R$ 50.000,00 é uma despesa de capital e R$ 4.000,00 é o custo sob demanda. Do ponto de vista contábil, R$ 50.000,00 é um valor que sai de uma conta com ativo a uma outra conta de ativo, ou seja, você está movendo capital que representa apenas ativos fixos. Da mesma forma, contábilmente falando, R$ 4.000,00 é um valor que representa um investimento direto em sua rentabilidade financeira, não sendo considerado portanto, um ativo. Neste caso, o servidor, do ponto de vista contábil, é um ativo depreciável. O que isso significa? Que a medida que esse servidor é utilizado, ele perde seu valor original (Ele não vai mais custar R$ 50.000,00) e tende a ser um fardo financeiro.

Num próximo artigo, irei explorar as implicações técnicas de se investir em arquiteturas baseadas em Cloud, em especial, sobre como desenvolver aplicações que estejam prontas para Cloud. Até mais!

O BPM que faço hoje... é realmente BPM?

2011-03-05T03:56:00.000-08:00

Você sabia que BPM é algo que já existe e é hype a pelo menos 30 anos? É interessante observar isso pois, até percebemos que algo tão popular atualmente possa ter sido criado a vários anos e somente agora tenha ganhado tamanha popularidade, mas é dificil de acreditar que, no caso de BPM, a 30 anos que ele já era algo tão badalado e super-estimado como é hoje. Esse é mais um caso do fênomeno "conceito-reiventado", como o que acontece com diversas tecnologias que assolam nosso mercado de tecnologia da informação. Vamos entender um pouco da história do BPM para compreender como esse fenômeno ocorre.

A história do BPM, escrita ao longo dos últimos 30 anos

Em 1980, várias organizações desprenderam um investimento e atenção considerável no que era conhecido e popular na época como TQM. TQM é a sigla de Total Quality Management, uma abordagem sistemática para garantia de que produtos e/ou serviços de uma dada organização estariam sempre evoluindo quanto a qualidade, a fim de evitar que a taxa de evasão de clientes aumentasse em detrimento da pesada concorrência nos setores da organização. Ou seja, uma abordagem sistemática (portanto processual) para garantia de retenção de clientes e, portanto, estabilização garantida da rentabilidade, dois indicadores bastante comuns atualmente quando se fala em BPM.

O ano agora é 1990. Surge a década demarcada pela presença do BPR, sigla de Business Process Reegineering, técnica inspirada e influenciada por Hammer e Champy, que ressaltava a atenção especial a ser dada a análise e modelagem dos processos do negócio, objetivando a melhoria contínua do entendimento funcional das organizações. BPR teve uma grande repercussão, baseado em vários casos de sucesso, como também casos de fracasso. O meio dos anos 90 também marcado pela introdução e proliferação do conceito de ERP, sigla de Enterprise Resource Planning. Seguindo a linha de raciocínio sobre eficiência operacional, ou seja, obter os mesmos resultados (ou melhores) com cada vez menos recursos, a técnica de sistematizar a utilização consciente e reduzida dos recursos se tornou bastante popular, principalmente com o advento dos diversos sistemas de informação de "caixinhas" como aplicativos da SAP, Microsiga, TOTVS que prometiam ser a solução para todos os problemas.

Seguido do grande fenômeno causado pelos ERPs, veio na mesma década o foco especial em clientes e na visualização eficaz de informações de clientes para sustentação de tomadas de decisão mais estratégicas e menos operacionais, propciando cenários por exemplo, de realização de cross-selling e up-selling por parte de organizações como bancos, operadores de telefonia e empresas de varejo. Surge então a era das soluções de CRM, sigla de Customer Relationship Management. A tendência agora é o foco inexorável no cliente e não somente, nos recursos. Do ponto de vista da linha do tempo, estamos beirando a chegada da década de 2000.

O inicio da década de 2000 foi marcado pelo conceito e técnicas de Six Sigma, abordagem criada e desenvolvida pela Motorola que depois foi amplamente utilizado por diversos segmentos e indústrias. As técnicas eram em sua maioria focadas na redução de defeitos através da análise minuciosa das possíveis causas destes defeitos, o que leva as organizações a revisão completa de todos os seus processos de demanda, elaboração, logística e entrega de produtos e serviços. Através da correta aplicação das técnicas de Six Sigma, a Motorola e demais organizações visavam aumentar a retenção de seus clientes e detrimento do aumento de sua qualidade e eficência (TQM + ERP) porém com a grande diferença de não focar somente em processos de negócio individuais como departamentos ou áreas de produção isoladas, mas sim, em toda cadeia de valor que culmina na entrega de produtos e serviços ao cliente, cobrindo também, muitas das vezes, no reflexo que isso causa a organização no que tange a rentabilidade. Eram também objetivos do Six Sigma prover métodos para monitoração da saúde do negócio, porventura feito através da análise de indicadores do negócio, que possibilitava que a organização pudesse saber quando seria interessante adquirir outras organizações ou mesmo ser adquirida no momento certo que lhe desse maior lucratividade.

De acordo com Hammer (1993), "Conceber novas idéias é a parte mais fácil, mas concretizar essas idéias e transformá-las em fatos é a parte mais difícil". Através da simples análise das relações e objetivos de todas as técnicas (ou "gerações" do BPM), podemos ver claramente que BPM é nada mais que a soma de todas as escolas de engenharia de processos vividas, mostradas e provadas ao longo dos anos. Mas com base nos objetivos de cada técnica, e, portanto, nos objetivos de uma estratégia de BPM, temos hoje realmente casos onde BPM foi corretamente aplicado? A experiência fala que, sim, existem casos de sucesso onde BPM foi corretamente aplicado, mas, segundo o Gartner, estes representam apenas 5% de todos os casos de projetos que se auto-intitularam, projetos de BPM.

A compilação das experiências e a formação do conceito

Com base da revisão da história do BPM que fizemos, creio que podemos sintetizar vários pequenos objetivos que uma boa estratégia de BPM deve entregar. Estes objetivos individualmente, devem ser adequadamente entregues para que o valor seja agregado a estratégia. Neste caso, cada objetivo deve ser entregue através de uma ou mais evidências que garantam o seu pleno cumprimento. São eles:

1) Aumento da retenção de clientes através de fidelização destes
2) Aumento da qualidade dos produtos e serviços oferecidos
3) Assimilação do conhecimento e difusão dos processos de negócio
4) Aumento da eficiência através da melhor utilização dos recursos
5) Possibilidade de tomada de decisões rápidas e mais estratégicas
6) Criação de mais negócios e oportunidades em clientes existentes
7) Visão mais holística dos processos, suas relações e dependências
8) Acompanhamento da saúde do negócio através de indicadores
9) Métodos para revisão contínua da estratégia organizacional

Apresentado os principais objetivos de uma estratégia de BPM, comece a se perguntar: Em todos os tais "projetos de BPM" que você ouviu falar ou mesmo achou que executou, quantos destes objetivos foram entregues? Em minha experiência, tenho visto muitos profissionais no mercado que dizem fazer BPM ou terem feito BPM sem nunca na vida terem refletido, como fizemos agora, sobre o que realmente implica na realização da uma estratégia de BPM. Vejo profissionais que usam tecnologias de workflows e máquinas de estado ou mesmo composição de serviços (BPEL) em estratégias intituladas de "projetos de BPM" que jamais conseguirão entregar tais objetivos. Vejo também, além de profissionais de TI que desenvolvem tais projetos, profissionais de gerência de projetos e analistas de processos que dizem ser especialistas em BPM, mas que ao final de seus engajamentos jamais entregarão nenhum dos objetivos listados e cuja única preocupação é a entrega do escopo no prazo e no custo negociado.

A conclusão da reflexão é que as pessoas esquecem o real significado da letra "M" em BPM. Qualquer aplicação Java ou .NET que coordena um conjunto de telas na forma de um fluxo é chamada de aplicação de BPM. Qualquer tecnologia que possibilite a modelagem, simulação, execução e monitoração de um ou mais processos de negócio se intitula suíte de BPM. Qualquer analista ou gerente de projetos que coordena uma iniciativa de melhoría de processos se intitula de analista de BPM. E, por fim, qualquer empresa que realiza um projeto que tenha alguma relação com uma área de negócio de uma organização se intitula empresa de BPM.

Além da clara falta de visão e entrega dos objetivos de negócio discutidos anteriormente, tais situações se enganam em pensar que fazem BPM devido a falta de execução de uma equação muito simples:

BPM = N * (APN + EPN + MPN)

Onde:

N = Número de ocorrências. Valor inicial é 3.
APN = Análise do(s) Processo(s) do Negócio
EPN = Execução do(s) Processo(s) do Negócio
MPN = Melhoría do(s) Processo(s) do Negócio

A leitura desta equação é a seguinte: Você só terá uma estratégia de BPM formal quando você entregar, pelo menos, 3 ou mais projetos que contemplem as atividades de APN, EPN e MPN, não respectivamente mas obrigatoriamente. E o mais importante de tudo é que, apesar de isso ser uma equação, que visa mostrar sistêmicamente uma idéia ou conceito, a realização desta equação têm como objetivos não o cálculo ou medição, mas a entrega de um ou mais objetivos cumpridos, objetivos esses que agregam valor as organizações.

"Você não pode controlar aquilo que você não pode medir" - Tom DeMarco

Maximizando sua Rentabilidade através do Progress Actional

2011-01-08T06:14:00.000-08:00

No atual cenário econômico mundial, organizações de diferentes segmentos estão em constante busca por meios de maximizar suas oportunidades de serem mais rentáveis, sem ter que investir em dispendiosos sistemas ou na contratação de mais e mais pessoas. Uma forma de se conseguir isso é assegurando o sucesso individual de cada pequena transação do seu negócio, transações estas como o processamento de uma compra via cartão de crédito, o registro de um hóspede num hotel ou habilitando uma nova linha telefônica para um cliente. Se uma organização conseguir assegurar estas transações de negócio, ela terá um aumento siginificativo em sua rentabilidade, na produtividade de seus funcionários e um aumento considerável da satisfação dos seus clientes.

Se um problema ocorre em qualquer uma destas transações, tal como atraso na confirmação de um pedido de compra, demora de uma cotação de seguros para uma corretora ou perda de detalhes sobre uma chamada telefônica, então a oportunidade de maximizar a rentabilidade desaparece e os clientes irão rapidamente em busca da concorrência para terem seus produtos ou serviços desejados.

Para complicar mais ainda a vida das organizações, existe o fato de que a maioria destas transações de negócio são típicamente executadas em sistemas complexos e altamente distribuídos, isto é, estão espalhadas por diversos servidores, bancos de dados e tecnologias de middleware de diferentes fabricantes e configurações.

Para que uma organização possa assegurar o sucesso destas transações de negócio, ela precisa ter visibilidade de toda a sua infraestrutura de TI, de ponta à ponta, contemplando até mesmo parte da infraestrutura de TI de seus parceiros de negócio e seus fornecedores, pois estes porventura serão envolvidos em todas as transações e processos de negócio que envolva a prestação de um serviço ou a entrega de um produto aos seus clientes.

É necessário também que ela possa rapidamente detectar, diagnosticar e reagir aos problemas que ocorrem, antes que o seu negócio seja impactado e antes que seus clientes saibam destes problemas. Para conseguir isso, ela precisa, depois de conseguir visibilidade de ponta à ponta, estabelecer políticas rígidas sobre os serviços que sua infraestrutura realiza para sustentar seus processos de negócio. Garantindo estas políticas, ela estará alinhada com os objetivos estratégicos da sua organização.

Para conseguir isso, organizações do mundo todo têm recorrido ao Progress Actional, a solução líder da indústria que ajuda companhias como a sua, a gerenciar ambientes complexos e distribuídos e a assegurar transações de negócio, objetivando a maximização da rentabilidade, aumento da satisfação dos clientes e o aumento da produtividade dos funcionários.

Neste artigo, irei mostrar como o Progress Actional pôde ajudar uma companhia de linhas aéreas a conseguir ser mais responsiva operacionalmente e a maximizar sua rentabilidade através da eficiente monitoração, gerenciamento e governo da sua infraestrutura de TI. O estudo de caso fala sobre uma empresa fictícia, criada apenas para fins didáticos. Qualquer semelhança com qualquer companhia do segmento de linhas aéreas é mera conscidência.

Estudo de Caso da BlueSky Linhas Aéreas

A BlueSky linhas aéreas é uma empresa brasileira focada na prestação de serviços de vôos nacionais e internacionais. Ela opera no mercado brasileiro desde 1992, onde sempre conquistou vários clientes com sua forma especial de lidar com o cliente e seus passageiros. Nos últimos meses, a BlueSky observou que seu faturamento diminuiu consideravelmente, e o nível de insatisfação de seus clientes começou a crescer. Seu faturamento caiu 60% nos últimos dois quarters, e a concorrência está cada vez mais a frente do seu mercado, liderando todas as posições de preferência dos clientes.

Além disso, a própria imagem da companhia já está sendo prejudicada. Seu serviço está virando sinônimo de piadas, as pessoas compram suas passagens somente quando as da concorrência já não estão disponíveis, enfim, ela não é mais a referência no mercado brasileiro de melhor companhia de linha aérea. Na última semana por exemplo, o Twitter teve um estouro de tweets com a hashtag #blueSkySucks, considerado o maior volume de tweets da história do Twitter.

Tentanto entender porque tal situação acontecera e porque ficou tão fora de controle, O CEO da BlueSky descobriu que grande parte dos problemas estavam relacionados a sua infraestrutura de TI, e ao excesso de tempo necessário para investigação e correção de problemas em produção, bem como o alto custo relacionado as equipes de infraestrutura e suporte. Quando problemas aconteciam, era necessário que todas as equipes (infraestrutura, desenvolvimento, banco de dados e redes) ficassem de plantão horas a fio em seus blackberry's, até mesmo altas horas da madrugada. O custo com horas extras estava crescendo astronômicamente, além de que os problemas eram recorrentes, nunca se encontrava a real causa dos problemas, apenas criava-se soluções de contingência.

Ao questionar a diretoria de TI sobre a razão pelo qual a BlueSky ainda passava por aqueles tipos de problemas que eram diariamente vivenciados, o CEO da BlueSky descobriu que baseado em sua complexa infraestrutura de sistemas, servidores, banco de dados e plataformas, era quase impossível descobrir a causa dos problemas de forma rápida e eficaz. Com mais de 19 anos de existência, a BlueSky já havia adquirido mais de 80 sistemas de informação, 6 tipos de soluções de banco de dados, 3 tipos de servidores de aplicação Java EE, e já contava com mais de 120 web services que são utilizados nas operações da companhia.

Preocupado com a situação, o CEO da BlueSky resolveu então procurar alguma solução no mercado que resolvesse seu problema. Ele sabia que o seu problema era a falta de capacidade de ser mais eficiente operacionalmente, e de não poder dar respostas rápidas as demandas do mercado e aos desafios do dia a dia. Foi ai então que ele encontrou o Progress Actional, uma solução integrada para assegurar transações de negócio e monitorar de ponta à ponta complexos e heterogêneos ambientes de TI, como o da BlueSky linhas aéreas.

A Solução da BlueSky Linhas Aéreas

Os vídeos abaixo mostram como o Progress Actional ajudou a empresa BlueSky a voltar a ser a companhia aérea de melhor prestígio no mercado brasileiro. A série de três vídeos mostra, passo à passo, a aderência do Progress Actional com o cenário da BlueSky.

Visão Geral sobre a Arquitetura Técnica da BlueSky Linhas Aéreas

Identificando Problemas e Gargalos nas Transações de Negócio da BlueSky

Melhorando a Tomada de Decisões da BlueSky com Análises Dimensionais

Se você deseja conhecer mais detalhes sobre como o Progress Actional ajudou organizações do mundo todo a serem mais responsivas operacionalmente, leia alguns casos de sucesso do produto como o da Bendit Digipen, British Airways, Intercontinental Hotels Group, Partners Healthcare e o da West Bend Mutual.

"Progress Software allows you transform the way you do business, from how you operate to how people work - their secret sauce is the ability to expose/extract key elements in the process flow and begin to make improvements immediately" - Forrester

"With Progress Software, you can listen to transactions irrespective of underlying software components and correlate then to the process view without reeengineering. This is incredible valuable..." - Gartner

"Key differentiator for Progress Software is true discovery and correlation - this is what set them apart" - IDC

Criando um Processo BPEL usando Sonic ESB

2010-12-31T11:33:00.000-08:00

Você trabalha na área de integração de TI numa operadora de telefonia do Brasil e seus gerentes funcionais lhe pedem para criar um serviço que possa dizer se determinado número de celular pode ou não ser portado de uma operadora para outra. Você sabe que para fazer isso, você deve primeiro consultar na base de dados de contratos de clientes da operadora para saber se aquele número está disponível, bem como assegurar que o dado número já não possui um pedido de portabilidade numérica feito por outra operadora concorrente.

Este serviço precisa ser disponibilizado nos próximos 25 minutos, pois o novo portal Web da operadora já contempla esta funcionalidade (de fato uma das funcionalidades mais esperadas neste novo portal) mas devido a problemas de comunicação entre as equipes do projeto, esqueceram de avisar você que o portal deve ser lançado hoje. A unica coisa que você possui em mãos é um Web Service chamado de ProvisioningService que responde se o número de celular está ou não disponível e um Web Service da Anatel chamado GatewayAnatelService que responde se o número possui ou não um pedido de portabilidade numérica. E agora, o que você faz?

Neste post, iremos mostrar como usando o Sonic ESB, podemos criar um Web Service que atenda a funcionalidade especificada. Para isso, criarei passo à passo um Web Service composto, ou seja, um Web Service que é baseado em um ou mais Web Services existentes. E pra isso, usarei a tecnologia BPEL. Utilizando o Sonic ESB, irei criar em apenas 25 minutos, um processo BPEL (Web Service) que irá responder se determinado número de celular está ou não disponível para portabilidade numérica.

Parte 1 - Criação Inicial do Processo BPEL e Definição da Interface da Operação de Consulta de Disponibilidade

Parte 2 - Implementação do Fluxo do Processo BPEL através dos Web Services Previamente Implementados

Parte 3 - Implantação do Processo BPEL dentro do Sonic ESB e Testes usando Cenários e Ferramentas de Depuração

Depurando Cenários de Integração usando Sonic ESB

2010-12-26T07:55:00.001-08:00

Você lembra do excelente artigo escrito por Gregor Hohpe em 2002 sobre EAI dirigido à testes? Sem dúvida, é até hoje um dos melhores artigos sobre o assunto, mesmo nos dias de hoje. No Artigo, ele fala sobre como conduzir testes de arquiteturas baseadas em integração e de multiplas camadas, cenário este que pode ser bem desafiador sem as ferramentas adequadas. Cenários de integração são por natureza dificeis de testar, pois você envolve diversas plataformas e aplicações distintas para atender a uma necessidade da organização.

Neste post, iremos mostrar os recursos e ferramentas que o Sonic ESB disponibiliza em seu ambiente de desenvolvimento para realizar complexas tarefas de depuração de cenários de integração, não importanto o tamanho ou natureza do cenário à ser testado. Confira estes recursos no vídeo abaixo.

Criando um Web Service usando Sonic ESB

2010-12-23T14:42:00.001-08:00

Imagine que você recebe a tarefa de disponibilizar para um parceiro de negócios, cliente ou mesmo fornecedor, um Web Service que ofereça a capacidade de buscar seus produtos em sua base de dados corporativa. Mas você possui apenas uma hora para fazer isso, e a única coisa que você possui pronta é a base de dados contendo os produtos. A equipe de infra-estrutura aguarda que em uma hora você tenha este Web Service pronto e funcional para que eles possam somente disponibilizar no servidor da Web exposto fora do firewall. Você deve implementar os seguintes requisitos funcionais e não-funcionais:

Busca de um determinado produto na base de dados, dado o código de identificação (chave primária) deste produto
Exibição uma mensagem descritiva de falha caso o produto não seja encontrado no Banco de Dados
Exibição uma mensagem descritiva de erro caso ocorra uma falha de comunicação com o Banco de Dados
Conectividade com o servidor de banco de dados MySQL 5.1, suporte a transações XA e mecanismo de fail-over para JDBC
Expor este Web Service numa porta específica do servidor de aplicações que irá hospedar o Web Service (Ex: Porta 5555)

E agora, o que você faria?

Este é o tipo de cenário que o Sonic ESB visa resolver. Através do Sonic ESB, você pode criar e manter processos de integração complexos como este, como o mínimo de esforço, sem ter que perder tempo com cansativas e errôneas horas de escrita de código em Java, C#, Ruby ou mesmo XML, além de poder garantir os requisitos funcionais e não-funcionais através de cenários de testes integrados e de regressão.

Para mostrar como isso pode ser feito, criei cinco vídeos que mostram passo à passo, a criação deste mesmo cenário, e a fim de suprir as expectativas, o cenário é criado e testado em apenas 48 minutos, menos de uma hora. Desafiador concorda? Pegue seu cronômetro e veja como isso é possível nos vídeos abaixo.

Parte 1 - Definição de um Modelo de Dados Canônico e dos Tipos Complexos

Parte 2 - Implementação da Lógica Inicial do Web Service

Parte 3 - Implementando á Consulta do Produto no Banco de Dados MySQL

Parte 4 - Tratando à Exceção "Produto não Encontrado" usando Faults

Parte 5 - Tratanto o Erro "Falha de Comunicação com o Banco de Dados"

Este é o tipo de velocidade que somente o Sonic ESB pode lhe trazer. Não é a toa que o Sonic ESB é o melhor ESB do mundo: Além de rápido e elegante, ele é super escalável e resiliente. Desculpe a concorrência mas quando o assunto é Sonic, o resto é literalmente, apenas o resto.

Introdução ao Progress Savvion BPM

2010-12-05T14:00:00.000-08:00

Quem acompanha a Progress Software sabe que, ela é uma empresa que diferentemente dos seus concorrentes, está continuamente a frente do seu próprio tempo, seja tecnologicamente, seja estratégicamente. A sua diferença se dá nas tecnologias e produtos que ela possue, seja por sua própria criação, seja pelas empresas que ela adquiriu ao longo dos anos. Alguns exemplos disso são suas soluções de CORBA, resultado da aquisição da IONA Technologies, líder mundial em soluções CORBA. Outro bom exemplo é o ESB mais rápido, simples e robusto do mundo, o Sonic ESB, resultado da aquisição da Sonic Software. Outro exemplo também interessante é sua plataforma de governança SOA conhecida como Actional, resultado da aquisição da MindReef. Vários outros exemplos podem ser citados também como DataDirect Technologies, Fuse Source, Apama entre outros.

Dentre todas estas aquisições, uma delas sem dúvida foi a melhor semente que a Progress Software plantou: A aquisição da Savvion. A Savvion é uma empresa que foi adquirida pela Progress Software em 11 de Janeiro de 2010, mas que possui uma estória de sucesso de 15 anos com clientes do mundo todo na área de BPM e tecnologia para melhoría contínua de processos de negócio. Agora imagine o que são 15 anos (5.475 dias) sendo uma empresa focada num único nicho, e que a cada ano vivido, investiu cada vez mais em sua tecnologia. O que você espera, no mínimo de uma empresa como essa? Se você pensa como eu, deve imaginar com certeza uma plataforma de BPM que já passou por diversos ciclos de melhoría e que se encontra num nível de maturidade muito alto. Deve esperar por uma plataforma de BPM que já foi utilizada por vários clientes do mundo todo, clientes esses que devem ter várias estórias de sucesso para contar. Diferentemente das plataformas de BPM dos concorrentes que possuem alguns poucos anos de experiência (entre 4 à 6 anos de existência), a Savvion definiu e liderou a essência do que é e o que deveria ser uma plataforma de BPM. Afinal de contas, estamos falando de 15 anos, e nada mais justo que ela seja pelo menos um dos líderes do Forrester.

Para apresentar um pouco do que essa plataforma de BPM é capaz, preparei especialmente para vocês uma sequência de vídeos que mostram, passo à passo, a modelagem, automação, simulação, implantação, utilização e monitoramento de um processo de negócio simples, mas que revela o potencial da solução. Neste post irei dar inicio à bateria de demonstrações dos produtos da linha Savvion, onde espero poder demonstrar a realidade que eu vejo: o poder e a supremacia na área de BPM que somente o Progress Savvion pode oferecer. Espero que gostem!

Parte 1: Modelagem de um Processo de Negócio usando Savvion BPM Studio

Parte 2: Automação do Processo de Negócio usando Savvion BPM Studio

Parte 3: Simulando o Processo de Negócio usando Savvion BPM Studio

Parte 4: Implantando o Processo de Negócio no Savvion BusinessManager

Parte 5: Utilizando o Processo de Negócio no Savvion BPM Portal

Parte 6: Monitorando o Processo de Negócio usando o BAM do Savvion (Savvion BusinessExpert)

Manipulando Flat Files com o Sonic ESB

2010-11-21T16:02:00.000-08:00

Você sabia que, na TI de qualquer empresa de médio e grande porte, são mantidos cerca de 40 à 60 cenários de integração que subsidiam alguns processsos de negócios críticos? Dentre estes cenários, um deles é o caso onde as informações são integradas via arquivo texto, e o arquivo deve ser processado e enviado à algum canal de dados particular, como sistemas de mensageria, uma tabela de banco de dados ou mesmo o acesso a um web service ou um componente EJB.

Imagine o esforço e tempo dedicados à criação e mais ainda, a manutenção destes cenários? É razoável pensar em formas de se manter ambientes como estes da forma mais simples, ágil e agradável possível. E pra isso, você deve usar as ferramentas corretas. Neste post, irei mostrar como o Sonic ESB da Progress Software pode ajudar você a manter cenários de integração complexos com extrema facilidade e elegância. Para mostrar isso, irei criar passo a passo, um cenário onde um arquivo CSV será lido pelo Sonic ESB, e depois de realizado o processamento (a transformação da mensagem do formato CSV para XML) será enviado à uma fila JMS do tipo Topic.

Parte 1: Criação inicial do projeto e transformação CSV para XML

Parte 2: Adequação da mensagem XML usando XSLT

Parte 3: Implantação do projeto no domínio do Sonic ESB

Boas Integrações ;-)

O Mundo Perfeito para SOA, CEP & BPM ... Existe?

2010-11-15T03:25:00.000-08:00

Depois de vários anos discutindo sobre SOA, CEP e BPM, seja neste blog ou em outros veículos de comunicação, já podemos perceber claramente o valor de uma arquitetura orientada a serviços (SOA), do processamento de eventos complexos (CEP) e do gerenciamento de processos de negócio (BPM) dentro das organizações. BPM ajuda as empresas a serem mais responsivas quanto as mudanças de mercado e a constante busca por eficácia e eficiência em pró de atender as demandas de seus clientes, parceiros e funcionários. SOA por sua vez, têm como premissa transformar a TI numa arma estratégica para que objetivos de negócio como melhoría de processos e atendimento a demandas de mercado possam virar uma realidade ágil, quebrando portanto a imagem que a TI hoje possui de ser um custo ao invés de um investimento, bem como de ser honerosa, dispendiosa e pouco eficaz. A TI ainda conta com outra arma poderosa para prova do seu valor: CEP. O processamento de eventos complexos visa monitorar nuvens de eventos e detectar padrões nestes eventos que os relacione de tal forma, a identificar uma condição especial que seja de suma importância para as organizações, condições como ameaças de produtos de concorrentes, falhas num processo de atendimento, novas oportunidades de atendimento, etc, condições estas que representam o conceito de eventos complexos. Empresas de "tempo real" ou empresas que devem possuir alto poder de resposta imediata as nuances do mercado ou as ameaças ao seu negócio devem possuir, mesmo que tímido, um investimento em CEP.

E como ter excelência nestes três assuntos dentro das organizações? profissionais do mercado, depois de alguns bons anos experimentando a aplicação de SOA, CEP e BPM nas empresas, têm observado que para que estes possam provar seus valores e cumprir seus objetivos, deve-se criar uma fundação de referência, com alto de poder de visibilidade e investimento nas empresas, que tenha a capacidade de liderar uma ou mais iniciativas (paralelas ou não) seja de SOA, CEP ou BPM. Para cada uma destas abordagens, deve-se criar o então já conhecido, centro de excelência ou simplesmente CoE. Um CoE deve ser visto numa organização como um "departamento" unipresente em todas as iniciativas da organização, sendo responsável por todas as questões sobre seu foco. Um CoE de BPM por exemplo, deve ser participado em todas as questões sobre melhoría de processos de negócio, e deve ter como participantes e interessados, pessoas de toda a organização, desde as pessoas que vivem os processos, até as pessoas que liberam orçamentos para novos investimentos.

Criar um CoE sólido e de credibilidade não é uma tarefa trivial. São necessários vários projetos de sucesso para que possamos dar os primeiros passos na instituição de um centro desses numa organização. E estamos falando apenas de um destes centros de excelência, como por exemplo, o de BPM. No mundo perfeito, deveríamos ter pelo menos três CoE's instituidos, SOA, CEP e BPM respectivamente. É notório portanto, quanto tempo leva e quanto custa instituir estes CoE's nas organizações: É demorado e é caro ... e tudo que demora e é caro facilmente se torna um risco, e riscos são situações que os investidores não gostam de viver. Contextualizado o cenário, você deve estar se argumentando: "Investir em SOA, CEP ou BPM então é algo inviável, dá muito trabalho e facilmente você pode ser levado ao fracasso!".

De fato, é uma argumentação válida, no sentido de que, implementar SOA, CEP e BPM num nível de maturidade que estes possam apresentar resultados que justifiquem próximos investimentos (um CoE) não é realmente uma tarefa trivial. Mas posso discordar quando se afirma que é algo inviável ou impossível. Inviável será se você não fizer um bom estudo de retorno de investimento (ROI) sobre a iniciativa que você deseja liderar. Sem uma boa justificativa sobre o quão lucrativo pode ser um investimento, ninguém em sã consciência enfia a mão nos bolsos. E impossível será, se você não usar as ferramentas, tecnologias e práticas corretas. Esta é a trinca perfeita sobre implementar uma boa solução, ter a ferramenta correta, a tecnologia adequada, e as práticas de mercado consagradas na implementação de uma abordagem.

O mundo perfeito para SOA, CEP ou BPM portanto, existe. Pra chegar nele, você deve ter uma série de projetos de sucesso, que tal como a figura de abertura do post (o gráfico acima) demonstre sucessivas implementações de sucesso que a cada vez, demonstram cada vez mais valor e maior agilidade, coeficientes principais na mensuração de um sucesso de um CoE. Essa é a premissa principal. A premissa operacional é que a cada projeto, você tenha sucesso, premissa esta que sustenta o resultado da premissa anterior. Sem o sucesso de um projeto individual, o fator de crescimento irá parar, e o mundo perfeito jamais poderá ser alcançado. E para ter sucesso um projeto, use as ferramentas, tecnologias e práticas corretas. Se você já sabe as práticas corretas, já sabe quais as tecnologias de mercado que são mais atrativas para SOA, CEP ou BPM, então o que lhe resta é utilizar as ferramentas corretas, e para isso, você precisa de uma referência, um guia que possa lhe ajudar a escolher, entre várias opções, aquela que possa cumprir a premissa operacional de implementar um projeto de sucesso. Nas próximas seções, irei mostrar com alguns exemplos, quais as perguntas que devem ser feitas na escolha de ferramentas para SOA, CEP e BPM, e qual deve ser a resposta aproximada para cada pergunta.

Business Process Management

... Utilize uma ferramenta de modelagem simples, intuitiva e bonita, que além disso esteja de acordo com padrões de mercado como XPDL, BPMN e BPEL ...

... Ao modelar processos de negócio, defina suas regras de negócio usando abordagens baseadas em wizards, evite linguagens que mesmo em alto nível, sejam de programação. Lembre-se que quem define estas regras e processos, não frequentou escolas e faculdades de TI ...

... Garanta que a ferramenta de modelagem de processos possui recursos de simulação destes processos. Quando você pode simular os processos ainda em tempo de desenho, você evita que o patrocinador de BPM espere até que o processo esteja operacional para ver se ele teve efeito ou cumpriu os objetivos traçados, criando portanto um ROI mais rápido de ser avaliado e recuperado. Na maior parte das vezes, os donos dos processos ao verem os processos "executando" mesmo que em simulações já podem ter a percepção sobre melhorar a utilização dos recursos (pessoas e sistemas) ou a direção do valor dos processos ...

... É interessante também que a ferramenta de simulação possa gerar relatórios sintéticos e analíticos sobre as simulações. Depois de 3 ou 4 simulações e ciclos de modelagem e melhorías, você pode observar como o processo se comporta nas diferentes situações especificadas (Happy Path, Alternative Flows, Exceptions) e aferir quanto a robustez do processo ...

... Preocupe-se em como os usuários (clientes, parceiros, funcionários ou fornecedores) irão interagir com os processos. No ramo de varejo, bancos e seguros por exemplo, 70% de um processo de negócio é composto por tarefas humanas. Assegure que a solução de BPM disponibilize uma plataforma agradável para a interação de tarefas humanas ...

... A solução de BPM possibilita que você rastreie uma instância de processo em andamento ou finalizada? É importante saber como andam os processos, ou no caso de alguma anomalia, saber que informações ou eventos aconteceram na execução de um processo ...

... Como seus gestores e líderes de área monitoram a performance do negócio? A solução de BPM disponibiliza um BAM (Business Activity Monitoring) digno de visualização de um diretor ou um patrocinador? Quão simples é implementar métricas de desempenho do negócio? O BPM possibilita a customização de métricas implementadas Out-Of-Box? Ele te dá previamente implementado sistemas de BalanceScoreCards? ...

... Crie dashboards de monitoração do negócio que possam dar poder e visibilidade aos usuários chaves, gestores de área e grupos de direção. Várias visualizações (Cubos) devem podem ser utilizados, e a origem dos dados apresentados em gráficos devem ser transparentes para os usuários. As perguntas respondidas devem ser: Como andam as minhas vendas? Quanto eu perdi na última hora com a NASDAQ? Qual o nível de satisfação dos meus clientes? Como meu concorrente se posiciona perante minha oferta de produtos e serviços? ...

Service-Oriented Architecture (Enterprise Service Bus)

... O ESB utilizado possui consoles de gerenciamento de fácil utilização, que compreendam todas as facilidades do produto? Quanto um recurso particular do ESB precisa ser configurado, você faz isso clicanco e arrastando ou escreve código Java ou XML? Como você aprovisiona os recursos da máquina para sustentar picos e novas demandas? Como você observa a utilização dos serviços e componentes do ESB? Como você coloca seu ESB em cluster? ...

... Para testar seus serviços você precisa escrever código? Para testar o envio ou recebimento de uma mensagem JMS, você precisa de uma IDE de desenvolvimento Java? Como você testa a garantia de entrega de mensagens, e a persistência de mensagens JMS? ...

... BPEL é uma linguagem baseada em XML extremamente difícil de escrever e de implementar. Se você não conhece a notação e a especificação da linguagem, sem um bom editor visual você pode ficar horas ou dias tentando fazer algo trivial. Use ferramentas de implementação que possam abstrair a complexidade do BPEL e que possa fazer com que foque no que realmente importa: Fazer a composição de Web Services funcionar ...

... E os seus serviços internos do ESB? Sabemos que um serviço normalmente é baseado em sua interface de acesso, que pode ser REST, JMS, SOAP, File ou SQL, mas independente da interface de acesso, como você define o comportamento (implementação) dos seus serviços? Programando em Java? escrevendo XML ou utilizando outros meios mais especialistas? Não faça isso, use abordagens mais ágeis e seguras e que não dependam de um especialista numa linguagem ou plataforma ...

... A arquitetura de um ESB é baseada no conceito de pipeline ou canal de mensagens. Com isso, quando uma mensagem chega a este canal, esta é processada ou um ou mais filtros ou etapas de execução. Ao enviar os dados da mensagem de uma etapa para a outra, você precisa escrever código XML ou Java pra isso? Use abordagens visuais que inibam você de causar problemas na construção de um serviço ou processo ESB. Torne a mudança dos parâmetros de uma mensagem uma tarefa trivial e segura, e não uma fonte inesgotável de problemas na hora da manutenção ...

... Um dos recursos mais comuns em qualquer ESB é o roteamento de mensagens dinâmico, baseado nas informações da mensagem a ser processada. É de suma importância que você possa lidar com roteamentos dinâmicos de forma ágil e segura. Não use plataformas de ESB que exponham você a detalhes internos de implementação para definir coisas simples como: "Vá para a etapa X caso tenha uma informação Y na mensagem". Não gaste mais do que 30 minutos na construção e teste de uma roteamento dinâmico ...

... Testar serviços de um ESB é uma tarefa que naturalmente é complexa, principalmente quando você possui serviços que possuem várias etapas ou fases. É importante utilizar ferramentas que possam testar isoladamente cada etapa do processo (Ex: Um acesso a um banco de dados SQL) e também que possam testar o processo completo, sem que para isso, você tenha que fazer deploy do mesmo. Use também ferramentas que possam lhe ajudar a realizar depuração de problemas. Use conceitos como "Breakpoints", inspeção de variáveis, "Watche's", etc. Sim, isso existe em soluções de ESB's ...

... XSLT também é uma linguagem baseada em XML extremamente difícil de escrever. Poucas são as pessoas que conhecem de fato a linguagem, mas mesmo estas, ao escrevem programas XSLT "Na mão" enfrentam problemas na horas dos testes ou mesmo a abordagem mais confiável. O mesmo se aplica ao REST. Devido a simplicidade da abordagem, várias alternativas podem ser aplicadas, mas a alternativa mais escalável e recomendada nos foge quando implementamos. Use ferramentas que tornem o dia a dia do desenvolvimento de soluções baseadas em REST e XSLT mais simples ...

Service-Oriented Architecture (Governance, Management)

... Gerenciar os ativos de uma fundação SOA é algo primário. Ter uma visão holística sobre os serviços, plataformas e sistemas que compôem uma arquitetura orientada a serviços é uma premissa básica para uma correta governança dos serviços. Saiba em tempo real as relações entre os serviços, monitore o comportamento destas relações e saiba mais sobre a importância de um serviço para a organização ...

... Quando seu cliente, parceiro ou fornecedor pergunta: "Qual o tempo de resposta médio do serviço que estou consumindo?" Como você responde essa pergunta? E independente da resposta, como você acha qual, numa interação entre serviços, quem é o vilão do tempo de resposta? Como você acha os gargalos de um serviço que pode ser distribuido e acessados por vários sistemas rodando em diferentes plataformas? Como você rastreia o tempo de resposta de uma interação entre diferentes tipos de aplicações a plataformas? ...

... É seu cliente que diz que seu serviço está indisponível ou é sua TI que pró-ativamente observa a queda para poder providenciar a ativação da redundância? Você espera seus consumidores reclamarem do tempo de resposta ou das falhas de segurança ou você define políticas de governança em seus serviços é é notificado visualmente quando estas estão comprometidas? ...

... Expor serviços para fora (parceiros, clientes, fornecedores) requer um nível de maturidade de governança bem maior do que quando você têm serviços utilizados apenas dentro da organização. Se você precisa expor seus serviços, preocupe-se com detalhes sobre fronteiras de segurança, Trust Zones, políticas de WS-Security, Reliable-Messaging, autenticação e autorização de domínios, Single-Sign On, porventura transformação da mensagem enviada para adaptação ao WSDL de destino, interceptação das mensagens para fins de auditoria, etc. Todas estas questões devem ser endereçadas em termos de governo dos serviços e não de implementação, principalmente se seus serviços são oriundos de fábricas de desenvolvimento ou foram comprados de um fabricante. Use plataformas de governança que possam endereçar estes pontos, e que possam "mediar" a interação de seus consumidores externos e sua implementação do serviço interno ...

Complex Event Processing

... Implementar, gerenciar e observar eventos não é uma tarefa trivial, os anos e o mercado já provaram isso. Se faz necessário a utilização de não uma, mas várias infra-estruturas diferentes para mapear as etapas de criação, desenho, implantação e observação de eventos e de eventos complexos. Use plataformas de CEP abrangentes e de preferência que sejam referência no mercado e tenham uma história no mundo de CEP e ESP ...

... Modele e descreva seus eventos complexos ao invés de implementá-los. CEP é uma abordagem que só faz sentido se você puder reagir a mudanças e comportamentos dos eventos num piscar de olhos. Se você usa abordagens baseadas em implementação, mesmo que em XML, você fatalmente ao ter que mudar um evento, vai ter que entrar no ciclo "Mudar > Testar > Implantar". A mudança em comportamentos de eventos devem esperar apenas por um "Botão de Ligar" para que entrem em produção, e a garantia de qualidade deve ser provida por um ambiente de desenvolvimento visual que elimine margens de erros de implementação ...

... Você não monitora seus eventos complexos através de consoles de texto ou através de arquivos de saída de log's certo? Isso seria muito irresponsável por parte de um profissional de TI tão distinto como você, principalmente porque não será você a observar os eventos complexos, e sim, os líderes de áreas, e gestores preocupados com a saúde em tempo real do negócio. Use dashboards corporativos que estejam conectados com a plataforma que identifica, detecta e cria os eventos complexos. Preferencialmente, tenha uma ferramenta que possa fazer isso através de dashboards, e que estes dashbordas também possam ser exportados para visualização em outras plataformas de monitoração do negócio, como por exemplo, um BAM ...

Considerações Finais

Vimos neste post algumas das questões que devem ser relevantes quando você está tentanto ter sucesso em SOA, CEP ou BPM. Uma vez que esteja claro que, o sucesso de cada uma destas abordagens depende diretamente da execução sustentável e de sucesso de vários projetos, torna-se necessário a utilização de ferramentas, tecnologias e práticas adequadas.

Vimos também que, independente das tecnologias e práticas escolhidas, alguns exemplos do que seriam ferramentas adequadas para o sucesso de abordagens basedas em SOA, CEP e BPM. Os exemplos sugeridos, são na verdade exemplos das plataformas que a Progress Software oferece aos seus clientes, plataformas estas que em suas áreas, são líderes de mercado, e possuem uma história de sucesso com organizações de diferentes portes e áreas de atuação, bem como histórias de sucesso com a comunidade de software em geral, seja estimulando a criação de tecnologias, seja liderando e sendo responsável por tecnologias no mundo todo, seja sendo referência para a criação de tecnologias, referência até mesmo, para nossos concorrentes ;-)

Se você gostou dos exemplos sugeridos e deseja saber mais sobre as soluções da Progress Software, visite o site http://www.progress.com e conheça melhor nossa tecnologia. Para maiores detalhes, até mesmo técnicos, mande um e-mail para rferreira (at) progress.com, terei maior prazer em atênde-los!

Excelência de Web Services com Actional Diagnostics

2010-11-06T04:38:00.000-07:00

Quem trabalha com Web Services, seja num contexto SOA ou não, sabe que entre o momento que você implementa seu serviço e o momento que o serviço é acessado por um possível consumidor, existe um longo caminho a ser traçado. Web Services são construções poderosas para que você tenha funcionalidades de um aplicativo ou negócio expostas para parceiros, clientes ou fornecedores, mas dão um certo trabalho para ficarem "prontos" para uso. Grande parte das frustrações sobre Web Services começam quando você termina sua implementação (que já representou um considerável esforço) e passa a validar coisas como: Meu serviço está entregando o comportamento ou funcionalidade desejado? Meu serviço está operando com as regras de SLA esperadas? Meu serviço está de acordo com as especificações de interoperabilidade do mercado? Meu serviço possui o comportamento necessário para operação quando detalhes como autenticação, autorização e testes de ataques são considerados?

Outro ponto pertinente é que, exceto o suporte ao desenvolvimento do Web Service em si, a maioria das plataformas de desenvolvimento do mercado, sejam elas baseadas em Java, .NET ou outras, não possuem suporte ao endereçamento das questões postas acima. Isso significa que, um desenvolvedor de um Web Service deve, na maioria das vezes, utilizar cerca de 3 ou 4 ferramentas "auxiliares" que irão ajudar no endereçamento das questões postas. Isso significa que o conhecimento do desenvolvedor começa a se tornar ortogonal, fazendo com que a construção de um dado Web Service fique preso a detalhes de construção que deveriam ser oficiais e padronizados. Se o desenvolvedor que criou um Web Service sair do time de desenvolvimento do projeto por alguma razão, a pessoa que o substituir irá ter uma grande dificuldade: Onde estão os artefatos deste Web Service? Quando preciso fazer testes de carga, qual ferramenta deve ser usada? Qual(is) cenário(s) de testes foram utilizados para endereçar os requisitos funcionais? E os não-funcionais?

Uma solução de software que costuma ser usada para estes casos, é o soapUI. O soapUI é uma ferramenta super poderosa, que mesmo na sua versão "open" possibilita diversas coisas. Mas grande parte das proposições feitas sobre o desenvolvimento e entrega de Web Services não são endereçados pela versão aberta, forçando profissionais a adquirem licenças da versão "Pro" ou então piratearem a mesma. Quando isso não é possível ou viável, a solução é usar técnicas mais criativas para o endereçamento dos problemas citados ou mesmo a utilização de outras ferramentas, tornando o desenvolvimento mais complexo de controlar e manter.

É com base neste cenário que escrevo este post: Você, profissional de construção de Web Services, não precisa mais viver este tipo de problema. A Progress Software, através da sua linha de produtos de governança SOA conhecida como Actional, disponibiliza gratuitamente um de seus componentes chamado de Actional Diagnostics. Trata-se de uma ferramenta leve, aberta e super simples de utilizar, que endereça 100% dos problemas citados anteriormente. Neste post, irei mostrar algumas de suas características através de um cenário de exemplo, para que você possa averiguar sobre a aderência do software ao seu cenário atual.

Mas perai, a Progress Software é uma empresa que possui softwares licenciados, qual a diferença então de usar o soapUI Professional?

Bem antes de mais nada, é interessante explicar que a Progress Software, tal como outras empresas, possui um modelo de negócios baseado no licenciamento de produtos de softwares, assim como o desenvolvimento de tecnologias abertas cuja utilização é livre e possui um suporte profissional como serviço. Isto quer dizer que, algumas suítes da Progress Software sim, são comercializadas na forma de licenças de uso, mas outras, são disponibilizadas gratuitamente, como é o caso do Actional Diagnostics.

Não é porque um fabricante possui um ou mais produtos comercializados sob licenças de uso, que todo o modelo de negócios da compania é assim. A IBM por exemplo possui softwares licenciados, mas possui tecnologias abertas e fomentadas como open source, assim como a Oracle, a Microsoft e a TIBCO. Um bom exemplo disso é a aquisição da empresa Fuse Source, responsável entre outras coisas por tecnologias como Active MQ, Apache Camel e Service Mix. Esta, opera atualmente como subsidiária da Progress Software, mas ainda em regime de suporte open source profissional.

Visão geral sobre o Actional Diagnostics

O Actional Diagnostics é uma ferramenta livre para que você possa auxiliar o desenvolvimento de Web Services cobrindo aspectos sobre testes funcionais e não-funcionais destes. Ele é um produto da linha Actional, que compreende uma série de produtos relacionados a governança em SOA em nível de desenvolvimento (design-time) quando de execução (run-time). Através destes produtos, uma empresa que possua um conjunto de processos de negócios implementados usando a arquitetura orientada a serviços, pode controlar e gerenciar todos os aspectos técnicos e não técnicos sobre sua infra-estrutura, negócio e ativos.

O papel do Actional Diagnostics é viabilizar aos profissionais que desenvolvem e mantêm Web Services, uma forma de aferir aspectos sobre qualidade dos serviços usando uma abordagem sistêmica e controlada, de forma que os testes e verificações a serem feitas possam ser auxiliadas pela máquina e que possam ser re-testados a qualquer momento criando um histórico do ciclo de vida do serviço, cobrindo desde mudanças sobre seu comportamento, como a adição de novas funcionalidades. Segue uma lista parcial sobre o que você pode fazer com o Actional Diagnostics:

Criar ciclos de QA que podem durar dias, meses ou até anos
Monitorar e gerenciar as dependências entre os Web Services
Capturar o tráfego (Payload) das mensagens trocadas entre os Web Services
Validar Web Services quanto ao seu WSDL e seus Schemas
Entendimento da funcionalidade de um Web Service através de Pseudo-Código
Realizar testes de carga para monitoração do desempenho
Geração de relatórios gerenciais sobre QA e testes de desempenho
Visualizar as dependências entre os Web Services e as máquinas envolvidas
Validar Web Services em políticas de interoperabilidade de mercado como WS-I Profile
Implementar testes baseados em WS-Security, WS-Policy e WS-Business Activity

Um tour sobre as features do Actional Diagnostics

A utilização do Actional Diagnostics começa quando você registra nele seus Web Services. Para isso, basta registrar o WSDL que descreve os componentes do seu Serviço como interfaces, bindings, portas e mensagens.

Feito isso, você pode solicitar a execução, gravada ou não, de todos os endpoints que você tiver nesse Web Service, a fim de constatar o comportamento e disponibilidade do Web Service gerenciado.

Outra possibilidade interessante é que você pode, uma vez que você tenha Web Services registrados, realizar um teste de stress nestes muito facilmente, e com uma riqueza de detalhes sobre o ambiente monitorado fantástica.

Além disso, é possível também solicitar a geração de um relatório dos testes de stress. Segue abaixo um documento gerado pelo Actional Diagnostics:

Diagnostics load test

View more documents from Ricardo Ferreira.

Estas e outras features do Actional Diagnostics podem ser testadas hoje mesmo e gratuitamente. Não reivente a roda, use ferramentas que possam melhorar seu ambiente de trabalho. Obter maior agilidade e qualidade no desenvolvimento não é algo dificil muito menos impossível. Basta usar as ferramentas e práticas corretas!

Bons Web Services ;-)

Master Data Mgmt. & Virtualização de Dados em SOA

2010-08-21T06:24:00.000-07:00

Ontem, dia 20 de Agosto de 2010, apresentei uma palestra no evento TDC 2010 sobre Master Data Management & Virtualização de Dados em SOA, que gostaria de compartilhar com as pessoas que assistiram e aqueles que porventura não puderam. Aos que puderam participar da minha apresentação, um muito obrigado pela presença.

Master Data Management & Virtualização de Dados em SOA

View more presentations from Ricardo Ferreira.

Forte Abraço ;-)

Novidades no JBoss ESB 4.9

2010-08-18T07:24:00.001-07:00

Foi lançado recentemente a mais nova versão do JBoss ESB, a versão 4.9. Esta versão é um release muito importante para os usuários e clientes da plataforma de ESB da JBoss pois ela insere vários conceitos estratégicos que visam melhorar a usabilidade e poder da plataforma. Até o final deste ano, vários outros releases devem ser lançados também regados de novas features e características, algumas delas que já podem ser verificadas nos fóruns de discussão da tecnologia. Isso mostra como a Red Hat e a comunidade em geral está investindo nessa plataforma de barramento de serviços que ganha cada vez mais espaço em empresas do Brasil inteiro, muitas destas que hoje já até possuem contratos de suporte profissional com a Red Hat, devido a criticidade de suas soluções. Neste post, iremos verificar de forma prática algumas destas novidades da versão 4.9.

Provedor baseado em Apache Camel

Sem dúvida, esta é a principal novidade da nova versão. Agora temos no JBoss ESB um provedor se baseia no projeto Apache Camel, o qual nos trás diversos adaptadores para os mais diferentes canais de transporte. Eis uma lista parcial do que pode ser feito com este novo provedor:

Receber mensagens do Apache ActiveMQ
Receber mensagens de qualquer broker AMQP (Ex: Red Hat MRG, RabbitMQ)
Receber mensagens via Atom Feed
Exposição de POJO's e JavaBeans em mecanismos de registros
Receber mensagens de mecanismos de Cache como o EHCache
Expor serviços via CXF Web Services
Expor serviços REST usando CXF Web Services
Expor componentes EJB (mesmo EJB 3.0) via o ESB
Receber mensagens via ApplicationEvents do Spring
Receber mensagens via File, FTP, Email, etc
Receber e enviar mensagens ao Gmail
Ler e escrever em sistemas de arquivos HDFS
Mensagens baseadas em HL7 usando o protocolo MLLP
Realizar CRUD's usando iBatis
Receber e enviar mensagens via IRC's
Recever e enviar mensagens via JavaSpaces
Integração com ServiceMix via JBI
Efetuar operações usando JDBC
Efetuar operações usando JPA e Hibernate
Executar pesquisas em sistemas LDAP
Enviar mensagens ao Nagios
Expor serviços via RMI
Enviar e receber mensagens usando SMPP (SMS)
Ler e escrever Unix Pipes usando Streams
Integração com XMPP e Grabber

Como você pode verificar, o uso deste novo provedor aumenta significativamente o número de canais de transporte no qual o JBoss ESB passa a lidar, deixando-o sem dúvida alguma como um dos barramentos de serviços mais flexíveis do mundo. Para demonstrar como este novo provedor pode ser usado, vamos a um pequeno exemplo. Vamos criar um exemplo em que o ESB monitora um diretório do computador a espera por um arquivo qualquer:

Repare a simplicidade de utilizar os recursos do Camel: Basta utilizar os atributos de "uri" e "to" comuns no framework Camel que tudo é perfeitamente integrado ao ESB, desde a inserção dos atributos nas propriedades da mensagem quanto a criação da mensagem "ESB Aware" para o pipeline.

Implementação de actions customizadas usando Anotações

Outra novidade interessante é a criação de actions personalizadas. Agora, você pode usar 100% POJO's para definir suas actions, e não mais ter que estender classes abstratas, implementar interfaces ou definir construtores para receber um ConfigTree. Tudo agora pode ser feito usando anotações. Vamos a um exemplo. Vamos alterar o exemplo anterior para criar nosso próprio adaptador de impressão da mensagem. Implementa a seguinte classe Java:

Repare que a única coisa a ser feita agora, é anotar um método como @Process, para indicar qual método será usado para processar a mensagem. A configuração desta ação também é muito simples, permanece como se fazia nas versões anteriores:

Outra questão interessante é a utilização de parâmetros. Agora, para consumir um parâmetro definido no arquivo jboss-esb.xml, basta usar a anotação @ConfigProperty como no exemplo abaixo:

A definição destes parâmetros usando o arquivo de configuração permanece o mesmo: Apenas crie uma tag do tipo "property" dentro da definição de sua ação no arquivo jboss-esb.xml e boa, será injetado automaticamente nos atributos internos da sua classe de ação. Outra novidade interessante são os métodos de lifecycle da action. Agora você pode definir comportamentos no momento do deploy da ação e no momento do UnDeploy da ação usando as anotações @Initialize e @Destroy, ideais para quando você aloca recursos em memória ou em buffer e deseja descárrega-los no momento apropriado.

Boas Integrações ;-)

"SystemPrintln" Genérico no JBoss ESB

2010-07-26T15:58:00.000-07:00

Um cliente a uns dias atrás me procurou para saber alguns detalhes técnicos do JBoss ESB, entre eles, sobre se existia uma forma "genérica" de imprimir passo a passo o processamento de uma mensagem. O que ele queria na prática, era que a cada ação executada no pipeline de um serviço, que a mensagem fosse exibida no log de mensagens do servidor. Segundo ele, criar uma ação do tipo "SystemPrintln" logo após cada ação era algo inviável quando você possui um projeto com mais de 20 serviços e com 10 ações por cada serviço. Irrefutávelmente eu concordei com ele :-)

Resolvi então explorar este requisito através do recurso de filtros do JBoss ESB, uma funcionalidade bastante interessante mas pouco explorada na documentação da plataforma ou dos "samples" que acompanham o ESB. O recurso de filtros é uma forma de realizar um pré ou pós processamento a cada vez que uma mensagem é processada por uma ação de um pipeline qualquer. A estratégia de implementação dos filtros no JBoss ESB não é muito diferente da usada na API de Servlets no Java EE. Em verdade, a abordagem é exatamente a mesma, exceto pelo fato de que o que está sendo filtrado não é uma requisição HTTP e sim, uma mensagem que pode estar em qualquer formato aceito pelos listeners do JBoss ESB, tais como JMS, SOAP, XML, EDI, TXT, JSON, etc.

Para criar um filtro para o JBoss ESB, você deve criar uma classe que estenda a classe org.jboss.soa.esb.filter.InputOutPutFilter. Esta classe encontra-se no arquivo JAR principal do JBoss ESB conhecido como jbossesb-rosseta.jar. Abaixo segue uma implementação que fiz para exibir a mensagem do pipeline no log do servidor. Para facilitar a implementação, usei a própria implementação de "SystemPrintln" que vem com o JBoss ESB para garantir que o mesmo tipo de lógica de log seja aplicada pelo filtro.

Repare que fiz uma rescrita do método onOutPut(), para lidar com o exato momento em que a mensagem já fora processada pela ação. Se você quiser realizar alguma lógica antes da execução da ação, sobreescreva o método onInput() disponível na classe base estendida. Os argumentos de ambos os métodos são, respectivamente, a mensagem enviada ao pipeline do serviço (criada por alguns dos gateways ou roteada por outros serviços) e uma instância de uma Map que possui parâmetros adicionais criados pelo contexto do serviço, porventura, informações sobre o ambiente da mensagem antes de ser recebida pelo ESB, como exemplo, informações de um diretório FTP caso o gateway usado seja do tipo FTP.

Para instalar este filtro no JBoss ESB, você deve editar o arquivo $JBOSS_ESB_HOME/server/$seuProfile/deployers/esb.deployer/jbossesb-properties.xml. Na seção "filters", crie uma nova entrada de filtro como mostrado abaixo. Repare que para cada filtro existe um número associado. Este número representa a ordem do filtro na cadeia de processamento. Prefira criar seus filtros para serem executados sempre depois dos filtros internos do JBoss ESB.

Você deverá criar um arquivo JAR contendo a implementação dos seus filtros e distribuir na pasta "lib" do deployer do JBoss ESB. Se você usa versões do JBoss ESB que rodam em versões inferiores à 5.0 do JBoss AS, talvez seja necessário colocar o JAR na pasta "lib"do seu profile.

Pronto! Inicie seu JBoss ESB e faça os testes. Agora, toda vez que uma mensagem for executada por um pipeline, à cada execução de uma ação um registro de log da mensagem será exibido no console ou no arquivo de logs.

Boas Integrações ;-)

BPO usando Savvion Modeler Parte 2

2010-06-19T05:45:00.001-07:00

Na parte 1 desta série de artigos, vimos alguns detalhes sobre o que é e o que implica BPO dentro das organizações. Vimos a importância sobre conhecer e melhorar contínuamente os processos vitais de uma organização em pró da melhoría operacional ou estratégica destas. Nesta segunda parte, vamos dedicar o artigo aos detalhes sobre COMO realizar melhoría contínua de processos, conhecendo os detalhes por trás desta prática e aprendendo a como realizar as etapas de análise, modelagem e simulação de processos usando a ferramenta Savvion BPM Modeler. O entendimento desta série do artigo é de suma importância porque aqui veremos os detalhes de "dia a dia" de quem engaja em iniciativas de BPO, detalhes esses que normalmente não podem ser vistos em livros, documentações e palestras. Com isso, iremos neste artigo trabalhar com um processo simples para que os detalhes sejam fielmente compreendidos, tornando a leitura muito mais didática.

Na parte 3 desta série, iremos ver como os conceitos e práticas mostrados na parte 1 e parte 2 podem ser aplicados a um processo de negócio real, que contêm detalhes e complexidades muito parecidos com outros processos que potencialmente você irá enfrentar. Para exercitar o que será mostrado aqui, você deverá possuir a versão 7.5 SP2 do Savvion Modeler. Este software poderá ser baixado dos repositórios da Progress caso você tenha este acesso ou licença de uso. Mãos à obra!

Entendendo o cenário que será usado como exemplo

Para que possamos praticar os conceitos de BPO, temos que primeiro traçar um cenário de negócio. O cenário que iremos trabalhar será de uma aprovação de requisição de material de uma empresa de fornecimento de energia elétrica. A idéia é que possamos mapear a situação onde um empregado da empresa solicita algum material que será usado para seu trabalho, como por exemplo, cartões de visita, um grampeador para sua mesa, ou até mesmo um laptop para trabalho remoto do escritório. Este cenário deverá mapear o momento que a requisição é feita, aprovada ou reprovada e operacionalizada dentro da compahia.

Começando a trabalhar: Iterações de análise de processo

A primeira coisa a se fazer é realizar um ou mais trabalhos de análise sobre estes processos. Estas análises devem ser categorizadas em diferentes frentes que a maioria dos escritórios de BPO devem ter mapeados de ante-mão. Exemplos destes tipos de análises são:

Análise de Viabilidade: O processo merece ser entendido e/ou melhorado?
Análise de Riscos: O processo representa quantos % do negócio da organização?
Análise de Custos: Quanto custa, em termos de esforço e financeiro, melhorar este processo?
Análise de Impacto: Mudar ou melhorar este processo apresenta impactos em pessoas e TI?

Estas análise normalmente são feitas com reuniões curtas entre os envolvidos e interessados no processo cujo formato são sessões de argumentações das categorias citadas. O insumo a ser criado é uma lista de argumentações que devem posteriormente serem respondidas e endereçacas as pessoas correspondentes. No caso particular da análise de custos, é interessante perguntar: "Quanto custa parar os envolvidos nos processos para melhorar isso?", "Se tiver que alterar sistemas da TI, quanto que isso me custa de tempo e dinheiro?", "É necessário adquirir novos pacotes de software ou contratar pessoas para isso?", "Precisamos contratar uma consultoria do assunto do processo?"

Assim que estas análises forem feitas, um relatório de embasamento deverá ser criado e enviado ao patrocinador do projeto. Ele deverá conseguir ver claramente quais os benefícios e impactos que um potencial investimento naquele processo irá ter. Deve ser possível também visualizar que tipo de melhoría será conseguida com aquilo. Isso é muito importante para efeitos de mobilização: Se um processo melhorado não apresenta benefícios, para que melhorá-lo? Se um sistema mapeia corretamente um fluxo da empresa (mesmo que não da melhor forma) por que atualizá-lo?

Nos primeiros esforços de BPO numa empresa, é comum constatar que nenhum benefício direto será alcançado. Isso acontece porque normalmente os processos ainda não são corretamente compreendidos e com isso, a percepção sobre que benefícios se obtêm quando se melhora não são claros. Mas como dito anteriormente, investir algum tempo e dinheiro no entendimento dos processos internos além de ser a fundação para um bom BPO, é um investimento que trás grandes benefícios, um deles é a clara percepção que o negócio possa estar mal conduzido. Quando você para para analisar como você faz as coisas, você percebe o quanto pode estar certo ou o quanto pode estar errado. Um ponto positivo de se fazer BPO pela primeira vez é que você nem precisa de tanto esforço de análise para ver o que está errado: Revisando o processo pela primeira vez você já têm a clara percepção de direção. Quando você tenta melhorar um processo que você já compreende e entende, ai muitas das vezes é necessário investir algum tempo analisando diferentes cenários e possibilidades, muitas das vezes, até por pessoas de fora, ou seja, pessoas que não tenham os mesmos interesses que os seus e que tenha expertise no tipo do processo.

O que é na prática melhoría de processos?

Alterar um processo e perceber uma melhoría? Isso pode ser um passo bem desafiador se você nunca fez isso ou se você não têm conhecimentos sobre a organização. É comum observar pessoas argumentando sobre o que é na prática melhoría de processos, pois muitas pessoas efetivamente repetem a frase mas não entendem corretamente seu significado e influências. Conheço um bom punhado de "Analistas de BPM" que na prática não ajudam em absolutamente nada. Melhoría de processos têm a ver com duas palavrinhas simples: Eficácia e Eficiência. Você é eficaz quando você desprende um conjunto de recursos disponíveis ou indisponíveis para um objetivo correto. Se você desprende recursos para objetivos incertos ou inviáveis, você não é eficaz. Eficiência têm a ver com alocar o menor número possível de recursos e conseguir o mesmo bom resultado (ou resultado melhor) que você teria com um conjunto menor de recursos. Costumo falar que eficácia têm a ver com visão e eficiência têm a ver com experiência.

Se você faz parte ou analisa um processo qualquer e consegue perceber que um dado processo é ou não é correto ou viável, você está tendo uma boa visão e portanto está sendo eficaz. O processo de escolha de uma lista de processos que devem ser melhorados têm a ver com visão. Em termos práticos, não somente escolher o processo correto, mas escolher o objetivo correto também é sinal de visão e de eficácia. Muitas das vezes, vemos empresas que possuem métodos de trabalho muito bons e uma boa base e equipe técnica qualificada, ingredientes estes que por si só apresentam sinais de um possível sucesso. Mas muitas destas empresas possuem objetivos pobres ou errôneos de forma que mesmo que conduzam os processos corretamente, eles trilham caminhos que não darão bons resultados. É o caso de grandes empresas que vemos no dia a dia que num dado momento são candidatas a falência em seu negócio. Os recursos eram bons, mas os objetivos não estavam bem traçados ou corretos. Empresas que pedem para serem compradas ou entram em processo de falência são bons casos destes. Faltou eficácia. Logo percebemos que podemos categorizar as empresas do mundo todo em 2 segmentos: As empresas que vão bem e as empresas que vão mal. As empresas que vão mal são aquelas que não possuem eficácia a fatalmente serão fadadas ao fracasso ou desligamento, e as empresas que vão bem são aquelas que possuem eficácia, e ainda estão no mercado disputando o espaço com outras no mesmo segmento. Estas empresas que vão bem, são aquelas que devem procurar ter mais eficiência.

Se você possuem um negócio que está indo pro caminho certo, mas está com dificuldades de alavancar seu negócio perante o poder dos concorrentes, está na hora de revisar sua eficiência. Como dito antes, eficiência têm a ver com trazer melhores resultados com menores ou os mesmos recursos ou diferentes estratégias. Bons exemplos de melhores resultados com menores recursos é quando você é um fabricante de algum material e consegue aumentar sua fabricação diminuindo os recursos necessários ou alterando sua abordagem de produzir. Para conseguir isso, você precisa de uma estratégia. Vamos a um exemplo da vida real ...

Imagine que você é do ramo de Data Centers. Você possui sua cartela de clientes fixos, mais para aumentar sua cartela implica em aumentar seu custo operacional de telefonia ou de links dedicados. Seu concorrente faz a mesma coisa que você mas possuem a "vantagem" de também ser uma operadora de telefonia móvel e fixa que inclusive presta serviços pra você. Para que você faça seu negócio acontecer, você têm um custo de telefonia, para que seu concorrente faça o negócio dele acontecer, ele não possui um custo de telefonia e por isso, pode escalar mais. Posicionar portanto uma empresa sobre se ela é ou não mais competitiva é a questão de perguntar: Os recursos operacionais dela são mantidos por ela mesma (auto-suficiência) ou são mantidos por terceiros? A empresa do concorrente portanto é muito mais eficiente que a sua, porque ela detêm os recursos operacionais necessários para o negócio.

Produzir coisas têm a ver com aquisição de matéria prima ou insumos. Se você produz alguma coisa e quer ser mais competitivo significa que você deve reavaliar com adquire sua matéria prima ou como você pode reduzir o custo desta aquisição. Uma outra forma de garantir que sua produção possa ser mais eficiente é trocando a matéria prima ou os recursos utilizados ou utilizando o conceito de recursos compartilhados. Compartilhar recursos sempre é uma abordagem que traz bons resultados de eficiência, não importa o contexto. Para os técnicos de plantão que estão lendo este artigo, pense por exemplo nos EJB's do tipo session: Quem escala mais, os SLSB's ou os SFSB's? Sem dúvida será aquele que tiver menor número de recursos alocados e maior número de recursos compartilhados.

Acredito que depois desta explanação sobre eficácia e eficiência, melhoría de processos deva estar mais clara agora. Melhorar um processo implica primeiro e acima de tudo fazer com que o processo seja eficaz, e quando este for eficaz que ele seja mais eficiente. A busca constante por melhoría na prática é a busca constante pela eficiência, mas, somente se o processo estiver buscando os objetivos corretos. De nada adianta você construir um processo que seja demasiadamente eficiente se ele não refletir os objetivos e resultados corretos. E, antecipando um pouco do que veremos a seguir, conseguir ser eficiente é, ao contrário do que se pensa, muito mais simples do que conseguir ser eficaz. Como dito antes, eficácia têm a ver com visão, e eficiência têm a ver com experiência. Se você já passou por uma situação, você pode dar palpites sobre como melhorar algo. A experiência é algo que é concreto, que podemos vivenciar ao longo dos anos. Pode demorar, mas uma hora você adquire a experiência em algo para torná-lo mais eficiente. Ter visão é mais complicado, não é algo que você vivencia ou experimenta. É um dom!

Você deve ter a sorte de ser uma pessoa de visão para saber que tipos de objetivos perseguir. Fazendo um breve paralelo com a vida real, existem muitas pessoas estáveis e experientes que quando argumentadas sobre o que ela quer da vida ... não sabem responder. Isso porque lhes falta visão. E normalmente, as pessoas que não têm visão sobre a própria vida jamais irão ter visão sobre o seu negócio. Justamente por isso, algumas grandes empresas, consolidadas e até líderes no seu mercado, contratam o que chamamos de CEO: pessoas que vem para as empresas para tentar trazer a visão que falta para a equipe de diretoria e grupos acionistas. Não é surpresa, dito isso, que muitas grandes empresas possuem CEOs que na verdade não são os donos destas empresas, e, contextualizando no nosso país, não é surpresa que um presidente precise de tantos acessores para "ajudar" a conduzir o país. Os acessores são as pessoas de visão e portanto que trará a eficácia ;-)

Brincando com o Savvion BPM Modeler

Agora vamos dar uma olhada na ferramenta de modelagem da Progress conhecida como Savvion BPM Modeler. Esta é sem dúvida uma das melhores ferramentas (senão a melhor) de modelagem de processos de negócio usando a notação BPMN. De fato, o Savvion BPM Modeler é bem mais do que isso, é uma suíte completa de BPO onde você pode praticar análise e simulação de processos e promover efetivamente melhoría de processos. Além disso, a ferramenta de modelagem é parte integrante de uma suíte maior de BPMS conhecida como Savvion Business Manager. Com esta suíte, você pode além de modelar e simular processos, transformar estes processos em aplicações corporativas completas com o mínimo de esforço possível. Mas vamos deixar a suíte BPMS da Progress para um próximo post, neste, iremos focar efetivamente em melhoría de processos usando técnicas de BPO. Para começar, inicie a ferramenta Savvion BPM Modeler para entendermos um pouco de como ela funciona.

Continua ...

BPO usando Savvion Modeler Parte 1

2010-06-14T07:03:00.000-07:00

Toda organização possui (ou deveria possuir) um conjunto de objetivos estratégicos e diretrizes onde todos na organização atuam. Estes objetivos e diretrizes tomam diferentes formas e diferentes níveis: visão, missão, planos e direção para os negócios, etc. Pessoas nestas organizações atuam colaborativamente e estão sujeitos as políticas e regulamentações, práticas e padrões relevantes e procedimentos estabelecidos para atingir estes objetivos. A entidade fundamental que reune todos estes elementos são os processos de negócio. Uma organização é em última análise, uma coleção de processos que determinam como a mesma opera, como ela gera seus rendimentos, como ela suporta seus clientes, etc. Como uma empresa se diferencia uma das outras têm a ver unicamente com seus processos de negócio. Neste caso, os processos de negócio de uma organização são ativos vitais e críticos que devem ser tratados como o bem mais valioso que existe. Sendo assim, eles devem ser gerenciados e mantidos apropriadamente. Para isso, os processos precisam ser reconhecidos, documentados, compreendidos e analisados antes que eles sejam automatizados e gerenciados. Este é o processo mais vital que fará com que os processos de negócio tenham a devida atenção que merecem. A automação destes somente fará com que a "roda possa girar" e fazer o dinheiro fluir, mas isso só acontecerá se os processos estiverem concisos.

Para estabelecer este ciclo, se faz necessário o uso de ferramentas visuais de simples utilização que possa gerar modelos e uma linguagem de notação padrão e que este possa ser controlado num sistema de repositórios centralizado de acesso controlado. Desta forma, as pessoas envolvidas nos processos podem criar modelos, atualizar existentes, promover discussões sobre os modelos já criados e garantir que os processos estejam sempre íntegros e atualizados. Mais ainda, estas ferramentas devem prover recursos de simulações destes processos, de forma que as pessoas possam "observar" as diferentes combinações criadas, e os diferentes caminhos e alocações de recursos que um dado processo possa gerar.

Uma vez que você tenha estabelecido este tipo de ferramenta em sua organização, em conjunto com os ciclos citados anteriormente, você poderá então oficialmente instituir um grupo responsável por BPO, sigla de "Business Process Optimization". Considerar um grupo de BPO dentro de qualquer organização de médio ou grande porte é sem dúvida uma forma de garantir sucesso de mercado e diferencial quanto aos concorrentes. Se você fizer isso e tiver uma pequena parcela de concorrentes que ainda não o façam (ou façam mas com pouca ou nenhuma seriedade) então você poderá colher os frutos de ser um líder no seu nicho de mercado. Em muitos casos, BPM é visto como algo extremamente dispendioso e dificil de justificar, principalmente quando se fala em alterações nas aplicações para acomodar a automação dos processos. Mas bem mais importante do que a fase de automação de processos é a fase de análise e melhoría destes. Instituir um grupo responsável por BPO numa empresa de médio ou grande porte é algo que de longe pode ser caro e pode (ou deve) ser tratado muito mais como um investimento do que como uma despesa.

Com níveis adequados de maturidade nos processos, é interessante fechar o ciclo do BPM e promover a automação dos processos junto a TI. A justificativa da mudança será simples e muito bem embasada. Boas estratégias de adoção de BPM devem incluir fases preliminares de observação e entendimento dos processos, seguido de propostas de melhoría e de melhorías em si, acordadas entre os interessados, aprovada pelos níveis de diretoria e fundamentada com dados estatísticos sobre redução de custos e recursos. Depois que estes primeiros passos forem dados, BPO poderá dar espaço a ciclos de automação e gerenciamento, fechando o que chamamos de ciclos de BPM. Dai o sentido da letra "M" do BPM.

A idéia deste artigo é mostrar, em termos conceituais e práticos, como operacionalizar análise, modelagem e melhoría de processos através de simulações de cenários. Nesta primeira parte iremos nos ater os quesitos conceituais sobre processos de negócio, e na segunda parte iremos ver como modelar, analisar e simular um processo de negócio na prática, usando para isso a ferramenta Savvion BPM Modeler da Progress.

A Necessidade de Análise e Modelagem de Processos de Negócio

Processos são os insumos básicos que governam qualquer tipo de negócio. Alguns destes processos estão embutidos em aplicações comerciais (ERP's, CRM's) que capturam algumas funcionalidades, atividades e segmentos de um processo. Mas muitos destes processos que governam o negócio envolvem várias aplicações, vários sistemas e várias pessoas, sejam elas funcionários, clientes, parceiros ou fornecedores. Estes processos também não são formalmente definidos e documentados. Cada departamento ou organização pode potencialmente definir seus próprios processos (ou segmentos destes processos) baseados em vários procedimentos, formulários, guidelines e outros documentos.

As coisas podem ficar muito piores quando você têm processos que são distribuídos em diferentes organizações, como nos casos onde o processo se inicia num fornecedor de serviços, passa por um fornecedor de produtos e termina nas fronteiras dos clientes. O conhecimento sobre estes processos distribuídos estão espalhados entre vários gerentes de negócio das organizações envolvidas. Não existe um único lugar ou pessoa onde se possa aprender sobre estes processos. Se algumas destas pessoas se desligar da sua organização, o processo terá uma lacuna de conhecimento. Mais ainda, nenhum processo de negócio é uma ilha isolada, todos os processos de negócio estão embutidos ou fazem parte de outros processos criando portanto camadas de processos dentro das organizações. Processos de camadas mais baixas normalmente são ditos processos operacionais quando que processos de camadas mais altas são ditos processos estratégicos.

Dado este grande número de problemas relacionados a processos, se faz necessário uma abordagem pragmática que mantenha os processos livre destes tipos de problemas. Primeiro, deve-se manter os processos em repositórios controlados nas organizações, ou, se trata-se de processos inter-organizacionais, em repositórios mantidos por pessoas (empresas) comuns para as organizações envolvidas. Segundo, os modelos não podem ser estáticos. A abordagem deve se basear na construção inicial dos processos e na evolução constante destes processos. Para isso, as ferramentas envolvidas deverão possibilitar a constante mudança nos artefatos dos processos de forma distribuída, ou seja, possibilitar que diferentes pessoas possam alterar os artefatos simultâneamente. Além disso, é necessário também que as ferramentas possam prover links entre os processos, de forma que se um processo é um processo interno de outro (um sub-processo), o processo maior possa, quando simulado ou executado, executar o processo interno e esperar que ele termine até que ele possa dar prosseguimento no processo maior. É necessário também que a ferramenta possa ter como atividades, diferentes tipos de "caixinhas" que possam variar de atividades humanas a atividades sistêmicas.

Deve ser possível por exemplo, que uma atividade seja operacionalizada por uma ação realizada por um dos sistemas da organização. Para isso, estas operações devem ser encapsuladas na forma de serviços e se tornarem disponíveis na forma de uma paleta de atividades: Todos os serviços da organização deverão estar registrados em algum sistema automatizado de registros de forma que possam aparecer na ferramenta de desenho de processos como uma paleta de possibilidades. Com isso, os donos dos processos podem pensar nas etapas dos processos em "caixinhas" que possuem um significado ou representação, sem se preocupar em como aquela caixinha quando executada, irá fazer seu trabalho. Há quem diga que um processo é uma coleção de caixinhas ligadas umas nas outras que formam um caminho a ser percorrido. Assim devem ser os processos construídos, simples ao ponto de poderem ser definidos desta forma.

Benefícios do Uso de Análise e Modelagem de Processos

Como mencionado anteriormente, organizações podem se beneficiar substancialmente realizando investimentos de análise, modelagem e melhoría nos seus processos de negócio. Estudos têm mostrado que mesmo que as organizações não tenham uma intenção formal de ter ciclos de BPM e de automatizar seus processos, apenas modelando e simulando os processos podem ajudar a melhorá-los consideravelmente. Mesmo que a melhoría não ocorra num primeiro momento, somente o esforço de modelar, documentar e entender os processos já é um ganho considerável. Muitas empresas não possuem entendimento dos seus processos e com isso, elas não podem evoluir e serem mais competitivas. Se você não entende corretamente o que você faz, como você pode saber se você está fazendo certo ou errado?

Aplicando corretamente BPO numa organização, possibilita que você usufrua dos seguintes benefícios:

Analistas do negócio, gerentes funcionais e diretores se tornam responsáveis pelos processos. Com essa autonomia, a decisão se torna mais simples e mais coesa;
Processos internos e inter-organizacionais serão melhor controlados e não mais irão existir somente quando as pessoas existirem: Na substituição da pessoa (recurso) o processo continua existindo e funcionando;
Previsão de funcionamento sem que a TI tenha que mostrar como se faz. Processos poderão ser analisados mesmo que não sejam automatizados pela TI. Isso possibilita maior agilidade na tomada de decisão, uma vez que toda a ciência, autonomia e responsabilidade está agora na área de negócios. Interações com a TI serão reduzidas a pedidos de automação concretos;
Suporte a iniciativas de compliance tais como Six Sigma, ISO 9000, Sarbanes Oxley, etc;
Investimentos melhores justificados. Ao requisitar para a TI a automação de um processo que foi comprovadamente dito como "de sucesso", os fundos para isso serão providenciados rapidamente, isto é, se houver fundo disponível e aprovado para o item "Melhoría de Processos";

Boas Melhorías :-)

Monitoramento de SLA's com JBoss ESB

2010-06-04T07:17:00.000-07:00

Suponha que você possui um ou mais serviços implementados no seu barramento e que deverão ser utilizados pelos seus clientes e parceiros. Para que você possa oferecer um serviço com um mínimo de segurança, você deve criar contratos de SLA (Service Level Agreement) com estes clientes e parceiros. Estes contratos normalmente regem condutas mínimas de utilização como percentual de disponibilidade do serviço, tempo de resposta mínimo, tempo de indisponibilidade do serviço e o tempo de recuperação deste caso haja falhas na operação. Isso se dá porque ou o cliente ou o parceiro possui um contrato de utilização do serviço (ou do negócio que está sendo prestado) com você, e estas regras de utilização são protegidas por multas que costumam ser bem desafiadoras do ponto de vista contratual. Para que você esteja preparado para acomodar este tipo de situação, você deve ter ferramentas e tecnologias que possam lhe ajudar a mensurar estes itens quanto a viabilidade, e também controlar e monitorar estes eventos de indisponibilidade ou utilização de forma reativa ou preferencialmente, de forma pró-ativa.

O objetivo deste artigo é mostrar como, através do conjunto de tecnologias e plataformas da JBoss, podemos oferecer este tipo "garantia" para os clientes e parceiros, caso você esteja engajado neste tipo de negócio, que, em algumas verticais de negócio como no ramo financeiro e principalmente o ramo das telecomunicações, se torna cada vez mais comum. Dezenas de operadoras brasileiras já possuem pelo menos um destes contratos com outras empresas fornecedores de conteúdo digital e afins. Para a vertical de governo, não é dificil imaginar este tipo de situação: Porventura, uma empresa que possui um serviço de nota fiscal eletrônica possa querer fazer outsourcing não da aplicação, mas do serviço de processamento de notas fiscais para órgãos do governo e assim, acarretar em um ou mais contratos de SLA.

Para implementar este tipo de cenário em suas instalações, você precisará essencialmente do JBoss ESB versão 4.7 ou superior e a plataforma de gerenciamento e monitoramento da JBoss conhecida como JOPR, versão 2.3.1 ou superior. Se você deseja possuir estas tecnologias a plataformas com o suporte e respaldo técnico da Red Hat [novamente a questão de SLA ;-)] você deve adquirir as subscrições do SOA Platform 5.0 que contêm o ESB e do JBoss Operations Network versão 2.3.1.

Entendendo o cenário, os SLA's e a arquitetura da solução de demonstração

Tenho uma solução baseada no JBoss ESB que processa pedidos de contratos de seguros. Suscintamente falando, a solução recebe estes pedidos de diferentes canais de transporte e de diferentes formatos de dados que vão desde documentos XML até mensagens baseadas em CSV lidas de um banco de dados relacional. A idéia é que estes pedidos sejam convertidos em um formato comum para o ESB, ou seja, o padrão Canonical Data Model e que uma vez que a mensagem esteja neste formato padrão, ela seja enriquecida com um punhado de regras de negócios que são disparadas a partir do software JBoss BRMS (Business Rules Management System). Estas regras vão destes regras sobre cálculo de riscos da aplicação da proposta, quanto a regras de aprovação da mesma e descontos promocianais criados pela equipe de marketing da empresa. Uma vez que a proposta esteja corretamente processada e seja aprovada, ela é transformada numa cotação e é enviada a diferentes canais de transporte para fins de notificação e finalização da transação do processo de negócio, canais estes que vão desde filas JMS até tabelas de bancos de dados. A figura abaixo sintetiza este cenário do ponto de vista do barramento de serviços:

Este processo de negócio supostamente foi contratado por um cliente da seguradora que deseja que alguns SLA's sejam definidos e resguardados contratualmente entre a seguradora e o tal cliente. Os SLA's definidos para este processo de negócio foram:

SLA_1: Através do canal SOAP, o número de mensagens não processadas não deverá ser superior à 5.
SLA_2: Através do canal FILE, o tempo de processamento não deverá extrapolar 5 segundos.
SLA_3: Independente do canal de transporte (SMS, SOAP, SMTP ou FILE), a cada 10 pedidos de seguro processados, um gerente de vendas do cliente deverá ser notificado via e-mail.

Repare que para cada SLA demos um apelido para que possamos referenciá-los futuramente no artigo. Grave estes apelidos para futura conferência do seu significado. A idéia é que possamos usufruir da excelente integração entre o JBoss ESB e o JBoss Operations Network para acomodar estes SLA's. As estratégias de configuração aqui apresentadas poderão ser personalizadas para outros cenários de negócio e não se restringe somente a este cenário apresentado, uma vez que as métricas, alertas e eventos do JBoss ESB são tratados pelo JBoss ON de forma genérica.

Atendendo o "SLA_1" usando o JBoss Operations Network

Para atender o SLA_1, temos que primeiramente configurar o JBoss ON para que ele gerencie automaticamente o uso médio da métrica "Overall Bytes Failed" que determina a quantidade de bytes que falharam na hora do processamento de uma mensagem. Isso é importante porque além da notificação sobre quanto o SLA é comprometido, devemos poder proativamente observar o andamento deste tipo de cenário nas plataformas de execução.

Para isso, acesse o serviço do JBoss ESB que será monitorado, e clique na métrica "Overall Bytes Failed" existente na guia "monitor" do JBoss ON.

Ao clicar na métrica, você será encaminhado para a visualização do gráfico de utilização da métrica. utilizando a barra de rolagem do seu navegador, desça até o final da página onde você verá uma seção chamada "Metric Baseline & Expected Range". Nesta seção, você pode verificar e calcular qual é a taxa de utilização média da métrica. Clique no link "Change Value" para solicitar a computação da métrica e na sequência, clique em "Save Value".

Agora que temos nosso baseline definido e marcado para 0 bytes, podemos criar um alerta que monitore as mensagens com erros de processamento. Para isso, irei criar um alerta para o serviço cujo endpoint é baseado em SOAP. Basta clicar na guia "Alert" e definir um novo alerta usando as configurações da interface. Crie um alerta baseado na métrica "Overall Bytes Failed" e diga que você quer "tolerar" apenas 5% do baseline, ou seja, a primeira mensagem com falha já irá alertar sobre mal funcionamento do processo de negócio e do SLA_1.

Atendendo o "SLA_2" usando o JBoss Operations Network

O SLA_2 é um pouco mais exigente e por isso, merece uma configuração um tanto quanto diferente. Como trata-se de um SLA relacionado a performance, temos que configurar além do JBoss ON, o nosso barramento de serviços. O JBoss ESB a partir da versão 4.7 possui um recurso super interessante relacionado a monitoramento de serviços. Em suma, você pode definir tanto em nível de serviço quanto em níve de ação do pipeline dois tipos de verificações: Tempo de processamento e tamanho da mensagem.

Para atender o SLA_2, eu defini no meu módulo de configuração do ESB (jboss-esb.xml) a propriedade "AlertTimeThreshold" definindo seu valor para 5 segundos. Com isso, toda vez que aquele serviço receber uma mensagem não importando o canal de entrada (SOAP, JMS, File, FTP) ele irá cronometrar o tempo de processamento da mensagem, ou seja, o tempo entre a data e hora de entrada da mensagem no barramento e o final da execução de todo o pipeline definido para o serviço, isto é, sua cadeia de ações. Uma estratégia também muito interessante é que isso pode ser feito em nível de ação. Você pode por exemplo, cronometrar o tempo que uma transformação de SOAP para JAVA leva, o que impacta diretamente no tempo de processamento total do serviço.

As configurações de threshold funcionam da seguinte forma: Quando o JBoss ESB verifica que o "SLA" definido foi quebrado, ele cria uma entrada no MBean "MessageAlerts" que está disponivel dentro do JBoss ESB. Além disso, ele cria uma entrada no log de eventos do servidor usando a configuração padrão do Log4J. Com isso, o JBoss ON através do seu plugin de integração, pode interceptar estes eventos e gerar eventos específicos do JBoss ON, possibilitando assim, a criação e geração de alertas de SLA. Para que o JBoss ON possa interceptar os eventos gerados pelo JBoss ESB, você deve habilitar a leitura de eventos no JBoss ON. Para isso, clique no servidor e acesse a guia "Connection" disponivel no link "Inventory":

Uma vez que você tenha definido a configuração dos eventos, você pode criar um alerta baseado no evento usando a mesma estratégia usada anteriormente: Clicar na guia "Alert" e definir um novo alerta. Repare que para a definição do alerta é necessário definir que o filtro de expressão deve ser igual ou semelhante a "MessageAlert", nome do MBean que será escrito no log do servidor. A cada vez que uma nova entrada no log for escrita, o agente do JBoss ON irá notificar sobre um evento do JBoss ESB, que será avaliado na expressão do alerta. Caso esta expressão seja avaliada como verdadeira, então um evento do JBoss ON será gerado e o alerta será executado. No caso especial do SLA_2, eu configurei meu alerta para notificar um administrador de sistema que poderá realizar alguns diagnosticos no JBoss ESB e na sua estrutura geral de hardware e software, tudo isso, usando somente o JBoss ON.

Atendendo o "SLA_3" usando o JBoss Operations Network

Para atender o SLA_3 é muito simples: Basta criar um alerta no JBoss ON que depois de executar deverá zerar o contador da métrica "Message Count". O gerente de vendas deverá estar configurado no JBoss ON como um usuário de credenciais limitadas e que somente receberá notificações:

OK, tecnicamente estou convencido, mas e qual o diferencial?

Muitos leitores do blog e amigos em geral porventura me questionam sobre qual a vantagem de se estabelecer uma arquitetura orientada a serviços baseadas em tecnologias JBoss. Bem, costumo começar a responder falando sobre a questão de custo: Se você não optar por contratar as subscrições da Red Hat para ter facilidades como garantia de continuidade da tecnologia e o suporte técnico, o custo é literalmente zero, ou melhor, alguns centavos referentes ao custo do download do software a partir dos repositórios do JBoss.ORG.

Mesmo que você opte por contratar a Red Hat para ter suporte e todos os beneficios da subscrição, o custo ainda sim é super mais barato que as demais soluções. Acima de tudo, o custo indireto baseado em subscrições Red Hat é infinitamente mais vantajoso do que as demais soluções baseadas em software licençiado, uma vez que você não têm CAPEX, apenas OPEX, ou seja, você paga e recupera o valor pago a medida que usa o suporte ou atualiza o produto a partir da Red Hat.

Outro ponto importante é a liberdade de escolha: Toda tecnologia JBoss é baseada em padrões abertos (JCP, OASIS, W3C, WS-I) e totalmente open-source baseado em LGPL, dando você a garantia de que não ocorrerá vendor Lock-In, nem mesmo impossibilidade de troca do fornecedor do software. Se você quiser mudar de tecnologia e arquitetura por qualquer motivo, sinta-se a vontade para fazê-lo que seu investimento não será perdido.

Dito isso, outras soluções do mercado como Oracle Service Bus e webMethods ESB fazem tecnicamente a mesma coisa que as soluções JBoss, mas, se você deseja menor custo e garantia de portabilidade do investimento, pergunte-se: Por quê não JBoss?

Bons SLA's!

Enviando Mensagens do JBoss ESB para um SGBDR

2010-04-25T12:31:00.000-07:00

Entender como funciona um ESB não é dificil. Todo ESB precisa dar suporte a três operações básicas: Receber mensagens de diversos canais de transporte (InBound), processar a mensagem recebida realizando uma ou mais operações de transformações e enriquecimentos (Internal Processing) e rotear a mensagem recebida e processada para diverentes tipos de canais de transporte (OutBound). Essa seria a síntese de qualquer implementação de ESB do mercado, e o que mudaria, seria como um dado ESB faria estes três passos.

Veremos neste post, como podemos trabalhar a parte de roteamento de mensagens para um banco de dadas SQL, ou seja, a realização de uma operação de OutBound da mensagem do barramento para um servidor de banco de dados compatível com ANSI/SQL. Para isso, iremos utilizar uma implementação customizada que criei para o JBoss ESB, que oferece recursos mais avançados do que as atuais estratégias do JBoss ESB, a saber, o NotifySQLTable da action Notifier, e os cartuchos de SQL do Smooks.

Qual os problemas das implementações atuais?

As implementações atuais do JBoss ESB para OutBound de mensagens para bancos SQL sofrem de algumas limitações de utilização e usabilidade. O NotifySQLTable por exemplo, possui diversas limitações técnicas como o fato de oferecer somente a operação de INSERT para o usuário, e o fato de oferecer somente a conexão via JDBC (DriverManager) e não a possibilidade de conexão via pools de conexão JDBC o que implica diretamente em diversas considerações de escalabilidade e robustez das soluções. Além disso, todas as informações que o componente manda para o banco de dados são estaticamente definidos no XML do JBoss ESB, tornando o seu uso pouco viável, uma vez que as informações que deverão ser enviadas para o banco de dados constarão no pipeline do serviço em tempo de execução.

O cartucho de SQL do Smooks em contra-partida resolve algumas das limitações do NotifySQLTable, como a de oferecer a possibilidade de conexão ao banco de dados via um pool de conexões JDBC. Porém ele ainda sim deixa a desejar em diversos pontos, como o de obrigar aos integradores de soluções a terem que escrever sentenças SQL baseadas em atributos dos beans transformados via Smooks, o que torna o desenvolvimento das soluções muito mais propenso a erros. Além disso, você deverá considerar que todos os dados que serão enviados ao banco de dados estarão no contexto do Smooks, ou seja, a sessão do Smooks para uma dada ação de transformação. Na maioria dos casos, os integradores de soluções desejam compor dados oriundos de enriquecimentos que se encontram dentro do pipeline da mensagem, fazendo com que o uso do cartucho do Smooks tenha como pré-condição o redesenho das mensagens que serão enviadas para o ESB. Não menos importante, existe a questão moral de se utilizar uma transformação Smooks só para ter o comportamento de OutBound para um banco SQL. Além de ferir o design da solução, isso torna seu uso muito mais complicado do que o simples e puro, uso de uma action do ESB.

SQLRouter: Solução "Simples Assim" para roteamento de mensagens

Um dos recursos mais poderosos e ao mesmo tempo simples do JBoss ESB são seus routers. Além dos routers de endereçamento (ContentBasedRouter, MessageFilter, MessagePersister) existem os routers que encaminham as mensagens do pipeline para algum canal de transporte específico, como o JMSRouter, o EmailRouter e o HTTPRouter. Trabalhando com o JBoss ESB por longos anos, sempre senti falta de um router que pegasse uma mensagem do ESB (ou fragmentos dela) e enviasse a um a tabela de um banco de dados SQL. Na maioria das vezes, tive que escrever uma action que fizesse isso para um cenário particular com pouco ou nenhum reuso da lógica de roteamento da mensagem.

Casos que justifiquem um router para SQL não faltam: De repente você precisa que o ESB sinalize uma aplicação via seu banco de dados, e esta sinalização pode ser a simples inserção de um registro, a atualização de um registro existente ou mesmo a remoção de um registro da tabela. Outro caso interessante é a de persistência de dados. Uma mensagem do ESB pode conter parte dos dados que precisa ser enviado a um Web Service .NET, outra parte precisa ser enviada a um endpoint FTP e outra parte precisa atualizar uma tabela de banco de dados, porém os três casos forma uma única operação atômica de persistência (uma transação) que precisa ser coordenada pelo pipeline de um serviço.

Para estes casos, eu criei um SQLRouter, que além de acomodar os cenários descritos acima, resolve, de forma bem simples e didática, as limitações das implementações atuais de OutBound SQL do JBoss ESB. Atualmente não tenho esta implementação em nenhum projeto open-source, mas assim que estiver eu posto aqui o link para download gratuito. Neste meio tempo, se você precisar deste roteador, mande uma mensagem para jricardoferreira (at) gmail.com que disponibilizo para você ;-)

Um primeiro exemplo usando o SQLRouter

Considere uma tabela de banco de dados para armazenamento de informações sobre clientes. A tabela deverá ter a seguinte estrutura:

Para fins de testes, crie esta tabela num banco de dados MySQL, PostgreSQL ou Firebird, Para inserir um registro nesta tabela através do JBoss ESB, você poderia simplesmente declarar a seguinte action no seu pipeline:

Repare que a action estabelece uma conexão com o banco de dados via JDBC, e com base nas informações declaradas na propriedade "columns", cria uma senteça SQL do tipo INSERT, conforme definido na propriedade "operation-type". Agora imagine que você precisa fazer a mesma operação, só que não quer conectar no banco de dados via JDBC puro, e sim, quer conectar usando um pool de conexões previamente configurado que deve ser acessado através do nome JNDI "java:/sqlRouterDemoDS". Você poderia configurar o SQLRouter da seguinte forma:

Outro recurso interessante deste SQLRouter é que o roteamento não deve ser somente uma operação de INSERT. Caso seja necessário, você pode criar as operações de UPDATE e DELETE apenas mudando a propriedade "operation-type". Opcionalmente também, você pode visualizar no log do JBoss ESB a instrução SQL gerada, habilitado a propriedade "show-sql" para "true".

Outro ponto importante do SQLRouter é que ele possibilidade que você escreva valores em colunas das tabelas oriundas da mensagem do pipeline. Nos exemplos anteriores, repare que sempre definimos estaticamente os valores a serem escritos nas colunas no arquivo de configuração do módulo ESB. Se quiséssemos recuperar estes valores da mensagem do pipeline, poderíamos fazê-lo da seguinte forma:

Repare que as colunas "PRIMEIRO_NOME" e "ULTIMO_NOME" terão seus valores escritos a partir dos objetos que estiverem na mensagem com os ID's "primeiroNomeParam" e "ultimoNomeParam" respectivamente. Para estabelecer estes valores, você pode gravar na mensagem usando a API de actions do JBoss ESB da seguinte forma:

Dependendo do tipo de valor que você configura na propriedade "operation-type" os valores das tags "column" serão usados de formas diferentes. Se você habilita por exemplo uma operação de INSERT, tudo que for declarado nas tags "column" serão usados para inserir valores nos campos de uma tabela. Por exemplo, usando a operação de INSERT, a seguinte instrução SQL será gerada:

Caso você precisa gerar um UPDATE numa tabela de banco de dados, altere a propriedade "operation-type" para "UPDATE" e para os campos que você deseja atualizar, habilite o atributo "update" nas colunas desejadas. As demais colunas que não forem sofrer atualização irão compor a cláusula WHERE da instrução SQL gerada. Caso nenhuma coluna "não update" seja definida, nenhuma cláusula WHERE será gerada. Eis um exemplo:

Para gerar um DELETE na tabela de banco de dados é mais simples ainda: Basta alterar a propriedade "operation-type" para "DELETE" e pronto. Caso você deseje filtrar a remoção gerando uma cláusula WHERE insira uma ou mais propriedades do tipo "column". Cada entrada de "column" se tornará uma condição da cláusula WHERE. Outro recurso interessante do SQLRouter para quando você deseja fazer um UPDATE ou DELETE, é que você pode estipular condições para a cláusula WHERE usando operadores SQL. O exemplo abaixo ativa todos os clientes que se chamarem "Ricardo" e que tenham CPF maior que zero:

Um exemplo do inicio ao fim usando SQLRouter

Agora que exploramos alguns dos detalhes por trás do SQLRouter, vamos ver como utilizá-lo num exemplo concreto. Para este exemplo, considere os seguintes componentes de software:

MySQL Server 5.1
JBoss ESB 4.7
MySQL JDBC Driver
Eclipse + JBoss Tools 3.1
JDK 1.6+

A idéia do exemplo é que o ESB monitore um diretório compartilhado da rede procurando por um arquivo de processamento de pedido no formato XML. Assim que tal arquivo for escrito no diretório, o ESB irá pegar os dados referente a um cliente e gravar no banco de dados fazendo um INSERT. Considere o seguinte módulo do ESB para configuração:

A descrição completa do arquivo de configuração do módulo ESB encontra-se textualmente aqui. Já o arquivo de configuração do Smooks que transforma de XML para Java pode ser adquirido aqui. Para testar o exemplo, crie um arquivo XML no diretório especificado no arquivo de configuração como mostrado abaixo:

Você deverá também configurar um pool de conexões no JBoss ESB para que ele aponte para seu banco de dados de testes. Se você é um usuário de JBoss, isso não será um problema. Qualquer banco de dados pode ser usado para testes, uma vez que o SQLRouter fala com o banco de dados via JDBC puro.

Boas Integrações ;-)

Evento JBoss In Bossa: Não Perca!

2010-04-23T14:12:00.000-07:00

Dias 07 e 08 de Maio acontecerá o maior evento de JBoss do Brasil dos últimos tempos. Serão dois dias de informações sobre tecnologias JBoss que estão sendo usados no Brasil e no mundo. É uma oportunidade única para você ficar por dentro sobre o que acontece no mundo Java e sobre os principais projetos open-source da Red Hat / JBoss.

Este evento terá um formato diferenciado. O dia 07 será reservado para workshops do tipo "hands-on" que irá capacitar os congressistas em vários dos assuntos que serão discutidos no dia de palestras. Neste caso, você terá os especialistas da JBoss do Brasil e autoridades do mundo Java ao seu dispor para que você aprenda praticando e tire suas dúvidas sobre os assuntos abordados. O dia 08 será voltado exclusivamente para as palestras que irão cobrir os assuntos mais interessantes do mundo atual, desde frameworks de desenvolvimento Web, passando por questões de portais e EAI, chegando a informações sobre as novidades do JBoss Application Server, JON / JOPR e arquiteturas baseadas em CEP com Drools Fusion.

Sem dúvida, serão dois dias de muita informação e capacitação, onde você terá a oportunidade de estar por dentro das principais tecnologias do mundo JBoss e aumentar ainda mais sua rede de relacionamentos profissionais ;-)

Garanta já sua vaga: http://www.jbossinbossa.com.br/2010/index.htm

Integrando MRG Messaging e o JBoss ESB

2010-03-12T13:28:00.000-08:00

Suponha que você tenha um componente EJB (um Stateless Session Bean) que forneça alguma funcionalidade de negócio que deva ser acessada por diversos canais de transporte. Conforme visto em outros artigos deste blog, usando um ESB você pode habilitar este componente EJB para escutar diversos tipos de canais que o mesmo suporte. No caso particular do JBoss ESB, você pode habilitar tal componente EJB criando um serviço interno que o encapsule (Usando por exemplo o adaptador EJBProcessor) e expô-lo usando qualquer um dos vários provedores que o mesmo suporte, tais como JMS, File, FTP, Socket, HTTP, SOAP, Hibernate, etc.

Uma estratégia interessante que pode potencializar a habilitação de um componente EJB (ou qualquer outro tipo de componente do legado) é fazer com que o JBoss ESB escute um Broker AMQP. Fazendo isso, qualquer aplicação que enviar uma mensagem para o Broker terá sua mensagem processada pelo JBoss ESB que pode, através dos seus mais diversos adaptadores, entregar a mensagem a um canal particular. A principal vantagem desta estratégia, em oposição a de que o próprio Broker entregue as mensagens, é que o ESB pode "preparar" a mensagem antes dela ser entregue. Como parte das funções de um ESB é a de fornecer mecanismos de transformação, você pode receber a mensagem pelo ESB, adaptá-la apropriadamente para ai sim, entregá-la ao canal de destino.

Neste artigo, irei mostrar como isso pode ser feito usando como Broker AMQP o MRG Messaging, e como ESB o JBoss ESB. O exemplo será baseado num cenário de negócio não muito diferente dos vividos no dia a dia de diversas empresas do ramo de telecomunicações.

Um cenário do mundo de telecomunicações

Uma dada empresa provedora de serviços de internet, tv e telefonia possui uma plataforma baseada em JEE que cuida de todo o processo de aprovisionamento de clientes. Em particular, a mesma disponibiliza um componente EJB do stipo SLSB que recebe um pedido de ativação de um ponto e configura-o junto as plataformas de engenharia da empresa.

Uma dada aplicação feita em Python precisa solicitar a ativação de um ponto do cliente diretamente neste componente EJB, mas devido as diferenças e restrições tecnológicas, isso tornou-se um problema emergente. Para contornar o problema, a empresa resolveu utilizar as facilidades que a plataforma MRG Messaging oferece quanto aos aplicações Python sobre conectividade. O programa Python foi modificado então para enviar uma requisição de ativação no formato XML para o Broker AMQP:

Repare que o programa, cria uma requisição baseada em XML que contêm o código do assinante (o campo 'customerKey'), se o cliente deseja ponto de internet (o campo 'internet'), se o cliente deseja ponto de TV (o campo 'tv') e se o cliente deseja ponto de telefone (o campo 'phone'). As informações sobre internet, tv e telefone são "flags" booleanas no estilo C++, onde "0" indica falso, e "1" indica verdadeiro. A idéia é que esta requisição seja transformada em uma requisição RMI/IIOP para o seguinte componente EJB:

Este componente EJB, possui um método chamado "executarAtivacao" que aceita um único argumento: Uma instância da classe com.redhat.mrg.demo.types.PedidoAtivacao. Segue abaixo o descritivo desta classe para conferência e implementação:

Veremos então como fazer com que a mensagem XML recebida pelo Broker AMQP seja processada pelo JBoss ESB de forma que ela seja transformada em uma chamada ao componente EJB implantando num servidor de aplicações J2EE sob o nome JNDI AprovisionadorBean/remote.

Configurando o JBoss ESB para escutar mensagens do MRG Messaging

O JBoss ESB integra de forma transparente com diversas soluções de mensageria, entre elas o ActiveMQ, JBoss Messaging, Websphere MQ e OracleAQ. Integrar com o MRG Messaging não poderia ser diferente. Basicamente, você deve configurar um provedor do tipo JMS que estabelece uma conexão com o MRG Messaging através de algum dos modelos de mensagens suportados (FanOut, Direct, Topic). Definido o provedor, você pode declarar um ou mais buses (canais de transporte) que apontam para filas internas do Broker AMQP. Segue abaixo um módulo ESB criado para o cenário proposto:

Repare que foi declarado um bus chamado "mrgChannel" que é vinculado ao serviço "AtivacaoProxyService" através do listener "mrgListener", conforme você pode ver na lista de listeners do serviço. Este serviço realiza duas transformações baseadas em Smooks (msgTrans1 e msgTrans2) que transformam a mensagem XML recebida (enviada pelo programa Python) na instância da classe com.redhat.mrg.demo.types.PedidoAtivacao que deverá ser passada como parâmetro ao EJB de aprovisionamento. O trabalho de invocar o componente EJB é feito pelo adaptador EJBProcessor, que realiza uma conexão JNDI com o servidor de aplicações e realiza um lookup do componente remoto para execução.

A primeira transformação muda o XML recebido para um documento XML que define tipos mais próximos ao Java, mudando por exemplo os flags de utilização para instâncias válidas de um java.lang.Boolean. A listagem abaixo mostra como esta transformação deve ser feita:

Foi utilizado para esta transformação um cartulho do tipo XSL que aplica um template XSLT no documento XML da mensagem. O restante da transformação fica por conta do script XSLT fornecido no cartucho. A segunda transformação é mais simples, ela apenas lê o documento XML resultante da primeira transformação e converte-o em um objeto Java:

Uma vez que a mensagem esteja no formato Java, isto é, como uma instância da classe com.redhat.mrg.demo.types.PedidoAtivacao, o adaptador EJBProcessor realiza uma invocação RMI/IIOP para o componente EJB hospedado num servidor de aplicações. Abaixo segue o screenshot da minha máquina, que mostra o exemplo sendo executado e a saída do console do servidor de aplicações:

Boas Integrações ;-)

Enterprise Messaging usando Red Hat MRG

2010-03-09T12:06:00.001-08:00

O Red Hat MRG é uma plataforma integrada que combina alta performance, computação distribuída e mensageria inteligente baseada em padrões de mercado. Em termos práticos, MRG sigifica: Messaging, Real-Time e Grid. O MRG teve seu anúncio em dezembro de 2007, e seu lançamento oficial em 19 de junho de 2008, durante a conferência do Summit 2008. Atualmente ele se encontra na versão 1.2 e possui diversas melhorías da versão original, muitas delas voltadas a questões de segurança e certificação com plataformas de hardware e software. Neste artigo, irei mostrar como o Red Hat MRG funciona, em especial, a parte referente a mensageria baseada em AMQP. Mas antes disso, deixe-me apresentar, mesmo que suscintamente, a plataforma MRG como um todo.

Red Hat MRG

O MRG é uma proposta corporativa para trazer três caraterísticas essenciais do mundo enterprise para dentro de um sistema operacional que dispensa apresentações: Red Hat Enterprise Linux. A idéia básica é fazer com que o próprio sistema operacional RHEL tenha features relacionadas a mensageria, processamento em tempo real e processamento de CPU distribuído. Com isso, clientes de diversos segmentos como telecomunicações, finanças e governo podem realizar um único investimento muito mais estratégico, tendo uma subscrição que elimina a necessidade de licenças em produtos diferentes como por exemplo, o IBM Websphere MQ (MQSeries).

Conforme dito anteriormente, o MRG é composto de três componentes. São eles:

Messaging: Solução de mensageria baseada no padrão AMQP e capaz de executar milhões de mensagens por segundo. A principal caracteristica do Messaging é a capacidade de receber e entregar mensagens de diferentes aplicações e linguagens, sem precisar sacrificar recursos corporativos de soluções de mensageria como garantia de entrega, transações, segurança do canal e das mensagens bem como alta performance.
Real-Time: O real-time é o elemento responsável por dar presivibilidade no processamento de aplicações em cima do kernel do RHEL. Através de um kernel otimizado, é possível dar menor latência no processamento de cargas pesadas e ainda sim, dar um comportamento previsível do ciclo total do processamento. Do ponto de vista de aplicações Java, o real-time também possibilita um melhor aproveitamento dos CPUs quanto a execução de coletas de lixo, evitando por exemplo grandes pausas de coleta (Full GC) e deteriorização da performance com a realocação de objetos entre as gerações.
Grid: Computação em grade não é um assunto novo, mas representa um tipo de solução que com o advento da virtualização e da computação nas nuvens possibilita crescimentos de poder de processamento em altos níveis. A principal caracteristica do Grid é possibilitar que um processamento pesado seja distribuído e coordenado entre vários nós sem que a separação físíca de CPUs seja um vilão quando performance e presibilidade sejam cruciais. Nesta apresentação, você pode perceber por exemplo, como uma renderização pode ser processada de forma mais rápida utilizando vários recursos virtuais baseados no Amazon EC2.

Para saber mais sobre o Red Hat MRG, você pode consultar on-line no site da Red Hat. Existem diversos documentos, papers e ativos sobre o MRG disponíveis. Vamos agora dar foco em ênfase a parte relacionada a mensageria do MRG.

MRG Messaging

A um certo tempo atrás, escrevi este artigo que fala sobre o protocolo AMQP. Na época, mencionei a plataforma Red Hat Messaging que seria a implementação do AMQP pela Red Hat. Atualmente, esta implementação faz parte do produto Red Hat MRG, apesar de poder ser adquirido separadamente através de subscrições exclusivas.

O AMQP possibilita que diferentes linguagens de programação possam trocar mensagens utilizando um broker que implementa as especificações ditadas pela iniciativa AMQP. Neste caso, podemos ter portanto diferentes implementações deste broker por diversos fornecedores, sem que a interoperabilidade seja sacrificada. Como analogia, pense por exemplo nas especificações do JEE, e nas diferentes implementações de servidores de aplicação, como JBoss, WebLogic e Websphere. Cada uma das soluções pertente a um fornecedor particular, mas todos eles possuem uma stack básica que é padrão (ditada por um consórcio) e que permite que as aplicações possam ser escritas de uma forma padronizada e uniforme.

Assim funciona implementações do AMQP. Você pode usar brokers de diferentes fabricantes que todos eles irão poder trocar mensagens entre si. Algumas das implementações existentes de brokers AMQP são o iMatix OpenAMQP, Red Hat MRG, Apache Qpid e RabbitMQ. Todos eles, possibilita que mensagens sejam enviadas e entregues através da mesma pilha de software, que possui implementações para linguagens diversas como Python, C++, Ruby, CSharp e claro, Java.

Porém, cada implementação possui suas especificidades, e a do Red Hat MRG com certeza é os altos níveis de desempenho e performance, bem como a previsibilidade de processamento das mensagens, graças a integração nativa com o Grid e o Real-time. As principais características do Red Hat MRG são:

Modelos de mensageria baseados em P2P, Publish/Subscribe e Async
Mensageria com alta disponibilidade
Transações locais e distribuídas
Multiplos clientes: Java, CSharp, C++, Python, Ruby, linguagens de Scripts
Ferramentas de gerenciamento e consoles de monitoramento
Federação de Brokers, ideal para nodos geograficamente distribuídos
Atenticação baseada em SASL
4 padrões de roteamento de mensagens, incluindo XQuery
Acesso direto a AIO para durabilidade de mensagens e Journaling
Broker C++ otimizado para o RHEL integrado com Grid e Real-time
E muito, mas muito mais coisas ...

Instalando o Red Hat MRG Messaging

Instalar o Messaging não pode ser mais simples quando você usa RHEL. Abra um console e entre com suas credenciais de super usuário (root). Feito isso, execute o seguinte comando:

yum groupinstall "MRG Messaging"

Este grupo de pacotes instala vários componentes do Messaging como o Broker, os stubs necessários para que clientes possam conectar no Broker e as stacks das linguagens de programação. Para quem não usa o RHEL e usa um Red Hat alternativo (Fedora, CentOS), o repositório que define este grupo não estará disponível. Neste link, você pode consultar os pacotes necessários e instalá-los individualmente.

Depois que os pacotes forem instalados, você pode verificar se tudo está correto iniciando o Broker. Para isso, abra um terminal e execute o seguinte comando:

/usr/sbin/qpidd -t

Este comando inicia o broker na porta 5672 e exibe uma série de mensagens no console (resultado do parâmetro -t de "trace") referentes as cargas e carregamentos feitos. Verifica se a mensagem "notice Broker running" aparece. Se aparecer, significa que o broker está pronto para receber e processar mensagens. Para interromper a execução do broker, basta teclar "Ctrl + C" no console. Caso a porta 5672 já esteja sendo usada por outro processo, é possível configurar o broker em outra porta. Para rodar o broker na porta 8888 por exemplo, execute o seguinte comando:

/usr/sbin/qpidd -t -p 8888

Alguns exemplos usando Red Hat MRG Messaging

Vamos agora verificar como podemos fazer uso do MRG Messaging. Para isso, irei mostrar várias aplicações escritas em linguagens diferentes que trocam mensagens através do Broker. Para este primeiro teste, execute o broker na porta padrão. Vamos criar um programa em Python que conecta no broker e espera por mensagens numa fila. Crie um programa em Python como mostrado abaixo:

Este programa realiza uma conexão com o broker, e define uma fila chamada "message_queue". Na sequência, é criado uma ligação entre esta fila e o nome "routing_key" para que conexões baseados no protocolo "direct" possa ser efetuado.

Abra um console, e execute este programa com o seguinte comando:

python ConsumidorUsandoPython.py

Para executar este programa, você precisará ter o interpretador do python instalado, bem como os stubs do AMQP. Agora vamos criar um produtor de mensagens em Python. Crie o seguinte programa:

Este programa Python faz um processo de conexão semelhante ao consumidor, mas a sua ação é de enviar uma mensagem para a chave "routing_key". Assim que esta mensagem chegar no broker, ele irá roteá-la para a fila mapeada a esta chave. Execute este outro programa usando o seguinte comando:

python ProdutorUsandoPython.py

Assim que a mensagem for enviada ao broker, o consumidor será notificado da sua entrega e irá exibir no console o resultado da mensagem enviada. O screenshot abaixo da minha máquina mostra este cenário:

Agora vamos deixar as coisas um pouco mais interessantes. Vamos criar um produtor usando Java. Para isso, escreva o seguinte programa Java usando a API do JMS:

Repare que o programa Java carrega algumas propriedades de conexão de um arquivo de propriedades. Antes de executar este programa, crie o seguinte arquivo:

Execute este programa Java. Você deverá ver a seguinte saída dentro do consumidor Python:

Para finalizar estes testes com o broker, vamos fazer algo um pouco fora da caixa: Consumir as mensagens do broker usando C# .NET. Vou deixar aqui o código fonte do programa CSharp que fiz, e vou apenas mostrar a execução do produtor Python e o consumidor .NET para maior clareza. Mas repare no código fonte disponibilizado o quão simples é criar uma aplicação cliente para AMQP.

Como funciona o modelo de troca de mensagens?

No AMQP, existem vários modelos de troca de mensagens. O modelo mais usado e conhecido sem dúvida é o de FanOut. No FanOut, cada fila é vinculada a um nome para o Broker, e um consumidor deve enviar suas mensagens para este nome. O nome, representa o vínculo da fila no Broker, e fornece portanto um acesso direto entre a fila e o consumidor da mesma.

Uma abordagem parecida com a FanOut é a Direct. Através do modelo de Direct, você enviada mensagens para um nome virtual que possui uma chave associada. Tanto o nome quanto a chave são vínculados a fila interna do broker, e o mesmo só autoriza a entrega da mensagem na fila (ou seu consumo) se o programa cliente enviar a chave correta.

Outro modelo também muito utilizado é o de tópicos. A idéia de tópicos também é baseada em chaves vínculadas a fila do broker, porém, várias chaves podem definir "assuntos" que diferentes filas e diferentes consumidores podem estar interessados:

Federação de Brokers: Integrando empresas usando AMQP

Um dos recursos mais interessantes do MRG Messaging é a capacidade de federação. Em linhas gerais, você pode "ligar" dois ou mais brokers fazendo com que produtores e consumidores de diferentes localizações possam trocar mensagens utilizando um dos modelos mostrados anteriormente.

Através deste recurso, você pode ter por exemplo um broker AMQP (MRG Messaging ou outro) rodando em Nova York escutando eventos de trading e bolsa de valores, e ter um broker MRG Messaging rodando em São Paulo, exibindo as mensagens de Nova York para os diversos consumidores (Java, Python, C++) quase em tempo real.

OK, este MRG Messaging parece interessante, mas e a performance disso?

Números explicam melhor que palavras, logo, nada melhor para falar de performance do que mostrar benchmarks baseados em cenários de hardware e software. Segue abaixo alguns números que mostram a capacidade de processamento do MRG Messaging num dado cenário montado pela equipe do MRG Messaging:

É realmente viciante trabalhar com o MRG Messaging, e espero que esta brilhante solução esteja sendo usada nos servidores de várias empresas do Brasil pois as possibilidades são infinitas. Se você achou este produto interessante e acha que ele pode ser bem utilizado na sua empresa, entre em contato comigo no e-mail ricardo.ferreira (at) redhat.com para falarmos mais afundo e com maior nível de detalhes. Terei grande prazer em ajudá-los ;-)

MetaMatrix Platform na Prática!

2010-02-17T09:35:00.000-08:00

"Você conhece alguém de Roraima?" Essa é uma frase comum quando queremos enfatizar que algo ou alguém jamais foi visto ou se há dúvidas se ele realmente existe. E olha que de fato, eu não conheço nínguem de Roraima ... acredito realmente que ela efetivamente não exista. Brincadeiras a parte, este post será dedicado a mostrar na prática, o que é a plataforma de Data Services da Red Hat conhecida mundialmente como MetaMatrix, e conhecida internamente como JBoss Data Services Platform. Acredito que muitas pessoas já ouviram coisas sobre o MetaMatrix, alguns já experimentaram seus conceitos na prática através do projeto Teiid, mas poucos, o viram realmente em sua plenitude, com todos os seus recursos, e até mesmo num cenário real. O MetaMatrix é líder mundial de soluções de EII (Enterprise Information Integration) porém sofre do mal de Roraima: Ele é bem pouco difundido e conhecido. Vou tentar explicá-lo através de uma demonstração que criei usando o MetaMatrix Platform versão 5.5, disponível para assinantes da subscrição da Red Hat, e que daqui um tempo, estará integralmente disponivel no site da JBoss.ORG no projeto Teiid.

Um cenário típico para o MetaMatrix

O propósito geral do MetaMatrix é ser uma plataforma para integração de dados. Com este objetivo em mente, ele pode ser usado para resolver N problemas comuns no mundo dos dados. O cenário mais trivial possível seria por exemplo, usá-lo como Firewall de dados. Imagine por exemplo que você possui milhares de bases de dados (possivelmente de diferentes fabricantes) e que, você tenha informações nestas bases que sejam sigilosas. Mas você precisa dar acesso a um grupo de aplicações para que estas via SQL possam recuperar e modificar dados. Usando o MetaMatrix, você pode consolidar estes dados num banco de dados virtual, e este poderia ser acessado por estas aplicações.

Outro cenário interessante é a de MDM (Master Data Management). Uma questão crucial para muitas organizações é possuir uma visão 360 graus de uma dada informação, geralmente clientes e produtos. No ramo bancário por exemplo, é de extrema importância que você tenha uma visão holistica sobre determinada informação (um cliente por exemplo) para que você ganhe maior agilidade. A um tempo atrás por exemplo, participei de um projeto de automação de uma empresa do ramo de cartões, cujo problema era que um atendimento demorava cerca de 24 minutos por cliente(quase 15 minutos a mais do que o SLA contratado) e essa demora se dava porque as informações do cliente, faturas, atendimento de call center e dados de transações de cartões residiam em sistemas diferentes, alguns destes baseados em mainframe. Logo, atender um cliente era uma tarefa árdua para as pobres atendentes. Na ocasião, o projeto era justamente de criar uma interface adminstrativa que reunia dados de sistemas SQL, mainframe, sistemas em Websphere e Delphi, que reunia tudo isso numa única tela, bastando que o atendente digitasse o CPF do cliente. Através do MetaMatrix, isso também é possível.

Agregar dados de diferentes fontes de dados não é algo inovador. Sistemas baseados em OLAP ou Data warehouse já usam este conceito. Mas este tipo de solução sofre de dois problemas graves: Primeiro as informações não são de tempo real, os dados são atualizados quando programas ETLs são disparados (normalmente num período onde os transacionais estão em "descanso") e segundo, os dados são somente para consumo e leitura, eles não podem ser modificados. Usando o MetaMatrix, você agrega várias fontes de dados e ainda consegue ter dados em tempo real porque a transformação é online, e o acesso as fontes de dados é feito por conectores especiais que possibilitam transações na camada de EIS. Criar portanto soluções de BAM ou BI tendo o MetaMatrix como fundação é algo a se considerar, uma vez que o nível da informação se torna ainda mais interessante.

Vários cenários são interessantes para uso do MetaMatrix, e é justamente isso que o torna tão poderoso. Para fins de demonstração, considere o seguinte cenário: Uma empresa de seguros de vida possui um setor de atendimento que necessita visualizar todas as informações relativas a um cliente numa única interface rica escrita preferencialmente para estações de trabalho Windows. As informações a serem visualizadas são:

1) Os dados pessoais do cliente, atualmente mantidos por um sistema PHP acessando o MySQL
2) Os dados de contato do cliente, atualmente mantidos por um sistema Perl acessando o PostgreSQL
3) Os dados de apólices armazenados no DB2 do CICS, que exporta diariamente dados para TXT

A interface criada, originalmente usando a plataforma .NET, em especial, usando a tecnologia de Windows Forms é mostrada abaixo. Repare que a consulta feita é baseada apenas no CPF do cliente, e todas as informações citadas são reunidas nesta interface rica.

Bem, a pergunta seria: Como todos estes dados vieram parar numa aplicação cliente feita em .NET? E a resposta curta (e óbvia) seria: Através do MetaMatrix. Vamos ver como foi o processo de construção deste projeto de Data Services e como os dados foram disponibilizados.

Importação de Fontes de Dados, Criação de Entidades virtuais, VDBs

A primeira coisa a se fazer num projeto de federação de dados usando o MetaMatrix é realizar a importação de todas as fontes de dados que comporão um data service. Isso é feito através da ferramenta MetaMatrix Designer, um ambiente visual baseado no Eclipse altamente produtivo.

O modelo de trabalho do MM Designer é muito simples: Você cria um projeto de data services, constitui suas fontes (origens) dos dados, cria uma ou mais entidades virtuais (views) compostas das fontes de dados, e depois integra tudo isso num banco de dados virtual conhecido como VDB, sigla de Virtual Database. A importação dos dados é feita por um processo 100% visual e bem pouco complicado.

Depois que todas as fontes de dados são importadas para dentro de um projeto do MM Designer, é possível criar as entidades virtuais, ou seja, os data services. Data Services são como views de um banco de dados, só que são baseadas em tabelas, views ou procedures de diferentes tipos de bancos de dados ou de até mesmo coisas que não sejam bancos de dados, como sistemas de caixinha (Excel, PeopleSoft, Siebel, Oracle EBS), tecnologias (SOAP, HTTP, JMS) e formatos (XML, EDI, TXT). Através do MetaMatrix e seus conectores, qualquer fonte de dados vira um potencial data service, possibilitando inclusive, que transformações sejam aplicadas aos data services. Abaixo segue um exemplo de como, duas entidades virtuais foram constituídas das fontes de dados importadas, a saber, a tabela "TAB_CLIENTE" do MySQL, a tabela "TAB_ENDERECO" também do MySQL, a tabela "CONTATO" a partir de um arquivo TXT e a tabela "TAB_APOLICE" do PostgreSQL.

Criado os data services, é hora de consolidar tudo num VDB. Criei um VDB e inserir todos meus data services, web services e fontes de dados nele. A partir do VDB criado, por dentro do MM Designer, você pode testar se suas entidades virtuais estão funcionando corretamente. Basta compilar o VDB e solicitar a execução de testes.

Deployment: A hora mais temida de todas. Será?

Além do MM Designer, a plataforma MetaMatrix é também composta por dois outros elementos. Uma deles é o MetaMatrix Server, ou simplesmente, MM Server. É ele que mantêm os bancos de dados virtuais no ar e que faz todo o acesso as fontes de dados. O MM Server é na prática, um servidor de banco de dados como qualquer outro. Você conecta com ele, realiza autenticações, cria bases de dados (virtuais), executa consultas SQL, ele cria Query Plans para consultas pesadas ... enfim, tudo o que um SGBDR possui, ele também têm. É possível inclusive, criar stored procedures e trigger dentro dele usando a implementação de SQL dele nativa.

A única coisa que o difere dos demais bancos de dados, é que ele além disso, é um middleware de integração, que através dos conectores acessa várias fontes de dados, e pode, expor estes dados através de SQL (sua abordagem padrão) ou via SOAP, expondo as entidades virtuais na forma de Web Services.

O outro elemento da plataforma MetaMatrix é o MetaMatrix Console, ou simplesmente, MM Console. Ele é a interface gráfica de gerenciamento do MM Server. Através dele, você pode fazer deployments, gerar estatísiticas dos VDBS, parar e reiniciar conectores de EIS e claro, gerenciar questões de autenticação e autorização dos usuários. Fazer o deploymento de um VDB no MM Server é uma questão realmente trivial. Vamos aos detalhes. Primeiro, você deverá conectar no MM Console. O servidor do MetaMatrix deverá estar sendo executado em algum computador da rede que o MM Console possa acessar.

Estando logado no MM Console, basta clicar no item "Virtual Databases" e clicar no botão "Import VDB" para importar o banco de dados virtual que você criou. O mesmo VDB pode ser importando diversas vezes. Cada processo de import gera uma nova versão do VDB, o que torna o MetaMatrix ainda mais poderoso: Você pode ter várias versões do seu banco de dados em produção.

Depois de importar seu VDB, você deverá configurar os parâmetros especiais dos conectores que você usou durante a etapa de projeto. Por exemplo, como eu importei dados oriundos de uma base MySQL, outra PostgreSQL e de um arquivo TXT, uma instância de cada um destes conectores me foi gerada pelo MM Designer e incorporada dentro do VDB. Como o ambiente de desenvolvimento pode ser ligeiramente diferente do ambiente de produção, talvez se faça necessário a re-configuração dos parâmetros de acesso a dados a cada uma destas fontes de dados, dados como URL de conexão, endereço IP, usuários e senhas. Feito isso, seu banco de dados virtual está pronto para receber conexões de aplicações via SQL ou SOAP.

Acessando o banco de dados virtual criado via JDBC

Para fins de testes, criei este pequeno programa Java que realiza uma conexão com meu servidor do MetaMatrix, realiza uma consulta em minha entidade virtual "Cliente" e exibe os dados retornados no console. Repare que a consulta feita é uma consulta padrão baseada no puro e simples SQL. Nenhum código "mirabolante" teve que ser criado, e reparando nos imports da classe, dá pra ver que nada mais do que o JDK e o driver JDBC do MetaMatrix (que acompanha o produto) são necessários para criar um cliente destes. Um ponto interessante a se notar também, é que dentro do JAR que contêm o driver JDBC do MetaMatrix, existe uma classe de dialeto do Hibernate, portanto, é possível também criar clientes em Hibernate e JPA acessando MetaMatrix, caso desenho O.O de aplicações seja imperativo em sua organização.

Acessando o banco de dados virtual criado via SOAP

Finalmente, através do MetaMatrix é possível acessar as entidades virtuais através de SOAP. Se no seu VDB você habilitou esta opção, fazendo a distribuição dos XSDs que definem seu endpoint e os tipos complexos dos data services (facilmente gerados pelo MM Designer) você pode disponibilizar qualquer data service via SOAP. A infra-estrutura necessária para isso será ter um servidor de aplicações ou contêiner de Servlets que possa rodar um pequeno programa WAR (Web Archive). O MM Server disponibiliza uma aplicação Web Java que atua como Gateway entre o servidor de aplicações e o servidor do MetaMatrix.

Ao fazer o deploy deste pequeno WAR no servidor de aplicações de sua escolha, você apenas instrui a aplicação a saber qual é o endereço IP e porta que o MM Server estará escutando. Feito isso, basta acessar a seguinte URL: http://192.168.0.1:8080/metamatrix-soap/

Onde "192.168.0.1" é o servidor de aplicações que você escolheu para ser o gateway de SOAP. Ao acessar esta URL, você irá se deparar com a seguinte interface Web:

Clicando no link "Discover MetaMatrix Web Services" você fará com que a pequena aplicação Web (O Gateway) acesso o MM Server e pesquise em sua base de UDDI interna sobre os Web Services publicados. Uma lista será apresentada na tela com o resultado da consulta, e cada item da lista, terá um endereço WSDL disponibilizando, criado automaticamente pelo MM Server. Dai pra frente, qualquer requisição SOAP enviada para um destes endpoints, será enviada diretamente para o MM Server.

E desta forma, com as entidades virtuais (Cliente e Apólice) disponibilizadas via SOAP, pode ser criado o cliente rico em .NET. Acredito que este post mostrou um pouco do poder e robustez da plataforma MetaMatrix, que é a fundação do JBoss Data Services Platform disponibilizado pela Red Hat via subscrições. Se você achou esta solução interessante, e consegue ver soluções suas baseadas nela, não hesite em procurar a Red Hat do Brasil que possamos lhe auxiliar no que for preciso. Tão em breve, toda esta plataforma estará disponível para a comunidade. Neste meio tempo, é uma boa pedida exercitar os conceitos do MetaMatrix através do projeto Teiid.

Forte abraço e até a próxima!