ads

Mostrando postagens com marcador Arquiteturas Orientadas por Serviço. Mostrar todas as postagens
Mostrando postagens com marcador Arquiteturas Orientadas por Serviço. Mostrar todas as postagens

domingo, 16 de novembro de 2008

Cases de Sucesso de Empresas que optaram por Arquiteturas Orientadas por Serviço (SOA)

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.