Implementando SCORM: Construindo a retaguarda

November 25th, 2003 § 4 comments

No meu artigo anterior sobre o SCORM, eu apresentei algumas considerações sobre a implementação da API de um LMS, tanto em relação à parte que funciona no navegador quanto à parte que funciona no servidor. O artigo deu uma visão mais geral sobre a implementação, mas sem entrar em grandes detalhes. Este novo artigo procura estender algumas das informações contidas no anterior, explicando mais alguns detalhes da implementação no lado do servidor. Um aspecto fundamental do SCORM é o fato de que ele roda em um ambiente Web. Isso significa que ele faz uso do protocolo HTTP para a comunicação entre a API local (que expõe as funções do SCORM para o SCO e que roda no navegador), e a API remota (que realmente implementa as funções e é disponibilizada pelo servidor). Entretanto, o protocolo HTTP, por sua natureza, é um protocolo sem estado, ou seja, informações entre requisições diferentes não são mantidas — cada requisição é tratada como se fosse única e independente das requisições anteriores e posteriores. Para contornar essa limitação, vários mecanismos foram desenvolvidos, envolvendo, em geral, a transmissão de um valor, chamado de identificador de sessão, entre o navegador e o servidor. Rastreando esse identificador, é possível saber a que sessão uma determinada requisição pertence.

Isso é importante porque a implementação da comunicação entre a API local e a API remota em um LMS depende desse rastreamento de sessão para identificar as chamadas executadas por um SCO. Como comentado no artigo anterior, a responsabilidade de iniciar a execução de um SCO é do próprio LMS e, portanto, nesse momento, ele pode fazer uso de informações a que só ele tem acesso como, por exemplo, os dados do usuário e o seu histórico no curso. Essas informações podem ser úteis na manutenção de algum mecanismo de sessão, seja usando cookies ou parâmetros nas invocações feitas ao servidor.

Dito isto, uma recomendação na hora de implementar a comunicação entre a API local e a sua contraparte remota é não depender da sessão que sua linguagem de desenvolvimento porventura providencie. Tomando como exemplo PHP e ASP, que possuem gerenciamento automático de sessão, o melhor a fazer seria criar o seu próprio identificador de sessão e passá-lo em cada requisição. O motivo para isto é simples: a API remota do seu LMS pode estar em um servidor diferente ou mesmo em servidores distribuídos e a maioria das linguagens não suporta sessões distribuídas. Mantendo sua própria sessão você ganha um controle maior sobre a mesma, reduzindo ou eliminando muitos dos problemas de desenvolvimento. Caso o servidor mude, por exemplo, você não terá que refazer o seu código para lidar com uma transferência de sessão de servidor onde o SCO está rodando para o servidor onde a API está agora. E, além disso, a implementação desse tipo de sessão é simples.Um identificador poderia, por exemplo, ser feita através do código do usuário e código do SCO.

Uma segunda recomendação quanto à implementação é tomar cuidado com as informações das quais o seu LMS faz uso. A especificação SCORM deixa bem claro que cada SCO é uma entidade independente que deve ser capaz de funcionar por si própria em qualquer implementação que se conforme ao padrão. Assim, uma boa implementação fará uso de dados mínimos para a execução do SCO, extraindo os dados dos locais corretos. Um erro comum é usar dados provenientes do banco de dados que deveriam na verdade estar sendo recolhidos do manifesto. Se o seu LMS também tem a função de LCMS, isso é duplamente perigoso já que a tentação de usar informações que estão no banco ao invés de processar o manifesto é ainda maior. Informações como se o SCO é de crédito ou não, devem vir do manifesto, mesmo que essas informações estejam duplicadas no banco de dados do LMS ou LMCS por motivos de performance, relatórios, ou outro qualquer.

Uma última recomendação, já mencionada no artigo anterior, é usar um tabela-dicionário para os elementos do SCORM que você implementa. Uma tabela assim permite simplificar a implementação das funções da API, unindo processamento comum, e pode também ser reutilizada em outras partes do sistema para obtenção rápida de dados agregados sobre os módulos, cursos e usuários. Com base neste dicionário é fácil estabelecer um processo de escolha que determine como o LMS devolverá os dados referentes a um determinado elemento, levando inclusive em conta que alguns elementos podem ser implementados completamente em tempo de execução, sem a necessidade de armazenamento de dados. Um exemplo disso é o elemento “cmi.core.student_data”, que vem das informações que o próprio LMS mantém sobre o usuário. Além dessa facilidade de processamento, o uso do dicionário simplifica também a implementação dos elementos raiz e dos elementos de conjunto como “cmi.interactions.n.*”.

A escolha dos elementos que o LMS implementará depende muito no nível de adequação desejado ao padrão SCORM. Como muitos elementos são opcionais, pode parecer que deixá-los de lado é uma decisão interessante, tendo em vista o tempo de desenvolvimento. Entretanto, além de agregar valor ao LMS, aumentando o seu nível de conformação ao padrão, a implementação de alguns desses elementos opcionais também serve para facilitar o desenvolvimento de outras partes do processo SCORM. Por exemplo, a criação de SCOs que são avaliações pode ser facilitada pela implementação dos elementos opcionais “cmi.student_data.*” e “cmi.interactions.n.*”.

Considerando também a facilidade de desenvolvimento, elementos extras podem ser adicionados ao dicionário, como mencionado no artigo anterior. Nesse ponto, porém, deve-ser ter um grande cuidado com o que introduzir. Primeiro, os nomes desses elementos devem ser escolhidos de modo a evitar qualquer chance de conflito com elementos do padrão, presentes e futuros. E, segundo, a implementação dos mesmos deve ser transparente para os SCOs, ou seja, esses novos elementos não devem ser utilizados na implementação de SCOs (devem ficar restritos à implementação da API) e o uso de um SCO não deve depender dos mesmos, o que violaria o padrão.

Concluindo, eu acredito que essas recomendações podem evitar alguns problemas na implementação do SCORM em um LMS, garantindo maior flexibilidade e extensibilidade ao mesmo, mesmo implicando em algumas concessões. Como na implementação de qualquer padrão que ainda não tenha atingido uma boa estabilidade, concessões devem ser feitas em alguns locais para garantir um sistema plenamente funcional. Entretanto, elas devem ser feitas de modo a não implicar em uma grande necessidade de manutenção no futuro. Eu acredito que as concessões acima atendam a esse critério.

Espero que esse artigo também tenha ajudado. Em um próximo artigo, alguns detalhes da implementação de um SCO serão tratados.

§ 4 Responses to Implementando SCORM: Construindo a retaguarda"

  • Aline Arielo says:

    Fantástico!
    Uma das poucas pessoas que escreve e escreve bem sobre SCORM no Brasil. Parabéns Ronaldo!

    Vou ler com calma e qualquer coisa posto as dúvidas no nosso grupo:
    implementando-scorm@yahoogrupos.com.br

    Beijos,
    Aline.

  • Ronaldo says:

    Obrigado pelos elogios. Espero que o artigo seja útil. Depois que você ler, gostaria realmente de feedback — principalmente se houver coisas a serem corrigidas.

    Eu tenho um outro enfileirado que não deve demorar muito a aparecer aqui.

  • Luis says:

    Desculpe se sou muito novato no assunto, mas estou implementando SCORM e desenvolvendo um LMS.
    Consegui fazer o SCO receber e enviar informações com a API.
    Mas estou com dúvidas justamente na parte do LMS.
    Como setar o STUDENT_ID e o STUDENT_NAME. Sei que foi isso que tentou explicar, mas realmente não intendi. Afinal, como o valor vai parar na variável, se a função não permite escrever nela?!
    Programo em ASP e essas funcionalidades de JavaScript são novas para mim.

    Desde já, OBRIGADO!

  • Ronaldo says:

    As variáveis que você menciona são somente para leitura, ou seja, o valor das mesmas vem do LMS. Na implementação da API no servidor, esses valores são preenchidos e dispobilizados ao SCO por meio de chamadas da API local.

    A propósito, se você tem mais dúvidas, participe da nossa lista no Yahoo! Groups. É só procurar por “implementando-scorm” na área em Português.

What's this?

You are currently reading Implementando SCORM: Construindo a retaguarda at Superfície Reflexiva.

meta