SlideShare uma empresa Scribd logo
1 de 54
Renato Groffe - MTAC
Outubro/2015
 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
 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
 Integração entre sistemas – uma visão geral
 Arquitetura Orientada a Serviços (SOA)
 REST
 Microservices
 Serviços na plataforma .NET
 Referências
 Comunicação por meio de arquivos
 Web Services (Serviços)
 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)
 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
Fonte:
http://www-01.ibm.com/support/knowledgecenter/SSKM8N_8.0.0/com.ibm.etools.mft.doc/ac55780_.htm
 Abordagem também conhecida como Arquitetura Orientada a Serviços
Pessoas Processos
 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
 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):
 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
 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)
 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
 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.)
 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
 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
 Capacidade de Composição
◦ Princípio diretamente relacionado à questão do reuso
◦ Composição primitiva
 Capacidade de Composição
◦ Composição complexa
◦ Composição complexa
 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
 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
 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
 A representação de recursos empregando formatos
como XML e JSON → menor volume de informações
trafegadas
 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
 2 abordagens de implementação
◦ Aplicações Monolíticas
◦ Microservices
 Estruturalmente mais simples
 Desenvolvimento, testes e implantação acontecem de forma mais
fácil
 Uma boa abordagem para aplicações relativamente pequenas
 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
 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
 Código mais compreensí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
 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
 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/
 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.
 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.
 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.
 Formatos suportados
◦ WCF → SOAP, XML, JSON, binário, MTOM.
◦ Web API → XML, JSON.
 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.
 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.
 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.
 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 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).
 Integração com JavaScript/jQuery
◦ WCF → Possível através da criação de serviços
RESTful.
◦ Web API → Suportada por default.
 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.
 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.
 Open Source
◦ Tanto WCF, como o ASP.NET Web API, são hoje
tecnologias abertas.
 Alguns livros – Thomas Erl:
 Microservices – Sam Newman:
 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/
Dúvidas, sugestões???
Obrigado!!!

Mais conteúdo relacionado

Mais procurados

SOA - Arquitetura Orientada a Serviços
SOA - Arquitetura Orientada a ServiçosSOA - Arquitetura Orientada a Serviços
SOA - Arquitetura Orientada a Serviços
alinebicudo
 
Padroes De Projeto
Padroes De ProjetoPadroes De Projeto
Padroes De Projeto
ejdn1
 

Mais procurados (20)

Servidores de aplicação apresentação
Servidores de aplicação apresentaçãoServidores de aplicação apresentação
Servidores de aplicação apresentação
 
Analise de Requisitos Software
Analise de Requisitos SoftwareAnalise de Requisitos Software
Analise de Requisitos Software
 
Análise e Modelagem de Software
Análise e Modelagem de SoftwareAnálise e Modelagem de Software
Análise e Modelagem de Software
 
Modelagem Arquitetural e Visão 4+1
Modelagem Arquitetural e Visão 4+1Modelagem Arquitetural e Visão 4+1
Modelagem Arquitetural e Visão 4+1
 
Normas e Padrões para a Qualidade de Software
Normas e Padrões para a Qualidade de SoftwareNormas e Padrões para a Qualidade de Software
Normas e Padrões para a Qualidade de Software
 
Modelos de processos de software
Modelos de processos de softwareModelos de processos de software
Modelos de processos de software
 
SOA - Uma Breve Introdução
SOA - Uma Breve IntroduçãoSOA - Uma Breve Introdução
SOA - Uma Breve Introdução
 
Arquitetura de Software EXPLICADA
Arquitetura de Software EXPLICADAArquitetura de Software EXPLICADA
Arquitetura de Software EXPLICADA
 
SOA - Arquitetura Orientada a Serviços
SOA - Arquitetura Orientada a ServiçosSOA - Arquitetura Orientada a Serviços
SOA - Arquitetura Orientada a Serviços
 
Es capítulo 5 - modelagem de sistemas
Es   capítulo 5  - modelagem de sistemasEs   capítulo 5  - modelagem de sistemas
Es capítulo 5 - modelagem de sistemas
 
NoSQL, Base VS ACID e Teorema CAP
NoSQL, Base VS ACID e Teorema CAPNoSQL, Base VS ACID e Teorema CAP
NoSQL, Base VS ACID e Teorema CAP
 
Banco de Dados - Transações e Controle de Concorrência
Banco de Dados - Transações e Controle de ConcorrênciaBanco de Dados - Transações e Controle de Concorrência
Banco de Dados - Transações e Controle de Concorrência
 
Bancos de dados NoSQL: uma visão geral
Bancos de dados NoSQL: uma visão geralBancos de dados NoSQL: uma visão geral
Bancos de dados NoSQL: uma visão geral
 
Análise Orientada a Objetos com UML
Análise Orientada a Objetos com UMLAnálise Orientada a Objetos com UML
Análise Orientada a Objetos com UML
 
Padroes De Projeto
Padroes De ProjetoPadroes De Projeto
Padroes De Projeto
 
Arquitetura Cliente-Servidor
Arquitetura Cliente-ServidorArquitetura Cliente-Servidor
Arquitetura Cliente-Servidor
 
Introdução a Sistemas Distribuídos
Introdução a Sistemas DistribuídosIntrodução a Sistemas Distribuídos
Introdução a Sistemas Distribuídos
 
Padrões de projeto - Martin Fowler - P of EAA
Padrões de projeto - Martin Fowler - P of EAAPadrões de projeto - Martin Fowler - P of EAA
Padrões de projeto - Martin Fowler - P of EAA
 
UML
UMLUML
UML
 
Padrões Arquiteturais de Sistemas
Padrões Arquiteturais de SistemasPadrões Arquiteturais de Sistemas
Padrões Arquiteturais de Sistemas
 

Destaque

Palestra sobre a SOA foi destaque no Ciasc
Palestra sobre a SOA foi destaque no Ciasc  Palestra sobre a SOA foi destaque no Ciasc
Palestra sobre a SOA foi destaque no Ciasc
guest880159
 
Modelo de arquitetura orientada a serviços para sistemas
Modelo de arquitetura orientada a serviços para sistemasModelo de arquitetura orientada a serviços para sistemas
Modelo de arquitetura orientada a serviços para sistemas
Leandro Najm
 
Camada de Serviços: Uma abordagem alternativa de acesso a objetos de domínio ...
Camada de Serviços: Uma abordagem alternativa de acesso a objetos de domínio ...Camada de Serviços: Uma abordagem alternativa de acesso a objetos de domínio ...
Camada de Serviços: Uma abordagem alternativa de acesso a objetos de domínio ...
Bruno Arueira
 

Destaque (17)

Vantagens e desvantagens de uma arquitetura microservices
Vantagens e desvantagens de uma arquitetura microservicesVantagens e desvantagens de uma arquitetura microservices
Vantagens e desvantagens de uma arquitetura microservices
 
Arquitetura Orientada a Servicos (SOA)
Arquitetura Orientada a Servicos (SOA)Arquitetura Orientada a Servicos (SOA)
Arquitetura Orientada a Servicos (SOA)
 
Palestra sobre a SOA foi destaque no Ciasc
Palestra sobre a SOA foi destaque no Ciasc  Palestra sobre a SOA foi destaque no Ciasc
Palestra sobre a SOA foi destaque no Ciasc
 
Modelo de arquitetura orientada a serviços para sistemas
Modelo de arquitetura orientada a serviços para sistemasModelo de arquitetura orientada a serviços para sistemas
Modelo de arquitetura orientada a serviços para sistemas
 
Arquitetura de Serviços - SOA, REST, Microservices e a plataforma .NET
Arquitetura de Serviços - SOA, REST, Microservices e a plataforma .NETArquitetura de Serviços - SOA, REST, Microservices e a plataforma .NET
Arquitetura de Serviços - SOA, REST, Microservices e a plataforma .NET
 
Da Integração Contínua à Entrega Contínua apenas com ferramentas open-source
Da Integração Contínua à Entrega Contínua apenas com ferramentas open-sourceDa Integração Contínua à Entrega Contínua apenas com ferramentas open-source
Da Integração Contínua à Entrega Contínua apenas com ferramentas open-source
 
SOA e Web Services
SOA e Web ServicesSOA e Web Services
SOA e Web Services
 
Node.js no Pagar.me
Node.js no Pagar.meNode.js no Pagar.me
Node.js no Pagar.me
 
Introdução a Arquitetura Orientada a Serviços
Introdução a Arquitetura Orientada a ServiçosIntrodução a Arquitetura Orientada a Serviços
Introdução a Arquitetura Orientada a Serviços
 
Camada de Serviços: Uma abordagem alternativa de acesso a objetos de domínio ...
Camada de Serviços: Uma abordagem alternativa de acesso a objetos de domínio ...Camada de Serviços: Uma abordagem alternativa de acesso a objetos de domínio ...
Camada de Serviços: Uma abordagem alternativa de acesso a objetos de domínio ...
 
Microservices Architecture (MSA) - Presentation made at The Open Group confer...
Microservices Architecture (MSA) - Presentation made at The Open Group confer...Microservices Architecture (MSA) - Presentation made at The Open Group confer...
Microservices Architecture (MSA) - Presentation made at The Open Group confer...
 
ASP.NET Core com Linux, Docker e Azure
ASP.NET Core com Linux, Docker e AzureASP.NET Core com Linux, Docker e Azure
ASP.NET Core com Linux, Docker e Azure
 
Melhoria e Transformação Digital de Processos, Casos e Decisões
Melhoria e Transformação Digital de  Processos, Casos e DecisõesMelhoria e Transformação Digital de  Processos, Casos e Decisões
Melhoria e Transformação Digital de Processos, Casos e Decisões
 
Workshop soa, microservices e devops
Workshop soa, microservices e devopsWorkshop soa, microservices e devops
Workshop soa, microservices e devops
 
Testes em uma startup do mundo financeiro
Testes em uma startup do mundo financeiroTestes em uma startup do mundo financeiro
Testes em uma startup do mundo financeiro
 
MicroService Architecture
MicroService ArchitectureMicroService Architecture
MicroService Architecture
 
JSON and REST
JSON and RESTJSON and REST
JSON and REST
 

Semelhante a Arquitetura de Serviços - SOA, REST, Microservices e a plataforma .NET

Arquitetura orientada a servicos soa
Arquitetura orientada a servicos   soaArquitetura orientada a servicos   soa
Arquitetura orientada a servicos soa
Leonardo Eloy
 
Consumindo dados via web service no android
Consumindo dados via web service no androidConsumindo dados via web service no android
Consumindo dados via web service no android
Alexandre Antunes
 
Sistemas Distribuídos - Comunicação Distribuída – Web Services
Sistemas Distribuídos - Comunicação Distribuída – Web ServicesSistemas Distribuídos - Comunicação Distribuída – Web Services
Sistemas Distribuídos - Comunicação Distribuída – Web Services
Adriano Teixeira de Souza
 
04 - Felipe Oliveira - Think Decoupled! (SOA)
04 - Felipe Oliveira - Think Decoupled! (SOA)04 - Felipe Oliveira - Think Decoupled! (SOA)
04 - Felipe Oliveira - Think Decoupled! (SOA)
DNAD
 
Web Services - Grupo F
Web Services - Grupo FWeb Services - Grupo F
Web Services - Grupo F
mdmansur
 

Semelhante a Arquitetura de Serviços - SOA, REST, Microservices e a plataforma .NET (20)

Arquitetura de Serviços - SOA, REST, Microservices e a plataforma .NET
Arquitetura de Serviços - SOA, REST, Microservices e a plataforma .NETArquitetura de Serviços - SOA, REST, Microservices e a plataforma .NET
Arquitetura de Serviços - SOA, REST, Microservices e a plataforma .NET
 
Serviços na Plataforma .NET (SOA, REST, Microservices, WCF, Web API)
Serviços na Plataforma .NET (SOA, REST, Microservices, WCF, Web API)Serviços na Plataforma .NET (SOA, REST, Microservices, WCF, Web API)
Serviços na Plataforma .NET (SOA, REST, Microservices, WCF, Web API)
 
Web Services
Web ServicesWeb Services
Web Services
 
Soa Woa Rest
Soa Woa RestSoa Woa Rest
Soa Woa Rest
 
Arquitetura orientada a servicos soa
Arquitetura orientada a servicos   soaArquitetura orientada a servicos   soa
Arquitetura orientada a servicos soa
 
Web Service - XML
Web Service - XMLWeb Service - XML
Web Service - XML
 
Engenharia de software orientada a servicos
Engenharia de software orientada a servicosEngenharia de software orientada a servicos
Engenharia de software orientada a servicos
 
Consumindo dados via web service no android
Consumindo dados via web service no androidConsumindo dados via web service no android
Consumindo dados via web service no android
 
WebServices intro
WebServices introWebServices intro
WebServices intro
 
Sistemas Distribuídos - Comunicação Distribuída – Web Services
Sistemas Distribuídos - Comunicação Distribuída – Web ServicesSistemas Distribuídos - Comunicação Distribuída – Web Services
Sistemas Distribuídos - Comunicação Distribuída – Web Services
 
04 - Felipe Oliveira - Think Decoupled! (SOA)
04 - Felipe Oliveira - Think Decoupled! (SOA)04 - Felipe Oliveira - Think Decoupled! (SOA)
04 - Felipe Oliveira - Think Decoupled! (SOA)
 
Maratona JBoss 2010 - JBossWS
Maratona JBoss 2010 -  JBossWSMaratona JBoss 2010 -  JBossWS
Maratona JBoss 2010 - JBossWS
 
Web service
Web serviceWeb service
Web service
 
Soa woa - rest
Soa   woa - restSoa   woa - rest
Soa woa - rest
 
SOA - WOA - REST
SOA - WOA - RESTSOA - WOA - REST
SOA - WOA - REST
 
Web Sphere Application Server
Web Sphere Application ServerWeb Sphere Application Server
Web Sphere Application Server
 
Desenvolvimento de uma API RESTful com Java EE
Desenvolvimento de uma API RESTful com Java EEDesenvolvimento de uma API RESTful com Java EE
Desenvolvimento de uma API RESTful com Java EE
 
Web services
Web servicesWeb services
Web services
 
Web Services - Grupo F
Web Services - Grupo FWeb Services - Grupo F
Web Services - Grupo F
 
Microservices - Canal .NET Dev Weekend
Microservices - Canal .NET Dev WeekendMicroservices - Canal .NET Dev Weekend
Microservices - Canal .NET Dev Weekend
 

Mais de Renato Groff

Mais de Renato Groff (20)

Microsoft Azure role-based certifications valem a pena? | Interop Day Edição ...
Microsoft Azure role-based certifications valem a pena? | Interop Day Edição ...Microsoft Azure role-based certifications valem a pena? | Interop Day Edição ...
Microsoft Azure role-based certifications valem a pena? | Interop Day Edição ...
 
Kubernetes: dicas e truques para o dia a dia | Azure Experts - Novembro-2020
Kubernetes: dicas e truques para o dia a dia | Azure Experts - Novembro-2020Kubernetes: dicas e truques para o dia a dia | Azure Experts - Novembro-2020
Kubernetes: dicas e truques para o dia a dia | Azure Experts - Novembro-2020
 
Como o Microsoft Azure pode melhorar o desenvolvimento de seu Back-End? | Dev...
Como o Microsoft Azure pode melhorar o desenvolvimento de seu Back-End? | Dev...Como o Microsoft Azure pode melhorar o desenvolvimento de seu Back-End? | Dev...
Como o Microsoft Azure pode melhorar o desenvolvimento de seu Back-End? | Dev...
 
Como avançar na Power Platform com Azure Functions e Logic Apps | MVPConf Lat...
Como avançar na Power Platform com Azure Functions e Logic Apps | MVPConf Lat...Como avançar na Power Platform com Azure Functions e Logic Apps | MVPConf Lat...
Como avançar na Power Platform com Azure Functions e Logic Apps | MVPConf Lat...
 
GitHub Actions: descomplicando o build/deployment automatizados | MVPConf Lat...
GitHub Actions: descomplicando o build/deployment automatizados | MVPConf Lat...GitHub Actions: descomplicando o build/deployment automatizados | MVPConf Lat...
GitHub Actions: descomplicando o build/deployment automatizados | MVPConf Lat...
 
A evolução da plataforma .NET: passado, presente e futuro | Baixada NERD - No...
A evolução da plataforma .NET: passado, presente e futuro | Baixada NERD - No...A evolução da plataforma .NET: passado, presente e futuro | Baixada NERD - No...
A evolução da plataforma .NET: passado, presente e futuro | Baixada NERD - No...
 
Polly: aplicações .NET resilientes e um melhor tratamento de falhas | MVPConf...
Polly: aplicações .NET resilientes e um melhor tratamento de falhas | MVPConf...Polly: aplicações .NET resilientes e um melhor tratamento de falhas | MVPConf...
Polly: aplicações .NET resilientes e um melhor tratamento de falhas | MVPConf...
 
Containers no Azure: Docker, Kubernetes e suas diferentes possibilidades | MV...
Containers no Azure: Docker, Kubernetes e suas diferentes possibilidades | MV...Containers no Azure: Docker, Kubernetes e suas diferentes possibilidades | MV...
Containers no Azure: Docker, Kubernetes e suas diferentes possibilidades | MV...
 
Docker: dicas e truques para o dia a dia | MVPConf Latam 2020
Docker: dicas e truques para o dia a dia | MVPConf Latam 2020Docker: dicas e truques para o dia a dia | MVPConf Latam 2020
Docker: dicas e truques para o dia a dia | MVPConf Latam 2020
 
Simplificando a montagem de ambientes de Dev+Testes com Docker | DEVDAY 2020
Simplificando a montagem de ambientes de Dev+Testes com Docker | DEVDAY 2020Simplificando a montagem de ambientes de Dev+Testes com Docker | DEVDAY 2020
Simplificando a montagem de ambientes de Dev+Testes com Docker | DEVDAY 2020
 
.NET Core + Serverless: Desenvolvimento Multiplataforma com Azure Functions |...
.NET Core + Serverless: Desenvolvimento Multiplataforma com Azure Functions |....NET Core + Serverless: Desenvolvimento Multiplataforma com Azure Functions |...
.NET Core + Serverless: Desenvolvimento Multiplataforma com Azure Functions |...
 
Aplicações Distribuídas com .NET | TDC Recife Online 2020
Aplicações Distribuídas com .NET | TDC Recife Online 2020Aplicações Distribuídas com .NET | TDC Recife Online 2020
Aplicações Distribuídas com .NET | TDC Recife Online 2020
 
Novidades do .NET 5 e ASP.NET 5 | Visual Studio Summit 2020
Novidades do .NET 5 e ASP.NET 5 | Visual Studio Summit 2020Novidades do .NET 5 e ASP.NET 5 | Visual Studio Summit 2020
Novidades do .NET 5 e ASP.NET 5 | Visual Studio Summit 2020
 
Serverless + Integrações com BDs: Azure Functions e Logic Apps - SQLSaturday ...
Serverless + Integrações com BDs: Azure Functions e Logic Apps - SQLSaturday ...Serverless + Integrações com BDs: Azure Functions e Logic Apps - SQLSaturday ...
Serverless + Integrações com BDs: Azure Functions e Logic Apps - SQLSaturday ...
 
Boas práticas de segurança no acesso a dados em Web Apps - SQLSaturday #972 -...
Boas práticas de segurança no acesso a dados em Web Apps - SQLSaturday #972 -...Boas práticas de segurança no acesso a dados em Web Apps - SQLSaturday #972 -...
Boas práticas de segurança no acesso a dados em Web Apps - SQLSaturday #972 -...
 
.NET: passado, presente e futuro | Semana FCI 2020 - Mackenzie
.NET: passado, presente e futuro | Semana FCI 2020 - Mackenzie.NET: passado, presente e futuro | Semana FCI 2020 - Mackenzie
.NET: passado, presente e futuro | Semana FCI 2020 - Mackenzie
 
Docker: visão geral e primeiros passos | Fatec Praia Grande - Semana Tecnológ...
Docker: visão geral e primeiros passos | Fatec Praia Grande - Semana Tecnológ...Docker: visão geral e primeiros passos | Fatec Praia Grande - Semana Tecnológ...
Docker: visão geral e primeiros passos | Fatec Praia Grande - Semana Tecnológ...
 
Kubernetes na Nuvem | Minicurso Gratuito - Azure na Prática
Kubernetes na Nuvem | Minicurso Gratuito - Azure na PráticaKubernetes na Nuvem | Minicurso Gratuito - Azure na Prática
Kubernetes na Nuvem | Minicurso Gratuito - Azure na Prática
 
Kubernetes de ponta a ponta: do Pod ao Deployment Automatizado | Setembro-2020
Kubernetes de ponta a ponta: do Pod ao Deployment Automatizado | Setembro-2020Kubernetes de ponta a ponta: do Pod ao Deployment Automatizado | Setembro-2020
Kubernetes de ponta a ponta: do Pod ao Deployment Automatizado | Setembro-2020
 
Sobrevoando os serviços do Azure | TDC São Paulo Online 2020
Sobrevoando os serviços do Azure | TDC São Paulo Online 2020Sobrevoando os serviços do Azure | TDC São Paulo Online 2020
Sobrevoando os serviços do Azure | TDC São Paulo Online 2020
 

Arquitetura de Serviços - SOA, REST, Microservices e a plataforma .NET

  • 1. Renato Groffe - MTAC Outubro/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.
  • 21.  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
  • 22.
  • 23.  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
  • 24.  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
  • 25.  A representação de recursos empregando formatos como XML e JSON → menor volume de informações trafegadas
  • 26.  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
  • 27.
  • 28.  2 abordagens de implementação ◦ Aplicações Monolíticas ◦ Microservices
  • 29.  Estruturalmente mais simples  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 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
  • 32.  Código mais compreensí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
  • 33.  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
  • 34.
  • 35.
  • 36.  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/
  • 37.  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.
  • 38.  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.
  • 39.  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.
  • 40.  Formatos suportados ◦ WCF → SOAP, XML, JSON, binário, MTOM. ◦ Web API → XML, JSON.
  • 41.  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.
  • 42.  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.
  • 43.  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.
  • 44.  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).
  • 45.  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).
  • 46.  Integração com JavaScript/jQuery ◦ WCF → Possível através da criação de serviços RESTful. ◦ Web API → Suportada por default.
  • 47.  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.
  • 48.  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.
  • 49.  Open Source ◦ Tanto WCF, como o ASP.NET Web API, são hoje tecnologias abertas.
  • 50.  Alguns livros – Thomas Erl:
  • 51.  Microservices – Sam Newman:
  • 52.  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/