Cinco maneiras de implementar SOA

Quando a arquitetura orientada a serviços (SOA) começou a ganhar força, a meta era simplesmente disponibilizar funcionalidades de aplicações como um serviço compartilhado. Ao longo do tempo, as empresas construíram suas arquiteturas — e continuam construindo. A diferença é que, nos últimos dois anos, o lado do negócio adquiriu melhor percepção do valor estratégico de TI, enquanto TI aprendeu mais sobre as pressões competitivas que o negócio tem que suportar. Conseqüentemente, agora mais do que nunca, SOA propicia maior alinhamento entre TI e negócio.

O negócio precisa de um conjunto de serviços que possam ser recombinados, resultando em novos processos de negócio que suportam novos produtos ou serviços. SOA diz respeito a publicar estes serviços e fornecer um framework coerente dentro do qual eles possam ser governados e compostos em aplicações. Apesar de muitas iniciativas SOA continuarem em uma fase inicial, a promessa de maior compreensão do negócio é real. E estamos vendo um número crescente de empresas promovendo implementações avançadas. Os estudos de caso a seguir são ótimos exemplos.

Comcast constrói SOA sobre expertise em domínio
Quando você decide adotar a abordagem SOA, é tentador começar a comprar barramento de serviços empresariais (enterprise service bus –ESB), registros e outras ferramentas. Mas o valor principal de SOA é posto de lado: o alinhamento entre as aplicações que você cria e implementa e os processos de negócio que elas executam, ressalta Tom Adler, gerente sênior de arquitetura de aplicação e governança de TI da Comcast. Começar com a arquitetura pode ajudar você a garantir que tem o framework certo para fazer isso – agora e à medida que as necessidades mudam, com o correr do tempo, segundo Adler.

“Quando iniciamos esta empreitada, 18 meses atrás, resistimos à tentação de trazer fornecedores. Trouxemos especialistas em determinados assuntos e descobrimos do que precisávamos em primeiro lugar”, diz Adler. “Todos os fornecedores só queriam nos vender um ESB.”

Adler observa que a iniciativa de arquitetura vai além de estabelecer o framework: ela identifica onde você já tem redundâncias, tanto em processos de negócio quanto em aplicações. Isso é fundamental para conquistar a adesão do negócio porque mostra, em termos muito reais, não só onde há oportunidades de economia que vão ajudar a justificar o investimento em infra-estrutura e ferramentas SOA, mas também onde o uso de serviços comuns reduzirá as complexidades de manutenção e integração, possibilitando esforços de desenvolvimento mais responsivos no futuro. “É o target que nos permite eliminar serviços redundantes”, diz Adler.

Depois de desenvolver a arquitetura – que Adler chama de modelo de domínio comum – o próximo passo da Comcast foi desenvolver o framework de governança para a criação e a implementação de serviços. “Os serviços precisam passar pelo portão da governança”, explica, “ou ninguém vai saber que o serviço existe ou adotar as políticas e os procedimentos certos”. Somente os serviços que passam pelo portão da governança são acrescentados ao registro de serviços e, assim, disponibilizados para reutilização.

Um desafio da governança que despontou rapidamente foi decidir quem era o “proprietário” dos serviços. A Comcast é bastante descentralizada e, portanto, a cultura da empresa naturalmente suportava que os criadores do serviço possuíssem os serviços em seus domínios. Serviços comuns, como single sign on, residem em TI, seu domínio natural, diz Adler.

Adler agora percebe que a Comcast deveria ter desenvolvido um modelo de serviço de dados comum depois de definir a arquitetura. Sem serviços de dados padrões para acessar informação corporativa e gerenciar interações entre sistemas, os desenvolvedores acabaram projetando seus serviços para executar o trabalho de diferentes maneiras, o que gerou inconsistências, quebrando a promessa de SOA de possibilitar um mix fácil de componentes de serviços. “Subestimamos o valor no início”, admite Adler, e o preço disso foi, posteriormente, ter que refazer alguns serviços para impor este modelo.

Outros destaques do COMPUTERWORLD:
>TI depois das fusões: delicada relação
> Mais de 50% dos europeus pagaria mais por tecnologia ‘verde’
> China investe pesado em tecnologia de gestão de risco
> Forrester: corporações continuam dizendo não ao Vista
> Seis práticas que mais fazem os CIOs perderem tempo

O foco arquitetural da iniciativa SOA da Comcast ajudou a aplicar o conceito mais amplamente do que se ele fosse visto apenas como uma questão tecnológica, acredita Adler. A Comcast não partiu da visão de que SOA significa usar web services e aplicou o conceito SOA a todos os seus esforços, não apenas aos que eram claramente capacitados para web. “Um web service é simplesmente mais uma maneira de expor um serviço – um detalhe de implementação”, diz.

O resultado é que grande parte dos esforços internos iniciais de SOA, na realidade, foi direcionada às aplicações legadas, reduzindo os pontos de integração tanto dentro quanto fora da empresa (com os fornecedores de billing, por exemplo), um importante ponto nevrálgico do negócio.

Os desenvolvedores utilizam uma variedade de ferramentas e linguagens de programação, por exemplo, de acordo com seu conhecimento e a aplicação que estão criando. Com a padronização de processos e políticas ao invés de ferramentas e métodos técnicos específicos, os desenvolvedores podem aderir melhor ao propósito da arquitetura ao invés de tentar encaixar cada tarefa nas limitações ou pressuposições de uma ferramenta ou tecnologia específica, orienta Adler.

Há também uma razão prática para permitir a heterogeneidade tecnológica sob a arquitetura comum: em uma empresa com 9 mil funcionários, seria irreal querer fazer todo mundo adotar a mesma tecnologia.

Uma empresa desta escala também tem que se adaptar a necessidades de negócio que mudam e a oportunidades tecnológicas, ensina Adler. É importante rever a arquitetura de referência periodicamente para que ela não se transforme em uma camisa-de-força ou em um documento que todos ignoram. Em ambos os casos, você perderia os benefícios de SOA. Adler revê a arquitetura todo mês, embora ela não seja modificada com tanta freqüência.

Leapfrog mantém opções SOA abertas com open source
É o clássico problema enfrentado por desenvolvedores de TI em qualquer lugar: aplicações desenvolvidas no decorrer de um ano por grupos diferentes não funcionam bem juntas quando são trazidas para um sistema comum como um portal web. O dilema atingiu a Leapfrog Enterprises no início de 2007, quando a fabricante de brinquedos educativos quis disponibilizar suas diversas aplicações para fornecedores e clientes de uma maneira consistente, com o objetivo de melhor se beneficiar do comércio e de transações baseadas na internet.

Em março, decidiu que precisava de uma nova maneira de desenvolver aplicações e partiu para uma iniciativa SOA que está começando a dar frutos, segundo Eugene Ciurana, diretor de infra-estrutura de sistemas. “Queríamos formar a base para a infra-estrutura e sistemas web e por isso optamos por começar do zero.”

A Leapfrog tinha muitos objetivos comuns a uma típica iniciativa SOA: maior reutilização de código, desenvolvimento mais veloz e integração mais fácil. Mas a empresa não queria limitar a iniciativa SOA a uma mudança da guarda de ferramentas de desenvolvimento e plataformas de integração.

Ao invés disso, a Leapfrog queria dispensar seus desenvolvedores de se submeter à idéia de melhores práticas de uma plataforma para que pudessem enfocar a funcionalidade das aplicações e utilizar as tecnologias de desenvolvimento mais adequadas a cada trabalho. (Os desenvolvedores da Leapfrog empregam uma miscelânea de Java 5 e 6, C# da Microsoft e web services com diversas bibliotecas de terceiros.)

Ciurana não quis obrigar todos os desenvolvedores a usar o mesmo transporte, por exemplo. “O transporte não importa”, afirma. Ele optou pelo open source ESB Mule como backbone de mensagem, apoiando-se nele para lidar com interfaces de transporte. Assim, “os desenvolvedores poderiam enfocar o mínimo possível a implementação de serviços”, explica. O foco é a funcionalidade que eles estão tentando alcançar.

O resultado é que os desenvolvedores tendem a usar HTTP como mecanismo de transporte, mas alguns empregam REST (Representational State Transfer) e SOAP –  “o que funciona melhor ou que lhes parece mais cômodo”, diz. Com a abordagem do ESB Mule, “eles não precisam se preocupar com o que há em uma pilha de SOAP específica ou qual IDE estão utilizando”. Ciurana já tinha usado o Mule em Walmart.com e estava convencido de que era o ponto de partida certo para a Leapfrog.

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).

Muitos processos têm um componente evento e um componente transação: os representantes de serviço ao cliente obtêm a programação para o dia no sistema de transação, mas mudanças no status de aviões devido a cancelamentos, atrasos por condições climáticas e coisas do gênero tornam esta programação confusa muito rapidamente. O sistema baseado em eventos rastreia o status dos aviões e o sistema de transação de programação atualiza as atribuições da equipe ao consultar este status periodicamente. (Os monitores de exibição dos horários de vôos empregam o mesmo processo.)

O maior desafio foi o sistema de mensagem. “ESBs não utilizam padrões fora dos padrões de web services”, afirma Cidambi. O modo de lidar com serviços baseados em eventos é obscuro e varia conforme o produto ou a ferramenta. Mas Cidambi valoriza o uso de ESBs para SOA e EDA porque eles lidam com mensagem, transformações de dados e outras tarefas críticas de roteamento de dados.

Hoje, a United Airlines tem dois ESBs: um para serviços EDA e outro para serviços SOA. A empresa utiliza um broker de integração IBM WebSphere como plataforma de mensagem orientada para publicação-assinatura para seus serviços baseados em eventos, propagando eventos conforme o necessário e suportando quaisquer transformações entre serviços – essencialmente, atuando como um ESB EDA. Para o transporte, as aplicações J2EE existentes são bastante orientadas a mensagem e todas usam JMS (Java Message Service) como padrão de mensagem ao invés de web services.

A United está adotando o BEA AquaLogic ESB para seus serviços SOA porque é uma plataforma mais nova que, acredita Cidambi, será mais orientada ao conceito moderno de SOA e mais adequada ao ambiente servidor WebLogic e ao ambiente de desenvolvimento Eclipse em uso na United. “O AquaLogic, basicamente, roda sobre o WebLogic”, explica Cidambi. Portanto, não há um esforço de integração.
Evitar esforços desnecessários é um dos motivos de Cidambi não migrar os serviços EDA para o AquaLogic.

O WebSphere se sai muito bem e passar para um novo ESB, inevitavelmente, causaria interrupções e surpresas. A United teve sete anos para otimizar a plataforma WebSphere e eliminar problemas operacionais. Migrar para um novo ESB como o AquaLogic consumiria esforço agora e, sem dúvida, exporia novos problemas.

Outra dificuldade que Cidambi enfrenta é a falta de esquemas XML padrões para EDA, fazendo com que a transferência de mensagens entre serviços EDA e SOA seja mais complexa e demande mais pessoal.

Thomson Financial automatiza conformidade do serviço
Um grande número de empresas aprecia o conceito de SOA porque ele promete acelerar o desenvolvimento. Mas alguns desenvolvedores descobriram que um elemento-chave da governança de serviço, na realidade, pode retardar o desenvolvimento, roubando a velocidade prometida. A empresa de serviços de informação financeira Thomson Financial teve esta surpresa desagradável no início de sua jornada SOA, recorda Vladimir Mitevski, vice-presidente de serviços core de gerenciamento de produto.

“Para ser considerado um ativo de produção empresarial, um serviço precisa estar em conformidade com diversas metodologias e políticas”, observa Mitevski. Muitas são bastante rígidas: os nomes de elementos XML não podem ser abreviados e têm que ser palavras de dicionário, por exemplo. Alguns itens, como nomes e senhas de usuários, não podem ser hard-coded.

Quando você tem poucos serviços, a equipe de arquitetura empresarial, em geral, pode acompanhar e também detectar qualquer problema, diz Mitevski. Mas, muito rápido, os revisores se transformam em gargalos e até começam a deixar passar problemas devido à carga de trabalho.

A Thomas Financial, que tem milhares de serviços com alta granularidade, baixa granularidade — com tudo que pode haver entre os dois — e uma equipe de arquitetura pequena, sentiu o golpe rapidamente. “Não importa a granularidade, todo serviço passa por este processo”, diz Mitevski. Só então ele é entrado no registro de serviços. Da mesma forma, a conformidade de serviços alterados tem que ser avaliada antes que a nova versão seja registrada e disponibilizada para uso em produção. “Mas o escritório de arquitetura era um gargalo devido à escala”, explica Mitevski.

Reduzir os requisitos de compliance não era uma opção, dada a natureza crítica das aplicações envolvidas, como os serviços de single sign-on, web services que fornecem informação sobre o mercado financeiro para analistas e empresas, e serviços de análises e gráficos financeiros baseados na web e acessados através do Microsoft Office.

A solução da Thomson para o problema de workload de conformidade era recorrer à automação, utilizando ferramentas de avaliação de políticas da WebLayers. “As ferramentas são mais eficientes e não deixam passar violações”, diz Mitevski. Levou algum tempo criar as políticas nas quais as ferramentas se baseiam para avaliar a conformidade e é vital que os arquitetos examinem as análises das ferramentas para ver se determinados problemas surgem repetidamente, indicando falta de entendimento de políticas-chave por parte dos desenvolvedores ou ambigüidade na arquitetura, observa Mitevski. “Ajuda a nos mostrar o que podemos fazer melhor, e algumas políticas precisam ser ajustadas.”

Mas Mitevski descobriu que a maioria das violações acontece porque os desenvolvedores tomam atalhos. Os arquitetos também decidem quando abrir exceções aos desenvolvedores por qualquer violação à conformidade, algo que acontece raramente. As exceções são anotadas no registro para conhecimento de outros usuários.

Na Thomson Financial, os resultados da automação de conformidade dos serviços são surpreendentes. “Antes, para colocar um serviço em atividade, eram necessárias 20 pessoas em um processo altamente orquestrado em vários grupos. Agora uma pessoa basta”, comemora Mitevski.

Jabil Circuit simplifica integração do cliente
Uma empresa focada em serviços de manufatura tem que enfrentar uma grande empreitada de integração do cliente – por exemplo, sistemas de billing, previsão e entrada de pedidos e os muitos sistemas utilizados por seus clientes. Mas é muito difícil gerenciar toda esta comunicação ponto-a-ponto à medida que a base de clientes cresce e evolui os próprios sistemas.

É por isso que muitos fabricantes migraram para fornecedores de hubs de transação, batizados de VANs (value-added networks). Cada fornecedor e cliente se preocupam apenas com uma conexão com a VAN , e para cada dupla cliente-fornecedor.

Mas esta abordagem fracassa quando você tem processos personalizados junto aos seus clientes que não são suportados por VANs padrões. A Jabil Circuit, fabricante de produtos eletrônicos personalizados, enfrentou este dilema da maneira mais difícil: manter manualmente todas as interfaces e aplicações personalizadas.

A Jabil tem mais de 5 mil parceiros comerciais e era possível lidar com a maioria deles através da abordagem de VAN. Mas 50 clientes precisavam de mecanismos de comunicação ou processos de negócio especiais para os quais a Sterling Commerce VAN havia sido projetada. Com freqüência, havia várias destas conexões personalizadas para cada cliente, aumentando o esforço, lembra Lowel Gilvin, gerente de comércio eletrônico da empresa. Alguma coisa precisava mudar.

Foi então que a Jabil adotou princípios SOA para substituir a maioria destas conexões personalizadas por conexões baseadas em serviços que possibilitam a reutilização de funções comuns.

O primeiro passo foi separar os processos de negócio – gerenciamento do pedido até o pagamento, previsão e estoque em consignação, por exemplo – dos processos de comunicação. A Jabil agora tem serviços padrões para a maioria dos mecanismos de comunicação em uso, como AS1 (Applicability Statement 1), AS2 (Applicability Statement 2) e FTP, e serviços separados de tratamento de dados, para os formatos XML, flat-file, Excel e SAP iDocs, por exemplo.

A empresa compõe o serviço de comunicação, o serviço de tratamento de dados e o serviço de negócio apropriados para cada um destes clientes, usando tabelas e metadados para automatizar a composição na maioria dos casos. Em alguns casos, os clientes utilizam mais de um mecanismo, talvez de acordo com o departamento em questão, e as tabelas dão conta destes múltiplos mecanismos, diz Gilvin.
Os conceitos SOA de abstração, modularidade e composição de serviço, em geral, funcionam como estão.

Em alguns casos, requisitos especiais não podem ser satisfeitos através da combinação de serviços. Portanto, a Jabil ainda tem algumas integrações one-off para manter. Mas, mesmo aí, a empresa pode usar a abordagem SOA para parte da integração. Os certificados para validação de XML e SSL, por exemplo, não podem ser tratados como serviços padrões, já que são únicos, mas a Jabil pode compor os serviços de comunicação e negócio apropriados com um serviço de tratamento de dados hard-wired, mantendo os benefícios de reutilização e consistência de SOA em dois dos três aspectos da integração, segundo Gilvin.

Outros destaques do COMPUTERWORLD:
>SOA: passo-a-passo rumo ao sucesso
>Qual o perfil ideal de um projeto de SOA?
>Cinco perguntas que você precisa fazer antes de investir em SOA
>SOA traz agilidade, não necessariamente corte de custos

Ao invés de usar um ESB para gerenciar mensagens, um registro para gerenciar o repositório de serviços ou um ambiente de desenvolvimento orientado a SOA para desenvolver os serviços, a Jabil emprega o Gentran Integration Suite da Sterling Commerce para as três finalidades. O pacote é projetado para interações do supply-chain, justamente o que a empresa está tentando gerenciar. Este escopo limitado permite que a Jabil se apóie na arquitetura embutida do conjunto de ferramentas ao invés de criar a sua própria. “Temos um pequeno conjunto de processos de negócio padrões”, diz Gilvin.