Baixado 52 vezes
Carregado porRenato Groff
Serviços na Plataforma .NET (SOA, REST, Microservices, WCF, Web API)
Renato Groffe é um especialista em tecnologia com mais de 15 anos de experiência e formação em engenharia de software e business intelligence. O documento aborda a integração entre sistemas, destacando a arquitetura orientada a serviços (SOA) e suas práticas, como o uso de web services, REST, e microservices. Além disso, discute a importância de reusabilidade, interoperabilidade e uma equipe capacitada na implementação de soluções eficientes.
Serviços na Plataforma .NET (SOA, REST, Microservices, WCF, Web API)
- 1. Renato Groffe -MTAC Setembro/2015
- 2. Mais de15 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 noFacebook 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 entresistemas – uma visão geral Arquitetura Orientada a Serviços (SOA) REST Microservices Serviços na plataforma .NET Referências
- 5. Comunicação pormeio de arquivos Web Services (Serviços)
- 6. Uma dasprimeiras 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 emtempo real Transações online (e-commerce, movimentações bancárias) Protocolo HTTP/HTTPS Uso do formato XML, através do procotolo SOAP
- 8.
- 9. Abordagem tambémconhecida como Arquitetura Orientada a Serviços Pessoas Processos
- 10. Alinhamento dasestraté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ásicapara 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 deuma 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 ◦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 ◦ Pesarquestõ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 ◦ Capacidadese descobrir e interpretar a estrutura exposta por um serviço ◦ Emprega 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 deComposição ◦ Princípio diretamente relacionado à questão do reuso ◦ Composição primitiva
- 19. Capacidade deComposição ◦ Composição complexa ◦ Composição complexa
- 21. Modelo arquiteturalproposto 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
- 23. Uso demé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
- 24. Exposição derecursos por meio de URIs ◦ URI → Uniform Resource Identifier ◦ URL → Uniform Resource Locator, tipo de endereço de acesso baseado no conceito de URI
- 25. A representaçãode recursos empregando formatos como XML e JSON → menor volume de informações trafegadas
- 26. Independência deestado ◦ 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
- 28. 2 abordagensde implementação ◦ Aplicações Monolíticas ◦ Microservices
- 29. Estruturalmente maissimples Desenvolvimento, testes e implantação acontecem de forma mais fácil Uma boa abordagem para aplicações relativamente pequenas
- 30. 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
- 31. Baseada emcomponentizaçã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
- 32. Código maiscompreensível (cada serviço corresponde a um aspecto de negócio específico) Possibilidade de adoção de novas tecnologias, sem que todo um sistema precise ser reescrito Modelo mais adequado em termos de continuous deployment
- 34. 2 tecnologiasprincipais atualmente: ◦ WCF (Windows Communication Foundation) ◦ ASP.NET Web API ◦ Estudo comparativo com referências: http://netcoders.com.br/blog/wcf-web-api-estudo-comparativo/
- 37. Alguns livros– Thomas Erl:
- 38. Microservices –Sam Newman:
- 39. 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/
- 40.
- 41.