Renato Groffe apresenta sua experiência e formação em tecnologia, com ênfase em integração de sistemas e arquitetura orientada a serviços (SOA). O documento aborda conceitos de web services, microservices, e as diferenças entre WCF e ASP.NET Web API, destacando práticas, protocolos e padrões para implementação de serviços. Além disso, discute a importância de segurança, reusabilidade e escalabilidade em projetos de integração.

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

8. Fonte:
http://www-01.ibm.com/support/knowledgecenter/SSKM8N_8.0.0/com.ibm.etools.mft.doc/ac55780_.htm

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

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

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

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

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/

53. Dúvidas, sugestões???

54. Obrigado!!!