Mostrando SOA da Forma Correta!

Em um dado momento, você estará ciente de que modernizar sua TI é a solução para a maioria dos seus problemas, e SOA aparentemente será uma boa pedida. Você então cria uma lista enorme de beneficios que SOA trás como por exemplo, que SOA irá agilizar o desenvolvimento de novas aplicações, que um ESB irá eliminar o problema de integrações ponto a ponto, que um ESB irá agregar bem mais flexibilidade na hora de garimpar o legado, etc, etc.

O unico e principal problema disso é, na hora que você vai mostrar todos estes beneficios para sua alta direção e patrocinadores a fim de conseguir fundos e orçamento para sua empreitada, você não está falando a língua correta deles. Neste caso, depois de apresentar razões e mais razões sobre porque SOA é um bom investimento, eles irão dizer: OK, mas o que eu ganho com isso?

Primeiramente, e acima de tudo, você deve mudar de abordagem. Para criar um case de sucesso SOA dentro da sua empresa, você precisa traduzir seu jargão técnico de TI para uma linguagem que pessoas não técnicas consigam ver valores mensuráveis no negócio e que sejam financeiramente atrativos. Segue abaixo algumas dicas sobre como fazer isso.

1) Jamais diga que uma abordagem SOA irá promover maior agilidade no desenvolvimento de aplicações para a empresa. Ao invés disso, explique os beneficios de se aplicar o time-to-market em novos produtos e serviços. Num cenário de corretagem, isso se tangibiliza em como tornar mais eficiente a forma como taxas são calculadas, como alterar planos de cobertura, etc.

2) Jamais diga que SOA irá promover maior eficiência para os empregados. Isso é algo muito simples e banal, e provavelmente eles já terão ouvido isso de você ou de outras pessoas de TI. Ao invés disso, julgue o fato de diminuição de capacitação de novos funcionários ou redução de erros de operação ao realizar uma operação de negócio ou executar um cenário de negócio que antes era complicado fazer no mainframe, e agora com web e portais, se torna mais simples.

3) Jamais diga que uma iniciativa SOA irá diminuir o tempo de processamento das coisas. A unica coisa que você ganhará com isso é que eles irão perguntar por mais detalhes sobre o assunto. Ao invés disso, ressalte os ganhos que eles irão ter sobre a redução do tempo de um dado cenário de negócio, como por exemplo, o atendimento de um cliente no call center. Outra boa idéia é ressaltar o quanto em dinheiro eles não terão que desprender caso as SLA's sobre atendimento (supondo um cenário que envolva atendimento ao cliente) sejam melhor atendidas devido a redução do tempo de operação de uma transação complexa.

4) Jamais diga o quão SOA torna simples acessar fontes de dados heterogêneas. Eles irão dizer: Hãm? Ao invés disso, ressalte o fato que com a correta aplicação de SOA, uma gama de possibilidades se abre quanto a aposta em novos mercados e oportunidades. Ressalte por exemplo, a possibilidade de expansão dos negócios através da integração de soluções de TI com parceiros e fornecedores.

Estas são algumas das dicas interessantes a serem usadas na hora de tornar SOA um objetivo de negócio numa empresa. Lembre-se, SOA deve ser interessante para que está pagando por isso, e não pra quem irá coloca-lo em prática. De fato, SOA reserva um interesse particular para todos os envolvidos, mas a TI não deve deter os maiores benefícios, afinal de contas, TI é apenas um instrumento para tornar factível algo muito maior: Oportunidades de negócio e lucro!

Boas Arquiteturas!

Rollout SOA usando "SOA Rocket Science"

Neste post, irei abordar a estratégia da Software AG sobre rollout de soluções SOA, conhecida como SOA Rocket Science. Através desta técnica, pode-se ter horizontes e metas sobre como executar um rollout de uma solução SOA de uma forma pragmática, seja em nível de experimentação, seja em nível de adoção empresarial.

A Filosofia dos Foguetes

Mesmo após um perfeito lançamento, um foguete ainda se encontra numa zona de risco. É a briga contra a gravidade. Apenas quando o foguete entra fora da órbita da terra, ele pode se considerar fora da zona de risco, pois a probabilidade do foguete depois de lançado, voltar a terra, é muito baixa.

Assim são projetos SOA. Quando você inicia sua abordagem, facilmente você se sente tentado, motivado ou até mesmo forçado a voltar a fazer as coisas do jeito antigo, sem nenhum foco em SOA. Até que você atinja este marco de maturidade que dá essa segurança que você jamais irá regredir sua empreitada, você deve continuamente brigar contra a "gravidade", e potencialmente voltar a fazer as coisas de forma tribal, defensiva, altamente acoplada, e sem nenhum foco no negócio.

Saindo de um Projeto SOA para um Programa SOA

Você deve trllhar vários projetos de sucesso em SOA para poder atingir o nivel de programa SOA, ou seja, o nível onde SOA está mudando a forma como a empresa reagi aos negócios de forma positiva, e que a empresa sabe disso e usa SOA como diferencial competitivo. Neste marco, a empresa sabe que o elemento que está fazendo isso ser possível é SOA, e neste caso, ela investe cada vez mais fundos e recursos numa iniciativa que dá resultados: O programa SOA. Algumas dicas para se atingir este marco são:

1. Mantenha a direção do Foguete estabilizada: Para que você mantenha sempre o foco da sua estratégia SOA na direção correta (rumo a algum objetivo estratégico previamente acordado) você deve continuamente medir o curso do programa, e verificar se o rumo ainda está correto ou viável. O uso de indicadores econômicos e processuais é muito importante neste cenário. Neste caso, use KPI's não somente nos processos de negócio, mas na abordagem de adoção SOA também.
2. Siga em Frente: Para seguir em frente, motive continuamente sua equipe de implementação, mas não esqueça de quem patrocinou por tudo. Executivos e gerentes precisam estar motivados também e saber das mudanças e resultados obtidos a cada passo. Para obter esta motivação, você deve acelerar o número de projetos feito no prazo com sucesso. Para obter esta proesa é muito simples: Não crie projetos muito grandes. A escolha dos projetos que irão determinar um programa SOA é crucial. Neste caso, prefira projetos pequenos, mas com grande visibilidade na empresa. Se um dado projeto devido a sua visibilidade não é pequeno, quebre-o em cenários de negócios e implemente-os individualmente.

A prática "SOA Rocket Science" deve ser aplicada de forma simultânea o seu blueprint arquitetural e seu blueprint organizacional, assim como mostrado na figura abaixo:

A Área de Perigo SOA

Até que você chegue no ponto de estabilização, você estará continuamente brigando contra a gravidade. Cada vez mais, você será puxado para fazer as coisas da forma como eram feitas antes de SOA. Estando na área de perigo SOA, você estará contantemente gastando energia na forma de orçamento, capital politico, capital humano, patrocínio executivo, investimento de negócio, gerência da atenção e outros esforços relacionados a SOA. Se você não gerir corretamente esta energia, você estará revertando sua estratégia para a abordagem tradicional sem SOA.

Quando você atinge o ponto de estabilização, você pode dar qualquer "próximo passo" sem precisar desprender energia adicional para lutar contra a gravidade. Você estará na gravidade do espaço sideral, onde a gravidade não têm mais influência. Agora, atingir o ponto de estabilização significa que você atingiu os objetivos do seu programa SOA? Não necessariamente - mas significa que você atingiu um ponto de maturidade importante no seu programa. Neste ponto de maturidade, os investidores acreditarão que SOA realmente é uma boa estratégia e admitirão que tardaram em fazer este tipo de investimento.

Do ponto de vista da TI, serviços serão criados sem maiores esforços, o reuso já será algo normal e não será mais motivo de comemoração, e pessoas de fora da TI se sentirão estimuladas a participar do programa SOA ajudando de qualquer forma.

Colocando o Foguete na Direção Certa

Foguetes geralmente medem a direção que estão tomando para assegurar que irão chegar em seu destino. A chave para se fazer isso no "SOA Rocket Science" é saber onde você está querendo chegar (algo simples mas que as pessoas ignoram) e manter uma motivação organizacional enquanto o foguete está em andamento. Desta forma, através da motivação, você não será facilmente abalado pela gravidade.

Mas antes que você faça qualquer correção no curso de sua jornada, você deve ter as corretas medidas no seu respectivo lugar. Conhecendo as métricas corretas, você deverá aplica-las para que você possa acelerar a melhoria de resposta e qualidade entre os projetos.

Acelerando Métricas de Valor para a TI

Você pode motivar as pessoas de TI mostrando a elas algumas das seguintes métricas:

1. Agilidade na hora de entregar serviços: Você ainda está com duvidas sobre o significado e valor de determinados serviços para sua organização? O quão ágil está o desenvolvimento de novos serviços?
2. O DeadTime do ciclo dos serviços: Quanto tempo seus serviços ficam no estado de "em aprovação" ou pendentes de implantação devido as questões de aprovisionamento, questões de segurança ou outras questões? Como você pode automatizar etapas ou prover relatórios e alertas sobre serviços que estão "estancados"?
3. Percentual de novos serviços versus o reuso de outros: Avaliar o delta entre reusar serviços existentes e a criação de novos serviços. A criação de novos serviços está sendo influenciado pelo reuso? Se isso for verdade, é um sinal de que o rollout está se dando rapidamente.
4. O custo de um novo serviço: Com o tempo, o custo de criação de um serviço tende a diminuir, enquanto que o custo para mante-lo também. Exaltar esta métrica pode ajuda-lo a acompanhar o quanto SOA está dando resultado.

Estas são algumas métricas importantes que podem ajudar seu pessoal de TI a estar motivado ao longo do programa, e faze-los não ser agentes importantes na sua luta contra a gravidade.

Acelarando Métricas de Valor para a área de Negócios

Durante o passar do tempo no programa SOA, a regra é que você possa comprovar valor agregado a medida que entrega os projetos. Para se fazer isso, você deve entender as dinâmicas de consumo de serviços por parte dos clientes, para que você possa determinar os melhores indicadores de performance de negócio para sua organização. Segue alguns indicadores clássicos baseados em alguns projetos SOA de sucesso e fracasso da Software AG:

• Número de Serviços efetivamente Reutilizados
• Número de aplicações e parceiros conectados a um serviço
• Taxa de acesso ao serviço por aplicação
• Volume de uso por usuários
• O quanto um serviço precisa ser alterado para atendimento
• O quanto os serviços melhoram e motivam seus consumidores
• O número de padrões de reuso aplicados aos serviços

Guia de Auxilio para as Organizações

Depois que você implantar em seu programa SOA uma área responsável por coleta e divulgação de métricas do programa para a TI e as áreas de negócio, é hora de investir tempo em algumas mudanças na organização para também combater o problema da gravidade. Algumas destas mudanças são:

• Reestruturação Organizacional
• Mudanças para realizar compensação de funcionários (estímulo empregatício)
• Atrelar o sucesso organizacional ás métricas de SOA (Sem inventar cenários)
• Capacitar empregados e contratar novos
• Promoções salariais, plano de cargos e salários, politicas de crescimento
• Alteração dos nomes dos cargos e suas descrições de atividades
• Alterar a forma de aquisição de fundos para uso da TI

Cada uma destas ferramentas pode ter um efeito positivo ou negativo na sua organização. Logo, monitorar o impacto de cada mudança e avaliar o beneficio agregado é algo a ser feito com cuidado e devoção, uma vez que normalmente as mudanças nunca entram em prática em seus "100%" . Mudanças na mudança devem ser feitas ao longo do tempo.

Não seja tão ingênuo a pensar que mudanças organizacionais afetam apenas as áreas de negócio e mudanças arquiteturais afetam apenas a TI. Ambas as pessoas de TI e negócios precisam de suficiente motivação para que seus comportamentos estejam alinhados com o que o programa SOA precisa.

A variável chave que irá determinar corretamente a prosperidade do seu programa SOA, será o entusiasmo organizacional para que elas possam acreditar de fato no valor de SOA. As pessoas precisam ver oportunidades de carreira, crescimento e futuro para cair de cabeça em qualquer grande investimento como é a SOA. Sem isso, com o tempo, as pessoas vão sendo cada vez mais responsáveis por fazer com que o programa SOA falhe, pois elas não estão motivadas para torcer por ele.

Uma lição importante disso é saber que, não são somente as pessoas que injetam fundos num programa SOA precisam estar constantemente posicionadas sobre o sucesso do programa. Quem faz a coisa acontecer também precisa. As vezes, pensamos que por estarmos no meio de uma obra ou construção estamos a par de tudo o que está sendo feito. A grande verdade é que sabemos apenas aquilo que nos mandam fazer, mas poucos operários sabem exatamente que tipo de serviço será agregado aquele prédio que estão construíndo. Todo especialista SOA responsável por um programa deve garantir que todo envolvido (seja TI ou negócios) esteja apropriadamente motivado.

Guia de Auxilio para a TI

Existem mudanças particulares a serem feitas na TI, cujo foco também é garantir a melhor eficiência do programa SOA através dos membros técnicos. Dentre estas mudanças, incluem-se:

• Adicionar novas politicas de governança
• Gerenciar de forma eficiente requisitos de software
• Versionamento de serviços
• Alterar a forma como serviços são identificados e descobertos
• Alterar o plano arquitetural corportivo da TI

Motivando Pessoas

Quando um foquete atinge a velocidade de escape, a força da gravidade tenta puxa-lo para baixo, enquanto que a força da extratosfera tenta puxa-lo pra cima. Nesta analogia, a extratosfera é a motivação das pessoas e a implementação correta do entusiasmo, a confiança do poder executivo e a realização positiva do seu programa SOA.

Em ultima analise, pessoas são motivadas pelo dinheiro, gerência de suas expectativas e pelo que seus chefes os falaram pra fazer. Sem estas concretas iniciativas, um caminho de adoção SOA pode ser dividido em interesses separados ao invés de convergir para um unico interesse. Segue abaixo uma lista de fatores que as pessoas consideram sobre como agir:

• Os dados: "Porque está certo."
• Seu chefe: "Porque ele disse pra fazer assim."
• Dinheiro: "Porque isso me trás dinheiro."
• Compromisso: "Porque eu prometi."
• Pressão: "Todo mundo está fazendo o mesmo."
• Amizade: "Porque eu gosto dele(a)."
• Cultura: "Porque é assim que se faz as coisas ..."

Acredito que através do "SOA Rocket Science" alguns detalhes preciosos sobre SOA possam estar mais claro agora para os caros leitores. Aplicar corretamente esta técnica (em conjunto com muitas outras) são elementos fundamentais para um correto, efetivo e rápido rollout de soluções SOA nas empresas. O ano de 2009 começou com grandes expeculações sobre o futuro de SOA, um bom exemplo disso é o artigo da InfoQ Is SOA Dead? lançado em janeiro deste ano.

IMHO, SOA ainda não é algo normal e pragmático de se fazer, porque muitas das principais coisas ensinadas neste post relacionadas principalmente sobre fatores humanos, são ignorados. Vejo excelentes profissionais de TI que supostamente aplicam SOA por ai, mas não têm noção nenhuma sobre como gerir este insumo tão importante nas corporações: As pessoas. SOA está morto? Ainda não. Ele será? Depende, se os ditos "profissionais SOA" ainda pensarem que isso é algo relacionado ao uso de BPM, ESB's, Web Services, JMS, SCA, SDO, UDDI, e demais letrinhas de praxe, realmente SOA estará fadado ao fracasso.

Terá sido mais um grande hype da área da TI, que devido a imensa ignorância deste tipo de profissional, acha que máquinas e tecnologias são mais importantes que pessoas. Termino este post com a seguinte frase:

"Por quê, pessoas racionais e inteligentes agem de forma tão irracional?"

Esta frase, foi retirada de um paper super interessante que compilo aqui, sobre os tipos de CIO's do futuro, e como eles deverão pensar para legitimar e aplicar o desenvolvimento sustentável usando a TI como principal arma. O paper "Circa 2015: The CIO of the Future", é uma produção da Software AG em parceira com a firma ValueDance. Ele pode ser baixado aqui.

Boas Arquiteturas!

Granularidade de Serviços usando GPS - Parte 1

Criar uma estratégia SOA numa empresa em nível corporativo não é uma tarefa simples. Apesar de existirem hoje várias ferramentas e soluções que possibilitem o rápido desenvolvimento de serviços e processos, uma abordagem SOA ainda é bastante regada de esforços humanos pra seu sucesso. Muitas das pessoas que me procuram e comentam sobre sua iniciação em SOA e o estágio atual de sua adoção, comentam sobre a eficaz capacidade de se sentirem perdidos no que fazer, mesmo antes de começar.

Neste caso, recomendo sempre procurar por uma arquitetura de referência que possibilite o rollout de uma estratégia SOA de uma forma controlada e repetida. Três das melhores arquiteturas de referência que respeito para SOA falam sobre como fazer isso. São elas: Oracle, Software AG e IBM. Neste post, irei mostrar como aplicar a abordagem da Oracle (de fato, da BEA) para rollout de serviços SOA.

A Oracle possui um método chamado de GPS (Global Positioning System) para ajudar arquitetos, projetistas e programadores a criarem serviços numa estratégia corporativa sem que em poucos dias, o processo vire um pandemônio rapidamente. No mundo real, um GPS lhe mostra a localização de algum objeto ou pessoa baseado nas coordenadas de latitude e longitude. Quanto mais exato for a coordenada em seu mapa, mais certo da localização você estará dada uma certa situação.

O Sistema de Coordenadas SOA

Coordenadas são uma união de escalas uni-dimensionais. Para sistemas GPS, coordenadas usam a escala da latitude (O quão próximo você está do norte ou do sul) e a escala da longitude (O quão próximo do oeste ou do leste) para determinar sua posição na superficie da terra. Em SOA, você precisa criar uma gama de escalas. Uma vez que você tenha determinado suas escalas, você pode começar a rabiscar seu sistema de coordenadas SOA, e, a partir disso, criar sua estratégia de rollout SOA em nível corporativo.

A Escala de Abstração do Software

A primeira a ser trabalhada é a escala da abstração. Arquitetos e programadores conhecem bem o valor desta ferramenta, e não iremos aqui discordar deste valor. Entretanto, nem tudo precisa ser altamente abstrato. Algumas coisas precisam ser literalmente concretas para que outras, possam ser altamente abstratas. A escala de abstração do software (mostrado na figura mais abaixo) começa em seu nível superior com artefatos que são altamente abstratos.

Por exemplo, uma implementação de banco de dados é concreto, assim como outras coisas que vemos no mundo do software. Não estou falando que não há espaço para abstração em implementações de banco de dados. O ponto é mostrar que numa grande visão sobre uma abordagem SOA, a implementação de um banco de dados deve ser a camada mais concreta possivel para quem "olha" as coisas de cima. De forma semelhante, dispositivos físicos como roteadores, modems e switches devem também fazer parte da porção mais inferior da escala.

Orientação a serviços é um conceito antigo, denominado anteriormente de "Application Integration". A medida que automatizar processos de negócio é uma prática que evolui dentro das empresas, mais há a necessidade que as aplicações destas empresas possam trocar informações conforme didato pelos processos de negócio.

Com o passar do tempo, programadores criam mais e mais API's publicas para expor as funcionalidades de um sistema para que outro possa consumi-los. Atualmente, temos esta figura na forma de serviços web, dai o nome, "Serviços Corporativos" na figura acima.

Em sistemas de compra via internet modernos, temos cerca de duzias a centenas de aplicações que subsidiam vários processos de negócio corporativos. Há claro um agrupamento natural de certas aplicações para formar um conceito. A este agrupamento, damos o nome de serviços de um domínio. Falarei mais tarde sobre serviços de um domínio, mas por hora, apenas saiba que são serviços com uma abstração bem maior que serviços de aplicação.

Finalmente, temos os serviços em nível corporativo. O Enterprise Service Layer (ESL). Devemos pensar nesta camada como sendo uma "API" para toda a corporação. Serviços neste nível de abstração não conhecem detalhes sobre banco de dados, aplicações ou domínios. Estes serviços podem ir a qualquer lugar e fazer o que quiser (fazendo uso dos serviços das camadas mais concretas). A unica regra para estes serviços é que eles não saibam nenhum detalhe sobre os demais componentes que os sustentam.

Agora você conhece a primeira escala do sistema GPS. Você deve entender que vários principios devem ser aplicados para fazer uso desta escala. O primeiro principio chama-se "Conhecimento da Dependência". Cada camada de abstração conhece sua camada de abstração inferior. Drivers JDBC conhecem (através de configuração) qual é a instância do banco de dados que devem acessar. Instâncias de banco de dados por outro lado, não conhecem quais drivers JDBC irão estar acessando-os. A dependência deve ser unidirecional.

O segundo principio é o "Ocultamento de Detalhes". Este principio fala que, a medida que você aumenta o seu nivel de abstração (sobe nas camadas) você está menos adepto a ter contato com detalhes de baixo nível sobre implementação, e cada camada conhece cada vez menos sobre as camadas anteriores. Isso não siginifica nas camadas mais altas, existe menos informação disponivel para se trabalhar, mas sim, a quantidade de código "baixo nível" dominui e tende a zero. Componentes das camadas mais baixas são regadas de uma quantidade grande de detalhes de baixo nivel. Componentes das camadas mais altas sabem somente o que fazer (processar um Pedido) mas têm pouca ou nenhuma informação sobre como isso será feito.

O resultado do emprego destes principios é a localização e a densidade dos serviços na sua estratégia SOA. Nas camadas mais baixas, existirá naturalmente um número muito grande de serviços do que comparado as camadas mais altas. É assim mesmo que as coisas devem ser. Se na sua camada ESL você tiver cerca de 100 serviços, enquanto que o número total de aplicações que você mantém também é 100, um problema sério sobre granularidade (aplicação da abstração) existe. Se na sua camada você têm cerca de 2 a 10 serviços, enquanto que sua camada de domínio e aplicações possuem bem mais serviços, então sua dosagem sobre granularidade e o uso do GPS, está boa.

Iremos explorar mais este conceito de GPS na continuação deste post. Até lá!

jBPM de Cara Nova!

Foi lançado recentemente o novo release do jBPM 4, ainda em versão alpha, mas já apresentando várias das funcionalidades novas prometidas a tempos. O release ainda está imaturo, várias coisas do GPD ainda estão falhando, os editores de propriedades ainda não estão presentes, pra variar, não há compatibilidade do GPD do 3.2 com o 4.X (deve-se usar um Eclipse novo pra funcionar) e a API ainda está sendo portada.

Mas algumas das nova features já dão pra serem vistas, e ainda por cima funcionando. Segue o link para baixar este release e sua documentação, agora bem mais trabalhada que a versão anterior.

Download do jBPM 4

Alguns recursos que chamam a atenção é, além do suporte a alguns elementos do BPMN, alguns elementos foram adicionados, como um elemento para execução de instruções HQL, um para execuções de código SQL, e outro para execução de código Java. O suporte a scripting foi mudado, agora existe a compatibilidade com a JSR 223 e a capacidade de modificar declarativamente qual engine de script está sendo usado.

Para aqueles que já iniciaram projetos com base no jBPM anterior, uma má noticia: Toda a API de acesso a objetos foi reformulada. A forma de criar instâncias de processos, sinalizar, recuperar tarefas foi totalmente alterado para acomodar a padronização com o PVM, mas agora está bem mais simples fazer as coisas. Em breve posto aqui as provas de conceito que fiz com este novo release, até lá!

Alta Disponibilidade de DataSources no JBoss

Neste quick-tip, irei apresentar como aplicar um recurso interessante do JBoss sobre alta disponibilidade de datasources. O recurso se refere a capacidade do pool de conexões poder identificar quando um determinado servidor de banco de dados está fora do ar, e automaticamente, sem que as aplicações que fazem uso do mesmo saibam da falha, ele direcione as conexões das aplicações (e suas respectivas sessões) para o próximo servidor SGBD disponível.

Entendendo o que é alta disponibilidade

Antes de mergulharmos nos detalhes técnicos sobre o recurso, é importante entender claramente o que é alta disponibilidade, o que isso acarreta e o que esperar deste recurso. Alta disponibilidade é um requisito de qualidade (requisito não funcional) que diz respeito a capacidade que um sistema provê sobre estar disponivel mesmo quando uma falha aconteça aos componentes principais do sistema.

O fruto deste tipo de solução é o uso de redundância, ou seja, colocar disponivel mais de uma instância de todo hardware e software necessário para a solução funcionar. A função da cópia redundante é assumir o controle do sistema quando a cópia oficial (Master Copy) falhar por qualquer razão. Neste caso, recomenda-se que o hardware tenha as mesmas caracteristicas (configuração) do hardware oficial.

Como a redundância implica em custo, é necessário escolher qual ponto do sistema realmente vale a pena ou é crucial a sua alta disponibilidade. Nem sempre, todo o sistema pode estar totalmente redundante e alguns pontos podem ter tempos de contingência para recuperação de falhas, outro requisito de qualidade muito comum. Escolhido qual é o componente do sistema que sofrerá redundância, é necessário usar mecanismos arquiteturais que possibilitem a troca de versão e contexto do hardware, sem impacto na execução da solução.

A unica coisa que este recurso deve prover é a capacidade de execução do sistema, perante falhas do hardware. Não é recomendado, nem prudente que você espere que o recurso vá garantir maior eficência da execução das tarefas do sistema, nem muito menos que o sistema fique mais rápido que o normal. Esta caracteristica é de outro requisito de qualidade, e é normalmente implementado com mecanismos de balanceamento de carga e cluster.

Entendido a diferença, é importante deixar claro o que se espera da solução, uma vez que as expectativas sobre alta disponibilidade são facilmente confundidas com balanceamento de carga e cluster, não sobre a solução em si, mas o que esperar dele. Já vi muitas pessoas com visões errôneas sobre este recurso.

Aplicando High Availability no JBoss

O servidor de aplicação JBoss possui uma infra-estrutura muito interessante para alta disponibilidade de recursos, em especial, recursos como pool de conexões, filas JMS e motores de jobs. A mágica sobre o recurso é o uso do JNDI na plataforma Java. Todo recurso no JEE é recuperado através de JNDI. Sendo assim, é prudente se esperar que o objeto que vai para o cliente, é potencialmente um proxy.

A chave para qualquer solução de alta disponibilidade (e balanceamento de carga) é colocar um Proxy entre o cliente da solução e a porção do sistema que provê os recursos. Através do proxy, pode-se obter um nível de indireção que favorece a troca de contexto e endereço do recurso físico. No caso de JEE, como os recursos são retornados para o cliente via JNDI, este canal de recuperação de recursos (Factory) pode ser usado para substituir o recurso real por um proxy.

É com base nesta idéia que o suporte do JBoss é fundamentado. A boa noticia é que nada em termos de implementação precisa ser mudado, o programador irá realizar o uso das conexões da mesma forma que sempre fez. O que muda é a declaração do recurso dentro do servidor de aplicação. No JBoss, para se criar um pool de conexões que ofereça recursos de tolerância a falhas e alta disponibilidade, basta criar um datasource como mostrado na listagem abaixo.

Repare que a listagem mostra uma declaração de um pool de conexões local (não XA) não muito diferente do que se já está acostumado a fazer. A grande sacada é a tag de declaração do datasource. Repare que a declaração começa com 'ha-local-tx-datasource' ao invés de 'local-tx-datasource'. Com isso, o JBoss irá inferir que se deseja criar um pool de alta disponibilidade.

Lido a declaração da tag, o JBoss irá procurar pelo caracter usado para separar os diversos endereços de conexão com os servidores de banco de dados, através da tag 'url-delimiter'. No exemplo mostrado, o caracter usado é o '|'. Neste caso, o JBoss irá ler a tag 'connection-url' e irá recuperar os diversos endereços de conexão separados por '|'. Repare que foram disponibilizados dois endereços, um apontando para o banco de dados 'gest_esc_a' e outro para 'gest_esc_b'. O banco A será usado como cópia mestre da solução, e se ele falhar, o banco de dados B assume o controle.

O controle sobre as conexões é feito de forma transparente para as aplicações. Quando o banco falha por qualquer razão, abre-se uma nova conexão no segundo servidor e o resto acontece naturalmente. Interessante heim?

Boas Arquiteturas!