EDI NG Server Light

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