[Openmark-developers] Architettura
Status: Planning
Brought to you by:
benfy
|
From: Lucio B. <ben...@de...> - 2003-01-05 18:02:34
|
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 |