| Entrambe le parti precedenti la revisioneRevisione precedenteProssima revisione | Revisione precedente |
| utenti:extraway_platform_server:extraway_overview [2023/03/20 16:40] – [Le Struttura SoftWare] chiara.pavanati | utenti:extraway_platform_server:extraway_overview [2023/03/21 11:53] (versione attuale) – [Glossario, Acronimi e Note] chiara.pavanati |
|---|
| ==== Le componenti di terze parti ==== | ==== Le componenti di terze parti ==== |
| |
| Lo schema precedente ha posto in evidenza l'esigenza, nei tre strati software indicati, di avvalersi di strumenti di terze parti quali //Web Servers// e //Java Containers//.\\ | Lo schema precedente ha posto in evidenza l'esigenza, nei tre **strati software** indicati, di avvalersi di **strumenti** di terze parti quali **Web Servers** e **Java Containers**. |
| Il presente manuale non ha la finalità di descrivere come essi vadano installati o gestiti limitandosi, dove necessario, a dare indicazioni su come essi debbano essere configurati. | |
| | Il presente manuale non ha la finalità di descrivere come essi vadano installati o gestiti limitandosi, dove necessario, a dare **indicazioni** su come essi debbano essere configurati. |
| |
| ==== eXtraWay Server ==== | ==== eXtraWay Server ==== |
| === Installazione e Struttura del Server === | === Installazione e Struttura del Server === |
| |
| Nel momento in cui viene stilato questo documento non esiste un vero e proprio //Setup// per le piattaforme Linux/Unix((E' in fase di realizzazione un'installazione dimostrativa per Linux)) diversamente da quanto avviene per le piattaforme Windows. Ad ogni modo, fatta eccezione per i moduli dei due strati precedenti, installare il Server eXtraWay corrisponde a realizzare una struttura di directory e compiere la copia in esse di alcuni files. | Nel momento in cui viene stilato questo documento non esiste un vero e proprio **Setup** per le **piattaforme Linux/Unix** ((E' in fase di realizzazione un'installazione dimostrativa per Linux)) diversamente da quanto avviene per le **piattaforme Windows**. Ad ogni modo, fatta eccezione per i **moduli** dei due strati precedenti, installare il **Server eXtraWay** corrisponde a realizzare una struttura di directory e compiere la copia in esse di alcuni files. |
| |
| La struttura dell software è, di fatto, molto semplice.\\ | La **struttura** del **software** è, di fatto, molto semplice. |
| Di seguito vedremo qual'è lo //standard// adottato anche se le diverse installazioni possono essere soggette a variazioni formali se pur non sostanziali.\\ | |
| Il primo è più importante "distinguo" va fatto tra le diverse versioni di piattaforma Windows e tutte le varie piattaforme Linux/Unix in quanto il percorso di installazione iniziale differisce. | |
| |
| ^ ^ Percorso di installazione | | Di seguito vedremo qual è lo **standard** adottato anche se le diverse **installazioni** possono essere soggette a **variazioni formali** se pur non sostanziali. |
| ^Windows | c:\3di.it\extrawawy\xw | | |
| ^Linux/Unix | /opt/it-3di/extraway/xw | | Il primo è più importante "distinguo" va fatto tra le diverse **versioni** di **piattaforma Windows** e tutte le varie **piattaforme Linux/Unix** in quanto il **percorso** di **installazione iniziale** differisce. |
| |
| Che rispetti o meno questi standard, ciascuna installazione ha un "punto di partenza" dal quale ha origine tutto quanto ne consegue. Identificata questa //directory// diviene semplice identificare tutte le successive parti e poter interpretare il comportamento dell'applicazione.\\ | ^ ^ Percorso di installazione ^ |
| Identificato il punto di origine come ''xw_root'' in esso avremo le seguenti //directory// | ^ Windows | c:\3di.it\extraway\xw | |
| | ^ Linux/Unix | /opt/it-3di/extraway/xw | |
| |
| ^ bin((Questa è l'unica //directory// il cui nome non è obbligatorio. In installazioni molto datate assume alle volte il nome ''prg'' ma in generale può avere un qualsiasi altro nome purché risulti evidente il significato del suo contenuto e sia collocata nel posto giusto)) |Directory contenente tutti gli eseguibili //Platform Dependent//. | | Che rispetti o meno questi standard, ciascuna **installazione** ha un "punto di partenza" dal quale ha **origine** tutto quanto ne consegue. Identificata questa **directory** diviene semplice identificare tutte le successive parti e poter interpretare il comportamento dell'applicazione. |
| | |
| | Identificato il punto di **origine** come ''xw_root'' in esso avremo le seguenti **directory**: |
| | |
| | ^ bin ((Questa è l'unica directory il cui nome non è obbligatorio. In installazioni molto datate assume alle volte il nome ''prg'' ma in generale può avere un qualsiasi altro nome purché risulti evidente il significato del suo contenuto e sia collocata nel posto giusto)) |Directory contenente tutti gli eseguibili Platform Dependent. | |
| ^conf |Directory ove trovano collocazione tutti i files di configurazione dei moduli presenti nella directory **bin**. | | ^conf |Directory ove trovano collocazione tutti i files di configurazione dei moduli presenti nella directory **bin**. | |
| ^context |Directory ove trovano collocazione i files di contesto. | | ^context |Directory ove trovano collocazione i files di contesto. | |
| ^db |Directory ove trovano collocazione naturale gli archivi. In tale directory viene realizzata una ulteriore directory per ciascun archivio((E' buona norma che più archivi non condividano la stessa directory d'origine)) entro la quale vengono collocati tutti i files che lo compongono. Il server è in grado di utilizzare archivi collocati in qualsiasi posizione ma questa è quella che potemmo definire //preferenziale//. | | ^db |Directory ove trovano collocazione naturale gli archivi. In tale directory viene realizzata una ulteriore directory per ciascun archivio((E' buona norma che più archivi non condividano la stessa directory d'origine)) entro la quale vengono collocati tutti i files che lo compongono. Il server è in grado di utilizzare archivi collocati in qualsiasi posizione ma questa è quella che potemmo definire preferenziale. | |
| ^jobs |<color maroon>//Il contenuto di questa directory è funzionale allo svolgimento di attività off-line del server. Non è necessario, in questa sede, scendere nel dettaglio//.</color> | | ^jobs |<color maroon>//Il contenuto di questa directory è funzionale allo svolgimento di attività off-line del server. Non è necessario, in questa sede, scendere nel dettaglio//.</color> | |
| ^logs |Directory ove trovano collocazione tutti i files di log prodotti dal server. | | ^logs |Directory ove trovano collocazione tutti i files di log prodotti dal server. | |
| ^lazy |<color maroon>//Il contenuto di questa directory è funzionale allo svolgimento di attività near-on-line del server. Non è necessario, in questa sede, scendere nel dettaglio//.</color> | | ^lazy |<color maroon>//Il contenuto di questa directory è funzionale allo svolgimento di attività near-on-line del server. Non è necessario, in questa sede, scendere nel dettaglio//.</color> | |
| |
| Esistono altre directory la cui presenza non è obbligatoria ma può dipendere dalla versione del server o dal fatto che le applicazioni su di esso realizzate sfruttino o meno alcune funzionalità. | Esistono altre **directory** la cui presenza non è obbligatoria ma può dipendere dalla **versione** del **server** o dal fatto che le **applicazioni** su di esso realizzate sfruttino o meno alcune funzionalità. |
| |
| ^collect |Directory contenente tutte le //raccolte//, ovvero insiemi di documenti equiparabili a selezioni non volatili di documenti eventualmente provenienti da archivi diversi tra loro. | | ^collect |Directory contenente tutte le raccolte, ovvero insiemi di documenti equiparabili a selezioni non volatili di documenti eventualmente provenienti da archivi diversi tra loro. | |
| ^conversion |<color maroon>//Il contenuto di questa directory è funzionale allo svolgimento di attività di conversione di files, estrazione del testo per l'alimentazione dei vocabolari, realizzazione di miniature di immagini o files .PDF a partire da un altro tipo documentale. Non è necessario, in questa sede, scendere nel dettaglio//.</color> | | ^conversion |<color maroon>Il contenuto di questa directory è funzionale allo svolgimento di attività di conversione di files, estrazione del testo per l'alimentazione dei vocabolari, realizzazione di miniature di immagini o files .PDF a partire da un altro tipo documentale. Non è necessario, in questa sede, scendere nel dettaglio.</color> | |
| ^tmp |Alternativamente alla directory di sistema destinata ai files temporanei, essi possono essere indirizzati in questa collocazione. | | ^tmp |Alternativamente alla directory di sistema destinata ai files temporanei, essi possono essere indirizzati in questa collocazione. | |
| ^wd |Directory per lo svolgimento di attività di //importazione documenti//. Essa può essere collocata in altra posizione ma, come per il caso della directory ''db'' questa è la sua posizione naturale. | | ^wd |Directory per lo svolgimento di attività di importazione documenti. Essa può essere collocata in altra posizione ma, come per il caso della directory ''db'' questa è la sua posizione naturale. | |
| |
| === Come opera il server eXtraWay === | === Come opera il server eXtraWay === |
| |
| Indipendentemente dal sistema operativo sul quale si installeranno i programmi della Piattaforma eXtraWay, c'è un'importante aspetto da conoscere per meglio comprendere come eXtraWay Server operi.\\ | Indipendentemente dal **sistema operativo** sul quale si installeranno i **programmi** della **Piattaforma eXtraWay**, c'è un'importante aspetto da conoscere per meglio comprendere come **eXtraWay Server** operi. |
| L'esecuzione del programma, manualmente o sotto forma di servizio, avvia un'istanza del server detta //Master//. Essa offre un servizio su una porta Socket nota((4859 per default)) e dialoga con //Client// che condividano con esso un protocollo personalizzato. In seguito l'argomento verrà approfondito parlando del //Broker//.\\ | |
| L'istanza //Master// attende che venga richiesta una connessione al server da parte di un client. Quanto questo avviene l'istanza //Master// produce un clone di se stesso((seguendo metodiche diverse da sistema operativo Windows a sistema operativo Linux/Unix)) che è un processo figlio detto anche //Slave//. E' questo il processo che, effettivamente, dialoga col client sino a quando il client non avrà più bisogno dei suoi servigi.\\ | L'esecuzione del programma, manualmente o sotto forma di servizio, avvia un'**istanza** del **server** detta **Master**. Essa offre un servizio su una porta **Socket** nota ((4859 per default)) e dialoga con **Client** che condividano con esso un **protocollo personalizzato**. In seguito l'argomento verrà approfondito parlando del **Broker**. |
| Le attività di generazione di processi //Slave// non sono incontrollate: il server //Master// è sottoposto ad una [[#Registrazione del Server|registrazione]] che stabilisce una tantum quante istanze, ovvero quante connessioni, siano consentite. Un server //Master// non può generare più server //Slave// delle connessioni per le quali è stato registrato, il tentativo di connettersi ad un server che abbia esaurito le proprie connessioni scaturirà in un errore e la connessione verà negata.\\ \\ La registrazione è principalmente finalizzata ad identificare alcuni metadati, ad esempio l'organizzazione che gestirà i dati dei DB, che caratterizzano i dati dei DB stessi in forma di //Processing Instructions//. Essa ha inoltre lo scopo di proporzionare il massimo numero di istanze di server eXtraWay alle capacità dell'HardWare in cui esso opera per evitare un proliferare incontrollato di istanze con un conseguente degrado prestazionale.\\ In pratica, tramite la registrazione, si mette sotto controllo l'uso che si farà del server. | |
| | L'**istanza Master** attende che venga richiesta una **connessione** al server da parte di un **client**. Quanto questo avviene l'**istanza Master** produce un **clone** di se stesso ((seguendo metodiche diverse da sistema operativo Windows a sistema operativo Linux/Unix)) che è un **processo figlio** detto anche **Slave**. E' questo il processo che, effettivamente, dialoga col **client** sino a quando il client non avrà più bisogno dei suoi servigi. |
| | |
| | Le attività di **generazione** di **processi Slave** non sono incontrollate: il **server Master** è sottoposto ad una ''[[#Registrazione del Server|registrazione]]'' che stabilisce una tantum quante **istanze**, ovvero quante **connessioni**, siano consentite. Un **server Master** non può generare più server **Slave** delle connessioni per le quali è stato registrato, il tentativo di connettersi ad un **server** che abbia esaurito le proprie connessioni scaturirà in un **errore** e la connessione verrà negata. |
| | |
| | La **registrazione** è principalmente finalizzata ad identificare alcuni **metadati**, ad esempio l'organizzazione che gestirà i **dati** dei **DB**, che caratterizzano i dati dei DB stessi in forma di **Processing Instructions**. Essa ha inoltre lo scopo di proporzionare il massimo numero di **istanze** di **server eXtraWay** alle capacità dell'**hardware** in cui esso opera per evitare un proliferare incontrollato di istanze con un conseguente degrado prestazionale. |
| | |
| | In pratica, tramite la **registrazione**, si mette sotto controllo l'**uso** che si farà del **server**. |
| |
| === Il Servizio eXtraWay === | === Il Servizio eXtraWay === |
| |
| Quale che sia stata la procedura di installazione di eXtraWay così come delle componenti degli altri due strati software coinvolti dalla Piattaforma, è normalmente necessario che essi operino come servizi, ovvero che siano eseguiti automaticamente dalla macchina e non influenzati dalle attività di un singolo operatore.\\ | Quale che sia stata la procedura di **installazione** di **eXtraWay** così come delle componenti degli altri due **strati software** coinvolti dalla piattaforma, è normalmente necessario che essi operino come **servizi**, ovvero che siano eseguiti automaticamente dalla **macchina** e non influenzati dalle **attività** di un singolo operatore. |
| Se è stata effettuata la procedura di installazione in Windows il servizio noto come "eXtraWay Server" sarà stato regolarmente installato ed avviato. Discorso analogo può essere fatto per l'installazione Linux/Unix che spiega come impostare l'avvio e lo spegnimento del servizio((tramite /etc/init.d o agendo sui //run level// a seconda del sistema operativo)).\\ | |
| Vediamo comunque come avviare o interrompere il servizio "eXtraWay Server" ovvero come avviare manualmente i moduli sulle diverse piattaforme. | Se è stata effettuata la procedura di **installazione** in **Windows** il **servizio** noto come **"eXtraWay Server"** sarà stato regolarmente installato ed avviato. Discorso analogo può essere fatto per l'installazione **Linux/Unix** che spiega come impostare l'avvio e lo spegnimento del servizio ((tramite ''/etc/init.d'' o agendo sui **run level** a seconda del sistema operativo)). |
| | |
| | Vediamo comunque come avviare o interrompere il **servizio "eXtraWay Server"** ovvero come avviare manualmente i **moduli** sulle diverse **piattaforme**. |
| |
| == Piattaforma Windows == | == Piattaforma Windows == |
| |
| Per l'avvio e l'interruzione del "servizio eXtraWay" se esso è stato regolarmente installato come tale, non sono necessarie particolari attività se non l'utilizzo dei //Servizi// di Windows nell'ambito degli //Strumenti di Amministrazione Comune//.\\ | Per l'avvio e l'interruzione del **"servizio eXtraWay"** se esso è stato regolarmente installato come tale, non sono necessarie particolari **attività** se non l'utilizzo dei **Servizi** di **Windows** nell'ambito degli **Strumenti** di **Amministrazione Comune**. |
| Differente discorso va fatto se il servizio non è stato ancora installato e si vuole procedere alla sua installazione ed esecuzione o se, all'opposto, si desidera eseguire manualmente eXtraWay Server.\\ | |
| | Differente discorso va fatto se il **servizio** non è stato ancora installato e si vuole procedere alla sua **installazione** ed esecuzione o se, all'opposto, si desidera eseguire manualmente **eXtraWay Server**. |
| | |
| ** Installazione del Servizio eXtraWay ** | ** Installazione del Servizio eXtraWay ** |
| Diversamente dalle precedenti distribuzioni dei server eXtraWay, l'installazione come servizio viene ora effettuata direttamente con parametri sulla riga di comando del server stesso. In sostanza sarà sufficiente eseguire da un qualsiasi //prompt dei comandi// una delle seguenti operazioni. | |
| | Diversamente dalle precedenti **distribuzioni** dei **server eXtraWay**, l'installazione come servizio viene ora effettuata direttamente con **parametri** sulla riga di comando del **server** stesso. In sostanza sarà sufficiente eseguire da un qualsiasi **prompt** dei **comandi** una delle seguenti operazioni. |
| ^ Operazione ^ Comportamento ^ | ^ Operazione ^ Comportamento ^ |
| ^ xw.exe -service_install | Installa (ed avvia) il server eXtraWay come servizio. | | ^ xw.exe -service_install | Installa (ed avvia) il server eXtraWay come servizio. | |
| ^ xw.exe -service_uninstall | Disinstalla (fermando se attivo) il servizio del server eXtraWay. | | ^ xw.exe -service_uninstall | Disinstalla (fermando se attivo) il servizio del server eXtraWay. | |
| |
| Tutti i comandi suddetti reagiscono anche al parametro ''-p<numero_porta>'' consentendo in questo modo di installare più istanze distinte di server operanti su porte socket diverse. | Tutti i **comandi** suddetti reagiscono anche al **parametro** ''-p<numero_porta>'' consentendo in questo modo di installare più **istanze** distinte di server operanti su porte **socket** diverse. |
| | |
| | Una volta installato come servizio, anche se il **server** consente l'avvio e l'interruzione da riga di comando, si rimanda ai **comandi** del **pannello Servizi** di **Windows**. |
| |
| Una volta installato come servizio, anche se il server consente l'avvio e l'interruzione da riga di comando, si rimanda ai comandi del pannello //Servizi// di Windows.\\ | Per quanto siano richiesti **diritti amministrativi** per poter installare eXtraWay, non è necessario che al servizio vengano dati diritti particolari ne tanto meno ai file presenti su disco cui esso dovrà fare accesso. |
| Per quanto siano richiesti diritti amministrativi per poter installare eXtraWay, non è necessario che al servizio vengano dati diritti particolari ne tanto meno ai file presenti su disco cui esso dovrà fare accesso. | |
| |
| ** Avvio Manuale ** | ** Avvio Manuale ** |
| |
| Per quanto concerne l'avvio manuale del modulo eXtraWay Server sarà sufficiente, da //Esplora Risorse//, accedere alla directory //bin// degli eseguibili e fare un doppio click sul modulo denominato ''xw.exe''. A quest'azione seguirà l'avvio del server dopo una breve pausa, di circa 20 secondi, necessaria al modulo a verificare di non essere stato eseguito come servizio.\\ | Per quanto concerne l'**avvio manuale** del **modulo eXtraWay Server** sarà sufficiente, da ''Esplora Risorse'', accedere alla **directory** ''bin'' degli eseguibili e fare un doppio click sul **modulo** denominato ''xw.exe'' . A quest'azione seguirà l'**avvio** del **server** dopo una breve **pausa**, di circa 20 secondi, necessaria al modulo a verificare di non essere stato eseguito come servizio. |
| Alternativamente esso può essere eseguito da un qualsiasi //Command Prompt// aggiungendo alcuni parametri su riga di comando. Quelli più comuni sono | |
| |<color red>-noserv</color>|Indica al server eXtraWay che non deve cercare il dialogo con il //Service Control Manager// di Windows. Questo comporta l'avvio immediato del server senza l'attesa di 20 secondi descritta precedentemente. | | Alternativamente esso può essere eseguito da un qualsiasi **Command Prompt** aggiungendo alcuni **parametri** su **riga** di **comando**. Quelli più comuni sono |
| | |<color red>-noserv</color>|Indica al server eXtraWay che non deve cercare il dialogo con il Service Control Manager di Windows. Questo comporta l'avvio immediato del server senza l'attesa di 20 secondi descritta precedentemente. | |
| |<color red>-p<numero></color>|Indica al server eXtraWay di avviarsi e porsi in ascolto su una specifica porta socket differente da quella di default((4859)). | | |<color red>-p<numero></color>|Indica al server eXtraWay di avviarsi e porsi in ascolto su una specifica porta socket differente da quella di default((4859)). | |
| |
| ** Gestione del Modulo ** | ** Gestione del Modulo ** |
| |
| Quale che sia stato il metodo per mezzo del quale è stato posto in esecuzione il Server eXtraWay esso darà traccia evidente della propria presenza nella Barra dei Processi((La cosa dovrebbe essere evidente sia eseguendo manualmente il server sia eseguendolo sotto forma di servizio. Se però si accede ad una postazione di lavoro tramite //Remote Desktop// l'icona del server qualora avviato come servizio non sarà visibile. Per le attività di verifica o di registrazione sarà necessario eseguirlo manualmente)). La sua presenza è resa manifesta dalla sua icona nella //Tray Bar//. | Quale che sia stato il metodo per mezzo del quale è stato posto in esecuzione il **Server eXtraWay** esso darà traccia evidente della propria presenza nella **Barra** dei **Processi** ((La cosa dovrebbe essere evidente sia eseguendo manualmente il server sia eseguendolo sotto forma di servizio. Se però si accede ad una postazione di lavoro tramite Remote Desktop l'icona del server qualora avviato come servizio non sarà visibile. Per le attività di verifica o di registrazione sarà necessario eseguirlo manualmente)). La sua **presenza** è resa manifesta dalla sua **icona** nella **Tray Bar**. |
| \\ | \\ |
| {{ :documentazione_3di:extraway_os:taskbar.jpg |Icona nella Tray Bar}} | {{ :documentazione_3di:extraway_os:taskbar.jpg |Icona nella Tray Bar}} |
| \\ | \\ |
| Ponendo il mouse sul simbolo presente nella //Tray Bar// verrà mostrato l'ID univoco del processo in esecuzione((Se il Server eXtraWay viene eseguito su una porta socket diversa dallo standard, oltre all'ID univoco del processo verrà mostrato anche il numero di porta sulla quale esso opera)). | Ponendo il **mouse** sul simbolo presente nella **Tray Bar** verrà mostrato l'**ID univoco** del **processo** in **esecuzione** ((Se il Server eXtraWay viene eseguito su una porta socket diversa dallo standard, oltre all'ID univoco del processo verrà mostrato anche il numero di porta sulla quale esso opera)). |
| |
| Facendo "click" su tale simbolo verrà mostrato un dialogo di informazioni come il seguente | Facendo **click** su tale simbolo verrà mostrato un dialogo di **informazioni** come il seguente: |
| \\ | \\ |
| {{ :documentazione_3di:extraway_os:xwinfo2.png |Stato del Server}} | {{ :documentazione_3di:extraway_os:xwinfo2.png |Stato del Server}} |
| \\ | \\ |
| Ad esso corrispondono informazioni che verranno spiegate meglio in un apposito paragrafo come il significato del numero di serie [[#Informazioni sul Server|numero di serie]] così come [[#Registrazione del Server|la registrazione]] del server. Il pulsante "Termina" consente l'interruzione del server principale e, con esso, di tutti i processi figli. Se il server è stato eseguito come servizio di Windows questo tasto è disabilitato perché gli interventi di avvio ed interruzione del servizio devono essere compiuti dal //Service Control Manager//.\\ | Ad esso corrispondono **informazioni** che verranno spiegate meglio in un apposito **paragrafo** come il significato del **numero** di **serie** ''[[#Informazioni sul Server|numero di serie]]'' così come ''[[#Registrazione del Server|la registrazione]]'' del server. Il **pulsante** ''Termina'' consente l'**interruzione** del **server principale** e, con esso, di tutti i processi figli. Se il server è stato eseguito come servizio di **Windows** questo tasto è disabilitato perché gli interventi di avvio ed interruzione del servizio devono essere compiuti dal **Service Control Manager**. |
| Utilizzando invece il bottone "Connections" verrà visualizzato l'elenco dei processi figli, indicando per ciascuno di essi l'utente che lo sta utilizzando, l'IP Address dal quale sta operando e da quanto tempo.\\ | |
| | Utilizzando invece il **bottone** ''Connections'' verrà visualizzato l'**elenco** dei **processi figli**, indicando per ciascuno di essi l'utente che lo sta utilizzando, l'**IP Address** dal quale sta operando e da quanto tempo. |
| {{ :documentazione_3di:extraway_os:connections.jpg |}} | {{ :documentazione_3di:extraway_os:connections.jpg |}} |
| \\ | \\ |
| Tramite questo dialogo è possibile interrompere le attività di quell'utente provocando la chiusa del processo figlio. | Tramite questo dialogo è possibile interrompere le **attività** di quell'**utente** provocando la chiusa del **processo figlio**. |
| |
| == Piattaforma Linux/Unix == | == Piattaforma Linux/Unix == |
| |
| Diversamente dalla piattaforma Windows l'installazione su piattaforma Unix/Linux richiede qualche accorgimento di sicurezza in più.\\ | Diversamente dalla piattaforma Windows l'installazione su **piattaforma Unix/Linux** richiede qualche **accorgimento** di **sicurezza** in più. |
| In primo luogo è fortemente sconsigliato lasciare che eXtraWay Server venga eseguito con diritti dell'utente ''root''. E' prassi comune, nonché buona norma, creare un utente, solitamente ''extraway'', cui verrà dato il compito di far eseguire eXtraWay Server. Tutti gli archivi da esso gestiti dovranno appartenere allo stesso utente. | |
| | In primo luogo è fortemente sconsigliato lasciare che **eXtraWay Server** venga eseguito con **diritti** dell'**utente** ''root''. E' prassi comune, nonché buona norma, creare un **utente**, solitamente ''extraway'', cui verrà dato il compito di far eseguire eXtraWay Server. Tutti gli **archivi** da esso gestiti dovranno appartenere allo stesso utente. |
| ** Installazione del Servizio eXtraWay ** | ** Installazione del Servizio eXtraWay ** |
| L'installazione di eXtraWay Server come servizio richiede di utilizzare lo script //xwctl//(())direttamente in /etc/init.d ovvero /etc/rc.d a seconda del sistema operativo. Sarà sufficiente creare un //symlink// allo script presente nella directory dei binari ed utilizzato anche per l'avvio manuale del server.\\ | |
| Una volta compiuti questi passi si dovrà prestare attenzione al file di configurazione dello script ''xwctl'', denominato ''xwctl.conf'' e presente nella directory ''conf'' dei files di configurazione.\\ | L'installazione di eXtraWay Server come servizio richiede di utilizzare lo **script** //xwctl//(())direttamente in ''/etc/init.d'' ovvero ''/etc/rc.d'' a seconda del sistema operativo. Sarà sufficiente creare un **symlink** allo **script** presente nella **directory** dei binari ed utilizzato anche per l'avvio manuale del server. |
| In tale file vanno dichiarate le impostazioni di partenza del server eXtraWay. Il file è composto da una serie di righe sotto forma di ''etichetta=valore'' precedute dal simbolo '#' che le commenta, ovvero le rende inefficaci. Ciascuna riga riporta il valore di default o un'indicazione sul contenuto da impostare. Di seguito i valori che può essere necessario compilare: | |
| | Una volta compiuti questi passi si dovrà prestare attenzione al **file** di **configurazione** dello **script** ''xwctl'', denominato ''xwctl.conf'' e presente nella **directory** ''conf'' dei files di configurazione. |
| | |
| | In tale file vanno dichiarate le **impostazioni** di partenza del **server eXtraWay**. Il file è composto da una serie di **righe** sotto forma di ''etichetta=valore'' precedute dal **simbolo** ''#'' che le commenta, ovvero le rende inefficaci. Ciascuna riga riporta il **valore** di **default** o un'indicazione sul **contenuto** da impostare. Di seguito i **valori** che può essere necessario compilare: |
| |
| ^xw_user |Utente con il quale viene eseguito extraway Server, che sia un servizio o eseguito manualmente((default: extraway)) | | ^xw_user |Utente con il quale viene eseguito extraway Server, che sia un servizio o eseguito manualmente((default: extraway)) | |
| ** Avvio Manuale ** | ** Avvio Manuale ** |
| |
| L'avvio manuale del modulo avviene per mezzo dello stesso script //xwclt// indirettamente utilizzato per l'avvio sotto forma di servizio. Eseguendo lo script da //command prompt// si può regolare l'attività della piattaforma eXtraWay. | L'avvio manuale del modulo avviene per mezzo dello stesso **script** ''xwclt'' indirettamente utilizzato per l'**avvio** sotto forma di **servizio**. Eseguendo lo **script** da **command prompt** si può regolare l'attività della piattaforma eXtraWay. |
| ^./xwctl start |Richiede l'avvio del server eXtraWay((Il server esegue, se presente nell'installazione, anche il modulo xwls, ovvero eXtraWay Log Server. Può avviare anche altri moduli ma in tal caso essi sono fuori dal controllo dello script di avvio/arresto)) sulla porta stabilita. Se il servizio è già attivo lo script darà errore | | ^./xwctl start |Richiede l'avvio del server eXtraWay((Il server esegue, se presente nell'installazione, anche il modulo xwls, ovvero eXtraWay Log Server. Può avviare anche altri moduli ma in tal caso essi sono fuori dal controllo dello script di avvio/arresto)) sulla porta stabilita. Se il servizio è già attivo lo script darà errore | |
| ^./xwctl stop |Richiede l'interruzione del server eXtraWay. Unitamente al server interrompe anche il modulo xwls((eXtraWay Log Server)) | | ^./xwctl stop |Richiede l'interruzione del server eXtraWay. Unitamente al server interrompe anche il modulo xwls((eXtraWay Log Server)) | |
| ** Gestione del Modulo ** | ** Gestione del Modulo ** |
| |
| Oltre a quanto indicato nel precedente paragrafo sono disponibili i seguenti comandi. | Oltre a quanto indicato nel **precedente paragrafo** sono disponibili i seguenti **comandi**. |
| ^./xwctl version |Mostra il numero di versione di tutti i moduli binari presenti nella directory, che si tratti di moduli eseguibili o librerie dinamiche((files con estensione .so)). Particolarmente utile per verificare che tutti i moduli coinvolti siano di versioni compatibili tra loro | | ^./xwctl version |Mostra il numero di versione di tutti i moduli binari presenti nella directory, che si tratti di moduli eseguibili o librerie dinamiche((files con estensione .so)). Particolarmente utile per verificare che tutti i moduli coinvolti siano di versioni compatibili tra loro | |
| |
| Per ottenere altre indicazioni sul server eXtraWay sarà invece necessario richimarlo direttamente eseguendo il comando | Per ottenere altre **indicazioni** sul **server eXtraWay** sarà invece necessario richiamarlo direttamente eseguendo il **comando**: |
| | |
| | <code> |
| ./xw -v | ./xw -v |
| che propone una serie di informazioni sul server, informazioni che saranno chiarite meglio nel prossimo paragrafo. | </code> |
| | |
| | che propone una serie di **informazioni** sul **server**, informazioni che saranno chiarite meglio nel prossimo paragrafo. |
| |
| == Informazioni sul Server == | == Informazioni sul Server == |
| |
| Il server mette a disposizione degli utenti una serie di informazioni inerenti | Il **server** mette a disposizione degli **utenti** una serie di **informazioni** inerenti: |
| ^Numero di Versione |Il numero di versione del server. Consente di identificarne le funzionalità e la compatibilità con altri moduli binari o librerie dinamiche | | ^Numero di Versione |Il numero di versione del server. Consente di identificarne le funzionalità e la compatibilità con altri moduli binari o librerie dinamiche | |
| ^Numero di Serie |Quando intercorrono rapporti diretto con 3D Informatica questo numero viene assegnato al fine di rendere più semplice l'identificazione delle installazioni compiute, specialmente se lo stesso utente ne ha diverse. Affiancato a tale valore, separato da un trattino, viene normalmente presentato il numero delle istanze per le quali si è compiuta [[#Registrazione del server|la registrazione]]. La registrazione può essere assente o prevedere particolari limitazioni che verranno chiarite meglio in seguito | | ^Numero di Serie |Quando intercorrono rapporti diretto con 3D Informatica questo numero viene assegnato al fine di rendere più semplice l'identificazione delle installazioni compiute, specialmente se lo stesso utente ne ha diverse. Affiancato a tale valore, separato da un trattino, viene normalmente presentato il numero delle istanze per le quali si è compiuta [[#Registrazione del server|la registrazione]]. La registrazione può essere assente o prevedere particolari limitazioni che verranno chiarite meglio in seguito | |
| == Registrazione del Server == | == Registrazione del Server == |
| |
| La registrazione del server consiste nello stabilire il numero massimo di connessioni che si intende far supportare da questo server proporzionandolo alla portata dell'HardWare disponibile e del servizio che si intende fornire. Tale operazione prevede quindi anche la registrazione di dati a corredo riferiti all'organizzazione che compie la registrazione, tali dati completeranno i metadati assegnati alle singole unità informative entro i DB eXtraWay prodotti e gestiti.\\ | La **registrazione** del **server** consiste nello stabilire il **numero** massimo di **connessioni** che si intende far supportare da questo **server** proporzionandolo alla portata dell'**hardware** disponibile e del **servizio** che si intende fornire. Tale operazione prevede quindi anche la **registrazione** di **dati** a corredo riferiti all'organizzazione che compie la **registrazione**, tali dati completeranno i **metadati** assegnati alle singole **unità informative** entro i **DB eXtraWay** prodotti e gestiti. |
| La registrazione dev'essere fatta una prima volta per avere un corretto comportamento del server e può essere effettuata nuovamente in particolar modo per modificare il numero di connessioni accettate.\\ Essa si compie come segue: | |
| | La **registrazione** dev'essere fatta una prima volta per avere un corretto comportamento del **server** e può essere effettuata nuovamente in particolar modo per modificare il **numero** di **connessioni accettate**. |
| | |
| | Essa si compie come segue: |
| ^Windows |Premendo il tasto "Registration" dal dialogo mostrato precedentemente | | ^Windows |Premendo il tasto "Registration" dal dialogo mostrato precedentemente | |
| ^Linux/Unix |Eseguendo il server col comando ''./xw -r'' | | ^Linux/Unix |Eseguendo il server col comando ''./xw -r'' | |
| |
| In ambo i casi verrà richiesto di impostare il numero di connessioni da abilitare((Si noti che il concetto di ''connessioni illimitate'' corrisponde alla cifra 998, non ha senso andare oltre e sovente un valore di 20/30 è più che adeguato)). | In ambo i **casi** verrà richiesto di impostare il **numero** di **connessioni** da abilitare ((Si noti che il concetto di ''connessioni illimitate'' corrisponde alla cifra 998, non ha senso andare oltre e sovente un valore di 20/30 è più che adeguato)). |
| A seguito di questa impostazione verranno richieste, nell'ordine | |
| * Numero di serie | |
| * Nome utente | |
| * Nome Organizzazione o Società | |
| |
| Al completamento di questa procedura l'istanza //Master// del server eXtraWay per mezzo del quale è stata effettuata la registrazione si chiuderà((La versione Windows mostra un //message box// che conferma la corretta registrazione)) e le impostazioni sarnno attiva al prossimo riavvio((Si noti che solo per la piattaforma Windows qualora il server sia installato ed eseguito come Servizio l'interruzione ed il riavvio devono avvenire manualmente tramite il //Service Control Manager//)). | A seguito di questa **impostazione** verranno richieste, nell'**ordine**: |
| |
| E' importante osservare che lo spostamento dell'installazione o i cambiamenti delle condizioni della macchina possono impattare sulla registrazione((In particolare, sulle piattaforme Linux/Unix, il variare dell'IP Address primario della macchina causa la perdita della registrazione della stessa)). | * **Numero** di **serie**; |
| | * **Nome utente**; |
| | * **Nome Organizzazione o Società**. |
| | |
| | Al completamento di questa procedura l'**istanza** ''Master'' del **server eXtraWay** per mezzo del quale è stata effettuata la **registrazione** si chiuderà ((La versione Windows mostra un message box che conferma la corretta registrazione)) e le **impostazioni** saranno attiva al prossimo riavvio ((Si noti che solo per la piattaforma Windows qualora il server sia installato ed eseguito come Servizio l'interruzione ed il riavvio devono avvenire manualmente tramite il Service Control Manager)). |
| | |
| | E' importante osservare che lo **spostamento** dell'**installazione** o i **cambiamenti** delle **condizioni** della **macchina** possono impattare sulla **registrazione** ((In particolare, sulle piattaforme Linux/Unix, il variare dell'IP Address primario della macchina causa la perdita della registrazione della stessa)). |
| |
| == Componenti aggiuntive == | == Componenti aggiuntive == |
| |
| Come precedentemente accennato, le componenti aggiuntive non sono altro che librerie dinamiche delle quali si avvale eXtraWay Server per svolgere attività supplementari a quelle normalmente compiute. Esse devono essere presenti nella directory dei binari e devono avere un nome noto con l'estensione prevista dal sistema operativo((.dll per Windows, .so per LInux/Unix)).\\ | Come precedentemente accennato, le **componenti aggiuntive** non sono altro che **librerie dinamiche** delle quali si avvale **eXtraWay Server** per svolgere attività supplementari a quelle normalmente compiute. Esse devono essere presenti nella **directory** dei **binari** e devono avere un **nome** noto con l'**estensione** prevista dal **sistema operativo** ((.dll per Windows, .so per LInux/Unix)). |
| |
| Di seguito una sintetica elencazione delle librerie dinamiche disponibili e del loro compito, che verrà dettagliato in seguito. | Di seguito una sintetica **elencazione** delle **librerie dinamiche disponibili** e del loro compito, che verrà dettagliato in seguito. |
| |
| ^libSQL2 |Consente al server eXtraWay di eseguire alcune semplici attività di ricerca ed updare con una sintassi SQL appositamente //mappata// sulle funzionalità del server | | ^libSQL2 |Consente al server eXtraWay di eseguire alcune semplici attività di ricerca ed updare con una sintassi SQL appositamente mappata sulle funzionalità del server | |
| ^liburl |Componente dell'estensione <color maroon>libxcrwl</color>| | ^liburl |Componente dell'estensione <color maroon>libxcrwl</color>| |
| ^libxcrwl |Estensione ''Crawler''. Consente di utilizzare eXtraWay Server, configurando un apposito archivio, come un crawler che interroga fonti dati pubbliche e pagina internet per alimentare un archivio con tali contenuti, una sorta di base di conoscenza | | ^libxcrwl |Estensione ''Crawler''. Consente di utilizzare eXtraWay Server, configurando un apposito archivio, come un crawler che interroga fonti dati pubbliche e pagina internet per alimentare un archivio con tali contenuti, una sorta di base di conoscenza | |
| ^libxw2occi |Componente necessaria all'interfacciamento con //Oracle RDBMS Server// per usufruire di esso come repository alternativo al ''file system'' | | ^libxw2occi |Componente necessaria all'interfacciamento con //Oracle RDBMS Server// per usufruire di esso come repository alternativo al ''file system'' | |
| |
| Oltre a queste componenti aggiuntive il server prevede che si possano dichiarare librerie dinamiche atte a svolgere funzioni specifiche correlate ad uno specifico archivio. Di esse si parlerà più avanti. | Oltre a queste **componenti** aggiuntive il **server** prevede che si possano dichiarare **librerie dinamiche** atte a svolgere **funzioni specifiche** correlate ad uno specifico **archivio**. Di esse si parlerà più avanti. |
| |
| ==== Dettaglio della Struttura ==== | ==== Dettaglio della Struttura ==== |
| === Directory 'bin' === | === Directory 'bin' === |
| |
| La directory 'bin' contiene gli eseguibili della piattaforma eXtraWay. Essi variano a seconda del sistema operativo ma hanno tutti la stessa funzione e comportamento. I moduli, infatti, garantiscono la piena portabilità degli archivi anche tra sistemi operativi solitamente ben poco compatibili. In sostanza, quindi, questa directory è la sola che richiede la sostituzione integrale del contenuto qualora s i intendesse migrare un'installazione da un server ad uno differente.\\ | La **directory** ''bin'' contiene gli **eseguibili** della piattaforma **eXtraWay**. Essi variano a seconda del **sistema operativo** ma hanno tutti la stessa funzione e comportamento. I **moduli**, infatti, garantiscono la piena **portabilità** degli **archivi** anche tra sistemi operativi solitamente ben poco compatibili. In sostanza, quindi, questa **directory** è la sola che richiede la **sostituzione** integrale del contenuto qualora si intendesse migrare un'**installazione** da un **server** ad uno differente. |
| I principali moduli contenuti sono di seguito descritti: | |
| | I **principali moduli** contenuti sono di seguito descritti: |
| |
| ^Modulo((Il modulo ha estensione //.exe// nel caso degli eseguibili Windows, //.dll// nel caso di librerie dinamiche Windows e //.so// nel caso di librerie dinamiche di altre piattaforme)) ^Funzione ^ | ^Modulo((Il modulo ha estensione //.exe// nel caso degli eseguibili Windows, //.dll// nel caso di librerie dinamiche Windows e //.so// nel caso di librerie dinamiche di altre piattaforme)) ^Funzione ^ |
| ^msg.dat\\ xw.rc |Files di risorse (stringhe e simili) necessarie al Server eXtraWay. | | ^msg.dat\\ xw.rc |Files di risorse (stringhe e simili) necessarie al Server eXtraWay. | |
| |
| Ad essi si aggiungono questi ulteriori moduli supplementari: | Ad essi si aggiungono questi ulteriori **moduli supplementari**: |
| |
| ^Modulo ^Funzione ^ | ^Modulo ^Funzione ^ |
| === Directory 'conf' === | === Directory 'conf' === |
| |
| Directory che ospita i files di configurazione del server eXtraWay e di ogni altro modulo del sistema.\\ | **Directory** che ospita i **files** di **configurazione** del **server eXtraWay** e di ogni altro **modulo** del sistema. |
| <color grey>Documentazione in allestimento</color> | |
| | <color grey> [ Documentazione in allestimento ] </color> |
| |
| === Directory 'context' === | === Directory 'context' === |
| |
| E' la directory dove trovano collocazione tutti i files detti //di contesto//. Essi hanno la finalità di indicare in quali condizioni il server eXtraWay stia operando sui documenti presenti nei diversi archivi.\\ | E' la **directory** dove trovano collocazione tutti i **files** detti **di contesto**. Essi hanno la finalità di indicare in quali **condizioni** il **server eXtraWay** stia operando sui **documenti** presenti nei diversi **archivi**. |
| La directory contiene i seguenti files: | |
| | La **directory** contiene i seguenti **files**: |
| |
| ^Identificativo File^Contenuto^ | ^Identificativo File^Contenuto^ |
| === Directory 'db' === | === Directory 'db' === |
| |
| E' la directory naturalmente preposta a contenere gli archivi che, di fatto, possono in realtà essere collocati ovunque. Dal momento che essa rappresenta un //default// si può però fare affidamento su questo comportamento.\\ | E' la **directory** naturalmente preposta a contenere gli **archivi** che, di fatto, possono in realtà essere collocati ovunque. Dal momento che essa rappresenta un **default** si può però fare affidamento su questo **comportamento**. |
| Come presumibilmente è noto al lettore, ogni archivio eXtraWay è accessibile per mezzo di un sui ''identificativo logico'', ovvero un' ''etichetta'' che ne consenta l'identificazione. In questo modo l'applicazione non ha alcun bisogno di conoscere alcunché della collocazione fisica ed organizzazione dell'archivio, gli sarà sufficiente conoscere l'etichetta, l'host che ospita il servizio ((default, l'host locale)) e la porta socket su cui tale servizio opera((default 4859)).\\ | |
| A questo punto l'applicazione decide di accedere ad un archivio detto ''myarc'' ed il server col quale si sarà instaurato il dialogo opera come segue: | Come presumibilmente è noto al lettore, ogni **archivio eXtraWay** è accessibile per mezzo di un suo **identificativo logico**, ovvero un'**etichetta** che ne consenta l'identificazione. In questo modo l'applicazione non ha alcun bisogno di conoscere alcunché della **collocazione fisica** ed organizzazione dell'archivio, gli sarà sufficiente conoscere l'etichetta, l'**host** che ospita il servizio ((default, l'host locale)) e la **porta socket** su cui tale **servizio** opera ((default 4859)). |
| - In prima istanza consulta il file ''xw.ini'' per stabilire se in esso vi sia l'accoppiamento tra tale etichetta ed un percorso fisico d'archivio. | |
| - Se il primo test non va a buon fine, compone il nome di default secondo questa specifica | A questo punto l'**applicazione** decide di accedere ad un **archivio** detto ''myarc'' ed il **server** col quale si sarà instaurato il **dialogo** opera come segue: |
| - Data la directory degli eseguibili, si passa alla directory ''..\db''. In essa si accede ad una directory ''myarc'' ed in essa si cerca la presenza del file ''myarc.stat.xml''((Ogni archivio si identifica per la presenza di un siffatto file. Esso è nella //radice// della directory in cui si trova l'archivio e con esso devono trovarsi tutti gli altri files dello stesso, da intendersi come file di mappa, titoli ed indici. Da questo punto in successive sub-directories ci si aspetta che trovino posto tutti i dati e gli allegati che, per ipotesi, potrebbero comunque essere collocati altrove.)) | |
| | - In prima istanza consulta il **file** ''xw.ini'' per stabilire se in esso vi sia l'**accoppiamento** tra tale **etichetta** ed un **percorso fisico** d'**archivio**. |
| | - Se il primo **test** non va a buon fine, compone il **nome** di **default** secondo questa **specifica**: |
| | - Data la **directory** degli **eseguibili**, si passa alla **directory** ''..\db''. In essa si accede ad una **directory** ''myarc'' ed in essa si cerca la presenza del **file** ''myarc.stat.xml'' ((Ogni archivio si identifica per la presenza di un siffatto file. Esso è nella radice della directory in cui si trova l'archivio e con esso devono trovarsi tutti gli altri files dello stesso, da intendersi come file di mappa, titoli ed indici. Da questo punto in successive sub-directories ci si aspetta che trovino posto tutti i dati e gli allegati che, per ipotesi, potrebbero comunque essere collocati altrove.)) |
| |
| === Directory 'logs' === | === Directory 'logs' === |
| |
| E' la directory candidata a contenere tutti i logs prodotti dal server eXtraWay e da tutti gli altri moduli appartenenti alla piattaforma.\\ | E' la **directory** candidata a contenere tutti i **logs** prodotti dal **server eXtraWay** e da tutti gli altri **moduli** appartenenti alla **piattaforma**. |
| Nel leggere il seguente schema si ricordi che i logs sono di due tipi: | |
| | Nel leggere il seguente schema si ricordi che i **logs** sono di due **tipi**: |
| ^Ciclici|Sono i logs che sono destinati a sparire da soli quando sono vetusti. La loro stesura può essere configurata per indicare la dimensione di ciascun file ed il numero complessivo dei files. Quando il file di log ciclico raggiunge la sua soglia dimensionale parte un meccanismo di rimozione/rinominazione. Il file con numerazione maggiore viene rimosso, tutti gli altri vengono rinominati aumentando di 1 la propria numerazione e viene generato un nuovo file di log di base.| | ^Ciclici|Sono i logs che sono destinati a sparire da soli quando sono vetusti. La loro stesura può essere configurata per indicare la dimensione di ciascun file ed il numero complessivo dei files. Quando il file di log ciclico raggiunge la sua soglia dimensionale parte un meccanismo di rimozione/rinominazione. Il file con numerazione maggiore viene rimosso, tutti gli altri vengono rinominati aumentando di 1 la propria numerazione e viene generato un nuovo file di log di base.| |
| ^Statici|Sono logs che, diversamente da quelli ciclici, non sono destinati ad essere rimossi per alcuna ragione. Essi solitamente hanno una denominazione che ha una componente cronologica così da non realizzare un unico file di dimensioni incontrollate| | ^Statici|Sono logs che, diversamente da quelli ciclici, non sono destinati ad essere rimossi per alcuna ragione. Essi solitamente hanno una denominazione che ha una componente cronologica così da non realizzare un unico file di dimensioni incontrollate| |
| |
| Nella fattispecie vanno presi in esame i seguenti files. | Nella fattispecie vanno presi in esame i seguenti **files**: |
| |
| ^Identificativo File^ Contenuto ^ | ^Identificativo File^ Contenuto ^ |
| === Directory 'collect' === | === Directory 'collect' === |
| |
| Nella directory 'collect' trovano posto le //raccolte// che gli utenti possono realizzare. Una raccolta è l'equivalente di una selezione o una combinazione di più selezioni, o ancora un elenco di documenti che un operatore ha facoltà di raggruppare a suo piacimento per categoria, contenuto, tema o qualsiasi altra ragione.\\ | Nella **directory** ''collect'' trovano posto le **raccolte** che gli **utenti** possono realizzare. Una raccolta è l'equivalente di una **selezione** o una combinazione di più **selezioni**, o ancora un elenco di **documenti** che un operatore ha facoltà di raggruppare a suo piacimento per **categoria**, **contenuto**, **tema** o qualsiasi altra ragione. |
| Nel parlare di //documenti// e selezioni ci si riferisce non propriamente ai documenti veri e propri bensì ai loro identificatori, ovvero i numeri di record che essi hanno entro ogni singolo archivio.\\ | |
| Nelle raccolte possono confluire identificativi di documenti appartenenti ad archivi diversi. | Nel parlare di **documenti** e **selezioni** ci si riferisce non propriamente ai documenti veri e propri bensì ai loro **identificatori**, ovvero i **numeri** di **record** che essi hanno entro ogni singolo **archivio**. |
| | |
| | Nelle **raccolte** possono confluire **identificativi** di **documenti** appartenenti ad **archivi** diversi. |
| |
| Le raccolte possono essere di due tipi, pubbliche o private. | Le **raccolte** possono essere di due tipi, **pubbliche** o **private**. |
| |
| ^Tipo Raccolta ^Funzionalità ^ | ^Tipo Raccolta ^Funzionalità ^ |
| ^Privata |Le raccolte private di un utente sono visibili solo a lui che è il solo che può compiervi interventi sopra aggiungendo o togliendo documenti. | | ^Privata |Le raccolte private di un utente sono visibili solo a lui che è il solo che può compiervi interventi sopra aggiungendo o togliendo documenti. | |
| |
| Una raccolta può essere utilizzata per accedere al suo contenuto esattamente come si fa nel consultare l'esito di una selezione, ovvero come strumento di //raffinamento// di una selezione indicandola entro una frase di ricerca. In tal caso della raccolta indicata si utilizzeranno solo i documenti che siano in essa presenti e riferibili all'archivio sul quale si sta facendo la selezione. I dettagli sulle modalità d'utilizzo delle raccolte, pubbliche e private, nell'ambito della ricerca saranno meglio chiariti nel capitolo dedicato appunto alla sintassi di ricerca. | Una **raccolta** può essere utilizzata per accedere al suo **contenuto** esattamente come si fa nel consultare l'**esito** di una **selezione**, ovvero come strumento di **raffinamento** di una **selezione** indicandola entro una **frase** di **ricerca**. In tal caso della raccolta indicata si utilizzeranno solo i **documenti** che siano in essa presenti e riferibili all'**archivio** sul quale si sta facendo la selezione. I dettagli sulle modalità d'**utilizzo** delle **raccolte**, pubbliche e private, nell'ambito della **ricerca** saranno meglio chiariti nel capitolo dedicato appunto alla **sintassi** di ricerca. |
| |
| === Directory 'tmp' === | === Directory 'tmp' === |
| |
| Il server eXtraWay, così come tutti gli altri moduli della piattaforma, necessitano di un'area nella quale collocare files temporanei per tutte le attività proprie del server ed in particolare per le attività di ricerca.\\ | Il **server eXtraWay**, così come tutti gli altri moduli della piattaforma, necessita di un'area nella quale collocare **files temporanei** per tutte le **attività** proprie del server ed in particolare per le attività di **ricerca**. |
| Entro la directory identificata, eXtraWay Server crea a sua volta una directory <color navy>hwtemp</color> al fine di avere pieno controllo sui files in essa presenti così da poter avviare processi in background che si occupino di regolare la crescita dei files in tale directory e provvedere alla rimozione di quelli non più necessari((Alcuni sistemi operativi prevedono già comportamenti simili per i files temporanei ma, per poter essere compatibili con qualsiasi piattaforma il server eXtraWay è autonomo in quest'attività)).\\ | |
| La directory prescelta è quella che corrisponde a quella configurata come segue: | Entro la **directory identificata**, eXtraWay Server crea a sua volta una directory <color navy>hwtemp</color> al fine di avere pieno **controllo** sui **files** in essa presenti così da poter avviare processi in background che si occupino di regolare la crescita dei files in tale directory e provvedere alla **rimozione** di quelli non più necessari ((Alcuni sistemi operativi prevedono già comportamenti simili per i files temporanei ma, per poter essere compatibili con qualsiasi piattaforma il server eXtraWay è autonomo in quest'attività)). |
| * Directory esplicitamente dichiarata nel file ''[[tecnici:prodotti_e_servizi:extraway_platform_server:file_profilo_xw_conf_xml#sezione_globalconf|xw.conf.xml]]'' | |
| * Variabile ambientale TEMP | La **directory prescelta** è quella che corrisponde a quella configurata come segue: |
| * Variabile ambientale TMP | |
| * Variabile ambientale TMPDIR | * **Directory** esplicitamente dichiarata nel **file** ''[[tecnici:prodotti_e_servizi:extraway_platform_server:file_profilo_xw_conf_xml#sezione_globalconf|xw.conf.xml]]''; |
| In assenza di una valida configurazione, il server assume nella directory 'tmp' la sua directory di default. | * **Variabile ambientale** ''TEMP'' ; |
| | * **Variabile ambientale** ''TMP'' ; |
| | * **Variabile ambientale** ''TMPDIR'' ; |
| | |
| | In assenza di una valida **configurazione**, il server assume nella **directory** ''tmp'' la sua **directory** di **default**. |
| | |
| | Si noti che le diverse **piattaforme** hanno comportamenti diversi che richiedono qualche attenzione quando non sia stata esplicitamente configurata la **directory** desiderata. |
| |
| Si noti che le diverse piattaforme hanno comportamenti diversi che richiedono qualche attenzione quando non sia stata esplicitamente configurata la directory desiderata. | |
| ^Piattaforma ^Accorgimento ^ | ^Piattaforma ^Accorgimento ^ |
| ^Windows |In Windows si deve tener conto di come venga eseguito il modulo. Se eseguito "manualmente" da un determinato utente eXtraWay Server assumerà come variabili ambientali quelle specifiche di utente mentre se il modulo viene eseguito come servizio saranno le variabili ambientali dell'utente //SYSTEM// ad essere prese in esame. Normalmente l'utente //SYSTEM// non ha proprie variabili TEMP o TMP((L'uso del modulo hisetup le imposta copiandole da quelle dell'utente che compie l'installazione)) e quando le ha o le ha acquisite, esse possono essere rappresentate sottoforma di regole composite. La stringa %SystemRoot%, ad esempio, identifica la directory di Windows e così via. Versioni datate dei sistemi operativi Windows, come ad esempio Windows 2000, compiono in maniera non corretta la //traduzione// di queste stringhe compromettendo quanto interpretato dal server. Per esse si suggerisce di scrivere in chiaro il valore di tali variabili ambientali. | | ^Windows |In Windows si deve tener conto di come venga eseguito il modulo. Se eseguito "manualmente" da un determinato utente eXtraWay Server assumerà come variabili ambientali quelle specifiche di utente mentre se il modulo viene eseguito come servizio saranno le variabili ambientali dell'utente //SYSTEM// ad essere prese in esame. Normalmente l'utente //SYSTEM// non ha proprie variabili TEMP o TMP((L'uso del modulo hisetup le imposta copiandole da quelle dell'utente che compie l'installazione)) e quando le ha o le ha acquisite, esse possono essere rappresentate sottoforma di regole composite. La stringa %SystemRoot%, ad esempio, identifica la directory di Windows e così via. Versioni datate dei sistemi operativi Windows, come ad esempio Windows 2000, compiono in maniera non corretta la //traduzione// di queste stringhe compromettendo quanto interpretato dal server. Per esse si suggerisce di scrivere in chiaro il valore di tali variabili ambientali. | |
| === Directory 'lazy' === | === Directory 'lazy' === |
| |
| Directory che ospita i files da elaborare //near on line//.\\ | Directory che ospita i **files** da elaborare near on line. |
| <color grey>Documentazione in allestimento</color> | |
| | <color grey> [ Documentazione in allestimento ] </color> |
| |
| === Directory 'xreg' === | === Directory 'xreg' === |
| |
| Nelle versioni più recenti del server le attività di registrazione nel file [[#directory_logs|xreg<annomese>.log]] possono avvenire sia nella modalità canonica, vale a dire per mezzo di una comunicazione sincrona tra i Server //Slave// ed il Server //Master//, ovvero riportando su file system le attività da svolgere per ridurre ai minimi termini il colli di bottiglia derivanti dalla comunicazione sincrona in presenza di elevata concorrenza d'accesso.\\ | Nelle **versioni** più **recenti** del **server** le attività di **registrazione** nel **file** ''[[#directory_logs|xreg<annomese>.log]]'' possono avvenire sia nella modalità canonica, vale a dire per mezzo di una **comunicazione sincrona** tra i **Server Slave** ed il **Server Master**, ovvero riportando su **file system** le attività da svolgere per ridurre ai minimi termini il **colli** di **bottiglia** derivanti dalla comunicazione sincrona in presenza di elevata **concorrenza** d'**accesso**. |
| Il Server //Master//, che ha il compito di effettuare la stesura del suddetto file di log, consuma i files presenti in questa directory in ordine cronologico.\\ La scelta tra le due modalità va compiuta a seconda delle criticità dell'installazione su cui ci si trova ad operare in quanto la modalità canonica fa ampio uso di //Socket//, la modalità asincrona su file va invece ampio uso del //File System//. | |
| | Il **Server Master**, che ha il compito di effettuare la stesura del suddetto **file** di **log**, consuma i **files** presenti in questa **directory** in **ordine cronologico**. |
| | |
| | La **scelta** tra le due **modalità** va compiuta a seconda delle **criticità** dell'**installazione** su cui ci si trova ad operare in quanto la modalità canonica fa ampio uso di **Socket**, la modalità asincrona su file va invece ampio uso del **File System**. |
| |
| === Directory 'wd' === | === Directory 'wd' === |
| |
| Directory che ospita i files da acquisire.\\ | **Directory** che ospita i **files** da acquisire. |
| <color grey>Documentazione in allestimento</color> | |
| | <color grey> [ Documentazione in allestimento ] </color> |
| |
| ===== Architettura HardWare ===== | ===== Architettura HardWare ===== |
| ==== Introduzione ==== | ==== Introduzione ==== |
| |
| Il presente documento vuole dare evidenza di quali possano essere gli scenari HardWare e SoftWare per soddisfare le esigenze di | Il presente documento vuole dare evidenza di quali possano essere gli **scenari hardware** e **software** per soddisfare le esigenze di qualsiasi **progetto** realizzato con **eXtraWay**. |
| qualsiasi progetto realizzato con eXtraWay. | |
| | In primo luogo vale la pena di sottolineare che un'**applicazione** realizzata con la **tecnologia ExtraWay** prevede normalmente una **struttura** "3 tiers" ovvero la presenza di tre **strati software** che si occupano di: |
| | |
| | * **Presentazione** delle **informazioni** raccolte e **controllo** delle informazioni inserite dall'utente ( ''Web Server'' ); |
| | * **Elaborazione** delle **informazioni** inserite dall'**utente** e **gestione** delle **comunicazioni** con la **banca dati** ( ''Application Server'' ); |
| | * **Gestione** dei **dati** vera e propria ( ''DataBase Server'' ). |
| | |
| | Una simile **struttura** si presta naturalmente per consentire una **scalabilità verticale** e, se le **condizioni** lo consentono, anche orizzontale. Il primo ed il secondo **strato software** possono essere scalati orizzontalmente senza limitazioni mente il terzo, vale a dire il **DataBase Server**, ovvero **ExtraWay**, può essere scalato orizzontalmente solo in alcuni casi. |
| |
| In primo luogo vale la pena di sottolineare che un'applicazione realizzata con la tecnologia ExtraWay prevede normalmente una struttura "3 tiers" ovvero la presenza di tre strati software che si occupano di:\\ | Va inoltre ricordato che un ulteriore **livello** di **separazione** dei **compiti** può essere ottenuto distinguendo il **Back Office** di un'applicazione dal suo **Front Office** se la **gestione** dei due **accessi** ai **dati** può essere **desincronizzato**. |
| * Presentazione delle informazioni raccolte e controllo delle informazioni inserite dall'utente(Web Server) | |
| * Elaborazione delle informazioni inserite dall'utente e gestione delle comunicazioni con la banca dati (Application Server) | |
| * Gestione dei dati vera e propria (DataBase Server) | |
| |
| Una simile struttura si presta naturalmente per consentire una scalabilità verticale e, se le condizioni lo consentono, anche orizzontale. Il primo ed il secondo strato software possono essere scalati orizzontalmente senza limitazioni mente il terzo, vale a dire il DataBase Server, ovvero ExtraWay, può essere scalato orizzontalmente solo in alcuni casi.\\ | Ciascuno di questi **concetti** sarà più chiaro al **lettore** nei capitoli successivi. |
| Va inoltre ricordato che un ulteriore livello di separazione dei compiti può essere ottenuto distinguendo il "Back Office" di un'applicazione dal suo "Front Office" se la gestione dei due accessi ai dati può essere desincronizzato.\\ | |
| Ciascuno di questi concetti sarà più chiaro al lettore nei capitoli successivi. | |
| |
| Di seguito vedremo tutti i possibili scenari soffermandoci sugli aspetti più significativi per ciascuna delle possibilità esposte. | Di seguito vedremo tutti i possibili **scenari** soffermandoci sugli **aspetti** più **significativi** per ciascuna delle **possibilità** esposte. |
| |
| ==== Gli scenari di base disponibili ==== | ==== Gli scenari di base disponibili ==== |
| |
| Si considerano scenari "di base" quelli che offrono il servizio minimo indispensabile senza garantire particolari livelli di performance, di continuità di servizio e di separazione tra settore redazionale e mera consultazione. | Si considerano **scenari di base** quelli che offrono il **servizio minimo** indispensabile senza garantire particolari **livelli** di **performance**, di **continuità** di **servizio** e di separazione tra **settore redazionale** e mera **consultazione**. |
| |
| __La rappresentazione dei "Dati" separatamente dalla macchina è solo indicativa. Esclusivamente nei casi di Cluster tale separazione è effettivamente un requisito__. | __La rappresentazione dei "Dati" separatamente dalla macchina è solo indicativa. Esclusivamente nei casi di Cluster tale separazione è effettivamente un requisito__. |
| === Configurazione Minima === | === Configurazione Minima === |
| |
| Lo scenario "minimo" va concepito con la compresenza sullo stesso server di tutti e tre gli strati software descritti precedentemente. Non sfrutta alcuna possibilità di distribuire il carico di lavoro rappresentato dai singoli strati scalando l'hardware verticalmente e non garantisce una continuità nel servizio in caso di guasto. | Lo **scenario "minimo"** va concepito con la compresenza sullo stesso **server** di tutti e tre gli **strati software** descritti precedentemente. Non sfrutta alcuna possibilità di distribuire il **carico** di **lavoro** rappresentato dai singoli **strati** scalando l'hardware verticalmente e non garantisce una **continuità** nel servizio in **caso** di **guasto**. |
| |
| {{:documentazione_3di:extraway_os:confhw_1.jpg|Configurazione Minima}} | {{:documentazione_3di:extraway_os:confhw_1.jpg|Configurazione Minima}} |
| === Configurazione Scalata Verticalmente === | === Configurazione Scalata Verticalmente === |
| |
| Deriva direttamente dalla configurazione minima e consiste nell'avere due o tre strati hardware, non replicati tra loro, che consentano di distribuire verticalmente il carico di lavoro. Sfrutta quindi la possibilità di distribuire il carico (da una configurazione minima su due livelli ad una "canonica" su tre) ma non garantisce una continuità nel servizio in caso di guasto. | Deriva direttamente dalla **configurazione minima** e consiste nell'avere due o tre **strati hardware**, non replicati tra loro, che consentano di distribuire verticalmente il **carico** di **lavoro**. Sfrutta quindi la possibilità di distribuire il carico (da una configurazione minima su due livelli ad una "canonica" su tre) ma non garantisce una **continuità** nel **servizio** in caso di **guasto**. |
| Di seguito i tre esempi possibili. In due casi si sfruttano solo due macchine per distribuire i tre livelli di software mentre il terzo caso rappresenta la condizione più ampiamente distribuita e quella solitamente adottata quando si decide di compiere una scalatura verticale dell'hardware. | Di seguito i **tre esempi** possibili. In due casi si sfruttano solo due **macchine** per distribuire i tre **livelli** di **software** mentre il terzo caso rappresenta la condizione più ampiamente distribuita e quella solitamente adottata quando si decide di compiere una **scalatura verticale** dell'**hardware**. |
| |
| {{:documentazione_3di:extraway_os:confhw_2.jpg|Configurazione Scalata Verticalmente}} | {{:documentazione_3di:extraway_os:confhw_2.jpg|Configurazione Scalata Verticalmente}} |
| ==== Scenari Complessi ==== | ==== Scenari Complessi ==== |
| |
| Negli scenari complessi trovano posto tutte le diverse configurazioni che possono risultare maggiormente garantiste per prestazioni, continuità del servizio e separazione tra settori.\\ | Negli **scenari complessi** trovano posto tutte le diverse **configurazioni** che possono risultare maggiormente garantiste per **prestazioni**, **continuità** del **servizio** e **separazione** tra **settori**. |
| In particolare si prenderanno in esame i sistemi che sfruttano una tecnologia di Load Balancing e/o Fault Tollerance avvalendosi di uno o più Cluster. | In particolare si prenderanno in esame i **sistemi** che sfruttano una **tecnologia** di **Load Balancing** e/o **Fault Tollerance** avvalendosi di uno o più **Cluster**. |
| |
| === Configurazione con l'uso di Cluster === | === Configurazione con l'uso di Cluster === |
| |
| Le configurazioni che si possono avvalere di sistemi di Cluster possono essere viste come dirette derivazioni degli scenari "di base" descritti precedentemente. In tal caso, in virtù della suddivisione "verticale" degli strati software sull'hardware posto in gioco, si possono assoggettare a Cluster gli strati preferiti. Si può infatti pensare di porre in Load Balancing (quindi in cluster di macchine tutte operative) il primo e/o il secondo strato software coinvolto (Presentazione ed Elaborazione) mentre per il terzo strato, la Gestione Dati, è necessario fare affidamento ad un sistema di Fault Tollerance. | Le **configurazioni** che si possono avvalere di **sistemi** di **Cluster** possono essere viste come dirette **derivazioni** degli **scenari di base** descritti precedentemente. In tal caso, in virtù della **suddivisione verticale** degli **strati software** sull'**hardware** posto in gioco, si possono assoggettare a **Cluster** gli strati preferiti. Si può infatti pensare di porre in **Load Balancing** (quindi in cluster di macchine tutte operative) il primo e/o il secondo strato software coinvolto (Presentazione ed Elaborazione) mentre per il terzo strato, la **Gestione Dati**, è necessario fare affidamento ad un sistema di **Fault Tolerance**. |
| |
| Vedremo infatti che anche in tutti gli scenari ad eccezione della separazione tra Back Office e Front Office, la Gestione Dati non può essere amministrata correttamente solo con una configurazione in Load Balancing. | Vedremo infatti che anche in tutti gli **scenari** ad eccezione della separazione tra Back Office e Front Office, la **Gestione Dati** non può essere amministrata correttamente solo con una configurazione in **Load Balancing**. |
| |
| Nulla vieta, comunque, che anche in presenza di una sola coppia di macchine in cluster tra loro, i diversi strati di software possano essere amministrati separatamente usufruendo della distribuzione di carico almeno per i primi due di essi. | Nulla vieta, comunque, che anche in presenza di una sola coppia di **macchine** in **cluster** tra loro, i diversi **strati** di **software** possano essere amministrati separatamente usufruendo della distribuzione di **carico** almeno per i primi due di essi. |
| L'immagine seguente vuole dare evidenza del fatto che le macchine possono essere poste in cluster quale che sia la scalatura verticale scelta secondo le ipotesi avanzate nel precedente capitolo. In particolare l'esempio di destra indica come "eventuale" ogni cluster in quanto si può decidere a quale livello esso è necessario ed applicarlo solo in tal caso. In caso di Cluster sul DataBase Server l'adozione di unità dischi esterna condivisibile dalle due macchine è pressoché inevitabile. | L'immagine seguente vuole dare evidenza del fatto che le **macchine** possono essere poste in **cluster** quale che sia la **scalatura verticale** scelta secondo le ipotesi avanzate nel precedente capitolo. In particolare l'esempio di destra indica come "eventuale" ogni **cluster** in quanto si può decidere a quale livello esso è necessario ed applicarlo solo in tal caso. In caso di Cluster sul **DataBase Server** l'adozione di unità dischi esterna condivisibile dalle due macchine è pressoché inevitabile. |
| |
| {{:documentazione_3di:extraway_os:confhw_3.jpg|Configurazione con l'uso di Cluster}} | {{:documentazione_3di:extraway_os:confhw_3.jpg|Configurazione con l'uso di Cluster}} |
| === Configurazione separata tra Back Office e Front Office === | === Configurazione separata tra Back Office e Front Office === |
| |
| In una simile configurazione c'è la massima disponibilità di scalare l'hardware coinvolto. Questa configurazione deriva dalla precedente ma replica su due serie di macchine i ruoli redazionali (Back Office) e di consultazione (Front Office) con una sincronizzazione tra i due ambienti da definire. | In una simile **configurazione** c'è la massima disponibilità di scalare l'**hardware** coinvolto. Questa configurazione deriva dalla precedente ma **replica** su due **serie** di **macchine** i **ruoli redazionali** (**Back Office**) e di **consultazione** (**Front Office**) con una **sincronizzazione** tra i due **ambienti** da definire. |
| |
| Lo scenario prevede quindi che il Back Office, strutturato in una qualsiasi delle precedenti modalità descritte, con o senza Cluster, mantenga aggiornato con uno strumento di distribuzione (Spreader) una batteria di macchine di Front Office (idealmente da due in su) che non hanno la necessità di essere poste in cluster. Sarà il procedimento di distribuzione, avvalendosi di un processo detto "arbiter" a sincronizzare tutte le macchine del Front Office. L'arbiter, a sua volta, potrà esporre all'utenza le sole macchine effettivamente sincronizzate. | Lo **scenario** prevede quindi che il **Back Office**, strutturato in una qualsiasi delle precedenti **modalità** descritte, con o senza **Cluster**, mantenga aggiornato con uno **strumento** di **distribuzione** (**Spreader**) una batteria di macchine di **Front Office** (idealmente da due in su) che non hanno la necessità di essere poste in cluster. Sarà il procedimento di **distribuzione**, avvalendosi di un **processo** detto **arbiter** a sincronizzare tutte le macchine del **Front Office**. L'arbiter, a sua volta, potrà esporre all'utenza le sole **macchine** effettivamente sincronizzate. |
| |
| __In sostanza, per il nostro esempio, il Back Office può essere strutturato in una qualsiasi delle modalità sin ora viste, quella prescelta è solo esemplificativa__. | __In sostanza, per il nostro esempio, il Back Office può essere strutturato in una qualsiasi delle modalità sin ora viste, quella prescelta è solo esemplificativa__. |
| __Oltre a quanto detto bisogna sottolineare che una simile configurazione si può prestare solo per archivi nei quali la fase redazionale differisca da quella di pubblicazione, solitamente legata ad una sorta di validazione dei dati introdotti o modificati, in quanto l'attività dello Spreader può essere ragionevolmente avviata solo alcune volte al giorno e non può essere considerato uno strumento adatto a mantenere costantemente aggiornato un Front Office "near-on-line"__. | __Oltre a quanto detto bisogna sottolineare che una simile configurazione si può prestare solo per archivi nei quali la fase redazionale differisca da quella di pubblicazione, solitamente legata ad una sorta di validazione dei dati introdotti o modificati, in quanto l'attività dello Spreader può essere ragionevolmente avviata solo alcune volte al giorno e non può essere considerato uno strumento adatto a mantenere costantemente aggiornato un Front Office "near-on-line"__. |
| |
| L'esempio che segue deriva dall'applicazione di un Cluster completo, scalato nell'hardware sui 3 livelli software (parte di sinistra). | L'**esempio** che segue deriva dall'applicazione di un **Cluster** completo, scalato nell'**hardware** sui tre **livelli software** (parte di sinistra). |
| |
| A destra vediamo invece l'aspetto che avrebbe il front office con l'uso di Web Server distinti ed una batteria di due o più macchine tutte contemporaneamente in grado di fungere tanto da Application Server quanto da DataBase Server grazie all'intervento di un Arbiter. | A destra vediamo invece l'**aspetto** che avrebbe il **front office** con l'uso di **Web Server** distinti ed una batteria di due o più macchine tutte contemporaneamente in grado di fungere tanto da **Application Server** quanto da **DataBase Server** grazie all'intervento di un **Arbiter**. |
| |
| La prima immagine rappresenta il caso tipico mentre la seconda mostra un caso più complesso nel quale si sia voluta compiere un'eventuale suddivisione del carico di lavoro separando anche lo strato software inerente l'Application Server. | La prima immagine rappresenta il caso tipico mentre la seconda mostra un caso più complesso nel quale si sia voluta compiere un'eventuale **suddivisione** del **carico** di **lavoro** separando anche lo **strato software** inerente l'**Application Server**. |
| |
| {{:documentazione_3di:extraway_os:confhw_4.jpg|Back Office con Cluster & Front Office}} | {{:documentazione_3di:extraway_os:confhw_4.jpg|Back Office con Cluster & Front Office}} |
| |
| Nella seconda immagine, fondamentalmente equivalente alla prima, si introduce solo l'Application Server in Load Balancing. | Nella seconda immagine, fondamentalmente equivalente alla prima, si introduce solo l'**Application Server** in **Load Balancing**. |
| |
| {{:documentazione_3di:extraway_so:confhw_5.jpg|Back Office & Front Office entrambe con Cluster}} | {{:documentazione_3di:extraway_so:confhw_5.jpg|Back Office & Front Office entrambe con Cluster}} |
| ==== Note sullo Spreader ==== | ==== Note sullo Spreader ==== |
| |
| Come detto in precedenza, una separazione tra Back Office e Front Office può essere ottenuta in diversi modi ed esistono senza alcun dubbio strumenti in grado di compiere una replicazione più o meno "complessiva" dello stato di dati ed indici (gli archivi) dalla macchina del Back Office a quelle del Front Office, assumendo che esse siano due macchine in Load Balancing. Condividere via NFS o altro strumento di rete i dischi di un server verso altri server per ampliare la batteria di macchine a disposizione dell'utenza è una pratica percorribile ma che, in particolare a fronte di un utenza di ampie dimensioni, risulta scarsamente performante. | Come detto in precedenza, una separazione tra **Back Office** e **Front Office** può essere ottenuta in diversi modi ed esistono senza alcun dubbio strumenti in grado di compiere una **replicazione** più o meno "complessiva" dello stato di **dati** ed **indici** (gli archivi) dalla macchina del Back Office a quelle del Front Office, assumendo che esse siano due macchine in **Load Balancing**. Condividere via **NFS** o altro strumento di rete i **dischi** di un server verso altri server per ampliare la batteria di **macchine** a disposizione dell'utenza è una pratica percorribile ma che, in particolare a fronte di un **utenza** di ampie dimensioni, risulta scarsamente performante. |
| |
| A tale scopo 3D Informatica ha realizzato uno strumento denominato "Spreader", avente lo scopo di distribuire alle macchine di un Front Office uno o più archivi provenienti dal Back Office operando in modo differenziale e, collaborando con l'Arbiter che compie la distribuzione di carico tra le macchine Front, mantenendo aggiornato lo stato delle macchine in modo sempre allineato. | A tale scopo 3D Informatica ha realizzato uno **strumento** denominato **Spreader**, avente lo scopo di distribuire alle macchine di un Front Office uno o più **archivi** provenienti dal Back Office operando in modo differenziale e, collaborando con l'**Arbiter** che compie la **distribuzione** di **carico** tra le macchine Front, mantenendo aggiornato lo **stato** delle **macchine** in modo sempre allineato. |
| |
| Cerchiamo quindi di spigarne il comportamento tramite un esempio. Abbiamo un server di BackOffice (BO1) e 5 server di Front Office (FO1, FO2, FO3, FO4 ed FO5). | Cerchiamo quindi di spigarne il comportamento tramite un esempio. Abbiamo un **server** di **BackOffice** (BO1) e 5 server di **Front Office** (FO1, FO2, FO3, FO4 ed FO5). |
| |
| Quando l'amministratore decide di compiere l'aggiornamento dal Back Office al Front Office, ovvero tramite un automatismo a tempo, lo Spreader controlla richiedendo le informazioni alle macchine del Front Office, quale sia il loro stato di aggiornamento. | Quando l'**amministratore** decide di compiere l'**aggiornamento** dal Back Office al Front Office, ovvero tramite un **automatismo** a tempo, lo **Spreader** controlla richiedendo le **informazioni** alle macchine del Front Office, quale sia il loro stato di aggiornamento. |
| Supponiamo in un primo momento che esse siano tutte aggiornate al giorno precedente. | Supponiamo in un primo momento che esse siano tutte aggiornate al giorno precedente. |
| |
| Lo Spreader richiede al Server BO1 di valutare le differenze intercorse in termini di dati ed indici dalla data ed ora (time stamp completo sino ai millisecondi) di ultimo aggiornamento "comune". Il file prodotto, chiamato "delta" viene in seguito usato per l'aggiornamento delle singole macchine. | Lo **Spreader** richiede al **Server BO1** di valutare le differenze intercorse in termini di **dati** ed **indici** dalla **data** ed **ora** (time stamp completo sino ai millisecondi) di **ultimo aggiornamento** "comune". Il **file** prodotto, chiamato **delta** viene in seguito usato per l'**aggiornamento** delle **singole macchine**. |
| |
| L'aggiornamento avviene secondo questa tecnica. | L'**aggiornamento** avviene secondo questa **tecnica**. |
| |
| Lo Spreader chiede all'Arbitro di porre in "stand by" FO1 che da quel momento non verrà più usata per distribuire il carico di lavoro richiesto dall'utenza. Poi invia a FO1 il "delta" e gli chiede di applicarlo. Una volta applicato il server FO1 viene mantenuto in "stand by". | Lo **Spreader** chiede all'**Arbitro** di porre in "stand by" **FO1** che da quel momento non verrà più usata per distribuire il **carico** di **lavoro** richiesto dall'**utenza**. Poi invia a **FO1** il **delta** e gli chiede di applicarlo. Una volta applicato il **server FO1** viene mantenuto in **stand by**. |
| |
| Poi fa altrettanto con FO2 e con FO3. Avendo superato "la metà" dei server disponibili sul Front Office, lo Spreader richiede all'Arbiter, con un'operazione atomica, di porre in "stand by" le macchine FO4 ed FO5 e di riportare "on line" FO1, FO2 ed FO3 che essendo tutte aggiornate ed in "maggioranza" possono meglio servire l'utenza. | Poi fa altrettanto con **FO2** e con **FO3**. Avendo superato "la metà" dei server disponibili sul Front Office, lo **Spreader** richiede all'**Arbiter**, con un'operazione atomica, di porre in "stand by" le **macchine FO4** ed **FO5** e di riportare "on line" **FO1**, **FO2** ed **FO3** che essendo tutte aggiornate ed in "maggioranza" possono meglio servire l'utenza. |
| |
| Di seguito provvede a compiere l'aggiornamento su FO4 ed FO5 richiedendo che vengano poste "on line" appena aggiornate per rimpinguare il pool di macchine disponibili all'utenza. | Di seguito provvede a compiere l'aggiornamento su **FO4** ed **FO5** richiedendo che vengano poste "on line" appena aggiornate per rimpinguare il **pool** di **macchine disponibili** all'utenza. |
| |
| Se nel procedimento descritto una macchina risulta non raggiungibile, spenta, precedentemente posta in "stand by" e non rimessa "on line" a causa di un errore di aggiornamento, lo Spreader stabilisce quale sia la combinazione migliore di macchine da lasciare "on line" per garantire il miglior servizio al miglior stato d'avanzamento. Se le macchine FO sono allineate in modo diverso, il "delta" che viene calcolato comprende il materiale necessario a condurle tutte allo stato d'aggiornamento corrente anche a costo di applicare aggiornamenti già applicati in parte (senza con questo impattare sulla validità degli archivi). | Se nel **procedimento** descritto una **macchina** risulta non raggiungibile, spenta, precedentemente posta in "stand by" e non rimessa "on line" a causa di un **errore** di **aggiornamento**, lo **Spreader** stabilisce quale sia la **combinazione migliore** di **macchine** da lasciare "on line" per garantire il miglior **servizio** al **miglior stato d'avanzamento**. Se le **macchine FO** sono allineate in modo diverso, il **delta** che viene calcolato comprende il **materiale** necessario a condurle tutte allo stato d'**aggiornamento** corrente anche a costo di applicare aggiornamenti già applicati in parte (senza con questo impattare sulla **validità** degli **archivi**). |
| |
| ==== Estensione degli Scenari, il Disaster Recovery ==== | ==== Estensione degli Scenari, il Disaster Recovery ==== |
| |
| Gli scenari, semplici e complessi, sin ora descritti consentono di costruire una struttura con diversi livelli di sicurezza già in essa. Ad esempio, un Back Office separato e configurato con un Cluster è ragionevolmente solido ed ha un Back Up naturale nel Front Office. Una struttura che preveda più Front Office ha in essa una sicurezza intrinseca di continuità del servizio. | Gli **scenari**, semplici e complessi, sin ora descritti consentono di costruire una **struttura** con diversi **livelli** di **sicurezza** già in essa. Ad esempio, un **Back Office** separato e configurato con un **Cluster** è ragionevolmente solido ed ha un **back up** naturale nel **Front Office**. Una **struttura** che preveda **più Front Office** ha in essa una **sicurezza** intrinseca di continuità del **servizio**. |
| |
| Se a questi scenari vogliamo affiancare un ulteriore livello di sicurezza entriamo nell'ambito del "Disaster Recovery" per il quale valgono le considerazioni già fatte negli scenari descritti. Anche in quel caso possono essere ipotizzati scenari semplici e complessi per il nodo “secondario” indipendenti dalla configurazione data a quello "primario". | Se a questi **scenari** vogliamo affiancare un ulteriore livello di **sicurezza** entriamo nell'ambito del **Disaster Recovery** per il quale valgono le considerazioni già fatte negli scenari descritti. Anche in quel caso possono essere ipotizzati scenari semplici e complessi per il **nodo “secondario”** indipendenti dalla **configurazione** data a quello "primario". |
| |
| Esso consiste, solitamente, nella replicazione dell'hardware (nella forma più opportuna) e di tutti i dati disponibili ed allineati in una struttura differente. Per "struttura", in questo caso, facciamo riferimento "fisicamente" ad un luogo diverso, servito differentemente sia dal punto di vista elettrico che per ogni altro aspetto logistico. | Esso consiste, solitamente, nella **replicazione** dell'**hardware** (nella forma più opportuna) e di tutti i **dati** disponibili ed allineati in una **struttura** differente. Per struttura, in questo caso, facciamo riferimento fisicamente ad un luogo diverso, servito differentemente sia dal **punto** di **vista elettrico** che per ogni altro aspetto **logistico**. |
| |
| Quello che può essere replicato in questa differente struttura è un qualsiasi scenario "minore o uguale" a quello primario che può essere mantenuto allineato con degli automatismi con cadenza giornaliera o con quella ritenuta più opportuna. | Quello che può essere replicato in questa differente **struttura** è un qualsiasi **scenario** "minore o uguale" a quello primario che può essere mantenuto allineato con degli **automatismi** con **cadenza giornaliera** o con quella ritenuta più opportuna. |
| |
| Gli strumenti a disposizione, dal trasferimento e l'applicazione di un backup all'uso dello Spreader, consentono di avere un allineamento ragionevolmente "fresco" della copia presso la struttura secondaria ed essa può essere concepita come sola salvaguardia dei dati (quindi una copia fedele del Back Office consultabile) sia come una completa replicazione della configurazione primaria. | Gli **strumenti** a disposizione, dal trasferimento e l'applicazione di un **backup** all'uso dello **Spreader**, consentono di avere un **allineamento** ragionevolmente "fresco" della copia presso la **struttura secondaria** ed essa può essere concepita come sola **salvaguardia** dei dati (quindi una copia fedele del Back Office consultabile) sia come una completa **replicazione** della **configurazione primaria**. |
| |
| Anche se per il "nodo primario" si fosse scelta una configurazione minima in essa dovrebbe trovare posto per lo meno uno spreader che provvederà a mantenere aggiornata una delle replicazioni che seguono. | Anche se per il **nodo primario** si fosse scelta una **configurazione minima** in essa dovrebbe trovare posto per lo meno uno **spreader** che provvederà a mantenere aggiornata una delle **replicazioni** che seguono. |
| |
| La replicazione dello scenario dovrebbe essere integrale. La replicazione integrale va vista come la riproduzione, presso diversa struttura, di una configurazione minima o scalata come dagli scenari descritti. Essa può essere una versione "ridotta" (ovvero priva di scalatura orizzontale o verticale o con una scalatura ridotta) di quella primaria ma comunque pienamente funzionante. | La **replicazione** dello **scenario** dovrebbe essere **integrale**. La replicazione integrale va vista come la **riproduzione**, presso diversa **struttura**, di una **configurazione** minima o scalata come dagli scenari descritti. Essa può essere una **versione** "ridotta" (ovvero priva di scalatura orizzontale o verticale o con una scalatura ridotta) di quella primaria ma comunque pienamente funzionante. |
| |
| Tramite spreader (considerando il BackOffice dell'installazione "secondaria" al pari di un Front Office da aggiornare da parte del nodo "primario") si può mantenere aggiornato il secondo nodo ed in esso si provvederà, se anche il nodo secondario è scalato verticalmente, ad aggiornare il proprio Front Office avvalendosi di un'installazione “locale” dello spreader. | Tramite **spreader** (considerando il BackOffice dell'installazione "secondaria" al pari di un Front Office da aggiornare da parte del nodo "primario") si può mantenere aggiornato il secondo **nodo** ed in esso si provvederà, se anche il **nodo secondario** è scalato verticalmente, ad aggiornare il proprio **Front Office** avvalendosi di un'**installazione “locale”** dello spreader. |
| |
| In caso il nodo "secondario" venga chiamato in causa per indisponibilità del "primario" esso prevederà un ambiente completo che consentirà di proseguire tanto nell'attività redazionale quanto in quella di fruizione del sistema mantenendo eventualmente distinte le due realtà. | In caso il **nodo secondario** venga chiamato in causa per indisponibilità del **primario** esso prevederà un **ambiente** completo che consentirà di proseguire tanto nell'**attività redazionale** quanto in quella di fruizione del **sistema** mantenendo eventualmente distinte le due **realtà**. |
| |
| __Si tratta attualmente dello scenario più completo ed esaustivo__. | __Si tratta attualmente dello scenario più completo ed esaustivo__. |
| |
| Possono essere presi in esame altri scenari in cui il nodo "secondario" ha una replicazione parziale del nodo "primario", replicando in esso il solo Back Office o il solo Front Office. | Possono essere presi in esame altri scenari in cui il **nodo secondario** ha una replicazione parziale del **nodo primario**, replicando in esso il solo **Back Office** o il solo **Front Office**. |
| |
| ==== Conclusioni ==== | ==== Conclusioni ==== |
| |
| Concludendo, gli scenari che si possono realizzare sono stati ampiamente descritti e possono essere ottenuti combinando in vario modo le possibilità esposte. La scelta sulla configurazione più opportuna deve tenere in considerazione due fattori evidenti: la scalabilità orizzontale garantisce di adeguarsi alle performance richieste dal sistema in virtù del carico di lavoro previsto sulla base dell'utenza che ne farà uso, potenzialità in parte ottenibile anche con la scalabilità verticale, ma rispetto a quest'ultima offre tipicamente maggiori risultati e da garanzie di continuità nell'erogazione del servizio che la sola scalabilità verticale non può offrire. | Concludendo, gli **scenari** che si possono realizzare sono stati ampiamente descritti e possono essere ottenuti combinando in vario modo le **possibilità** esposte. La scelta sulla **configurazione** più opportuna deve tenere in considerazione due **fattori** evidenti: la **scalabilità orizzontale** garantisce di adeguarsi alle performance richieste dal sistema in virtù del **carico** di **lavoro** previsto sulla base dell'utenza che ne farà uso, potenzialità in parte ottenibile anche con la **scalabilità verticale**, ma rispetto a quest'ultima offre tipicamente maggiori risultati e da **garanzie** di **continuità** nell'**erogazione** del **servizio** che la sola scalabilità verticale non può offrire. |
| |
| L'unico reale vincolo si ha nella realizzazione di un Cluster per il DataBase Server del BO (o globale se non v'è distinzione tra le due parti) in quanto non è possibile adottare una configurazione in Load Balancing ma solo in Fault Tollerance per lo meno sino a quando alcune limitazioni esistenti nella piena accessibilità delle risorse condivise non saranno superate dei produttori di hardware e software di base.\\ | L'unico reale **vincolo** si ha nella realizzazione di un **Cluster** per il **DataBase Server** del BO (o globale se non v'è distinzione tra le due parti) in quanto non è possibile adottare una **configurazione** in **Load Balancing** ma solo in **Fault Tollerance** per lo meno sino a quando alcune **limitazioni** esistenti nella piena **accessibilità** delle **risorse condivise** non saranno superate dei **produttori** di **hardware** e **software** di base. |
| Questo, per lo meno, sulla base dell'esperienza sino ad ora accumulata in proposito. | |
| | Questo, per lo meno, sulla base dell'**esperienza** sino ad ora accumulata in proposito. |
| |
| ==== Gli sviluppi futuri ==== | ==== Gli sviluppi futuri ==== |
| |
| Se il documento ha raggiungo lo scopo, il lettore avrò ora un quadro sufficientemente chiaro di cosa si possa realizzare con il software della 3D Informatica ed in particolare saprà comprendere quale tra gli scenari descritti potrà soddisfare pienamente le proprie esigenze.\\ | Se il **documento** ha raggiungo lo **scopo**, il **lettore** avrà ora un **quadro** sufficientemente chiaro di cosa si possa realizzare con il **software** della 3D Informatica ed in particolare saprà comprendere quale tra gli **scenari descritti** potrà soddisfare pienamente le proprie **esigenze**. |
| Oltre a ciò il lettore avrà anche compreso come il modificarsi del carico di lavoro o delle esigenze di fruizione delle informazioni nell'arco del tempo non trovino in eXtraWay un limite bensì un valido alleato, pronto a modellare le proprie capacità al servizio del più importante degli obiettivi che accomunano 3D Informatica e coloro che ne hanno scelto la tecnologia: fornire un servizio solido e performante che unisca un'ampia fruibilità delle informazioni alle tecniche più adatte per garantire la massima sicurezza dei dati stessi. | |
| | Oltre a ciò il **lettore** avrà anche compreso come il modificarsi del **carico** di **lavoro** o delle esigenze di **fruizione** delle **informazioni** nell'arco del tempo non trovino in **eXtraWay** un **limite** bensì un valido alleato, pronto a modellare le proprie **capacità** al **servizio** del più importante degli **obiettivi** che accomunano 3D Informatica e coloro che ne hanno scelto la **tecnologia**: fornire un **servizio solido** e performante che unisca un'ampia **fruibilità** delle **informazioni** alle tecniche più adatte per garantire la massima **sicurezza** dei **dati** stessi. |
| | |
| | Questo è quanto abbiamo voluto fare sino ad ora ma certo possiamo fare molto di più. Per venire ulteriormente incontro alle **esigenze** della **clientela** ci sono **progetti** che riteniamo degni di essere presi in esame, anche se parte di essi non vedrà la luce se non tra diverso tempo. |
| |
| Questo è quanto abbiamo voluto fare sino ad ora ma certo possiamo fare molto di più. Per venire ulteriormente incontro alle esigenze della clientela ci sono progetti che riteniamo degli di essere presi in esame, anche se parte di essi non vedrà la luce se non tra diverso tempo.\\ | |
| Tra essi ci preme sottolineare: | Tra essi ci preme sottolineare: |
| |
| === Hot Backup === | === Hot Backup === |
| |
| Tra le esigenze che ci sono state spesso esposte c'è quella di poter compiere backup senza causare una effettiva interruzione dei servizi, garantendo quanto meno la consultazione delle informazioni contenute nei Data Base.\\ | Tra le esigenze che ci sono state spesso esposte c'è quella di poter compiere **backup** senza causare una effettiva **interruzione** dei **servizi**, garantendo quanto meno la **consultazione** delle **informazioni** contenute nei Data Base. |
| Una simile modalità consiste in un congelamento effettuato direttamente dallo strato più basso, ovvero il DataBase Server, delle sole funzionalità di modifica così da consentire la copia e quindi il salvataggio della fotografia del Data Base in un dato momento senza con questo inibire la consultazione. In uno scenario ideale un parco utenti anche molto vasto è in realtà composto da una minoranza che ha funzioni di redazione ed una maggioranza che invece si limita alla fruizione dei Data Base. Lo scenario proposto consentirebbe quindi di limitare l'operato solo di una minoranza. | |
| | Una simile modalità consiste in un **congelamento** effettuato direttamente dallo **strato** più basso, ovvero il **DataBase Server**, delle sole funzionalità di **modifica** così da consentire la **copia** e quindi il **salvataggio** della fotografia del Data Base in un dato momento senza con questo inibire la **consultazione**. In uno scenario ideale un parco utenti anche molto vasto è in realtà composto da una minoranza che ha funzioni di **redazione** ed una maggioranza che invece si limita alla **fruizione** dei **Data Base**. Lo scenario proposto consentirebbe quindi di limitare l'**operato** solo di una minoranza. |
| |
| === Scalabilità Orizzontale del Tier DataBase Server === | === Scalabilità Orizzontale del Tier DataBase Server === |
| |
| Questo è tra i progetti più ambiziosi ma, al contempo, uno dei più importanti.\\ | Questo è tra i **progetti** più **ambiziosi** ma, al contempo, uno dei più importanti. |
| Nei diversi scenari che sono stati presentati, specie in quelli complessi, è stato più volte posto in evidenza come la scalabilità verticale sia sempre garantita mentre quella orizzontale si riferisca esclusivamente ai primi due livelli del software in quanto attuali limiti tecnologici impediscono di garantire scalabilità sul livello che insiste sui Data Base.\\ | |
| Al fine di superare questo vincolo con il pieno rispetto delle diverse piattaforme su cui eXtraWay può essere installato (ed in considerazione di costituire anche installazioni scalate su hardware di diversa tipologia che si avvalgano di Sistemi Operativi diversi) esiste un progetto di realizzazione di un servizio di sincronizzazione e locking delle basi dati da installare parallelamente ad eXtraWay su tutti i server coinvolti nel cluster. A tale servizio verrebbe demandato il compito di garantire un accesso sempre corretto e, la dove necessario, esclusivo unendo le esigenze del Back Office con la grande flessibilità del Front Office.\\ | Nei diversi **scenari** che sono stati presentati, specie in quelli complessi, è stato più volte posto in evidenza come la **scalabilità verticale** sia sempre garantita mentre quella orizzontale si riferisca esclusivamente ai primi due livelli del software in quanto attuali **limiti tecnologici** impediscono di garantire scalabilità sul livello che insiste sui **Data Base**. |
| Ad esso può affiancarsi, ulteriormente, un intervento sull'Arbiter, che comunque sarebbe una componente indispensabile in un simile scenario, perchè le attività redazionali vengano distribuite equamente su tutti i server per ottenere la miglior distribuzione di carico ovvero concentrate su un singolo server del cluster, il principale di essi, per ottimizzare proprio il compito del servizio di sincronizzazione.\\ | |
| Una volta realizzato questo servizio le possibilità di scalatura delle configurazioni eXtraWay diverrebbe, di fatto, senza limite. | Al fine di superare questo **vincolo** con il pieno rispetto delle diverse piattaforme su cui eXtraWay può essere installato (ed in considerazione di costituire anche **installazioni scalate** su hardware di diversa tipologia che si avvalgano di Sistemi Operativi diversi) esiste un progetto di realizzazione di un **servizio** di **sincronizzazione** e **locking** delle basi dati da installare parallelamente ad eXtraWay su tutti i **server** coinvolti nel **cluster**. A tale servizio verrebbe demandato il compito di garantire un **accesso** sempre corretto e, la dove necessario, esclusivo unendo le esigenze del **Back Office** con la grande **flessibilità** del **Front Office**. |
| | |
| | Ad esso può affiancarsi, ulteriormente, un intervento sull'**Arbiter**, che comunque sarebbe una componente indispensabile in un simile scenario, perché le **attività redazionali** vengano distribuite equamente su tutti i **server** per ottenere la miglior **distribuzione** di **carico** ovvero concentrate su un **singolo server** del **cluster**, il principale di essi, per ottimizzare proprio il **compito** del servizio di **sincronizzazione**. |
| | |
| | Una volta realizzato questo servizio le possibilità di **scalatura** delle **configurazioni eXtraWay** diverrebbe, di fatto, senza limite. |
| |
| === Servizio di Content Server === | === Servizio di Content Server === |
| |
| Le applicazioni documentali quali quelle che ci si propone di realizzare con eXtraWay fanno ampio uso di documenti informatici e digitali da considerarsi come allegati dei singoli record degli archivi.\\ | Le **applicazioni documentali** quali quelle che ci si propone di realizzare con **eXtraWay** fanno ampio uso di **documenti informatici** e **digitali** da considerarsi come **allegati** dei **singoli record** degli **archivi**. |
| Essi possono essere di dimensioni contenute come di ampie dimensioni così come possono essere in numero esiguo come in quantità ragguardevoli. L'esperienza insegna che solitamente essi rappresentano una parte imponente dell'intero Data Base, per dimensioni ed aspetti quantitativi.\\ | |
| Parimenti di questi file si può dire che:\\ | |
| * Nella stragrande maggioranza dei casi non possono e non devono essere mai cambiati, al limite sottoposti a versioning, operazione che ne deve comunque garantire la reperibilità in originale. Essi possono quindi essere sottoposti a Backup meno frequenti in quanto destinati ad essere invariabili ma vengono ad appartenere sempre e comunque ai Backup di tutto l'archivio. | |
| * A seconda della natura di tali files le applicazioni possono aver necessità di sfruttarne delle trasformazioni, basti pensare ad un file .PDF non modificabile come versione pubblica di un documento effettivamente registrato in formato Microsoft Word oppure un'immagine ad alta risoluzione della quale si voglia mostrare una versione ridotta (thumb nail) ovvero una versione non sfruttabile perché modificata con un WaterMark. Ciascuna di queste conversioni dev'essere pianificata a monte perché essa possa essere sfruttata applicativamente. | |
| Ciascuno di questi casi viene attualmente gestito da strumenti esistenti che vanno dalla politica di distribuzione degli allegati su disco, alla gestione delle loro trasformazioni con procedure off-line alla realizzazione di complesse modalità di Backup per ottenere risultati parziali. | |
| |
| Con la realizzazione di un simile strumento esso può essere sottoposto a proprie politiche di Backup e replicazione, può compiere autonomamente ed a run-time le conversioni richieste rendendole estremamente dinamiche ed adattabili quindi al variare delle esigenze applicative senza dover compiere attività di manutenzione/trasformazione del Data Base.\\ | Essi possono essere di **dimensioni** contenute come di ampie dimensioni così come possono essere in numero esiguo come in quantità ragguardevoli. L'**esperienza** insegna che solitamente essi rappresentano una parte imponente dell'intero **Data Base**, per **dimensioni** ed **aspetti quantitativi**. |
| A sua volta esso può rappresentare un ulteriore grado di scalabilità orizzontale del tier inerente i DataBase con un ulteriore beneficio sia prestazionale che architetturale. | |
| | Parimenti di questi **file** si può dire che: |
| | |
| | * Nella stragrande maggioranza dei **casi** non possono e non devono essere mai cambiati, al limite sottoposti a **versioning**, operazione che ne deve comunque garantire la **reperibilità** in **originale**. Essi possono quindi essere sottoposti a **Backup** meno frequenti in quanto destinati ad essere **invariabili** ma vengono ad appartenere sempre e comunque ai **Backup** di tutto l'**archivio**. |
| | * A seconda della natura di tali files le **applicazioni** possono aver necessità di sfruttarne delle **trasformazioni**, basti pensare ad un **file** ''.PDF'' **non modificabile** come versione pubblica di un documento effettivamente registrato in formato **Microsoft Word** oppure un'**immagine** ad **alta risoluzione** della quale si voglia mostrare una **versione ridotta** (**thumb nail**) ovvero una versione non sfruttabile perché modificata con un **WaterMark**. Ciascuna di queste conversioni dev'essere pianificata a monte perché essa possa essere sfruttata applicativamente. |
| | Ciascuno di questi casi viene attualmente gestito da **strumenti esistenti** che vanno dalla **politica** di **distribuzione** degli **allegati** su **disco**, alla gestione delle loro **trasformazioni** con procedure off-line alla realizzazione di complesse modalità di **Backup** per ottenere risultati parziali. |
| | |
| | Con la realizzazione di un simile strumento esso può essere sottoposto a proprie **politiche** di **Backup** e **replicazione**, può compiere autonomamente ed a **run-time** le **conversioni** richieste rendendole estremamente **dinamiche** ed **adattabili** quindi al variare delle esigenze applicative senza dover compiere attività di manutenzione/trasformazione del Data Base. |
| | |
| | A sua volta esso può rappresentare un ulteriore grado di **scalabilità orizzontale** del **tier** inerente i **DataBase** con un ulteriore **beneficio** sia **prestazionale** che **architetturale**. |
| |
| ===== Glossario, Acronimi e Note ===== | ===== Glossario, Acronimi e Note ===== |
| |
| Questo documento descrive il significato dei termini più frequentemente utilizzati nella documentazione inerente il server e la piattaforma documentale **eXtraWay**.\\ | Questo **documento** descrive il **significato** dei **termini** più frequentemente utilizzati nella **documentazione** inerente il **server** e la **piattaforma documentale eXtraWay**. |
| La conoscenza dei significati di questi termini può essere fondamentale per la corretta comprensione della documentazione. | |
| | La **conoscenza** dei **significati** di questi termini può essere fondamentale per la **corretta comprensione** della **documentazione**. |
| |
| ^DocWay |Applicazione di Protocollo Informatico e Gestione Documentale realizzata facendo uso della Piattaforma eXtraWay| | ^DocWay |Applicazione di Protocollo Informatico e Gestione Documentale realizzata facendo uso della Piattaforma eXtraWay| |
