Gemma
Il DS implementato dal gruppo LTW04
Tecnologie Utilizzate
Rails : Framework per sviluppo applicazioni MVC scritto in ruby
- Essendo un framework per lo sviluppo di applicazioni web, pertanto il processo di sviluppo consentito da tale framework è veloce e ricco di strumenti che agevolano lo sviluppatore. Consentendogli di focalizzare la sua attenzione sulle features dell'applicazione senza dover perdere troppo tempo dietro ad eccessive configurazioni
- Linguaggio : il linguaggio ruby è "Bello", rispetto a PHP è apprezzabile per la forza dei suoi costrutti linguistici e per la sua sinteticità (L'unico problema è che avendo uno stile poco diffuso risulta di difficile approccio a molti)
Postgresql: RDBSM usato per tenere l'indice dei matadati su cui effettuare le query
- I DBMS sono fatti apposta e ben ottimizzati per le query, quindi ci è sembrato giusto delegare tale compito a un DBMS
- In SQL da tempo esistono le espressioni regolari per fare ricerche. Questo non è un vantaggio indifferente, siccome in XPath 1.0 manca tale funzionalità manca. Così facendo l'uso delle wildcard (tradotte in regex) è immediato e completo.
- In particolare la scelta che che ha fatto cadere l'attenzione su Postgresql invece che altri, è che tale RDBMS supporta come tipo di dato nativo il vettore (non è standard), consentendoci di memorizzare con facilità quegli attributi del DC che si presentano con una molteplicità maggiore di uno.
Profilo d'esecuzione
Il DS non e' un CGI, viene eseguito come demone di sistema su
http://ruiz.cs.unibo.it:3000/ come da protocollo. Questa caratteristica è propria delle applicazioni sviluppate con rails. Rimane sempre la possibilità di eseguirla come un CGI, ma per tale scopo sarebbe stato necessario uno spazio su golem solo per il DS.
Problemi legati alle scelte fatte
Siccome lo sviluppo di applicazioni con ruby è recente non si dispone di tutte le librerie che altri linguaggi più datati come PHP. Il problema principale è che per ruby non è ancora disponibile un parser validante per XMLSchema, e in binding a librerie esterne che potrebbero sopperire a tale mancanza sono tuttora inaffidabili. Per ovviare a tale problema si è deciso di delagare il compito della validazione a un CGI esterno.
Struttura MVC
Model
- Work : istanza della tabella designata a memorizzare le informazioni sui work
- Expression : istanza della tabella designata a memorizzare le informazioni sulle expression
View
Sono disponibili per ogni interfaccia dei controller una vista che serve da risposta alla loro invocazione. La viste sono degli XML generati dinamicamente per fornire le risposta come da protocollo.
Controller
Il controller di tale DS è formato dai seguenti oggetti
- ApplicationController : è il controller di livello più alto, il suo compito è controllare l'intera applicazione e gestire gli errori interni all'applicazione
- QueryController : ricevere query e di rispondere come da protocollo
- StoreController : salva le schede come da protocollo
- ExpressionsController : rende reperibili le schede tramite URI
Dettagli sulla query
Siccome ci appoggiamo a un RDBMS, il controller della query non deve fare altro che controllare i parametri in GET e riformulare la richiesta in SQL.
Per tale scopo si sono implementati due oggetti
Transposed e
ArrayTransposed (sottoclasse sel primo). Di tale classe se ne istanza un o per ogni elemento DC, tale oggetto provvede a tener traccia della relazione su cui è memorizzato e con che nome. Inoltre detiene un metodo per controllare se il parametro è corretto e uno che genera il frammento di query SQL relativo a quel campo. Il primo oggetto serve per gli elementi DC con cardinalità 1, il secondo per quelli con cardinalità maggiore.
Per semplificare la gestione di queste istanze c'è un Singleton che tiene tali istanze con un mappa
NomeDc ->
TrasposizioneRelazionale.
Per formalizzare il confronto degli attributi multipli è stato necessario implementare una funzione SQL sul DB, che preso una regex controlla se fa match con almeno un elemento di un vettore di stringhe. Tale funzione è stata necessaria in quanto in SQL era possibile formulare solo la query
se una stringa fa mach con almeno un elemen di un vettore di pattern e non viceversa.
La response viene generata dalla view associata a tale controller.
Dettagli sul salvataggio
Come precedentemente detto la validazione è esterna. Per realizzarla si è implementato un semplice CGI a cui passare in POST la scheda da validare, la risposta avviene settando l'header HTTP a 200 per validazione riuscita o a 400 per validazione fallita.
Successivamente si analizza la richiesta e si completano i campi della scheda come da protocollo. L'univocità degli identifier è garantita dal RDBMS che tiene indici incrementali.
Una volta sistemata la scheda si fa una copia dei suoi campi dc sul RDBMS e la si salva su file.
Cataloghi
http://ltw0805.web.cs.unibo.it/cataloghi/gemma.xml
http://ltw0805.web.cs.unibo.it/cataloghi/gemma.html
to top