[Gfoss] [OT] Architettura Sigmater: era Architettura SIT Open Source

[Andrea Peri]

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                 §
~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.faunalia.com/pipermail/gfoss/attachments/20080130/cb5811b1/attachment.htm