Introdução
Retornando ao tema de escalabilidade e performance, já vimos em tópicos anteriores abordagens sobre Grid Computing, Jobs , Hash Map e Filas, além de alguma abordagem teórica sobre escalabilidade e performance, técnicas e abordagens.
SOA
Uma destas abordagens, baseada nos princípios da computação distribuída (Grid) é chamada de SOA – Services Oriented Architecture. Esta abordagem de desenvolvimento propicia facilidade na integração de sistemas, e por ser embasada nos princípios da computação distribuída, pode ajudar a tornar partes críticas do sistema mais escaláveis.
Arroz com feijão
Imagine que dentro do seu software, cada bloco de operações seja encapsulado — por exemplo — em um Web Service, ou qualquer outro meio de comunicação de dados tipo request/response. Por exemplo, a classe de cadastro e operações com clientes pode ser chamada facilmente pelo próprio sistema ou por um sistema de tereiros através de uma API padronizada.
Incluir um título a receber passa a ser uma operação que utiliza uma API Client do módulo financeiro, para enviar a requisição do título a ser incluído, e todas as demais operações relacionadas a um título de recebimento também pode ser implementada nesta API. Você pode colocar várias APIs em um ou mais servidores, e utilizar gateways ou controladores, para enfileirar requisições ou distribuir as requisições entre várias instâncias da mesma API distribuidas no ambiente.
Prós e Contras
Como cada parte de um sistema possui suas particularidades, e nem todas podem ser apropriadas para serem paralelizáveis, escolhe-se esta abordagem onde ela é mais necessária e terá ganhos visíveis. Distribuir as aplicações exigem um nivel de controle maior e domínio na aplicação, pois como as camadas são interdependentes, se uma camada não funcionar direito, ela deve prover os detalhes do que entrou e do que saiu, pois quando um procedimento de depuração for necessário, todas as camadas envolvidas serão verificadas para ver qual camada não apresentou o comportamento sistêmico esperado.
Porém, uma vez encontrada a camada, basta subir apenas o serviço desejado no seu ambiente de depuração, refazer a chamada desta API com os mesmos parâmetros, e depurar apenas esta camada. As escolhas dos protocolos de comunicação são importantes nos quesitos de praticidade e desempenho. XML para requisições curtas é ótimo, o overhead não é significativo, JSON também é uma boa alternativa.
Já para requisições maiores, pode ser cogitado o uso do sistema de arquivos, ou um FTP SErver como servidor de sistemas de arquivos para funcionalidades especificas.
Exemplo de uso
Vamos pegar por exemplo uma funcionalidade comum entre todos os sistemas ERP que utilizam Workflow: O Envio de e-mails. Quando cada programa usa uma API direta para envio de e-mails, cada uma é responsável pelo envio e tratamento de erro de conexão ou envio, e normalmente o processamento do envio do e-mail é feito no mesmo processo do programa, logo o usuário aguarda a resposta do servidor de e-mail ou do programa de conexão, e é informado se o e-mail foi enviado ou se houve alguma falha ( problema de conexão, senha inválida, falha de envio ).
Agora, imagine quantos casos de envio de e-mail que o operador realmente precisa saber na hora se o e-mail foi realmente enviado. Existem muitos casos onde a criação de um serviço independente e remoto, dedicado a envio de e-mails, pode ser útil e dar agilidade ao sistema.
Neste serviço, você poderá configurar um ou mais servidores SMTP alternativos para envio de e-mais, e poderá colocar um ou mais processos dedicados a envio. Cada programa que usar a API client deste serviço simplesmente chama a API informando o e-mail a ser enviado. O Serviço de envio pode colocar este e-mail em uma fila em memória ou no próprio banco de dados, e os processos dedicados ao envio desempilham os e-mails e os enviam. Quem chama a API pode fornecer informações de rastreabilidade, e caso a API falhe ao enviar, o e-mail continua na fila, e o serviço deve prover uma interface de monitoramento e administração, para saber se e quais e-mails não foram enviados, e por quê.
Caso seja necessária uma confirmação de envio, você pode construir um mecanismo de “gatilho”, onde a API de e-mails, assim que conseguir enviar um e-mail, execute uma função fornecida como parâmetro, para por exemplo atualizar um flag de uma tabela de confirmação, relacionada ao programa que originalmente fez a requisição.
Para garantir a disponibilidade do sistema, você pode subir dois ou mais serviços de envio de e-mail em duas maquinas distintas, e configurar estes serviços em um cluster. Caso o servidor onde esteja o serviço de pool de e-mails caia, o cluster subirá a outra instância do serviço de envio em outro nó do cluster.
Conclusão
Sempre deve haver um meio-termo na escolha de determinados recursos, e isto normalmente deve ser guiado pela necessidade. Quanto mais especialista for uma parte do sistema, mais complexa será a manutenção desta. Normalmente distribuir a aplicação exige mais skill no desenho e implementação, mas as abordagens de desenvolvimento buscam dividir coisas complexas em coisas simples interligadas, e cada coisa no seu lugar, o que torna naturalmente mais fácil reaproveitar código e componentes, mas aumenta o número de partes e coisas envolvidas.
Para o próximo post, estou separando algumas sugestões de assunto, e teremos um pouco mais de código AdvPL. Até o próximo, pessoal 😀
Referências
SERVICE-ORIENTED ARCHITECTURE. In: WIKIPÉDIA, a enciclopédia livre. Flórida: Wikimedia Foundation, 2014. Disponível em: <http://pt.wikipedia.org/w/index.php?title=Service-oriented_architecture&oldid=39359250>. Acesso em: 3 maio 2015.
Tudo em AdvPL 