Tdc 2013 eric lemes - integracoes entre sistemas-2

Globalcode – Open4education

Trilha Arquitetura .NETEric Lemes


Eric Lemes

Desenvolvedor

Blogueiro

Participante da comunidade .NET Architects

Participante eventual do Void Podcast (http://voidpodcast.com) por falta de convite.

Criador do MSBuildCodeMetrics - http://ericlemes.github.io/MSBuildCodeMetrics/

@eric_lemes | ericlemes.com | linkedin.com/in/ericlemes | [email protected]

http://voidpodcast.com/

http://ericlemes.github.io/MSBuildCodeMetrics/


Integrações entre sistemasDesafios de arquitetura corporativa, de soluções e de software


Arquitetura alvo


Arquitetura alvo

Sistema único

Atende todos os domínios funcionais

Uma única tecnologia

Um banco de dados, normalizado e íntegro

Sem duplicidade de informações e funções

Sem necessidade de integração


Arquitetura real


Arquitetura real

Diversos sistemas: in house, pacotes, legados

Cada sistema atende uma ou mais partes do processo negócio (domínios)

Sobreposição funcional

Diversas tecnologias

Diversos bancos de dados, com redundância e replicação de dados

Integrações ponto a ponto


Desafios

Integração

Baixo acoplamento

Reuso de interfaces


Acoplamento


Acoplamento

Número de suposições que uma parte faz sobre a outra quando estão trocando informações [EAP]

Endereço do banco de dados

Estrutura do banco de dados

Endereço do serviço

Contrato do serviço

Protocolo

Maior quantidade de suposições = maior acoplamento


Integrações ponto a ponto

Interfaces diferentes para compartilhar a mesma informação

Desenvolvedores investindo mais tempo resolvendo problemas de integração em detrimento ao código de negócio


Como melhorar?

Barramento de serviços (ESB)

Ferramentas de ETL


Barramento de serviços (ESB – Enterprise Service Bus)

Como reduzir acoplamento?


Como reduzir acoplamento?

Ferramentas de ETL (Extract, transform, load)

ETLETL


É suficiente?


SOA - mais uma tentativa de definição

Visualizar serviços invés de sistemas (implementações)

Estabelecer contratos de serviço com visão de negócio

Possibilidade de trocar sistemas inteiros com maior facilidade


Visão orientada a dados


Visão orientada a serviços


SOA - Desafios técnicos

ESBVisão request/reply

Reuso de comportamento

Geralmente implementado com REST, SOAP (Web services), Mensageria MQ

Baixo desempenho com grande volume de dados

ETLIntegração base a base ou via arquivos

Reuso de dados

Bom desempenho com grande volume de dados


SOA – Desafios técnicos

É possível implementar uma arquitetura orientada a serviços para cenários de grande volume de dados?

Pouca ou nenhuma literatura sobre o assunto

Pesquisa envolvendo 9 cenários de integração

Objetivo:Qual o melhor método para transferir grande volume de dados em cenário request/reply?

Volume de 1.000.000 registros

~14Mb request

~291Mb response


Transferência de arquivos



Sistema origem

Sistema origem

Sistema destino

Sistema destino

CópiaPela rede

Máquina origem

Rede

Máquina destino



Preocupações adicionaisDois processos não podem ler arquivos simultaneamente

File watcher?

Arquivo bastão?

Sim, precisa de espaço em disco

Sim, I/O costuma ser lento


WCF – SOAP e net.tcp

X


WCF – SOAP e net.tcp

Método Tempos net.tcp (segundos) Tempos soap (segundos)20.000 chamadas 201,20 193,652000 chamadas em lotes de 10 40,87 39,75200 chamadas em lotes de 100 24,46 25,2020 chamadas em lotes de 1000 22,39 19,8410 chamadas em lotes de 2000 20,23 18,82

5 chamadas em lotes de 4000 18,44 19,004 chamadas em lotes de 5000 18,69 17,94

Máquina origem

Rede

Máquina destino


HTTP Request

Único request com todos os dados

Muito consumo de memória = paginação em disco

Processamento do response assíncrono, do request não

Máquina origem

Rede

Máquina destino


TCP – 1ª tentativa

Cliente e servidor single-threaded

Implementação síncrona

Máquina origem

Rede

Máquina destino


MSMQ, Websphere MQ e RabbitMQ

Cliente coloca requisição na fila, em pedaços

Segunda thread no cliente ouve respostas na fila

Servidor ouve fila de entrada

Conforme servidor vai processando o request, insere respostas na fila (em nacos)

Máquina origem

Rede

Máquina destino


MSMQ, Websphere MQ e RabbitMQ



Implementação multi-threaded simulando comportamento do MQ

Cliente

Thread principal coloca requisição, de forma sequencial

Thread secundária ouve resposta, para cada resposta dispara uma worker thread

Servidor

Thread principal processa requisição, enfileirando cada request

Thread secundária desempilha e processa requisições

Máquina origem

Rede

Máquina destino




Os números!


Aprendizados

Aderência a ESBAderentes: MQ, SOAP

Não aderentes: arquivos, net.tcp, HTTP request, TCP

Particionamento de respostasAderente: MQ, TCP

Não aderente: todos os outros

Facilidade de implementação:Fácil: Web services, net.tcp

Médio: MQ

Dolorido: TCP


O guia prático!

Serviços = visão negócioEliminar visão técnica: eliminar pensamento de protocolo, método de construção ao pensar o serviço

Pensar em parâmetros de entrada e saída.

Visão transacional

Blocos de reuso que façam sentido para o negócio


O guia prático!

Para desempenho, prefira o assíncrono invés do síncrono

Visão assíncrona minimiza espera entre consumidor e provedor

AssíncronoSíncrono


O guia prático!

Qual tecnologia usar?Web service e net.tcp: Fácil implementação, baixo desempenho, pouco seguro em cenários transacionais. Primeira escolha em cenários síncronos.

MQ: Implementação mais difícil, alto desempenho (força modelo assíncrono), melhor para cenário transacional. Primeira escolha em cenários assíncronos.

Qual formato usar?XML: fácil de interpretar, pesado

CSV e posicional: chato de interpretar, leve na maioria dos casos. Boa idéia em cenários de alto volume.


Arquitetura do software

Reuse seu domínio!Se sua camada de apresentação e seus serviços não compartilham a mesma lógica, algo está errado.

Se existem métodos de acesso a dados específicos para os serviços, algo está errado


Arquitetura do software

Uma única porta de entrada e uma única porta de saída

Não deve existir código de integração específico para cada sistema destino

Não deve existir mais de um código de integração para mesma função de negócio

Traduções, enriquecimentos, transformações são funções do ESB!

Existem diversas alternativas abertas para ESB’s

O conceito do ESB pode ser aplicado sem a aquisição de uma ferramenta

Enterprise Integration Patterns (EIP)


Cenário possível


Referências

[EIP] Hohpe G., Woolf, B. Enterprise application patterns: designing, building and deploying messaging solutions. Addison-Wesley professional, 2003.

Linthicum, D. Enterprise application integration. Addison-Wesley professional, 1999

Ruh, W., Maginnis, F, Brown W. Enterprise application integration: a Wiley tech brief. Wiley, 2000.

http://ericlemes.com/indice - Integrações entre sistemas

https://github.com/ericlemes/IntegrationTests

http://ericlemes.com/indice

https://github.com/ericlemes/IntegrationTests


OBRIGADO!Eric Lemes

Date post:	03-Jul-2015
Category:	Documents
Upload:	eric-lemes
View:	389 times
Download:	0 times

Tdc 2013 eric lemes - integracoes entre sistemas-2

Documents