Simpatia e antipatia sono sentimenti giustificati, poiche' investono la sfera soggettiva.
Io stesso quando scrivo un programma, nel mio piccolo, in genere dopo averlo scritto, mi rimane sempre un po' antipatico, perche' con il senno del poi, vedo sempre i difetti e non i pregi, e mi pento regolarmente delle scelte fatte nello sviluppo. (Non hai idea di quanto mi sia antipatico "Castore".) Nel caso di Sigmater, se anziche' i prodotti commerciali che vi sono dentro, avesse avuto come base di sviluppo dei prodotti FOSS, quali ad esempio, Postgres+postgis e GeoServer (o mapserver) e Tomcat (o JBoss) avrebbe avuto un'altra percezione verso certe utenze, e forse anche una differente possibilita' di utilizzo. Pero' , non per giustificare chi ha stilato le specifiche (oltretutto non conosco quali sono state le considerazioni che hanno portato a tale architettura.), se posso azzardare delle ipotesi: all'epoca il db di riferimento OS era senz'altro MySQL, con la componente spaziale che conosciamo. Postgres non aveva ancora un modulo spaziale cosi' evoluto come lo e' ora. E in prospettiva Oracle dava maggiori garanzie di supporto ed evoluzione. Per la parte Middleware (OAS) il discorso e' forse piu' sottile. Si cercava senz'altro una piattaforma enterprise, all'epoca vi era gia' JBoss e poteva essere un buon candidato, ma non aveva una gran base di installato, e forse era un po' un salto nel buio. Li' forse, ha prevalso una logica di mercato e la scelta di OAS e' stata principalmente dovuta al fatto che era un prodotto abbastanza conosciuto da parte di chi avrebbe sviluppato il sistema. Una prova del fatto che la scelta del middleware sia stata piu' soggettiva, e' dettata dal fatto che comunque bene o male, come faceva notare Ivano, la parte middleware, viene piu' o meno regolarmente portata anche su WebSphere e su JBoss stesso. Segno che si e' cercato sulmiddleware, di mentenere un profilo neutrale, senza fare un uso pesante di elementi specifici di un prodotto, cosa che lo avrebbe reso senz'altro poco portabile. Devo comunque spendere una parola tecnica a favore del DB adoperato in Sigmater. Le operazioni che il DBMS e' chiamato a compiere ogni volta che parte un aggiornamento sono talmente onerose, che metterebbero alle corde qualsiasi DB. Nel caso specifico di Sigmater e' stata adottata una tecnica molto sofisticata, chiamata exchange-partition. Che si basa sulla atomizzazione dello spostamento di una mole considerevole di dati come se fosse una operazione unica. Mi spiego meglio. Quando si deve spostare qualche decina di Gbytes, da alcune parti di un DB verso altre, questo comporta del tempo. Durante questo lasso di tempo gli utenti devono poter accedere analogamente ai dati e non perderli di vista. Per cui l'operazione deve atomizzarsi, ovvero un istante prima ci sono i vecchi dati, un istante dopo ci sono i nuovi. Questo deve essere percepito cosi' nonostante lo spostamento fisico dei dati comporti magari qualche ora di tempo. tenendo anche presente che se durante questi spostamenti avvengono delle violazioni di FK (cosa non infrequente nei dati catastali), anche il rollback deve atomizzarsi. Questo non si riusciva ad ottenerlo con il semplice comando di commit, perche' durante l'elaborazione dei dati venivano effettuate delle operazioni che per loro natura sono autocommittanti, per cui non era possibile avere un unico commit alla fine di tutto, ma si avevano dei commit intermedi che a fronte di un errore sui dati verso la fine, non sarebbe stato possibile con il rollback tornare allo stato originale, e i dati sarebbero rimasti in uno stato ibrido. Per ottenere questo, in Sigmater, si e' fatto ricorso a una peculiarita' di Oracle, la cosidetta operazione di exchange-partition. Trattasi di una caratteristica che e' propria di oracle enterprise e non appartiene al mondo dei DB OS. Onde per cui probabilmente la scelta e' stata anche motivata dai meccanismi che Oracle metteva a disposizione. Certo potevano essere usate altre soluzioni o altre tecniche, o magari mettere in piedi piu' macchine o piu' DB. Ognuna avrebbe avuto i suoi pregi e i suoi difetti. Andrea. Paolo Cavallini ha scritto: > > Scusate se cerco di metterla piu' sul semplice: a me (cittadino, ancor > prima che GISsaro) SigmaTer piacerebbe se fosse implementabile anche con > FOSS. Il fatto che richieda (se interpreto correttamente) > *necessariamente* un determinato DB proprietario me lo rende antipatico. > pc _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [email protected] http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it.
