[Gfoss] Architettura SIT Open Source

Local Chapters GFOSS.it
1

Mi permetto di intervenire sul documento della Reg. Puglia, per dare alcuni suggerimenti.

L’architettura che viene proposta in tale documento non va considerata come una qualsiasi architettura, a cui si puo’ contrapporre una’ltra architettura.

Ed e’ vero che se ne puo’ proporre tante e anche di tipo OS altrettanto valide, con vantaggi e svantaggi.

Ma bensi’ e’ una architettura che trae la sua ragion di essere dal riuso del progetto Sigmater.
Un progetto in cui sono state sviluppate diverse componenti anche rilevanti e che funziona sulla base di tale architettura.

Per cui una proposta alternativa non dovrebbe essere finalizzata solo
al fornire un elenco di prodotti alternativi, ma dovrebbe scontare anche l’onere di dover riadattare o ri-scrivere quanto gia’ esiste all’interno del progetto Sigmater.

come citato al capitolo 5 punto b)

l’architettura generale del sistema, nella logica del “RIUSO” e della interoperabilità, dovrà
essere coerente con la impostazione architetturale prevista dal progetto SigmaTER ovvero, più
in generale, dal progetto “Estensione dei Servizi informativi Integrati per la gestione del
Territorio”, con riferimento ai seguenti livelli dello Stack tecnologico di riferimento: Sistema
Operativo, Web server, Application Server J2EE compliant, RDBMS, MapServer, ImageServer.

Anche se a onor del vero, alcuni punti di tale elenco non fanno specificamente parte del progetto Sigmater, come ad esempio Arcgis server, arcsde e arcims non mi risulta fossero elencati nello stack tecnologico originale del progetto sigmater.
(Il loro ruolo in Sigmater sarebbe comunque marginale)

Mentre invece lo sono senzaltro oracle 10g e oracle OAS.

Andrea.

–

§ Andrea §
§ Peri §
2

On Tue, Jan 29, 2008 at 05:40:29PM +0100, Andrea Peri wrote:

Ma bensi' e' una architettura che trae la sua ragion di essere dal riuso del
progetto Sigmater.
Un progetto in cui sono state sviluppate diverse componenti anche rilevanti
e che funziona sulla base di tale architettura.

Per cui una proposta alternativa non dovrebbe essere finalizzata solo
al fornire un elenco di prodotti alternativi, ma dovrebbe scontare anche
l'onere di dover riadattare o ri-scrivere quanto gia' esiste all'interno del
progetto Sigmater.

Una domanda da ignorante della materia.
Le licenze dei componenti gia' usati in precedenza, non verrebbero pagate
nuovamente per un nuovo utilizzo ?
Intendo dire, dov'e' la logica del riuso esattamente ?

Il costo del "collante" sviluppato in casa puo' davvero eccedere
quello delle licenze dei componenti ?

--strk;

3

Intanto dire che il fatto che sia iscritto al Riuso da’ gia’ una risposta.

Il riuso e’ una delle grandi iniziative che si sono avute nel 2007

http://www.cnipa.gov.it/site/it-IT/Attivit%C3%A0/E-gov__per_Regioni_ed_Enti_locali/Linee_di_azione_(II_fase)/Linea_2._(riuso)/
e
http://riuso.cnipa.gov.it/soluzioni/iniziativa.bfr

Tra i punti caratterizzanti al link n.ro 2
vi sono il punto d) e il punto g) :wink:

d) garantire benefici economici e gestionali rilevabili e misurabili;
g) favorire la diminuzione della spesa per licenze d’uso.

Al link seguente,
http://www.sigmater.it/template1.asp?itemID=11&level=1&label=riuso
e’ indicato che Sigmater e’ “riusabile”, cosa del resto segnalata nel bando che Ivano aveva riportato.

Per cui ne dedurrei che Sigmater, consente delle “economie” in linea con i principi del bando del riuso.

E’ poi evidente che ognuno si fa’ i conti in casa sua e decide sulla base di specifiche situazioni.
Chi gia’ dispone di tali architetture ha dei costi in meno, chi le deve acquisire ha dei costi in piu’ e magari puo’ decidere di ricorrere ad altre soluzioni.
Ovviamente deve fare i conti per bene e soppesare tutte le voci di costo , compreso il costo di sviluppo del “collante” che puo’ risultare non cosi’ semplice come a prima vista si potrebbe ritenere.
Qui direi che molto dipende dalla “bonta” di chi sviluppa. Un buon sviluppatore puo’ abbattere i costi di sviluppo. Un pessimo sviluppatore li aumenta, specie se sono pagati a giornate.

Andrea.

Una domanda da ignorante della materia.

Le licenze dei componenti gia’ usati in precedenza, non verrebbero pagate
nuovamente per un nuovo utilizzo ?
Intendo dire, dov’e’ la logica del riuso esattamente ?

Il costo del “collante” sviluppato in casa puo’ davvero eccedere
quello delle licenze dei componenti ?

–strk;

–

§ Andrea §
§ Peri §
4

Ciao, il tuo intervento è giusto, approfondisco solo alcuni punti per
chiarire meglio in che contesto è inserito Sigmater e quindi perchè la
mia proposta di architettura non è del tutto "campata in aria"

Mi permetto di intervenire sul documento della Reg. Puglia, per dare alcuni
suggerimenti.

L'architettura che viene proposta in tale documento non va considerata come
una qualsiasi architettura, a cui si puo' contrapporre una'ltra
architettura.

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
(lo so per esperienza diretta) in un, appunto, sistema di
integrazione.

Ma bensi' e' una architettura che trae la sua ragion di essere dal riuso del
progetto Sigmater.

In cui per esempio non c'è una componente di visualizzazione, che deve
essere realizzata ad -hoc. Tanto per fare un esempio.

Un progetto in cui sono state sviluppate diverse componenti anche rilevanti
e che funziona sulla base di tale architettura.

Per cui una proposta alternativa non dovrebbe essere finalizzata solo
al fornire un elenco di prodotti alternativi, ma dovrebbe scontare anche
l'onere di dover riadattare o ri-scrivere quanto gia' esiste all'interno del
progetto Sigmater.

Questo è vero. Come ho detto in separata sede è tutta una questione
di tempi di sviluppo, possibilità economiche e lungimiranza (tirare su
un architettura ex-novo richiede anche una certa flessibilità, tipo
capire cosa si può fare OLTRE alla soluzione del problema contingente)

come citato al capitolo 5 punto b)

>l'architettura generale del sistema, nella logica del "RIUSO" e della
interoperabilità, dovrà
>essere coerente con la impostazione architetturale prevista dal progetto
SigmaTER ovvero, più
>in generale, dal progetto "Estensione dei Servizi informativi Integrati per
la gestione del
>Territorio", con riferimento ai seguenti livelli dello Stack tecnologico di
riferimento: Sistema
>Operativo, Web server, Application Server J2EE compliant, RDBMS, MapServer,
ImageServer.

Anche se a onor del vero, alcuni punti di tale elenco non fanno
specificamente parte del progetto Sigmater, come ad esempio Arcgis server,
arcsde e arcims non mi risulta fossero elencati nello stack tecnologico
originale del progetto sigmater.
(Il loro ruolo in Sigmater sarebbe comunque marginale)

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.
Un'altro appunto: Sigmater prevede anche JBOSS e Websphere.

Il riuso è sui componenti "applicativi" non sui componenti infrastrutturali!

Ciao!