Arquitetura de Serviços - SOA, REST, Microservices e a plataforma .NET
Post on 15-Apr-2017
523 Views
Preview:
Transcript
Arquitetura de Serviços -SOA, REST, Microservices e a
plataforma .NETRenato Groffe - MTAC
Novembro/2015
Apresentação – Renato Groffe
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
Contatos Página no Facebook
https://www.facebook.com/RenatoGroffeSW
Perfil no Facebookhttps://www.facebook.com/renatogroff
Canal .NEThttps://www.facebook.com/canaldotnet
LinkedInhttp://br.linkedin.com/in/renatogroffe
Integração entre sistemas – uma visão geral
Arquitetura Orientada a Serviços (SOA)
REST
Microservices
Serviços na plataforma .NET
Referências
Agenda
Integração entre sistemas
Comunicação por meio de arquivos
Web Services (Serviços)
Comunicaçao por meio de arquivos 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)
Web Services 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
Web Services – Exemplo de mensagem SOAP
Fonte:http://www-01.ibm.com/support/knowledgecenter/SSKM8N_8.0.0/com.ibm.etools.mft.doc/ac55780_.htm
SOA (Service Oriented Architecture) Abordagem também conhecida como Arquitetura Orientada a Serviços
Pessoas Processos
SOA – Visão Geral 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
Definição de serviço segundo SOA
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):
SOA - Benefícios 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
SOA - Cuidados 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)
SOA – Tipos de Serviço (Thomas Erl) 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
SOA – Princípios de Design de Serviços
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.)
SOA – Princípios de Design de Serviços 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
SOA – Princípios de Design de Serviços 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
SOA – Princípios de Design de Serviços Capacidade de Composição
◦ Princípio diretamente relacionado à questão do reuso
◦ Composição primitiva
SOA – Princípios de Design de Serviços Capacidade de Composição
◦ Composição complexa
◦ Composição complexa
SOA – Princípios de Design de Serviços Granularidade
◦ Escopo abrangido pelas capacidades de um serviço
◦ A granularidade é determinada com base na quantidade de funcionalidades encapsuladas por um serviço
SOA – Princípios de Design de Serviços
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
REST (Representational State Transfer)
REST – Visão Geral 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
REST – Representação Esquemática
REST – Arquitetura 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
REST – Arquitetura 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
REST – Arquitetura A representação de recursos empregando formatos como
XML e JSON → menor volume de informações trafegadas
REST – Arquitetura 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
Microservices
Microservices – Visão Geral 2 abordagens de implementação
◦ Aplicações Monolíticas
◦ Microservices
Aplicações Monolíticas - Características Estruturalmente mais simples
Desenvolvimento, testes e implantação acontecem de forma mais fácil
Uma boa abordagem para aplicações relativamente pequenas
Aplicações Monolíticas - Problemas 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
Arquitetura de Microservices 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
Microservices - Benefícios Adoção de novas tecnologias com maior facilidade
Alta disponibilidade
Escalabilidade
Facilidades no Deployment
Melhor organização do trabalho
Microservices - Infraestrutura 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
Microservices – Cases de Sucesso
Serviços na plataforma .NET
Serviços na plataforma .NET 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/
Serviços na plataforma .NET 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.
Serviços na plataforma .NET 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.
Serviços na plataforma .NET 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.
Serviços na plataforma .NET Formatos suportados
◦ WCF → SOAP, XML, JSON, binário, MTOM.
◦ Web API → XML, JSON.
Serviços na plataforma .NET 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.
Serviços na plataforma .NET 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.
Serviços na plataforma .NET 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.
Serviços na plataforma .NET 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).
Serviços na plataforma .NET 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).
Serviços na plataforma .NET Integração com JavaScript/jQuery
◦ WCF → Possível através da criação de serviços RESTful.
◦ Web API → Suportada por default.
Serviços na plataforma .NET 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.
Serviços na plataforma .NET 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.
Serviços na plataforma .NET Open Source
◦ Tanto WCF, como o ASP.NET Web API, são hoje tecnologias abertas.
Referências – Arquitetura de Serviços Alguns livros – Thomas Erl:
Referências – Arquitetura de Serviços Microservices – Sam Newman:
Referências – Arquitetura de Serviços Microservice architecture - Chris Richardson
http://microservices.io/index.html
Microservices - Martin Fowlerhttp://martinfowler.com/articles/microservices.html
Thomas Erl – Sitehttp://www.thomaserl.com/
Dúvidas, sugestões???
Obrigado!!!
top related