Differenze

Queste sono le differenze tra la revisione selezionata e la versione attuale della pagina.

--- utenti:extraway_platform_server:extraway_overview [2023/03/21 10:21] – [Gli scenari di base disponibili] chiara.pavanati
+++ utenti:extraway_platform_server:extraway_overview [2023/03/21 11:53] (versione attuale) – [Glossario, Acronimi e Note] chiara.pavanati
@@ Linea 561: / Linea 561: @@
 ==== 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 ===
-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}}
@@ Linea 577: / Linea 577: @@
 === 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__.
@@ Linea 585: / Linea 585: @@
 __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}}
-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}}
@@ Linea 599: / Linea 599: @@
 ==== 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.
-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 ====
-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__.
-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 ====
-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 ====
-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:
 === 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 ===
-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 ===
-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 =====
-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|