[Openmark-developers] Architettura

[Lucio B. <ben...@de...>]

  Ciao,
ancora una volta si tratta di proposte di architettura, ma dato che 
intendo far procedere abbastanza velocemente lo sviluppo, se non 
verranno esposti rapidamente dubbi, controindicazioni, proposte 
alternative, ecc.., OpenMark si basera' su questo. Riprendero' molte 
delle cose del documento architetturale di Ugo, dando pero' delle linee 
guida piu' definite e meno semplicemente investigative.

Credo non ci sia molto da discutere sul fatto che OpenMark sara':

* sviluppato in Java (a meno che in futuro non ci sia l'esigenza di 
integrare librerie sviluppate in altri linguaggi o di sviluppare parti 
in altri linguaggi per ragioni di performance, ma per ora il problema 
non si pone)

* Web-based: sicuramente per la parte di utilizzo per svolgere gli 
assessment, e probabilmente (per quanto possibile) anche per la parte di 
authoring. Per quanto riguarda la parte di authoring potrebbe essere 
pensabile una soluzione "mista": web-based per quanto riguarda le 
funzionalita' di base, e Swing-based per quelle avanzate. In questo modo 
chi scrivera' degli assessment potra' decidere se gli bastano le 
funzionalita' di base (e quindi usare semplicemente il browser web, 
senza bisogno di nessuna installazione), oppure se ha bisogno anche di 
quelle avanzate (e quindi installarsi JRE, applicazione Swing, etc, 
eventualmente usando il Java Web Start).

* XML-intensive: soprattutto per quanto riguarda la definizione e 
gestione degli assessment.

Passando ora ai vari elementi del sistema:

1. Sotto-sistema di authoring: al momento non e' una priorita'. In 
generale il compito principale di questo sottosistema e' quello di 
generare i documenti XML che rappresentano gli assessment. In fase di 
sviluppo e di testing (ed anche per un primo utilizzo da parte nostra) 
puo' essere fatto a mano con un qualunque editor XML. A questo 
proposito, attualmente io uso semplicemente XEmacs con XAE 
(http://xae.sunsite.dk/): se ne conoscete uno migliore che funzioni 
anche in ambiente Linux e possibilmente freeware, fatemelo sapere.

2. Sotto-sistema di pubblicazione:

Come si diceva si tratta sostanzialmente di un sistema di Workflow 
management, con lo scopo di transitare l'utente nei vari passaggi di un 
assessment, composto da domande, messaggi e parti condizionali.
Nella fase iniziale, pur prevedendone l'inserimento, trascurerei le 
parti condizionali, che di solito sono piu' utili per un questionario 
statistico, che non per un test a fini di una valutazione del candidato.
In questo modo, in questa fase riportiamo il flusso ad una semplice sequenza

Sara' Web-based e J2EE-compliant. Il web container quindi e' abbastanza 
indifferente. Personalmente prevedo di utilizzare Tomcat 4.1.x (al 
momento 4.1.17), ma se qualcuno vuole utilizzarne qualche altro sara' 
sicuramente utile. L'architettura della Web application sara' ovviamente 
MVC. A tal fine occorrerebbe qualche tecnologia per facilitare lo 
sviluppo della vista. Ho dato un'occhiata a XForm, ma non mi sembra 
qualcosa di sufficientemente maturo (anche la definizione dello standard 
da parte del W3C e' ancora una RC...figurarsi in che stato si trovano i 
tools). Piuttosto (tanto immaturo per immaturo, almeno andiamo verso 
qualcosa prodotto dal Java Community Process di cui esistera' almeno una 
reference implementation) mi rivolgerei verso le JavaServer Faces 
(http://java.sun.com/j2ee/javaserverfaces/). Anche queste purtroppo sono 
troppo immature: sono ancora una Early Access.
Al momento credo che la soluzione piu' conservativa sia quella di fare 
il tutto un po' artigianalmente, usando semplicemente una tag library 
per evitare di mettere codice nelle JSP. Non credo ci serva niente di 
troppo specializzato, quanto piuttosto qualcosa di piu' generale e 
standard possibile, quindi una buona scelta mi pare JSTL 
(http://jakarta.apache.org/taglibs/doc/standard-doc/intro.html).

3. Persitenza
Non sono ancora completamente convinto dell'utilita' di memorizzare le 
informazioni in un database XML, comunque, al momento, sembra una 
soluzione semplice e molto pratica. Avrei quindi pensato (come suggerito 
da Ugo) di utilizzare Xindice (http://xml.apache.org/xindice/), che e' 
molto semplice da utilizzare e sembra funzionare bene. Dal punto di 
vista applicativo si cerchera' di tenerlo molto isolato, in modo che sia 
semplice sostituirlo se sorgeranno motivi che consiglino di passare ad 
una soluzione piu' potente (ad esempio ad un piu' tradizionale DBMS 
relazionale).

I dati che richiedono persistenza sono principalmente:

* le domande
* gli assessment
* le risposte dei candidati
* le informazioni per l'accesso dei candidati ad uno o piu' assessment

Per quanto riguarda il problema dei link fra le varie risorse (ad 
esempio, fra un assessment e le domande che lo compongono), eviterei di 
usare la funzionalita' sperimentale di Xindice per l'AutoLinking, ma mi 
baserei semplicemente sulla specifica W3C XLink, che e' anche cio' su 
cui si basa (ma con qualche variante) l'autolinking di Xindice. Cio' ci 
permette di rimanere aderenti agli standard, ed eventualmente di 
utilizzare l'autolinking non appena esso cessera' di essere sperimentale 
(non sono comunque convinto della sua utilita', dato che sembra 
semplicemente un sistema per assemblare risorse collegate da un link, ma 
non garantisce consistenza in senso relazionale).

4. Object Model
Dato che la maggiorparte dei dati saranno in formato XML, sono d'accordo 
con Ugo di non appesantire l'applicazione con un OM troppo complesso e 
di utilizzare direttamente la struttura gerarchica XML. Eviterei 
 l'approccio SAX, dato che alla fine costringerebbe ad implementare un 
OM complesso. Mi indirizzerei quindi verso una soluzione DOM-based. Le 
scelte possibili sono amio avviso Xerces, DOM4J e JDOM. Scarterei subito 
quest'ultimo, dato che lo sviluppo e' fermo ad una beta8 da marzo del 
2002. Istintivamente andrei verso Xerces, anche per una questione di 
omogeneita' di provenienza di altre tecnologie (in particolare Xindice), 
che probabilmente ne facilita l'assemblaggio. L'unico dubbio riguarda la 
maggior semplicita' di utilizzo di DOM4J (almeno mi ha dato questa 
impressione) e il benchmark comparativo fra i due presente nel sito di 
DOM4J, che darebbe un leggero vantaggio a quest'ultimo. Per il momento 
scelgo Xerces, se qualcuno ha maggiori esperienze con qualcuno di questi 
prodotti (magari con tutti e due), per favore confuti questa scelta.

---------------------------------

La mia prossima mossa sara' la definizione degli XML Schema per le 
domande e gli assessment. Appena avro' qualcosa di pronto ve lo spedisco.

Cerchero' anche di produrre un diagramma XML che riassuma graficamente 
l'architettura.

A presto
  Lucio