Difference between revisions of "EDI NG Server Light"
(Created page with "== Premesse == EDI si divide in due componenti principali: * Client javascript * Server Java Il server gira in un container JBoss. La prima considerazione che sorge è che, a...") |
|||
| Line 9: | Line 9: | ||
E' stato un lavoro di poche ore perché mi sono limitato a tradurre la "compilazione" dell'EDIML in XML specifico dei metadati (RNDT, INSPIRE, SensorML, ...). | E' stato un lavoro di poche ore perché mi sono limitato a tradurre la "compilazione" dell'EDIML in XML specifico dei metadati (RNDT, INSPIRE, SensorML, ...). | ||
Non ho pertanto tradotto tutte le altre feature, ad es.: | Non ho pertanto tradotto tutte le altre feature, ad es.: | ||
| − | * gestione delle autorizzazioni dei server GET-IT | + | <blockquote>* gestione delle autorizzazioni dei server GET-IT |
** se la compilazione avviene sul server GET-IT stesso, non vedo il senso di autorizzarlo: la compilazione non usa alcuna risorsa del server centrale | ** se la compilazione avviene sul server GET-IT stesso, non vedo il senso di autorizzarlo: la compilazione non usa alcuna risorsa del server centrale | ||
| + | </blockquote> | ||
Altri punti in cui si distingue la versione light da quella completa sono: | Altri punti in cui si distingue la versione light da quella completa sono: | ||
| + | <blockquote> | ||
* assegnazione degli EDIML id | * assegnazione degli EDIML id | ||
** non avendo un punto centrale di assegnazione degli ''id'' è necessario definire un nuovo sistema per attribuire agli EDIML un uri (risolvibile, quindi, di fatto, un url) univoco | ** non avendo un punto centrale di assegnazione degli ''id'' è necessario definire un nuovo sistema per attribuire agli EDIML un uri (risolvibile, quindi, di fatto, un url) univoco | ||
| Line 18: | Line 20: | ||
* storage delle coppie (EDIML, XML) | * storage delle coppie (EDIML, XML) | ||
** EDI NG server è, da un punto di vista logico, un compilatore: non deve assumersi anche l'onere di fare da repository dei metadati, né sotto forma di XML, né tantomeno sotto forma di EDIML | ** EDI NG server è, da un punto di vista logico, un compilatore: non deve assumersi anche l'onere di fare da repository dei metadati, né sotto forma di XML, né tantomeno sotto forma di EDIML | ||
| + | </blockquote> | ||
In quest'ottica propongo per GET-IT un'architettura, relativa ai soli metadati semantici, leggermente differente da quella attuale. | In quest'ottica propongo per GET-IT un'architettura, relativa ai soli metadati semantici, leggermente differente da quella attuale. | ||
== Architettura proposta == | == Architettura proposta == | ||
| Line 24: | Line 27: | ||
* persistere EDIML per le funzionalità di ''edit'' e ''duplicate'' ('''da subito''') | * persistere EDIML per le funzionalità di ''edit'' e ''duplicate'' ('''da subito''') | ||
* persistere RDF ottenuto dall'EDIML e fornirlo al server centrale sia in modalità ''harvesting'', sia in modalità ''broker'' ('''quando sarà pronto il modello RDF per i metadati''') | * persistere RDF ottenuto dall'EDIML e fornirlo al server centrale sia in modalità ''harvesting'', sia in modalità ''broker'' ('''quando sarà pronto il modello RDF per i metadati''') | ||
| − | [[File:GET-IT_proposed_MD_arch2.png| | + | [[File:GET-IT_proposed_MD_arch2.png|Proposed MD architecture]] |
| + | == Benefici == | ||
| + | I benefici che vedo sono: | ||
| + | * Autonomia dei nodi GET-IT dal punto di vista dei metadati | ||
| + | ** questa autonomia si potrebbe spingere ulteriormente facendo sì che il Triple-Store montato a bordo tenga una ''cache'' delle codelist | ||
| + | * Annullamento del carico sul server centrale | ||
| + | * Maggior facilità di installazione per chi scarica da GitHub | ||
| + | ** dal punto di vista del codice: '''conterrebbe solo il codice necessario alla compilazione dell'EDIML''' | ||
| + | ** dal punto di vista della disponibilità di container: '''Tomcat è molto più diffuso di JBoss''' | ||
Latest revision as of 19:16, 3 March 2015
Premesse
EDI si divide in due componenti principali:
- Client javascript
- Server Java
Il server gira in un container JBoss. La prima considerazione che sorge è che, avendo GET-IT un Tomcat installato, sarebbe possibile avere un EDI server su ciascun server GET-IT, alleggerendo così il carico sul server EDI centrale. Ho provveduto a tradurre EDI NG Server per Tomcat (tecnicamente ho dovuto solo eliminare l'uso degli EJB, Enterprise Java Beans, non gestiti da Tomcat). E' stato un lavoro di poche ore perché mi sono limitato a tradurre la "compilazione" dell'EDIML in XML specifico dei metadati (RNDT, INSPIRE, SensorML, ...). Non ho pertanto tradotto tutte le altre feature, ad es.:
* gestione delle autorizzazioni dei server GET-IT
- se la compilazione avviene sul server GET-IT stesso, non vedo il senso di autorizzarlo: la compilazione non usa alcuna risorsa del server centrale
Altri punti in cui si distingue la versione light da quella completa sono:
- assegnazione degli EDIML id
- non avendo un punto centrale di assegnazione degli id è necessario definire un nuovo sistema per attribuire agli EDIML un uri (risolvibile, quindi, di fatto, un url) univoco
- assegnazione degli identificatori dei sensori
- vale la considerazione di cui sopra
- storage delle coppie (EDIML, XML)
- EDI NG server è, da un punto di vista logico, un compilatore: non deve assumersi anche l'onere di fare da repository dei metadati, né sotto forma di XML, né tantomeno sotto forma di EDIML
In quest'ottica propongo per GET-IT un'architettura, relativa ai soli metadati semantici, leggermente differente da quella attuale.
Architettura proposta
La mia proposta consiste nell'aggiunta di un EDI NG Server Light al Tomcat già presente su GET-IT, con l'unico scopo di "compilare" i metadati. Aggiungerei poi un blocco (nell'immagine l'ho chiamato "Semantic Repo Interface"), basato su Apache Jena (https://jena.apache.org), in grado di svolgere i compiti:
- persistere EDIML per le funzionalità di edit e duplicate (da subito)
- persistere RDF ottenuto dall'EDIML e fornirlo al server centrale sia in modalità harvesting, sia in modalità broker (quando sarà pronto il modello RDF per i metadati)
Benefici
I benefici che vedo sono:
- Autonomia dei nodi GET-IT dal punto di vista dei metadati
- questa autonomia si potrebbe spingere ulteriormente facendo sì che il Triple-Store montato a bordo tenga una cache delle codelist
- Annullamento del carico sul server centrale
- Maggior facilità di installazione per chi scarica da GitHub
- dal punto di vista del codice: conterrebbe solo il codice necessario alla compilazione dell'EDIML
- dal punto di vista della disponibilità di container: Tomcat è molto più diffuso di JBoss