Modelo de Aplicativo (Avalanche - framework de aplicativos para Java)

“Avalanche - framework de aplicativos para Java” - implementação da tecnologia de difusão de diferenças
entre chamadas para código local e remoto. Tolerância a falhas, escalabilidade,
modificabilidade, disponibilidade contínua vem com ótimos bônus.

O modelo de aplicativo considerado neste artigo nasceu com base em nossa própria experiência na implementação e operação de várias interações de integração de sistemas de informação (IP) e teve como objetivo principal reduzir o uso de vários recursos (financeiro, mão-de-obra, tempo, etc.) na implementação dessas soluções de integração.

A maioria das empresas opera muitos sistemas diferentes que automatizam processos individuais ou o trabalho de unidades ou departamentos estruturais individuais. Como resultado, é necessário organizar a troca de informações entre esses sistemas ou com os sistemas de informações de organizações relacionadas, a fim de reduzir custos operacionais, eliminar a introdução de dados duplicados e inconsistência de dados em vários sistemas (por exemplo, NSI), reduzir o fator humano, reduzir o tempo gasto na troca de informações.

A necessidade de integração surge não apenas em software especial de desenvolvimento próprio ou personalizado, mas também em soluções “in a box”. O custo das vendas pode exceder a redução esperada nos custos operacionais.

Maneiras existentes de abordar a integração de sistemas de TI:

• Compartilhamento de arquivos
• Mensagens (um tipo de compartilhamento de arquivo)
• Integração no nível do modelo de dados, por exemplo, criando objetos especiais de banco de dados ou procedimentos armazenados
• Usando tecnologias RCP (procedimento de chamada remota), por exemplo, CORBA, RMI, SOAP, DCOM, etc.

Todos esses métodos de implementação de soluções de integração têm as mesmas desvantagens: complexidade de implementação e modificação, baixa repetibilidade, necessidade de resolver problemas de tolerância a falhas, incapacidade de trabalhar em um modo de várias versões durante a instalação de alterações, complexidade da operação e manutenção da documentação operacional atualizada.

Como resultado da busca de uma alternativa às soluções existentes, a idéia foi formulada para converter o modelo MVC (MODEL - VIEW - CONTROLLER) para o modelo MVFA (MODEL - VIEW - FUNCTION - APPLICATION), dividindo o CONTROLADOR em duas camadas de programa FUNCTION e APPLICATION entre as quais uma rede de transmissão de dados pode ser colocada (SPD )



A divisão em funções no controlador está presente em um grau ou outro em todos os sistemas de TI modernos, especialmente se o desenvolvimento for realizado usando linguagens de programação orientadas a objetos. E a separação dessas funções em uma camada de software separada resolve o problema de sua reutilização por outros sistemas de TI.

A separação de objetos de "aplicativo" em uma camada de programa separada padroniza a chamada não apenas para suas próprias funções, mas também para as funções de outros sistemas, o que apaga todas as diferenças nas chamadas de funções "próprias" e "alienígenas".

Para implementar o modelo MVFA, o seguinte modelo de software é proposto:

1. Função (Função), qualquer objeto que possua métodos para implementar qualquer funcionalidade;
2. Um adaptador, um objeto declarado que não possui uma implementação. Este objeto fornece a conexão dos objetos "aplicativo" com funções locais ou remotas. Para acessar funções remotas, o objeto "interface" é usado;
3. Conector (conector), fornece acesso às funções locais de objetos remotos usando objetos "publicação";
4. Publicação (publicação), publica uma função local no conector;
5. Interface (Interface), fornece acesso aos adaptadores para funções remotas;
6. Aplicativo (Aplicativo), realiza a conversão de dados entre a apresentação e a função / funções, também pode atuar como uma "função" para outros objetos do "aplicativo".

Um par de “interface” - “conector” forma um canal de dados através de um protocolo entre diferentes sistemas ou nós diferentes do mesmo sistema. Um canal implementado deve ter a capacidade de transmitir as quantidades necessárias de dados.

Existem implementações especializadas de “interfaces” que não possuem elementos de “conector” emparelhados, por exemplo, uma interface de alta disponibilidade que permite criar sistemas de informações tolerantes a falhas. O principal objetivo da interface de alta disponibilidade é redirecionar a carga para nós duplicados ao planejar ou fora do encerramento planejado de um dos nós do sistema.

O modelo MVFA considerado é implementado na Avalanche - estrutura de aplicativo para produto de software Java, que pertence à categoria middle ware e foi projetada para criar clusters de software ou sistemas de informações de alta disponibilidade tolerantes a falhas.

Obviamente, como qualquer tecnologia, o Avalanche - framework de aplicativos para Java tem algumas limitações:

1. Quaisquer objetos (tipos) declarados nos adaptadores (parâmetros de entrada e retorno) podem ser transmitidos pela rede e, portanto, esses objetos devem implementar a interface java.lang.Serializable . Objetos locais são chamados diretamente, sem usar operações de leitura e gravação no fluxo.
2. Nem todos os objetos podem ser transferidos pela rede. Por exemplo, objetos cujo estado ou desempenho dependem da configuração do nó do sistema em que foram criados. Esses objetos incluem objetos que implementam a especificação javax.sql.DataSource.
3. Nós do sistema duplicados devem estar localizados em hardware diferente.
4. Nós do sistema duplicados não devem ser desativados (atendidos) ao mesmo tempo.

Um exemplo de aplicativo simples é descrito no artigo - Primeiro aplicativo (Avalanche - framework de aplicativos para Java)