Arquitetura de Serviços - SOA, REST, Microservices e a plataforma .NET
Transferir como PPTX, PDF5 gostaram1,799 visualizações
O documento apresenta a trajetória profissional de Renato Groffe, destacando sua experiência em tecnologia, formações acadêmicas e certificações. Também discute a arquitetura orientada a serviços, abordando temas como integração de sistemas, microservices e a comparação entre WCF e ASP.NET Web API. Toca em aspectos técnicos sobre serviços, reusabilidade, segurança e boas práticas na implementação de soluções de TI.
Arquitetura de Serviços - SOA, REST, Microservices e a plataforma .NET
- 1. Renato Groffe - MTAC Novembro/2015
- 2. Mais de 15 anos de experiência na área de Tecnologia Pós-graduação em Engenharia de Software – ênfase em SOA MBA em Business Intelligence Graduação em Sistemas de Informação Técnico em Processamento de Dados MTAC (Microsoft Technical Audience Contributor), MCP, Microsoft Specialist, MCTS, OCA, ITIL, COBIT
- 3. Página no Facebook https://www.facebook.com/RenatoGroffeSW Perfil no Facebook https://www.facebook.com/renatogroff Canal .NET https://www.facebook.com/canaldotnet LinkedIn http://br.linkedin.com/in/renatogroffe
- 4. Integração entre sistemas – uma visão geral Arquitetura Orientada a Serviços (SOA) REST Microservices Serviços na plataforma .NET Referências
- 5. Comunicação por meio de arquivos Web Services (Serviços)
- 6. Uma das primeiras formas de integração Ainda em uso atualmente, normalmente na transferência de grandes lotes de informações Comum em aplicações criadas para mainframe e soluções de BI (Business Intelligence) Texto ou outro formatos (principalmente .csv, .xls/.xlsx)
- 7. Comunicação em tempo real Transações online (e-commerce, movimentações bancárias) Protocolo HTTP/HTTPS Uso do formato XML, através do procotolo SOAP
- 9. Abordagem também conhecida como Arquitetura Orientada a Serviços Pessoas Processos
- 10. Alinhamento das estratégicas de negócio com a TI Uso de Web Services na integração entre sistemas Engloba diretrizes, padrões e boas práticas para a implementação de serviços
- 11. Unidade básica para a implementação de serviços em conformidade com esta arquitetura Um componente de software com capacidades, as quais são implementadas sob a forma de operações (métodos) As capacidades podem ser vistas como funcionalidades das quais um ou mais sistemas dependem Notações para a representação de serviços (segundo Thomas Erl):
- 12. Reusabilidade Interoperabilidade (entre diferentes plataformas) Uma maior organização dos processos de negócio (graças à ênfase na análise e modelagem dos mesmos) Reduções no tempo e custo de implementação de novos projetos
- 13. Necessidade de uma equipe capacitada e familiarizada com conceitos de SOA Mudanças drásticas em um serviço podem produzir efeitos colaterais em outra aplicações Segurança na transmissão de informações Análise criteriosa quanto à necessidade de implementação de um serviço (potencial de reuso, questões de infraestrutura)
- 14. Entity Services → utilizados em operações de CRUD (inclusão, exclusão, alteração e / ou consulta a informações) Utility Services → funcionalidades que não estejam diretamente relacionadas ao negócio (log, envio de e-mail, etc.) Task Services → automação de processos de negócio, com o consumo de Entity e/ou Utility Services Orchestrated Task Services → lógica de orquestração, controlando o fluxo em composições que envolvam Entity, Utility e Task Services
- 15. Contrato padronizado ◦ Serviços SOAP: Uso de XML Web Services Description Language (WSDL) → descrição da interface de um serviço XML Schema Definition Language (XSD) → definições detalhando a estrutura dos objetos manipulados por um serviço Geração de proxies para consumir um serviço Acoplamento ◦ Menor, graças à separação de funcionalidades em serviços Abstração ◦ Ideia de “caixa-preta” ◦ Ocultação de detalhes técnicos (infraestrutura, banco de dados, controle de acesso, etc.)
- 16. Reusabilidade ◦ Pesar questões como reuso imediato ou futuro Autonomia ◦ Independência de influências externas ◦ Tende a diminuir com a composição de serviços Independência de Estado ◦ Serviços stateless ◦ Evitar ao máximo o armazenamento de informações em memória
- 17. Visibilidade ◦ Capacidade se descobrir e interpretar a estrutura exposta por um serviço ◦ Serviços SOAP empregam padrões como: UDDI (Universal Description, Discovery and Integration) WS-MetadataExchange → especificação para a geração de documentos XML com a estrutura de um serviço
- 18. Capacidade de Composição ◦ Princípio diretamente relacionado à questão do reuso ◦ Composição primitiva
- 19. Capacidade de Composição ◦ Composição complexa ◦ Composição complexa
- 20. Granularidade ◦ Escopo abrangido pelas capacidades de um serviço ◦ A granularidade é determinada com base na quantidade de funcionalidades encapsuladas por um serviço
- 21. Granularidade ◦ Granularidade fina (fine-grained) Maior potencial de reusabilidade Entity e Utility Services são bons exemplos ◦ Granularidade grossa (coarse- grained) Menores chances de reaproveitamento Algum acoplamento com outras construções Não significa, contudo, um mau design Task e Orchestrated Task Services costumam ser exemplos típicos
- 23. Modelo arquitetural proposto por Roy Fielding em 2000, estando baseado no conceito de recurso e no uso de requisições HTTP Recurso → elemento (conjunto de dados) do qual uma aplicação dependente, normalmente representando um item de negócio RESTful Web Services → serviços seguindo esta arquitetura
- 25. Uso de métodos HTTP de forma explícita ◦ POST → criação de um novo recurso ◦ GET → consulta para obtenção de um ou mais recursos ◦ PUT → alteração do conteúdo ou estado de um recurso ◦ DELETE → remoção/exclusão de um recurso
- 26. Exposição de recursos por meio de URIs ◦ URI → Uniform Resource Identifier ◦ URL → Uniform Resource Locator, tipo de endereço de acesso baseado no conceito de URI
- 27. A representação de recursos empregando formatos como XML e JSON → menor volume de informações trafegadas
- 28. Independência de estado ◦ Performance e escalabilidade (capacidade de se adequar a demandas crescentes) são grandes preocupações em projetos críticos ◦ Importantíssimo que os serviços sejam “stateless”, minimizando assim o uso de memória
- 30. 2 abordagens de implementação ◦ Aplicações Monolíticas ◦ Microservices
- 31. Estruturalmente mais simples Desenvolvimento, testes e implantação acontecem de forma mais fácil Uma boa abordagem para aplicações relativamente pequenas
- 32. Não é uma abordagem recomendável para aplicações mais complexas ◦ A adoção de práticas de continuous deployment torna-se mais difícil (indisponibilidade de todo o sistema durante implantações) ◦ Costuma-se ficar preso a uma tecnologia ◦ Difícil entendimento e manutenção, com o crescimento da aplicação ◦ Problemas em coordenar as ações em equipe ◦ Queda na qualidade do código com o decorrer do tempo ◦ Consumo maior de recursos (IDE, servidores de aplicação) ◦ Escalabilidade comprometida
- 33. Baseada em componentização, através do uso de serviços Serviços “pequenos”→ Princípio de Responsabilidade, coesão Foco em produtos, não projetos Organização em torno de capacidades de negócios → Cross-functional teams Desenvolvimento e implantação de cada serviço de forma independente Comunicação baseada no modelo REST (requisições HTTP + JSON) Dados descentralizados
- 34. Adoção de novas tecnologias com maior facilidade Alta disponibilidade Escalabilidade Facilidades no Deployment Melhor organização do trabalho
- 35. Uma única instância de um serviço por host Múltiplas instâncias de um serviço por host Uma instância de um serviço por máquina virtual Uma instância de serviço por Container → Docker
- 38. 2 tecnologias principais atualmente: ◦ WCF (Windows Communication Foundation) ◦ ASP.NET Web API (ou simplesmente “Web API”) ◦ Estudo comparativo com referências: http://netcoders.com.br/blog/wcf-web-api-estudo-comparativo/
- 39. Visão geral da Arquitetura ◦ WCF → A implementação de um serviço envolve a especificação de um endereço, de um binding (configurações) e de um contrato (interface descrevendo as operações suportadas). ◦ Web API → Serviços são implementados como Controllers, nos quais as funcionalidades disponíveis correspondem às Actions. Importante destacar que com o ASP.NET 5, os frameworks MVC e Web API foram unificados em um único modelo chamado MVC 6.
- 40. Configuração ◦ WCF → No arquivo .config de uma aplicação ou ainda, a partir de classes que compõem o próprio framework WCF. ◦ Web API → Via código-fonte, através de instruções definindo o comportamento de um serviço.
- 41. Protocolos suportados ◦ WCF → HTTP/HTTPS, TCP, P2P, MSMQ (Microsoft Message Queuing), dentre outros. Uma mesma solução WCF pode ser projetada para suportar mais de um protocolo (HTTP/HTTPS e TCP, por exemplo). ◦ Web API → Somente HTTP/HTTPS.
- 42. Formatos suportados ◦ WCF → SOAP, XML, JSON, binário, MTOM. ◦ Web API → XML, JSON.
- 43. Manipulação de dados ◦ WCF → Criação de classes convencionais (com a exposição de propriedades públicas) ou Data Contracts (propriedades expostas através do serviço são marcadas como Data Members). ◦ Web API → Classes convencionais (as propriedades públicas serão automaticamente expostas aos consumidores de um serviço), além de tipos anônimos ou dinâmicos.
- 44. Padrões para troca de mensagens ◦ WCF → Request-Reply, One Way, Duplex. ◦ Web API → HTTP request/response, com capacidades adicionais através do uso de WebSockets ou SignalR.
- 45. Documentação/descrição de um serviço ◦ WCF → Serviços baseados em SOAP têm sua estrutura detalhada automaticamente, através do uso do padrão WSDL (Web Services Description Language). ◦ Web API → Geração automática de documentação a partir do site da aplicação ou ainda, através de soluções como Swagger.
- 46. Hospedagem ◦ WCF → Conta com classes para self-host, além da possibilidade de hospedagem em servidores IIS. ◦ Web API → Hospedagem em servidores IIS. Há a possibilidade ainda de self-host, através do mecanismo conhecido como OWIN (Open Web Interface for .NET).
- 47. Serviços RESTful ◦ WCF → Implementados através de ajustes de configuração, com a opção de uso de JSON e/ou XML. ◦ Web API → Por default um serviço Web API é RESTful (suportando tanto JSON, quanto XML).
- 48. Integração com JavaScript/jQuery ◦ WCF → Possível através da criação de serviços RESTful. ◦ Web API → Suportada por default.
- 49. Integração com outras plataformas / linguagens ◦ WCF → Possível através da implementação de serviços SOAP ou RESTful. ◦ Web API → Possível, já que todo serviço Web API é RESTful.
- 50. Segurança ◦ WCF → Baseada no uso de SSL, além de certificados digitais, NTLM, Kerberos e tokens. ◦ Web API → SSL e autenticação baseada em tokens são possibilidades.
- 51. Open Source ◦ Tanto WCF, como o ASP.NET Web API, são hoje tecnologias abertas.
- 52. Alguns livros – Thomas Erl:
- 53. Microservices – Sam Newman:
- 54. Microservice architecture - Chris Richardson http://microservices.io/index.html Microservices - Martin Fowler http://martinfowler.com/articles/microservices.html Thomas Erl – Site http://www.thomaserl.com/
- 56. Obrigado!!!