Introdução a Arquitetura Orientada a Serviços

6,288 views

Published on

Slides utilizados em sala de aula

Published in: Education

Introdução a Arquitetura Orientada a Serviços

  1. 1. http://www.takenami.com.br Introdução a Arquitetura Orientada a Serviços - SOA Igor Takenami itakenami@gmail.com http://twitter.com/itakenami Versão 1.0
  2. 2. http://www.takenami.com.br O cenário de TI nas Organizações • Necessidade das organizações em evoluir a gestão de TI = Governança • Migrar o foco do gerenciamento de dados para o gerenciamento dos processos e clientes • Redesenho dos processos e implantação dos grandes sistemas de gestão empresarial (ERP) • Disponibilizar informações corporativas aos usuários ou sistemas que extrapolam as fronteiras das organizações
  3. 3. http://www.takenami.com.br O cenário de TI nas Organizações • A globalização (início dos anos 90) - Muitas organizações foram fundidas ou adquiridas • A diversidade de sistemas coexistindo nas empresas é enorme - Grandes pacotes comerciais a aplicações desenvolvidas sob-medida - Diferentes fornecedores de software - Diferentes tecnologias (monolítica, cliente/servidor, n-tier, etc) - Diferentes plataformas
  4. 4. http://www.takenami.com.br Como atender a toda esta demanda ?
  5. 5. http://www.takenami.com.br Como Integrar ? • Geração de arquivos texto - FTP como meio • Banco de Dados • Requisição • Os sistemas não estavam preparados para compartilhar seus dados além de suas fronteiras
  6. 6. http://www.takenami.com.br Como o mercado respondeu • Soluções de integração foram criadas para suprir as necessidades das empresas • Outros problemas aconteceram - falta de escalabilidade - falta de extensibilidade - alto acoplamento - baixa interoperabilidade
  7. 7. http://www.takenami.com.br Surgimento dos EAI • Apareceram então os EAI (Enterprise Application Integration) mais conhecidos como Middlewares • A arquitetura resultante era de fato mais extensível - Alto custos de aquisição e manutenção • A aquisição de um middlewares também trazia uma relação de dependência com o fornecedor
  8. 8. http://www.takenami.com.br Modelo ORB • Object Request Broker • Funcionalidades de broker com as características da programação O.O. • CORBA - Common Object Request Broker Architecture • Linguagem IDL
  9. 9. http://www.takenami.com.br Tecnologias para Integração • RPC • CORBA - Padrão RPC independente de plataforma • DCOM - RPC para Windows • RMI - RPC para Java
  10. 10. http://www.takenami.com.br Tecnologias para Integração • Web Services - Independente de Plataforma - SOAP - REST - Utiliza intra-estrutura existente
  11. 11. http://www.takenami.com.br Com o amadurecimento e evolução dos componentes distribuídos foi possível criar uma arquitetura que tem como base os serviços criados por estes componentes
  12. 12. http://www.takenami.com.br Service Oriented Architecture - SOA • SOA é uma arquitetura que representa funcionalidades do software como serviços • Principais requisitos viram serviços e são acessados por outros serviços • Modularização e aumento da coesão dos componentes • Interoperabilidade é muito importante - Padronização - Fraco acoplamento
  13. 13. http://www.takenami.com.br O que é um serviço ?
  14. 14. http://www.takenami.com.br Características de um Serviço • Independência • Granularidade • Visibilidade • Estado • Reutilização • Composição
  15. 15. http://www.takenami.com.br Independência • Deve fazer sentido isoladamente - Utilizar tipos de dados básicos • Interoperabilidade - Serviços devem estar disponíveis independente de plataforma
  16. 16. http://www.takenami.com.br Granularidade • Tamanho, escala e nível de detalhe de um serviço • Granularidade fina (fine-grained) - Muitos “grãos” - Serviços com poucas operações - Operações divididas por vários serviços • Granularidade grossa (coarse-grained) - Poucos “grãos” (maiores) - Poucos serviços - Cada um com mais operações • Serviços robustos são de grossa granularidade e serviços mais leves são de fina granularidade • Atomicidade
  17. 17. http://www.takenami.com.br Granularidade • A granularidade de um serviço pode depender da estratégia de descobrimento do mesmo - Top-down - Bottom-up • A definição de um serviço quanto a sua granularidade dependerá de fatores como capacidade de reúso e performance • SOA está focado em processos de negócio, por isso sempre que possível opte por top-down
  18. 18. http://www.takenami.com.br Granularidade • Top-down - Primeiro identifica os processos de negócios, onde cada atividade dos mesmos podem ser desmembradas em sub- processos e assim por diante, até que não seja mais possível desmembrá-los - Neste ponto chega-se aos serviços • Bottom-up - Os serviços serão expostas através das funcionalidades dos sistemas legados existentes onde a granularidade e atomicidade desses serviços vão sendo refinados, até que os mesmos possam ser compostos (orquestrados) em processos de negócio
  19. 19. http://www.takenami.com.br Visibilidade • Pesquisa a existência de um serviço • Repositório de Serviços - Público - Pesquisa - Exploração • Acesso ao arquivo WSDL
  20. 20. http://www.takenami.com.br Estado • Um serviço pode ser com estado (stateful) ou sem estado (stateless) • Stateless - Não mantém estado entre chamadas, ou seja, todas as variáveis e objetos envolvidos na execução daquela instância, ao término da execução do serviço, tem seus valores descartados • Stateful - Mantém estado através das chamadas dos serviços • Preferencialmente usar stateless - Serviços com estado precisam ser tolerantes a falha - Serviços com estado trazem overhead de balanceamento de carga - Complexidade de escalabilidade
  21. 21. http://www.takenami.com.br Reutilização • Objetivo, mas nunca uma regra • A identificação dos candidatos a serviço está ligada a reutilização do mesmo • Um serviço reutilizável não carrega particularidades técnicas, de uma implementação ou regra de negócio específica
  22. 22. http://www.takenami.com.br Composição • Um serviço pode se compor com outro serviço com a finalidade de expor um novo serviço • A forma como esses serviços serão compostos é chamada de orquestração - Toda composição deve resolver um problema de negócio
  23. 23. http://www.takenami.com.br Características de SOA • Ponto de vista: Técnico X Negócio • Orientada a Serviço - Expressam uma metodologia para desenvolvimento de software • Arquitetura - Panorama de todos os ativos de software de uma empresa - Planta arquitetônica que representa todas as peças que, juntas, formam uma construção
  24. 24. http://www.takenami.com.br Características de SOA • É um estilo de projeto, com vários aspectos - Arquitetural, metodológico e organizacional - Portifólio de serviço • A metodologia de desenvolvimento em si não traz vantagens - O efeito que ela tem sobre uma infra-estrutura redundante e complexa que o faz • Um bom aplicativo orientado a serviços envolve mais trabalho do que a tradicional integração de software • Pesquisas mostram que SOA está sendo usada para integração tradicional de aplicativos na maioria das empresas
  25. 25. http://www.takenami.com.br Vantagens de SOA • Desenvolvimento Orientado a Serviço - Reutilização de Software - Aumento de produtividade - Maior Agilidade • Estratégia SOA - Melhor alinhamento com o negócio - Maneira melhor de vender arquitetura para o negócio
  26. 26. http://www.takenami.com.br Integração Ponto-a-Ponto
  27. 27. http://www.takenami.com.br Integração Centralizada
  28. 28. http://www.takenami.com.br Barramento de Serviço
  29. 29. http://www.takenami.com.br Conectores
  30. 30. http://www.takenami.com.br Enterprise Service Bus • Não implementa uma arquitetura orientada a serviço - Fornece as características para que possa ser implementado • A maioria dos fornecedores constroem ESB’s para incorporar princípios de SOA - Business Process Execution Language (BPEL) • Integrações espaguetes produzidas ao longo dos anos, não some com a implantação de um ESB - Ficam escondida sob uma camada de tecnologia
  31. 31. http://www.takenami.com.br Vantagens de um ESB • Redução de Conexões Ponto-a-Ponto • Funciona como um Middleware para integração de aplicações que seguem uma especificação definida • Fornecem uma base de serviços para arquiteturas mais complexas • Utiliza padrões baseados em mensagens
  32. 32. http://www.takenami.com.br Características de um ESB • Transformação de dados • Roteamento • Gerenciamento • Monitoramento • Logging • Integração
  33. 33. http://www.takenami.com.br Mashups • Aplicação que combina elementos e conteúdos de outras ferramentas, formando uma nova • É a combinação de várias funcionalidades e recursos de diferentes fontes, reunidos em um só lugar, com por exemplo em um site • Na formação dessa aplicação "híbrida" inclui-se o uso de API’s externas (Serviços) • Um exemplo é o uso do Google Maps em sites que precisam de localização para prover outro serviço
  34. 34. http://www.takenami.com.br Cloud Computing • Utilizar capacidades de armazenamento e processamento de computadores e servidores compartilhados e interligados por meio da Internet • Segue o princípio de grid computacional • O armazenamento de dados é feito em servidores que poderão ser acessados de qualquer lugar • Não é necessário instalação de programas, serviços ou de armazenar dados • O acesso a programas, serviços e arquivos é remoto, através da Internet
  35. 35. http://www.takenami.com.br Cloud Computing
  36. 36. http://www.takenami.com.br Dúvidas ?

×