1. Comcast
Uma das maiores (se não a maior) operadora de TV a cabo dos EUA. Eis a sua abordagem:
Se preocuparam inicialmente com a arquitetura e não em comprar ESB
Depois de desenvolver a arquitetura, o foco foi o framework de governança para implementação e gestão dos novos serviços
Direcionou os esforços iniciais de SOA para o legado (e.g. billing)
Tempo de maturação do projeto: 18 meses
Lições aprendidas: “…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“
2. Leapfrog
Uma das mais conhecidas fabricantes de brinquedos educativos.
Cenário: vários sistemas e soluções em Java 5 e 6, C# da Microsoft e web services com diversas bibliotecas de terceiros
Objetivo: 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
Abordagem: POJO, ESB Open-source (Mule), utilização de 2 (dois) ESBs - um para gerenciar fluxo de dados e outro para aplicações Web (Portal do cliente)
Por que o 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’…“, afirma o diretor de infraestrutura de sistemas
3. United Airlines
Grande empresa aérea dos EUA, companhias aéreas, assim como empresas de Telecom, de Finanças etc, tem muitas tarefas baseadas em eventos. É neste ponto que entra a EDA (Event-driven Architecture).
Histórico: 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.
Precisa conviver com estes 2 ambientes (EDA e SOA)
Desafio: projetar e implementar serviços em uma empresa que tem duas arquiteturas e necessita de ambas
Problemas que tiveram com ESB: “ESBs não utilizam padrões fora dos padrões de web services”, afirma o gerente de middleware da United
Por que o ESB é tão importante? a United “...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….“
Experiência com EDA+SOA: 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.
4. Thomson Financial
Empresa de serviços de informações financeira (também uma das maiores do mundo).
Lições aprendidas: “…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. “
Serviços: muitos (milhares) com om alta granularidade, baixa granularidade — com tudo que pode haver entre os dois — e uma equipe de arquitetura pequena
Solução: 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 o VP de serviços de gerenciamento de produto
5. Jabil
A Jabil é uma grande empresa de manufatura (monta circuitos, impressoras, computadores etc).
Desafio: integração do cliente – por exemplo, sistemas de billing, previsão e entrada de pedidos e os muitos sistemas utilizados por seus clientes; é muito difícil gerenciar toda esta comunicação ponto-a-ponto à medida que a base de clientes cresce e evolui os próprios sistemas
Arquitetura anterior: baseada em “hubs” de integração para trocar informações com seus mais de 5.000 parceiros. Resultado: muita dificuldade para manter manualmente todas as interfaces
Solução: 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
Produto/Abordagem de implantação: 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.
