Na seção anterior, através das arquiteturas de gerência para ATM e IP, foi possível verificar quão genérico o modelo pode ser. Essa característica é importante para que o modelo possa se acomodar em redes diferentes. A diversidade de aplicações e serviços na rede, entretanto, permite que um conjunto de variáveis a serem suportadas na gerência seja ainda maior que o existente atualmente. Nestas condições, o modelo apresentado deve se adaptar às necessidades dos administradores de forma adequada.
A adaptabilidade do modelo em situações diferentes das normais pode ser realizada de diversas formas. A criação de novas políticas é a forma mais básica. Porém, em situações mais específicas, o uso de novos módulos pode passar a ser necessário
como forma de complementação do ambiente de gerência existente. A utilização de novos módulos deve, obviamente, ser feita também de forma integrada à solução, para que o administrador da rede tenha um ambiente único de acesso às várias funcionalidades existentes, inclusive as novas funcionalidades incorporadas.
O modelo proposto permite a inclusão de novas funcionalidades através da modularidade existente. Novos módulos criados podem ser incorporados, e obter comunicação com os outros módulos existentes através de dois modelos principais: indiretamente, via bases de dados, e diretamente, via API de programação e/ou protocolos de comunicação.
Integração indireta via bases de dados
A integração indireta via bases de dados é possível quando os novos módulos criados recebem acesso às bases e podem proceder com leituras e gravações. Como todos os outros elementos do modelo tem a integração também baseada no uso comum das bases, um novo módulo inserido é capaz de se comunicar com os outros módulos já existentes utilizando as bases.
Teoricamente, a base que deve sofrer menos alterações por novos módulos é a base de políticas, pois as funcionalidades criadas originalmente devem ser suficientes em uma implementação. Entretanto, por exemplo, um novo módulo de criação de políticas poderia ser adicionado para dar suporte ao gerenciamento de segurança (não coberto nesta tese). Outro exemplo seria a criação de um módulo para gerência de contabilização, onde um usuário teria acesso à rede apenas em períodos específicos do dia. Nestas duas situações, módulos adicionais permitiriam ao administrador criar políticas relacionadas não apenas ao QoS. As políticas seriam armazenadas pelos módulos na base de políticas e aplicadas por novos consumidores de políticas capazes de traduzir as novas políticas.
Com novos módulos criados para suportar outras políticas, também é esperada a criação de outros módulos capazes de verificar a efetividade de tais políticas. Tais módulos (que no caso do QoS são os monitores de QoS) acabarão tendo acesso à base de status para atualizar o estado de um política em observação. Logo, a base de status também permitirá uma integração indireta.
Por fim, a base de associações fornece o ponto de maior integração indireta do modelo, já que possui os relacionamentos entre informações mais importantes do ambiente. Vários módulos poderiam ser criados neste contexto. Por exemplo, no modelo original o administrador da rede é responsável por associar os consumidores de políticas e monitores de QoS aos alvos encontrados. Um módulo novo, utilizando-se de técnicas de inteligência artificial, poderia criar associações iniciais desses elementos na base de associações que posteriormente seriam validadas, se necessário, pelo administrador. Novos módulos, utilizando tecnologias diferentes, poderiam ser utilizados para descobrir dispositivos que normalmente não seriam descobertos pelos processos padrão. Novamente, a base de associações seria acessada pelos novos módulos que informariam os dispositivos que anteriormente não poderiam ser descobertos.
Uma questão importante em relação à integração indireta é que possivelmente algumas informações necessárias aos novos módulos podem não existir nas bases originais. Felizmente, a inclusão de novos campos em tabelas não tende a causar
problemas para os módulos que já utilizavam as bases anteriormente. Por exemplo, um campo poderia determinar se um roteadores possui internamente filtros para funcionar como firewall. Como a gerência de segurança não era o foco do modelo, originalmente este campo não existiria, mas um processo de descoberta de firewalls e similares necessitaria desse campo. Nesse caso, a tabela que descreve os dispositivo teria um campo a mais incluído, e todos os dispositivos até então cadastrados receberiam por padrão o valor false para o campo, sem prejuízo para o funcionamento dos módulos já existentes.
Integração direta via API de programação e/ou protocolos de comunicação
A integração indireta usando acesso às bases de dados, como visto anteriormente, é possível. Entretanto, muitas vezes uma comunicação direta com um módulo já existente é necessária. Por exemplo, supondo que um novo módulo do sistema foi criado para a detecção de um ataque (novamente, gerência de segurança), e que a indicação de tal ataque deve ser feita pela alteração da cor utilizada no dispositivo atacado no mapa da rede, uma comunicação direta com os processos de visualização deve ser fornecida. Neste caso, deve existir uma API que permite ao novo módulo de detecção de ataque informar aos processos de visualização para mostrarem o computador atacado na cor vermelha, por exemplo.
Para que esse tipo de integração seja possível, duas soluções diferentes podem ser utilizadas: APIs de programação ou protocolos de comunicação. Antes de se entrar em detalhes sobre estas possibilidades, é importante notar que a integração direta depende fundamentalmente das facilidades que as implementações dos módulos “padrão” do modelo disponibilizam. Isso significa dizer que se um módulo original não permitir nenhum tipo de comunicação externa, ainda que tal módulo siga estritamente as definições do modelo, não existirá um mecanismo de integração disponível para este módulo.
A integração direta mais comumente encontrada é aquela que utiliza protocolos de comunicação para realizar a troca de informações entre os elementos existentes. Neste caso, cada elemento (ou módulo) do modelo fornece um meio de entrada ou ativação de suas funções ao mundo externo. Novos módulos implementados utilizam então estas facilidades dos outros módulos para estabelecerem comunicações. Na seção 5.2, a comunicação com os elementos intermediários da arquitetura QAME era realizada através da Script MIB. Novos módulos criados também poderiam utilizar a Script MIB para estabelecer conversações com os módulos “originais” do modelo. Por exemplo, um monitor de QoS diferente poderia comunicar-se diretamente com um consumidor de políticas para informar que uma das políticas monitoradas está apresentando degradações.
A interação entre módulos menos simples, em relação à utilização de protocolos de comunicação, é aquela que necessita ser realizada com os elementos internos ao ambiente de gerência do modelo (módulos para visualização, análise e implantação de QoS). De certa forma, o ambiente de gerência “esconde” tais elementos através dos pontos de acesso a serviços. Como tais pontos são restritos a algumas comunicações (notificações, transferência de políticas, etc.) o acesso direto aos elementos internos ao ambiente de gerência possivelmente acaba sendo necessário freqüentemente. Neste caso, ou a implementação explicitamente fornece um protocolo para comunicação com tais
elementos, como acontece com os elementos intermediários do modelo, ou APIs de programação devem ser utilizadas.
A idéia principal das APIs de programação é permitir que os módulos existentes possam ser expandidos em relação às suas funcionalidades. Um exemplo típico de expansão de módulo é o mecanismo de recebimento de traps SNMP muito freqüentemente encontrado em plataformas de gerência. Tipicamente, o mecanismo recebe traps e imprime seu conteúdo na saída padrão. Entretanto, uma expansão pode fazer com que as traps sejam direcionadas a outros processos de análise, enviadas por e- mail, ou qualquer outra opção, limitada apenas pela expansão do módulo. Entre as expansões possíveis, pode-se inclusive implementar protocolos de comunicação que acabam permitindo a interação externa nos mesmos modos descritos anteriormente.
Na verdade, existe ainda um terceiro modo de integração possível, mas menos factível: a reprogramação de módulos a partir de seus códigos fonte. Nesta solução, praticamente qualquer tipo de comunicação pode ser implementada, utilizando qualquer protocolo, já que se está de posse do código fonte de um módulo. Apesar de ser possível, já que módulos com código aberto estão se tornando cada vez mais disponíveis, a solução não é factível porque dificilmente um administrador de rede irá despender tempo com uma reimplementação.