pensamento de especialistas acerca de quais s˜ao os pontos mais not´aveis para a monitorac¸˜ao e o controle de um sistema ou de determinados aspectos deste sistema, conforme comentado em [Wellens e Auerbach, 1996].
Esses pontos muitas vezes enderec¸am caracter´ısticas espec´ıficas do fabricante, normalmente aquelas caracter´ısticas que tornam o sistema diferente de sistemas similares produzidos por outros fabricantes.
O problema com isso ´e que na maioria das vezes Aplicac¸˜oes de Gerˆencia de prop´osito geral n˜ao tomam conhecimento desses pontos e n˜ao podem enderec¸´a-los atrav´es de PDUs SNMP.
Tem-se ent˜ao um cen´ario indesej´avel no qual a gerˆencia daqueles sistemas se faz localmente, ou remotamente atrav´es do protocolo TELNET [Postel e Reynolds, 1983]. Muitas vezes, uma soluc¸˜ao paliativa ´e dada por meio de navegadores de MIB, mas sem nenhum resultado expressivo.
Em [Bruins, 1996] ´e sugerida uma abordagem baseada na utilizac¸˜ao de servidores HTTP embu- tidos em sistemas gerenciados, que exportavam p´aginas codificadas em HTML (Hyper Text Markup
Language) contendo informac¸˜oes de gerˆencia para navegadores Web.
A principal vantagem provida por aquela abordagem ´e que os sistemas gerenciados podiam exportar GUIs (Graphical User Interfaces) semanticamente ricas para a sua monitorac¸˜ao e controle, dispensando o uso de ferramentas de gerˆencia personalizadas.
Apesar da enorme vantagem oferecida por aquela abordagem, deve se ter sempre em mente que ela tamb´em baseia-se na definic¸˜ao estrita de um protocolo e um modelo de dados. Naquele caso, as informac¸˜oes de gerˆencia s˜ao transferidas utilizando-se HTTP e codificadas em HTML.
Possuindo inspirac¸˜ao na id´eia exposta em [Bruins, 1996], ´e sugerida a incorporac¸˜ao do Pro- jeto ServiceUI [Venners, 2005], surgido no ˆambito da Comunidade JINI, para tornar poss´ıvel a importac¸˜ao dinˆamica de Interfaces com o Usu´ario semanticamente ricas a partir dos Servic¸os JINI associados aos sistemas gerenciados.
A id´eia por tr´as do Projeto ServiceUI ´e a de embutir Objetos de Interface com o Usu´ario nos
proxies para os Servic¸os JINI, mais precisamente nos seus atributos. Nesse contexto, tais Objetos
s˜ao tamb´em chamados de Objetos Adaptadores de Usu ´ario, porque eles adaptam a interface provida por um proxy a alguma interface compreens´ıvel pelos usu´arios. A incorporac¸˜ao dessa id´eia na modelagem de Servic¸os JINI associados aos sistemas gerenciados ´e ilustrada pela Figura 4.4.
Atrav´es da incorporac¸˜ao do Projeto ServiceUI, consegue-se o mesmo efeito observado na pro- posta descrita em [Bruins, 1996], por´em com duas vantagens adicionais frente `aquela iniciativa.
A primeira dessas vantagens remete ao pr´oprio uso da tecnologia JINI, mais precisamente ao fato de que n˜ao h´a nenhuma restric¸˜ao ao protocolo utilizado na comunicac¸˜ao entre proxies e seus Servic¸os associados.
Considerac¸˜oes gerais sobre a utilizac¸ ˜ao de JINI na construc¸˜ao de NMSs sistema gerenciado proxy para o Serviço JINI com o Usuário Objeto de Interface plataforma de gerência Aplicação de Gerência administrador Serviço JINI 0 0 0 1 1 1
Figura 4.4: Incorporac¸˜ao do Projeto ServiceUI.
Assim, contrariamente `a abordagem vista em [Bruins, 1996], ´e poss´ıvel que qualquer protocolo, n˜ao apenas HTTP, seja utilizado para transmiss˜ao dos dados de gerˆencia. Inclusive, para cen´arios com restric¸˜oes de seguranc¸a, a vers˜ao simplificada do HTTP n˜ao pode ser utilizada.
A segunda vantagem remete ao pr´oprio Projeto ServiceUI, que n˜ao imp˜oe qualquer restric¸˜ao ao tipo da Interface com o Usu´ario provida pelo Objeto correspondente. Assim, a incorporac¸˜ao deste Projeto em NMSs baseados em JINI permite aos usu´arios daqueles sistemas utilizar uma interface gr´afica, uma interface de texto, uma combinac¸˜ao de texto e gr´aficos ou at´e mesmo um ambiente de Realidade Virtual. De fato, o Objeto ´e dito ser simplesmente de Interface com o Usu´ario, e n˜ao de Interface Gr´afica com o Usu´ario.
Apesar dos coment´arios feitos nesta subsec¸˜ao serem limitados `a comparac¸˜ao com a abordagem exposta em [Bruins, 1996], h´a outras considerac¸˜oes importantes sobre a utilizac¸˜ao de Objetos de Interface com o Usu´ario.
Seguem algumas desvantagens da abordagem baseada em proxies e Objetos de Interface com o Usu´ario, em detrimento da comunicac¸˜ao Cliente/Servidor tradicional envolvendo p´aginas HTML transferidas usando o HTTP:
¯ Servic¸os JINI n˜ao s˜ao t˜ao f´aceis de serem constru´ıdos quanto p ´aginas HTML: enquanto
uma simples p´agina Web pode ser constru´ıda a partir do conhecimento de algumas poucas
tags, Servic¸os JINI podem ser constru´ıdos somente a partir de um conhecimento pr´evio de
programac¸˜ao Orientada a Objetos, fundamentos da linguagem de programac¸˜ao Java e conhe- cimento b´asico da API disponibilizada no JTSK. Muito embora o trabalho de desenvolvi- mento destes Servic¸os seja amenizado por ferramentas do tipo IDE (Integrated Development
Considerac¸˜oes gerais sobre a utilizac¸ ˜ao de JINI na construc¸˜ao de NMSs
¯ tempo de descarregamento: o overhead causado pelo tempo de descarregamento do c´odigo
referente ao proxy para um Servic¸o ´e um obst´aculo relevante ao seu emprego. Isso ´e parti- cularmente verdade caso considere-se que um Cliente humano queira utilizar aquele Servic¸o. Curiosamente, as maneiras de enderec¸ar-se este problema s˜ao an´alogas `aquelas adotadas para o projeto de p´aginas Web: manter sob controle o tamanho do c´odigo do proxy, dividir sempre que poss´ıvel as funcionalidades providas e utilizar estrat´egias de caching.
Por outro lado, as vantagens de embutir-se Objetos de Interface com o Usu´ario em proxies, se- parando a forma de apresentac¸˜ao da funcionalidade oferecida por seus respectivos Servic¸os, podem ser sumarizadas com se segue:
¯ facilidade de automac¸ ˜ao n˜ao prejudica a utilizac¸ ˜ao direta dos proxies: um mesmo proxy pode
ser igualmente acess´ıvel por quaisquer Clientes, sejam eles humanos ou n˜ao;
¯ facilidade de evoluc¸ ˜ao: visto que as Interfaces com o Usu´ario sofrem modificac¸ ˜oes mais
freq¨uentemente do que a interface para o Servic¸o, a separac¸˜ao entre ambas garante que mudanc¸as nas primeiras n˜ao afetem o projeto da ´ultima;
¯ extens˜ao do alcance do Servic¸o: a possibilidade de associar-se diferentes interfaces a um mes-
mo proxy permite que o seu Servic¸o correspondente seja disponibilizado em equipamentos t˜ao distintos como uma TV, um computador convencional ou um telefone celular, por exemplo;
¯ formas de interac¸˜ao mais naturais com o usu ´ario: quando Servic¸os s˜ao acessados atrav´es de
um Objeto de Interface com o Usu´ario, essa interface pode potencialmente assumir qualquer forma, inclusive aquela mais natural para o usu´ario. Servic¸os de Email e Chat poderiam incluir uma interface de voz, por exemplo;
¯ utilizac¸˜ao mais suave por parte do usu ´ario: visto que proxies encapsulam o comportamento
necess´ario `a execuc¸˜ao dos seus respectivos Servic¸os, os usu´arios n˜ao confrontam-se com problemas tais como aqueles observados quando um componente de software (uma imagem TIFF, por exemplo) n˜ao pode ser manipulado por um navegador Web e um plug-in precisa ser descarregado pelo Cliente.