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

[Ivano Picco]

scusate se riallego il messaggio ma il mio sistema mobile ha qualche problema:

se non ho capito male il discorso sull'architettura è fortemente
vincolato dall'utilizzo di componenti realizzati con tecnologie
proprietarie. il discorso regge se non ci sono alternative, ovvio,
quindi: quanto è incompatibile pl-pgsql nei confronti di pl-sql??

Arcgis server non è solo il nuovo nome di arcsde. È anche application
server. dipende da cosa compri. in sigmater arcgis server non è un
componente dell'architettura oggetto dei pezzi applicativi in riuso
nel nucleo base. nel contesto della proposta di architettura oggetto
della domanda nel thread iniziale era fuori dalle parti necessarie per
compatibilità con sigmater. era di più.

il visualizzatore può benissimo essere replicato con poca spesa,
essendo i dati in oracle spatial. senza la necessità di oas. poi si
parlava del nucleo del riuso e non del sistema sigmater realizzato da
RT. almeno, io l'ho intesa in tal senso..

On 1/30/08, Andrea Peri <peri.rtoscana a gmail.com> wrote:
> 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                 §
> ~~~~~~~~~~~~~~~~~
>

-- 
Sent from Gmail for mobile | mobile.google.com