A sessão de acesso é responsável por estabelecer uma relação segura e gerenciável entre entidades pertencentes a domínios administrativos diferentes (usuário e provedor do serviço). Esta relação im- plica, genericamente, em uma relação contratual entre os domínios envolvidos, permitindo ao usuário o acesso aos serviços disponibilizados pelo provedor de serviços.
O projeto REAL desenvolveu uma sessão de acesso para serviços implementados segundo o mo- delo CM-tel. Esta sessão proporciona os mecanismos de suporte às funções de subscrição, reserva de recursos e gerência do serviço. A partir de uma sessão de acesso podem ser iniciadas muitas sessões de serviço que estarão vinculadas à sessão de acesso.
A Figura 5.2 ilustra os principais elementos da arquitetura da sessão de acesso utilizada pelo REAL. A sessão de acesso é implementada por Java Servlets, páginas dinâmicas JSP, componentes e contêineres CM-tel. Os servlets interagem com um sistema gerenciador de base de dados que disponibiliza um driver compatível com JDBC. Na base de dados são armazenadas informações sobre os serviços disponibilizados, os usuários cadastrados e reservas de horário para uso dos serviços. Um
servlet específico interage com um componente CCM-tel, o componente de sessão descrito a seguir.
Páginas JSP AccessServlet ReservServlet SubServlet JDBC Base de Dados HTTP Navegador Web Evento de Sessão CCM−tel de Sessão Componentes (MySQL) Contêiner Web
Fig. 5.2: Arquitetura da sessão de acesso do REAL.
5.3.1
Funções da Sessão de Acesso
As três funções proporcionadas pela sessão de acesso são disponibilizadas por interfaces gráficas apresentadas no navegador do usuário. Estas interfaces, implementadas por meio de páginas JSP, atuam como um cliente do provedor iniciando e gerenciando a comunicação do usuário com o labo- ratório virtual. As funções de subscrição de usuários, reserva de recursos e de gerência de serviço (acesso e uso do serviço) são descritas a seguir.
Subscrição de Usuários
A subscrição de usuários é necessária para que estes possam usufruir dos serviços oferecidos pelo provedor dos serviços. Para isto, é disponibilizada uma interface para subscrição, a partir da qual o usuário fornece informações para o seu cadastramento. Estas informações consistem do fornecimento de seus dados, tais como nome completo, identificação do usuário, senha de acesso, telefone, insti- tuição, posição, serviços subscritos e endereço eletrônico (e-mail). O servlet SubServlet (Figura 5.2) processa as informações submetidas pelo usuário, adicionando-as à base de dados caso isentas de er- ros. As informações de identificação e senha fornecidas serão solicitadas nas interações subseqüentes do usuário com o serviço.
Reserva de Recursos
Serviços como o REAL que necessitam de acesso exclusivo aos recursos (no caso o robô) deman- dam da sessão de acesso um mecanismo de reserva de recursos. A sessão de acesso implementada possui uma interface para reserva de recursos, pela qual o usuário pode reservar um intervalo de tempo para acesso ao serviço. No caso do REAL, a interação com o robô é permitida apenas para usuários com reserva de horário. O servlet ReservServlet (Figura 5.2) processa as informações de reserva de recursos submetidas pelo usuário, autenticando-o e verificando a existência de conflitos (horário já reservado). As reservas aceitas são armazenadas na base de dados.
Acesso ao Serviço
O acesso ao serviço consiste no carregamento do serviço no terminal do usuário. Este carrega- mento ocorre simplesmente pelo acesso à URL do serviço (usualmente a partir da página principal do provedor de serviços). O acesso à URL propicia o carregamento de páginas HTML contendo referências a applets e arquivos JAR. Os arquivos JAR contêm classes Java que implementam os componentes e contêineres do serviço no lado do usuário do serviço. Adicionalmente ao serviço, uma interface da sessão de acesso é apresentada ao usuário. Esta interface permite que o usuário use efetivamente o serviço. A separação entre carregamento e uso do serviço é uma vantagem principal- mente para acessos de baixa velocidade, onde o usuário pode carregar o serviço sem que seu uso seja contabilizado durante o tempo de carregamento.
Uso do Serviço
Após o carregamento, o serviço pode ser efetivamente usado. Para tal, o usuário fornece iden- tificação e senha na interface da sessão de acesso disponibilizada juntamente com o serviço. Esta interface envia a identificação e senha a um servlet da sessão de acesso (AccessServlet ilustrado na Figura 5.2), que irá autenticar o usuário e verificar se o mesmo possui horário reservado. O serviço somente se inicia caso estas verificações sejam bem sucedidas. O início do serviço consiste na intera- ção deste servlet com o componente da sessão responsável por gerenciar o serviço (Figura 5.2). Este componente é o “ponto de contato” entre o serviço no lado do provedor e a sessão de acesso.
O componente de sessão expõe duas portas: uma faceta e um publicador de eventos. Existe uma instância deste componente para cada serviço gerenciado pela sessão de acesso. Instâncias deste componente são registradas no Home com o próprio nome do serviço que gerenciam. Ao receber uma requisição de acesso ao serviço, o servlet AccessServlet, após as verificações descritas acima, localiza a instância do componente de sessão responsável pela gerência do serviço e invoca o método
sessão e ajusta um contador de tempo para o período de reserva que ainda resta ao usuário do serviço. O componente de sessão notifica, pela emissão de um evento tipo start na sua porta publicadora de eventos, os componentes de configuração de serviço conectados. Este evento desencadeará o processo de montagem da aplicação, conforme descrito na seqüência.
Uma vez terminada a interação do servlet com o componente, o servlet redireciona o processa- mento da requisição para uma página JSP que irá substituir a página da sessão de acesso utilizada para iniciar o serviço. Esta nova página possui um botão de encerramento do serviço e um script Java (Javascript) que confirma o uso do serviço a cada intervalo de 60 segundos (ambos pela submissão de um documento HTML ao servlet AccessServlet). O encerramento e a confirmação são processados pelo mesmo servlet. Este servlet invoca as operações de confirmação (ping_session) ou encerramento (end_session) de sessão na faceta do componente de sessão. A operação de confirmação reinicia o contador de tempo que monitora a inatividade da sessão.
A sessão pode ser encerrada em três situações:
1. encerramento pelo usuário: o usuário ativa o botão de encerramento da interface da sessão de acesso;
2. encerramento devido a inatividade: a inatividade é noticiada pela ausência de confirmação causada, por exemplo, pelo fechamento do navegador do usuário ou sobreposição da página do serviço;
3. encerramento por timeout: o período de tempo reservado para uso do serviço expirou.
Qualquer que seja o motivo do encerramento, o componente de sessão notifica, por meio de um evento tipo end na sua porta publicadora de eventos, os componentes de configuração de serviço conectados. Este evento desencadeará o processo de desmontagem da aplicação.
5.3.2
Interação entre as Sessões do Modelo de Serviço do REAL
As interações entre as três sessões definidas pelo modelo de serviço do REAL são importantes para a realização da gerência e controle dos serviços. Esta seção mostra a interação entre os com- ponentes pertencentes a estas sessões para concretizar o estabelecimento e utilização dos serviços disponibilizados pelo laboratório virtual.
Interação Entre as Sessões de Acesso e Serviço
A Figura 5.3 ilustra uma visão geral dos componentes e seus contêineres envolvidos na interação entre as sessões de acesso e de serviço. A interação entre a sessão de acesso e a sessão de serviço
ocorre por meio de eventos propagados entre o componente de sessão e o componente de configu- ração do serviço. Ao receber um evento tipo start, o componente de configuração do serviço inicia o processo de configuração inicial do serviço, procedendo à instanciação e conexão dos demais compo- nentes da sessão de serviço. A instanciação e conexão dos demais componentes da aplicação torna o serviço pronto para uso por parte do usuário. Analogamente, ao receber um evento tipo end, o com- ponente de configuração do serviço desfaz as conexões entre os componentes da sessão de serviço destruindo determinados componentes (tipicamente aqueles instanciados no domínio do usuário). Nesta ação são liberados os recursos alocados durante o estabelecimento da sessão de serviço.
Navegador Web sessão acessode AccessServlet Evento de Sessão instancia, remove do Serviço Configuração de Serviço Componente de de Sessão Componente end_session create_session ping_session end Sessão de Acesso conecta, desconecta ... Componentes Container Web Sessão de Serviço/Comunicação start ping start end
Fig. 5.3: Interação entre componentes das sessões de acesso e de serviço.
Para serviços multipartite, uma sessão de acesso pode abrigar vários usuários. É o caso do modo de interação assistido do REAL descrito na Seção 5.4.3. Para tais serviços, o componente de configu- ração do serviço deve ser capaz de proceder a montagem e desmontagem de componentes do serviço associados a um usuário específico. Tal situação ocorre quando um usuário ingressa ou abandona a sessão de serviço. A identificação do usuário e seu domínio estão presentes nos parâmetros do evento de início e término de sessão. Com esta identificação, o componente de configuração do serviço
é capaz de proceder à instanciação (destruição) e conexão (desconexão) de componentes para um usuário específico. Para serviços multipartite, um usuário específico não pode encerrar a sessão de acesso. Neste caso, a sessão de acesso é encerrada por timeout ou quando o último usuário abandona o serviço.
Interação entre as Sessões de Serviço e de Comunicação
Uma sessão de serviço possui uma sessão de comunicação associada que é composta de vários fluxos de mídia contínua. Os fluxos são produzidos através da interconexão de componentes pro- dutores e apresentadores de mídia. Durante o tempo de duração da sessão de serviço, a sessão de comunicação tem natureza dinâmica quanto aos fluxos. Fluxos podem ser estabelecidos, suspensos, reiniciados e finalizados em qualquer instante de tempo, ter sua estrutura alterada (por exemplo, a inclusão de um consumidor em um fluxo ponto-multiponto), ou ter seus parâmetros modificados no tempo (por exemplo, a qualidade do vídeo pode se alterar em função do desempenho da rede).
A interação entre os componentes das sessões de serviço e de comunicação também ocorre por meio do componente de configuração associado ao serviço. Os componentes da sessão de comuni- cação (produtores e apresentadores de mídia contínua) são instanciados e conectados pelo compo- nente de configuração do serviço durante o processamento do evento tipo start. Analogamente, os componentes da sessão de comunicação são desconectados e destruídos em resposta a eventos do tipo
end.
5.3.3
Detalhes da Implementação da Sessão de Acesso
A implementação da sessão de acesso do REAL foi realizada na linguagem de programação Java utilizando a plataforma Java 2 SDK, versão 4.2. O código de implementação do componente de sessão CM-tel também foi gerado em Java pela plataforma CCM-tel e, a partir do descritor de distribuição, foi gerado um arquivo para a instalação do contêiner no domínio do provedor na forma de processo Java.
Para processamento de formulários e páginas HTML, utilizamos o servidor Apache Tomcat [118] no provedor de serviços. As informações cadastrais dos usuários, as reservas de horário e os serviços oferecidos pelo REAL são armazenadas em uma base de dados relacional gerenciada pelo MySQL [119].