ricarte@dca.fee.unicamp.br
A principal crítica à especificação/implementação realizada pelo grupo diz respeito ao Servidor do Laboratório. Em nosso entender, o Servidor do Laboratório é basicamente uma aplicação -- Laboratório -- e não um servidor.
O servidor de Laboratório recebe o perfil da aula (pode interromper ou não, pode gravar ou não etc.), realiza autenticação, exibe aula e fornece material extra. A implementação dessas funcionalidades através de um servidor vai implicar na duplicação de dados, por exemplo, sobre os atores (professores e alunos) durante a autenticação, e do conteúdo da disciplina, quando da exibição de uma aula. É mais razoável que estes dados fiquem em um único lugar, até para ser possível garantir sua consistência. Os dados sobre os atores devem estar no servidor administrativo e os dados de conteúdo da disciplina devem ficar por conta do servidor do instituto responsável. Dessa maneira, a aplicação Laboratório deverá utilizar este dados através de requisições de serviços aos servidores.
Por exemplo, suponhamos que o professor deseje iniciar a aula. Ele deverá "baixar" um "applet" aula e iniciá-lo. Durante a iniciação, o professor pode autenticar-se e definir o perfil de aula que deseja (com interrupção ou não, com gravação permitida ou não etc.). Note-se que, para a autenticação, o "applet" no cliente professor vai consultar o objeto respectivo implementado no servidor administrativo; para estabelecer o perfil de aula, vai ajustar parâmetros do serviço "exibição de aula" previsto no objeto "disciplina". Este objeto disciplina a que nos referimos é a instância da disciplina Física I para o curso de Engenharia Elétrica.
De maneira semelhante, o aluno vai "baixar" o "applet" que lhe permite assistir a aula e utilizar o laboratório. Esta aplicação também vai envolver uma autenticação (que irá servir de "freqüência) e a exibição da aula, com todos os recursos necessários e com o perfil definido pelo professor. Esta aplicação no cliente aluno deverá requisitar os serviços dos servidores adequados (administrativo e do instituto).
É importante notar que a utilização do conceito de laboratório como aplicação requer quase que obrigatoriamente a utilização de uma abordagem cliente-servidor baseada no paradigma CORBA. Isto se deve fundamentalmente porque os clientes (professor e alunos) são em dados momentos da interação "aula" também "servidores". Por exemplo, quando o aluno coloca uma dúvida, esta dúvida deve estar disponível para todos os demais alunos e, obviamente, para o professor; porém, com relação aos dados que descrevem a dúvida, o cliente aluno é o servidor. Da mesma forma, quando o professor divulga material extra (material que eventualmente ele tennha preparado na noite anterior!), a sua máquina é o servidor.
Portanto, concluímos que não há necessidade de um "servidor de laboratório" e que sua funcionalidade pode ser implementada como uma aplicação. Mais ainda, esta aplicação deve ser realizada através de "applets" Java que fazem invocações a métodos de objetos localizados remotamente através da plataforma CORBA. Estas duas soluções de implementação devem ser utilizadas porque, no caso dos "applets", eles podem ser "baixados" sem intervenção notável do cliente e permitem uma atualização imediata das eventuais modificações na aplicação laboratório; e, com relação à utilização de CORBA, porque este paradigma permite uniformização de conceitos (tudo é objeto) e de distribuição de dados, de tal sorte que mesmo um cliente, em dadas situações, pode ser servidor; em especial, para a situação 2, esta característica é fundamental.
Para o caso de sobrecarga dos servidores que fornecem dados durante a "aula" que utiliza a aplicação laboratório, é possível, sem perder a unidade conceitual proposta acima, utilizar "proxies" "laboratório" para reduzir a constante requisição de dados. É importante observar que se trata apenas de uma solução de implementação que não implica em redistribuição de dados (objetos) por entre os servidores.