CAPÍTULO 12 CONCLUSÃO

Transcrição

1 CAPÍTULO 12 CONCLUSÃO Existe somente um avanço. A hora mais escura da noite é o prenúncio do alvorecer. Nos dias sombrios de inverno, prosseguem incessantemente os preparativos para a primavera. Tudo que parece dificuldade é, na verdade, valioso trampolim para um grande saldo. (Do livro Inochi Hikidasun Rensukai- Seicho Tanuguchi). Este trabalho de pesquisa concentrou-se em apresentar uma arquitetura que pode ser aplicada ao software de controle de satélites do INPE, com a finalidade de suprir as limitações das versões atuais que foram elucidadas no final do Capítulo 5, bem como agregar novas funcionalidades. Como foi apresentado nos capítulos anteriores, esta arquitetura engloba os objetos da aplicação propriamente ditos (telemetrias, telecomandos etc.), bem como os serviços propostos, os quais são os responsáveis por disponibilizar uma infra-estrutura flexível e dinâmica para os objetos da aplicação. O serviço de balanceamento proporciona a disponibilidade de serviços, uma vez que sua atuação consiste em replicar ou migrar objetos que estejam sendo muito solicitados. A predisposição de mais de um objeto, que presta o mesmo serviço, garante a continuidade das operações de controle de um satélite, mesmo em falhas em um dos objetos ou no nó onde ele se encontra instanciado. O serviço de balanceamento sustenta as características de flexibilidade e dinamismo anunciadas na arquitetura. A primeira provém da capacidade de adaptabilidade da arquitetura proposta, em face das situações a que expõe um aplicativo de controle de satélites durante a sua existência. A fase de lançamento talvez seja a mais crítica, quando um número variável de usuários (projetistas, controladores, engenheiros) desejam obter as primeiras informações do satélite. Nesse estágio, o software para controle de satélite deve ser robusto, flexível e capaz de disponibilizar os serviços de acordo com a demanda. Ao término dessa fase, o satélite entra em operação de rotina e, nesse caso, a operação se restringe 205

2 aos usuários controladores de satélites. Novamente aflora a característica de flexibilidade do sistema, já que nessa fase o serviço de balanceamento atua no sentido de eliminar o excesso de objetos que foram criados para atender à primeira fase e agora se encontram ociosos. Entretanto, o período crítico não se restringe apenas ao lançamento. A demanda pela utilização do aplicativo de controle de satélite aumenta nos períodos de manobra. As operações de manobra ocorrem mensalmente e objetivam mudar a atitude de um satélite; portanto, envolve usuários de dinâmica orbital, usuários responsáveis pelos painéis solares etc. Novamente, a atuação do serviço de balanceamento garante a disponibilidade do software para controle de satélites nesses períodos de picos. A capacidade de os objetos migrarem de uma máquina para outra, conforme as solicitações de serviços dos usuários e a disponibilidade de CPU do nó onde o objeto está instanciado, confere à arquitetura um caráter dinâmico. Um ambiente distribuído flexível e dinâmico difere de um ambiente distribuído estático, pela capacidade de o primeiro se ajustar à demanda por solicitações de serviços. O aumento da demanda propicia a criação de novas réplicas do objeto que atendam a essa solicitação. Em contrapartida, a queda na demanda pode disparar o processo de destruição dos objetos ociosos no sistema. O balanceamento de carga ainda são técnicas caras e difíceis de ser implementadas. A maioria dos aplicativos que implementam a especificação CORBA propala uma distribuição seqüencial de carga. Ou seja, se o sistema distribuído contém mais de um objeto, para atender a uma mesma solicitação de um usuário, a conexão é estabelecida de forma seqüencial. Primeiro, com o objeto 1, depois com o objeto 2 etc. Ao alcançar o último objeto, retorna-se para o primeiro. O balanceamento de carga proposto nesse trabalho difere do proposto pela especificação CORBA em importantes aspectos: A tentativa de balancear a carga do sistema acontece desde o processo de atendimento da solicitação de serviço de um usuário. Ou seja, o processo de atendimento das solicitações de serviços dos usuários é sustentado por um 206

3 algoritmo capaz de localizar qual o objeto está mais apto para atender a essa solicitação. A capacidade do serviço de balanceamento em migrar ou replicar objetos de máquinas saturadas para máquinas ociosas. Talvez a imaturidade, até o momento, dos banco de dados orientados a objetos, proporcione uma instabilidade tecnológica no desenvolvimento dos serviços de persistência. O reflexo deste quadro pode ser observado ao analisar o histórico dos serviços de persistência propostos pela especificação CORBA. A primeira versão, Persistent Object Service-POS, foi cancelada e a Segunda, Persistent Sate Service (PSS), até o momento ainda não foi implementada pela maioria dos ORBs. O serviço de persistência proposto incrementa o PSS proposto na especificação CORBA, à medida que elimina a necessidade do desenvolvedor de software construir os arquivos PSDLs. O desenvolvedor concentra esforços na especificação dos objetos de negócio. Cada objeto de negócio contém métodos de acesso ao sistema de armazenamento de dados. O código interno desses métodos simplesmente aciona o serviço de persistência proposto. A grande contribuição do serviço de persistência proposto talvez esteja na capacidade deste serviço explorar os recursos já existentes no repositório de interfaces. A partir das informações geridas pelo repositório de interfaces, o serviço de persistência tem a capacidade de acessar os dados de um objeto, em tempo de execução, montar a SQL de conformidade com os atributos e seus respectivos tipos e, finalmente, armazená-los em um banco de dados. O ganho de explorar o conteúdo do repositório de interfaces reside no fato de que as alterações nos atributos de um objeto são imediatamente refletidas no repositório de interfaces e automaticamente visíveis para o serviço de persistência. Ou seja, não é necessária a compilação do serviço de persistência. Entretanto, mudanças nos atributos de um objeto, utilizando o serviço de persistência CORBA, necessita da compilação e geração de códigos para realmente refletir as alterações realizadas. A união da utilização do conceito de distribuição com o conceito de agentes permitiu 207

4 construir uma aplicação dinâmica e flexível, capaz de se adaptar às necessidades do usuário. Se a demanda por determinado serviço aumenta, os agentes supervisores são capazes de detectar o objeto que atenda esse serviço, bem como o número de usuários solicitantes. Esta informação é repassa para os agentes mensageiros responsáveis por disseminá-la para os outros nós, dentro do domínio de rede, que o sistema está carregado. O objeto que atenda a esta demanda poderá migrar ou ser replicado. Desta forma, o sistema se auto-ajusta para atender às solicitações de seus usuários. A tecnologia de agentes poderia ter sido substituída por programas ou qualquer outro recurso computacional que implementassem as mesmas funcionalidades, como por exemplo, os agentes móveis poderiam ter sido substituídos por banco de dados distribuídos. Ou até mesmo utilizar o recurso de troca de mensagens entre os agentes supervisores para substituir os agentes mensageiros. A utilização das funcionalidades dos agentes foi com intuito de explorar esta tecnologia, já que pelas próprias características intrínsecas, os agentes, se apresentam melhor adaptado para monitoração de aplicações distribuídas. Dentre as contribuições preponderantes deste trabalho, para o grupo de desenvolvimento de software de controle de satélites do INPE, deve-se ressaltar: - A arquitetura proposta, sustentada pela atuação do serviço de balanceamento, permite a continuidade do controle de um satélite, mesmo em situações de contingências, como por exemplo falha em um servidor, falha em um objeto etc. Isto em função da disponibilidade de serviços proporcionada pelas réplicas dos objetos. - A disponibilidade de serviços pode trazer, como consequência imediata, um incremento no desempenho, já que a arquitetura proposta tem cópias de um mesmo objeto distribuído em máquinas distintas para atender às solicitações dos usuários. Atualmente, as versões do SICS estão centradas na arquitetura cliente-servidor. Desta forma, o aumento do número de clientes compromete o desempenho do servidor. - Flexibilidade para atender à dinâmica dos programas espaciais (satélites a serem controlados poderão aumentar e até diminuir ao longo do tempo).atualmente, a cada 208

5 nova missão é necessário criar um ambiente dedicado para controle do satélite (um servidor e um conjunto de clientes). Além dos custos envolvidos, existem serviços semelhantes em cada novo ambiente. A idéia é ter um conjunto de servidores para controlar um conjunto de satélites, sem ter a rigidez na alocação dos serviços de controle e servidor dedicado a um dado satélite. Alguns resultados deste trabalho de pesquisa já foram publicados no SPACE OPS jun/2000 (Ferreira,2000) e outros serão publicados no 19th AIAA International Communications Satellite Systems Conference (Ferreira, 2001), ambos na França. Além dos trabalhos já publicados, a contribuição deste trabalho de pesquisa não se restringiu apenas à tese de doutorado aqui apresentada, pois foram originados pelo menos três vertentes de pesquisa. O serviço dos agentes foi a motivação do primeiro trabalho de pesquisa, tendo sido tema da dissertação de Silva (Silva,2000). O serviço de persistência será explorado em mais detalhes em uma futura dissertação de mestrado. Acredita-se que um ambiente flexível e dinâmico exija, do serviço de segurança, facilidades que até o momento não estão implementadas em nenhum ORB; portanto, uma análise mais criteriosa neste serviço pode ser tema de tese de outros trabalhos de pesquisa. Enfim, os serviços agregados (persistência, segurança, agentes e balanceamento) ao aplicativo para controle de satélites tornaram-se fatores preponderantes e proporcionaram a criação de um ambiente capaz de se adaptar dinamicamente às solicitações dos controladores e demais usuários do sistema, melhorando um conjunto de características, como desempenho, flexibilidade, confiabilidade e utilização dos recursos computacionais disponíveis. 209

6 210