Por IDG News Service

A empresa pôde adotar esta abordagem por causa do seu foco em integrar aplicações, observa Ciurana. “A maior parte da integração está acontecendo no nível da aplicação, ou seja, aplicações se comunicando com outras aplicações. Portanto, aplicações fazem inputs e outputs”, diz. Os desenvolvedores criam serviços como POJOs (plain old Java objects) e permitem que o ESB Mule “wire” os POJOs à rede de mensagem, lidando com qualquer transformação dentro do ESB. “Normalmente, quando você usa SOAP e REST, tende a pensar em como conectar com o mundo exterior. Com POJOs, você não precisa fazer isso.”

Ciurana também gosta da simplicidade do ESB Mule porque sua única tarefa é gerenciar mensagem. “Todos os fornecedores comerciais queriam nos vender um pacote completo de produtos. Mas o ponto principal de SOA é passar de um sistema fechado para outro”, acrescenta Ciurana. Com o ESB Mule, a Leapfrog tem que montar as várias camadas da pilha SOA, mas Ciurana está feliz por pagar este preço para ter a flexibilidade de usar o que funcione melhor na ocasião.

A Leapfrog utiliza dois ESBs, um para gerenciar fluxo de dados e handoffs de aplicações em sistemas intermos como ERP, ActiveDirectory e data warehousing, e outro para aplicações de contato com o cliente baseadas na web, como a aplicação de autogerenciamento de contas dos clientes e os games online que oferece aos clientes. Isso não só traz um limite natural para gerenciamento de segurança e acesso, como também provê capacidade mútua de backup, já que cada ESB pode assumir no lugar do outro, se necessário.

A Leapfrog teve que criar um esquema comum de nomeação de serviço para que os serviços pudessem executar em ambos os ESBz, revela Ciurana. Nomes exatos “ajudam a manter todos os serviços muito claros”, ensina. É um pequeno preço a pagar pela liberdade do ESB.

United Airlines alia SOA à arquitetura baseada em evento
Sendo SOA um conceito racional – decompor processos de negócio em seus elementos e desenvolver serviços de software autônomos que lhe permitam mesclar os componentes de acordo com as demandas do negócio – ele presume que você está lidando com funções transacionais distintas. A premissa básica de SOA requer que estas funções sejam building blocks que possam ser combinados de maneiras quase ilimitadas.

Entretanto, muitas tarefas de negócio não são tão passíveis de decomposição, apoiando-se em seqüências específicas de eventos. As companhias aéreas são um exemplo clássico de conjunto de processos baseado em eventos e, normalmente, têm uma arquitetura baseada em eventos (event-driven architecture – EDA) para lidar com eventos. “EDA é muito orientada para fluxos, enquanto SOA tem a ver com caixas pretas distintas”, aponta Ramnath Cidambi, gerente de engenharia de middleware da United Airlines. As duas arquiteturas têm seu lugar.

Afinal, as companhias aéreas possuem sistemas de transação, como reservar passagens e marcar assentos, não apenas sistemas baseados em eventos, como despachar caminhões de combustível quando um avião aterrissa ou atualizar o painel de aviso de chegadas de vôos.

A United investiu há tempos em EDA, usando o WebSphere da IBM como barramento de mensagem por sete anos. Em 2006, deu início a uma implementação SOA para lidar com os web services modernos usados no web site United.com. Entretanto, estes dois ambientes são bastante diferentes, diz Cidambi, e existiam paralelamente.

Mas isso está começando a mudar à medida que a empresa agrega serviços de transação às suas operações internas – por exemplo, informar aos representantes de serviço ao cliente através de mensagens de texto (usando web services) qual é o cronograma do dia, empregar sistemas de RH para ver quem está agendado e quem avisou que está doente, e assim por diante, de forma a designar os funcionários para os diversos portões de cada aeroporto. Isso coloca web services no mesmo ambiente que os processos baseados em eventos, fazendo com que a companhia aérea inicie uma implementação SOA para além do programa United.com.

O desafio da United é projetar e implementar serviços em uma empresa que tem duas arquiteturas e necessita de ambas. Embora as operações internacionais tenham duas arquiteturas, a companhia aérea não pode tratá-las como entidades totalmente distintas. Afinal, um vôo cancelado (um evento) também tem implicações para os sistemas de transação (remarcar vôos de passageiros, atualizar ferramentas de pesquisa de status de vôos baseadas na web ou emitir vouchers de crédito).