Sigmater e’ composto da tanti moduli, alcuni possono essere usati a se stanti, altri hanno senso solo all’interno dell’architettura complessiva.
Considerarli come un unico prodotto o come tanti prodotti, e’ pun problema di capirsi.
Se guardi il link che avevo indicato .
http://www.sigmater.it/template1.asp?itemID=11&level=1&label=riuso
Al punto A.2 e al punto A.3 viene indicato l’ SXCR.
Trattasi di sistema che si interfaccia con Oracle DB e fa usa pesante di store-procedure scritte in pl-sql. Questo gia’ da ’ una indicazione. Le store-proc sono scritte in linguaggi nativi e nel caso di oracle si usa il PL-SQL.
Che determina lla necessita’ di avere oracle.
Naturalmente se poi si tratta di una store-proc di 10 righe si puo’ anche riscrivere, ma se, invece, e’ una serie di store-procedure e package che complessivamente racchiudono migliaia di righe di codice e’ pura utopia pensare di convertirle senza spendere niente o comunque spendendo poco.
Al punto A.4 si indica il DBTI.
E il sistema di caricamento del DBTI medesimo. L’ambiente di caricamento e’ realizzato in java e quindi e’ riciclabile. Ma se il programma in java fa’ anche esso riferimento a specifiche store-procedure che sono al solito nel linguaggio nativo Oracle vale lo stesso discorso di sopra.
Punto A.6 :
Applicazione General Purpose
Questa e’ realizzata in java tramite EJB ed effettivamente e’ riciclabile con un po’ di sforzo su altre piattaforme di pari livello, prova ne e’ che in sincrono con lo sviluppo sulla piattaforma ufficiale (OAS) viene realizzato (con un po’ di ritardo probabilmente) il porting su WebSphere di Ibm e su JBoss.
Il punto e’ intendersi se per sigmater si intende solo la parte di servizi offerti all’utenza, e quindi si vede solo la parte web, in tal caso il resto e’ un buglione indistinto in cui non si sa’ bene cosa ci stia dentro.
O se si vuole considerare anche la parte di gestione dei dati e aggiornamento dei medesimi.
Questa seconda parte e’ fortemente dipendente da Oracle DB per le ragioni sopra dette.
In realtà in ottica di sistema di integrazione un’architettura
dovrebbe valere un’altra. Sigmater non è un prodotto ben definito, un
pacchetto i cui pezzi li installi qui, gli altri là etc etc. E’ più un
collage di pezzi, che devono essere modificati perchè parlino tra loro
Il fatto che i singoli pezzi si possano separare in piu’ macchine e’ perche’ Sigmater vuole essere un sistema scalabile.
Il che non e’ di per se’ una prova che siano pezzetti tipo lego che uno stacca e ci mette un altro DB e tutto magicamente funziona da se’.
La scalabilita’ e’ indice solo che se prima tenevi tutto su una macchina e poi quella macchina non ce la fa’ piu’, metti 2, 3, … 10 macchine separi i pezzi nelle varie macchine e tutto continua a funzionare bene.
Ma i pezzi devono restare quelli originariamente previsti.
Ad esempio il DB di sigmater si compone di vari pezzi, DBI, Staging e DBTI, che possono essere su una sola macchina o su piu’ macchine , essi vengono tenuti insieme da una specifica configurazione detta DB-LINK, che consente di presentare diversi database contenuti su DBMS separati su macchine differenti come se fossero un unico DB installato su una sola macchina.
Tecnicamente pregevole, anche se complica un po’ la gestione.
Ovviamente lo fai se ti serve , se il carico di lavoro del DBMS e’ tale che ti conviene scalare le macchine, altrimenti non lo fai e tieni tutto su una macchina sola.
Se provi a sostituire al DBMS oracle un altro sistema il sistema non funziona piu’.
Le store-procedure scritte in PL-SQL non mi risulta che esistano altri DB in grado di eseguirle senza battere ciglio.
In cui per esempio non c’è una componente di visualizzazione, che deve
essere realizzata ad -hoc. Tanto per fare un esempio.
Questo non e’ esatto, e lo dico con cognizione di causa visto che il ruolo di Regione Toscana nel progetto Sigmater e’ stato proprio quello di realizzare da zero una interfaccia di navigazione webonline basata sullo stack tecnologico originale di sigmater.
se la vuoi vedere puoi guardarla a questo link.
http://www.rete.toscana.it/sett/territorio/carto/progetti/sigmater.htm
e clicckando su “dati territoriali accesso pubblico”
Il fatto che poi altri enti in Sigmater abbiano poi optato per non usarla e ricorrere invece, a soluzioni proprie basate su altri prodotti, e’ secondario.
Infatti, nel riuso uno puo’ usare quello che gli pare, e quindi se non vuole riusare l’interfaccia gisonline, ma solo la parte di navigazione sui servizi catastali ICI, Tarsu, etc… che sono alfanumerici tradizionali e come tali si possono portare facilmente su JBoss, nessuno lo vieta.
Il ruolo di RT in Sigmater era sviluppare tale componente restando rigidamwente ancorata allo stack tecnologico di Sigmater
E quindi e’ stato fatto uso di MapViewer, un prodotto di navigazione gisonline fornito gratuitamente da Oracle (e scaricabile via web), che ha l’unica peculiarita’ di volere obbligatoriamente oracle DB e oracle OAS (Entrambi presenti nella architettura di Sigmater
). E su quello sono stati sviluppati interfacce, webservices, ejb e quanto altro era previsto.
No, non ne fanno parte. Ma appunto, se si presenta un’architettura
basata su ARCGIS Server allora le alternative possibili diventano
“molteplici” e non strettamente legate a Sigmater.
??
Questa non la capisco .
Tutto e’ riusabile al di fuori di Sigmater, basta volerlo e avere la capacita’ di farlo.
RT ha sviluppato appunto una webgis usando MapViewer e ora la sta riusando per altri progetti, e la sta’ anche evolvendo. La versione che vedi al link, infatti e’ una versione evoluta.
Che serve non solo per Sigmater , ma anche per altri progetti.
ArcGIS server e’ un prodotto di middle-level che ha la peculiarita’ di rendere usabile geograficamente anche dei DBMS che geografici non sono (nel senso che non hanno al loro interno dei moduli spaziali).
In questo senso OAS e’ meno completo di ArcGIS server, e analogamente lo e’ MapViewer, ma lo sono perche’ sanno di poter contare (nel bene e nel male) su un DB (oracle db appunto) che al suo interno ha un modulo spaziale molto potente.
Analogo se si usasse una soluzione basata su postgres+postgis.
Le operazioni spaziali le puo’ fare benissimo postgis e quindi non serve un ambiente “di mezzo” dotato di una forte caratterizzazione sulle analisi spaziali, ma basta un ambiente piu’ tradizionale, come ad esempio JBoss o OAS o similari e una componente di visualizzazione geografica, come appunto e’ MapViewer.
Aggiungo che poi la parte di aggancio tra i servizi di consultazione catastale alfanumerici (ICI, tarsu, etc…) e la parte di navigazione geografica gisonline prevede anche di passare da chiamate a un server WMS.
Per cui’ e’ molto facile introdurre altri prodotti per la parte del server WMS.
Pero’ non so’ se a oggi qualche ente ha attivato questa parte.
Il riuso è sui componenti “applicativi” non sui componenti infrastrutturali!
L’ SXCR si occupa di caricare la parte staging del DB e per questo ci sono delle store-proc. specifiche per oracleDB, poi devi passare tutto su DBTI e anche li’ vi sono analoghe store-proc.
In alternativa come caricheresti il DBTI ?
Ciao !
–
§ Andrea §
§ Peri §