Relatório Intercalar. n

Transcrição

1 Relatório Intercalar José Gonçalves n January 2006

2 Contents 1 Introdução 2 2 Objectivos e Resultados a obter 3 3 Trabalho Relacionado 4 4 Trabalho Realizado 6 5 Trabalho Proposto 7 6 Plano de Trabalhos 8 7 Conclusões 9 1

3 1 Introdução O Instituto Superior Técnico dispõe de um sistema para gestão académica denominado Fénix 1, servindo de suporte a todos os alunos, docentes e funcionários. Apesar das suas inúmeras funcionalidades existem ferramentas de e-learning mais orientadas ao ensino, com o objectivo de tornar o processo de aprendizagem mais dinâmico e interactivo. Uma destas ferramentas é o Moodle 2, actualmente em funcionamento para algumas cadeiras. A primeira parte do trabalho consiste na integração dos dois sistemas referidos, com o objectivo de eliminar algumas desvantagens e problemas que surgem quando tanto alunos como docentes se vêem obrigados a usar dois diferentes sistemas, mais especificamente nos aspectos de autenticação e na passagem de informação de um sistema para outro. A segunda parte do trabalho consiste na criação de novas funcionalidades e interfaces (quando necessárias) para facilitar a passagem de informação referida anteriormente, e também para a inserção de novos conteúdos no Moodle, com base em necessidades específicas de cadeiras. De momento existe uma máquina de testes com os dois sistemas instalados, na qual é já possível fazer autenticação no sistema Fénix para aceder ao Moodle. É também possível a chamada de serviços remotos não autenticados através de uma nova camada de Web Services no Fénix. No futuro a funcionalidade de autenticação passará para o ambiente de produção, e será possível a chamada de serviços remotos autenticados, peça chave para permitir a passagem de informação entre os dois sistemas. Após estes dois problemas resolvidos, serão feitas as modificações necessárias no sistema Moodle para tirar máximo partido da ligação criada

4 2 Objectivos e Resultados a obter O processo de autenticação dos serviços perante o Fénix é um passo tecnologicamente complexo e algo delicado, visto que a segurança e privacidade dos dados são condições determinantes para a sua implementação. Uma vez conseguido, será possível correr serviços no Fénix tal como um utilizador corre serviços via interface web já disponível. Serão implementadas novas funcionalidades e interfaces correspondentes no Moodle (módulo MoFenix) de forma a tirar partido da ligação com o Fénix: Exportação de aulas com respectivo conteúdo Exportação de notas Gestão de grupos e submissões de projectos Fácil inserção de conteúdo composto (slides, video, etc) Gestão de dados dos utilizadores O resultado do trabalho será portanto a implementação de todas as funcionalidades, com a aceitação por parte do utilizador na óptica do aluno e professor, e no funcionamento normal das cadeiras suportadas pelo Moodle no decorrer do semestre. 3

5 3 Trabalho Relacionado No trabalho de investigação, foram analisadas soluções de Single Sign-On e de serviços remotos. Nos serviços remotos, foi feita uma análise entre o CAS 3, Pubcookie 4, Webauth 5, A-Select 6 e Shibboleth 7 A opção já estava um pouco influenciada desde o início, dado o facto de o Fénix já estar a utilizar o CAS. As soluções CAS e Shibboleth são as mais fortes do grupo, bastando para isso ver a sua utilização na maioria das universidades. O Shibboleth é mais abrangente, focado na autenticação entre instituições e não dentro de uma só, que é o requisito para o trabalho. O CAS é uma solução relativamente simples, e com a grande vantagem de ter módulos já implementados nas mais diversas ferramentas (nas quais se inclui o Moodle). Em relação aos serviços remotos, foram analisadas: Solution Vendor Language License Corba Multiple (standard set by OMG) independent n.a. Java RMI Sun Microsystems Inc. Java GPLv2 DCOM Microsoft independent Proprietary Web Services Multiple (standard set by W3C) independent n.a.net Remoting Microsoft C++, C#, VB, J# Proprietary Table 1: Serviços Remotos As soluções foram comparadas com base em: Interoperabilidade (entre plataformas diferentes) Protocolo de comunicação Segurança (encriptação e autenticação) Performance Velocidade/Facilidade de desenvolvimento Tipo de parâmetros aceites em chamadas de serviços Ferramentas de desenvolvimento existentes

6 mt. má má suficiente bom muito bom Table 2: Legenda Nota: Escala relativa, apenas faz sentido quando usada em comparações. Solution Interoperability Comm. Protocol Security Performance Devel. speed Parameter types Existing tools Corba Java RMI DCOM Web Services.NET Remoting Table 3: Comparação das soluções de serviços remotos O CORBA e o DCOM são as tecnologias mais antigas, que hoje em dia estão a cair em desuso. São ambas relativamente difíceis de programar quando comparadas com outras, especialmente em ambientes heterogéneos, caso do Moodle/Fénix. O Java RMI está preso à linguagem, o que o torna à partida uma opção não viável (o Moodle está implementado em PHP). O.NET Remoting sofre um pouco do mesmo problema do DCOM, está muito ligado à.net e não existem alternativas viáveis fora do universo Windows. Escolheram-se os Web Services pela facilidade de programação, e pela capacidade de ligar plataformas com diferentes arquitecturas. A baixa classificação na performance em relação aos outros deve-se ao facto do processo de serialização/deserialização dos argumentos em XML ser inerentemente lento, no entanto a performance não é uma prioridade. Esta solução também só suporta parâmetros que possam ser descritos num schema XML com composição de tipos simples, no entanto esta também não é uma grande desvantagem e é na verdade necessária para manter a informação estruturada independente da linguagem usada. Outro grande ponto forte dos Web Services (que também se aplica ao.net Remoting) é a possibilidade de usar HTTP/HTTPS como protocolo de comunicação, facilitando a comunicação em ambientes com firewalls e usando um canal seguro encriptado sem configuração ou codificação adicional. 5

7 4 Trabalho Realizado O período inicial do trabalho foi dedicado a ganhar conhecimento nas plataformas e a implementar protótipos funcionais relevantes nas mesmas. Estas plataformas/tecnologias são: Fénix XFire 8 Web Services CAS 9 Single Sign-On Moodle Em relação ao sistema Fénix, a grande dificuldade é a sua complexidade, enumerando por exemplo a instalação/configuração numa máquina de testes e a percepção da estrutura do código, necessária para efectuar o trabalho de desenvolvimento. Os Web Services XFire são uma das muitas implementações disponíveis de Web- Services, sendo das mais fáceis de perceber e implementar, com uma rápida curva de aprendizagem. O processo decorreu sem problemas, sendo rapidamente desenvolvido um protótipo para chamar um novo serviço no Fénix a partir do Moodle (em linguagem PHP). O sistema CAS, que trata do aspecto da autenticação, é uma ferramenta relativamente simples. No entanto todo o processo que é necessário para a sua utilização não é nada trivial, envolveu a utilização do módulo CAS disponibilizado no Moodle, que por sua vez usa um servidor de LDAP onde estão guardados os dados dos utilizadores. Está em funcionamento na máquina de testes a autenticação a ser feita com sucesso através do CAS, de uma maneira muito semelhante à que vai ser efectuada em ambiente de produção. Na plataforma Moodle foi desenvolvido um novo módulo para agregar as novas funcionalidades de integração com o Fénix. De momento incorpora o código necessário para a chamada de Web Services referido em cima, e outros aspectos como que informação a guardar sobre o estado da ligação entre os dois sistemas Fénix e Moodle

8 5 Trabalho Proposto Numa primeira fase, vai ser activada a autenticação no Moodle através do CAS. Desta maneira será possível usar o login único do IST. No entanto é necessária também a passagem dos dados dos alunos para o Moodle, processo este que não está contemplado no esquema. Isto será feito apenas porque ainda não é possível chamar serviços remotos autenticados, procedimento previsto para mais tarde. Figure 1: Arquitectura : Componentes Escolhemos os Web Services como solução, sendo esta decisão baseada no trabalho de investigação a decorrer. Provou-se que esta é a opção mais viável, devido à necessidade de ligar duas plataformas de linguagens diferentes (Java e PHP) e à sua menor complexidade de programação neste tipo de ambiente. 7

9 6 Plano de Trabalhos Figure 2: Planeamento 8

10 7 Conclusões O trabalho de investigação não só reforçou a escolha das tecnologias adoptadas, como também ajudou a aprofundar conhecimentos sobre as mesmas. Este ponto é muito relevante porque permitiu estabelecer a ponte entre os serviços e a autenticação, numa maneira que se desconhecia ao início. Foram necessárias fazer algumas escolhas importantes devido a prazos a cumprir (início do próximo semestre) como fazer a passagem de dados para o Moodle de uma maneira manual, de forma a ter o mínimo a funcionar na óptica do utilizador. A primeira fase do trabalho (infra-estrutura de integração) parece ser a mais demorada e abre novas possibilidades de interacção com o Fénix. Em termos de protótipos implementados, apenas falta o caso dos serviços remotos autenticados. Embora já estejam estipuladas as funcionalidades na segunda fase poderão surgir novas que tirem partido da infra-estrutura implementada sem grandes dificuldades. O mesmo se pode dizer da futura integração de outras aplicações diferentes do Moodle, para as quais o processo fica bastante mais simplificado. A preocupação presente é começar o semestre com o login unificado, e ir construindo a infra-estrutura e implementar funcionalidades à medida que este decorre. 9

11 References [ase07] A-select authentication system. Last accessed January [cas07] Ja-sig central authentication service. Last accessed January [fen07] Fénixedu open-source project. Last accessed January [moo07] Moodle - a free, open source course management system for online learning. Last accessed January [pub07] Pubcookie. Last accessed January Last checked Jan- [Shi07] Shibboleth project. uary [Sta07] Stanford webauth. Last accessed January [xfi07] Codehaus xfire. Last accessed January