Por IDG News Service

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.