> Mooooolto interessante, stavamo giusto discutendo di fare una cosa > simile per GeoServer :-).
Mi ha sempre piaciuto REST, ma anche python, e guando si vede come e' minimo feature server, no si puo non inamorarsi ;-) > Diciamo che ci sono due strade su cui le persone si stanno muovendo. > Una è aggiungere funzionalità come routing e geocoding a WFS come > sotred procedure or something like it, l'altro approccio è di mettere > un bel WPS > su per fare le operazioni in modo da non " incasinare" la divisione in > tier proprio dei servizi OGC (WFS data management, WPS business loigc > aka processing). Ho scoperto oggi che per WPS esiste un fratello di featureserver che sembra ugualmente elegante e REST: Guardati la demo: http://crschmidt.net/mapping/wpserverdemo/ Certo che wps e' meglio che fare una cosa monolitico in stored procedures... Ma piccolo e elegante in REST mi sembra piu' addatto per uso interno che la stessa cosa molto piu' pesante.. > Noi in questo momenti stiamo lavorando un pochino su WPS con > l'obiettivo di integrarli in una architettura enterprise con workflow > management. Ci sono alcuni progetti interessanti da usare e riusare, > stiamo valutando se integrare qualcosa in geoserver o meno. Stiamo poi > guardando a udig perche' esiste un plugin per accedere a WPS piu' > svariati tools basati su eclipse RCP per fare workflow management. So di udig ma fin ora mi sono orientato molto piu' verso qGIS. Sara' perche C/python mi e' molto piu' simpatico che Java... > Mio modestissimo parere. Qualcuno piu' noto e bravo di me ha detto > "l'ottimizzazione precoce è la radice di tutti i mali" e concordo, > ma cmq il punto è che si deve tenere conto a livello architetturale > dei problemi di performance e lasciare spazio alle soluzioni > altrimenti poi son guai! Si, sono d'accordo che l'architettura limita fortemente la scalabilita' e che non si cambia al volo in un secondo passo. Detto questo, non penso che noi per usi interni abbiamo bisogno di una architettura "enterprise" (come in J2EE con EJB e tutto cio') e il time to market e' molto piu' importante ;-) > > Verso il fuori (cittadini, potenzialmente tanti), la situazione e' > > certamente molto diverso--ma anche il fabbisogno di creare e modificare > > geometrie (la maggiore ragione per quale vorrei vector tramite web) e' > > molto limitato (a mettere qualche punto con annotazione su qualche > > piano oppure in casi eccezionali un poligono...). > > > > Hai pensato a gestire la sicurezza con un approccio RBAC? Ci sono > cosine interessanti da tenere conto in fase di progetto anche se > magari le si implementa poi. Si, per tutti servizi tramite web, noi usiamo RBAC. E' molto usato da noi; ad esempio per i scedolini dei impiegati e par le forze dell'ordine che accedono a alcuni dei nostri dati dall'esterno. Per tutto questo richiediamo smartcards per autenticazione (incluso la CIE che emettiamo noi). A proposito, sono io l'architetto della nostra soluzione e ho implementato la prima versione dell'apache handler che fa l'autenticazione. Piccolo, semplice, e sicuro ;-) La cosa bella del REST e' che lostesso sistema funziona anche qui ;-) Detto questo, attualmente al interno usiamo qGIS che accede a postgres tramite username/password. Ma internamente, la sicurezza e' diverso che sul internet ostile ed i rischi non sono tanto alti (al meno se inizio fare backups ;-). Ma siccome mi piace semplicita', provo di semplificare il problema di controllo di accessi al massimo: avere quanto possibile dati sotto una licenza aperta (ancora da raggiungere ;-) saluti -b _______________________________________________ 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.
