Sobre a integração de aplicações através da execução de “chamadas remotas”
Olá pessoal. Tudo certo?!
Nos últimos posts, fiz algumas considerações sobre integrações de aplicações utilizando transferências de arquivos e compartilhamento de bancos de dados. Hoje, falo sobre integração através de chamadas a procedimentos remotos. São diferentes estilos de integração, cada um com seus pontos fortes e fraquezas.
Integrando mais que dados
Tanto a “transferência de arquivos” quanto o “compartilhamento de banco de dados” visam, primariamente, a integração de dados. Entretanto, para mim, integrações mais úteis são aquelas que unificam mais que isso, integram processos. Ou seja, a execução de uma rotina em um sistema implica na execução de uma outra rotina, em um segundo sistema.
Nos dois estilos já apresentados, a “integração de processos” pode ocorrer de forma reativa através do monitoramento dos dados. Entretanto, no modelo que apresento aqui, o que ocorre é fazer com que uma aplicação “chame” procedimentos diretamente em outra. A alteração dos dados ocorre em decorrência da execução dos processos – e não o inverso.
Implementação básica
A implementação desse modelo de integração respeita a seguinte dinâmica:
Para considerar:
- Pelo menos duas aplicações precisam ser integradas;
- Uma delas disponibiliza um “contrato público” definindo procedimentos/recursos que vão ficar acessíveis;
- A aplicação “cliente” (app 1) realiza uma série de chamadas a procedimentos da outra, em conformidade com esse contrato;
- A aplicação “fornecedora” (app 2) executa o procedimento e prepara um retorno (resultado da execução);
- A aplicação “cliente” (app 1) recebe o retorno e continua seu fluxo de atividades.
Na prática, a aplicação “cliente” costuma ser bem menor do que a aplicação “fornecedora”.
Contratos de consulta
Algumas integrações, visando a eliminação de duplicidade de dados, substituem a execução de procedimentos por consultas. Considere:
Para considerar:
- Pelo menos duas aplicações precisam ser integradas. Entretanto, cada uma fica responsável de gerenciar um conjunto determinado de entidades;
- Uma delas disponibiliza um “contrato público” definindo consultas que vão ficar acessíveis (incluindo recuperação, persistência e remoção);
- A aplicação “cliente” (app 1) realiza uma série de consultas na outra;
- A aplicação “fornecedora” (app 2) opera as consultas e prepara um resultado (resultado da execução);
- A aplicação “cliente” (app 1) recebe o resultado (conjuntos de dados) e continua suas atividades.
Este modelo, embora mais pobre, é o mais frequente.
Reciprocidade (ou dependência cíclica)
Independente do cenário, é comum que os papéis de “cliente” e “fornecedor” sejam alternados entre as diversas aplicações envolvidas conforme a natureza das operações.
Por que, na prática, é tão difícil?
A sequência com que determinadas operações são realizadas podem impactar consideravelmente no resultado dessas operações. Em consequência disso, este tipo de integração demanda que cada “aplicação integrante” conheça com mais profundidade detalhes de funcionamento das demais. Logo, temos aumento considerável de acoplamento E COMPLEXIDADE.
Com o tempo, se uma aplicação modificar sua “lógica de funcionamento”, implicará, também em uma revisão do contrato que disponibiliza e, em decorrência disso, de uma revisão das aplicações que o consome.
Também temos que considerar o fato de que existem diferentes métodos e tecnologias para proporcionar esse tipo de integração – CORBA, COM, Remoting, WCF, apenas para citar alguns. Sendo que cada uma dessas abordagens possui particularidades difíceis de tratar em algumas plataformas.
Para integrações baseadas em consultas, também devemos considerar o custo de execução, geralmente muito maior do que de consultas locais.
Por fim, embora esse estilo evite “unificação de esquema”, costuma exigir um planejamento de desenvolvimento global. Difícil de ser preservado e, principalmente, acordado com outros fornecedores de software.
Além de tudo, há fragilidade inerente
Como as aplicações fazem chamadas regulares a procedimentos de outras, todo o sistema ficará “potencialmente instável” caso uma das aplicações pare de funcionar adequadamente. Em função disso, é necessário estabelecer uma estratégia madura de contingência e recuperação de falhas.
E também é difícil de escalar…
Para que o “sistema” escale, cada aplicação precisa ter condições de escalar individualmente.
Relação com SOA
Para mim, a única forma desse modelo de integração funcionar adequadamente parte de uma mudança de perspectiva arquitetônica. No lugar de modelar aplicações, modelamos serviços que são, então, desenvolvidos – catalogados – integrados.
Concluindo
Integrações baseadas em chamadas remotas podem aumentar o acoplamento e a fragilidade potencial do sistema como um todo. Por isso, precisam de implementação cuidadosa.
Os riscos podem ser mitigados com a utilização de um paradigma arquitetônico adequado.
Era isso.
Outro ponto negativo é a falta de transacoes “baratas”. Nao acho que transacionar com DTC ou WS* seja uma boa ideia. Transacoes comoensatorias tambem nao sao simples. Ai lascou!
O que percebi até agora na série de posts é que não gostei de nenhuma das opções. Conheço troca de dados por txt e xml (gosto muito do xml, mas os outros sofreares nem sempre se comportam bem, então não adianta). Minha esperança são os próximos posts da série, hehe. Eu estava estudando casos de EF com WCF e agora acho que nem vou continuar com nada de WCF, somente terminar os estudos do EF.
Pode mandar mais.
Essa série veio em boa hora pra mim.
Saudações Mestre Elemar.
Correção: “…outros softwares…” (dormir, nota mental, hehe)