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.

1. Renato Groffe - MTAC
Setembro/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
◦ 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
◦ 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 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

34.  2 tecnologias principais 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. Dúvidas, sugestões???

41. Obrigado!!!