arquitetura de serviços - soa, rest, microservices e a plataforma .net

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!!!