Tópicos abordados nesta apresentação de 26/09/2015:
- Integração entre sistemas – uma visão geral
- Arquitetura Orientada a Serviços (SOA)
- REST
- Microservices
- Serviços na plataforma .NET (WCF, Web API)
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
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
◦ 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
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
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.
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/
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/