Che ne pensate di questa trovata di mettere SOAP come prerequisito
essenziale per l'infrastruttura INSPIRE? A me pare una notevole
baggianata, che complichera' orribilmente la vita a *tutti*, ma
sicuramente sto perdendo di vista qualcosa di importante.
Qualcuno ha una visione piu' chiara?
--
Paolo Cavallini
http://www.faunalia.it/pc
Sul precedente thread il commento di Lorenzo era positivo... Non dico
che SOAP non debba essere previsto, considerando che in certe
applicazioni distribuite è lo standard, ma quello che non capisco è
perché debba essere reso *necessario*. Tanti hanno scelto altre vie,
come ad esempio servizi di tipo RESTful, quindi ho l'impressione che
l'introduzione di SOAP si tradurrà in complesità (e ritardi) per
molti.
Ripeto, niente in contrario a SOAP di per sé... Ma personalmente avrei
accelerato su altri aspetti di INSIPRE.
--
giovanni
Il 13/07/07, Paolo Cavallini <cavallini@faunalia.it> ha scritto:
Che ne pensate di questa trovata di mettere SOAP come prerequisito
essenziale per l'infrastruttura INSPIRE? A me pare una notevole
baggianata, che complichera' orribilmente la vita a *tutti*, ma
sicuramente sto perdendo di vista qualcosa di importante.
Qualcuno ha una visione piu' chiara?
--
Paolo Cavallini
http://www.faunalia.it/pc_______________________________________________
Gfoss mailing list: 234 iscritti (13-07-2007)
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Paolo, Giovanni,
pensare adesso che SOAP sia un prerequisito essenziale mi sembra per lo meno prematuro.
Primo: i giochi di INSPIRE sono ancora aperti, quanto è ora in circolazione è una serie di documenti in bozza (draft1). Nel suo post Jo scrive " As it stands, the draft Rules …", ed infatti si tratterà di una draft1 da commentare come SDIC o LMO, per tirare fuori una draft2 da commentare successivamente con consultazione pubblica.
Quindi, appena saranno pubblicate i draft sui network service cerchiamo tutti di mandare più commenti possibile! (*)
Secondo: INSPIRE si rivolge agli Stati membri, che dovranno mettere in pratica sia la parte legislativa (recepire la direttiva) che la parte tecnica (recepire le IR). Chissà cosa viene fuori da noi con il Sistema Pubblico di Connettività ??
pg
(*) a proposito: perchè non registrare GFOSS come SDIC ?? … Sempre che si riesca a rintracciare da qualche parte il presidente di Gfoss.it !!
On 7/13/07, G. Allegri < giohappy@gmail.com> wrote:
Sul precedente thread il commento di Lorenzo era positivo… Non dico
che SOAP non debba essere previsto, considerando che in certe
applicazioni distribuite è lo standard, ma quello che non capisco è
perché debba essere reso necessario. Tanti hanno scelto altre vie,
come ad esempio servizi di tipo RESTful, quindi ho l’impressione che
l’introduzione di SOAP si tradurrà in complesità (e ritardi) per
molti.
Ripeto, niente in contrario a SOAP di per sé… Ma personalmente avrei
accelerato su altri aspetti di INSIPRE.giovanni
Il 13/07/07, Paolo Cavallini <cavallini@faunalia.it > ha scritto:
Che ne pensate di questa trovata di mettere SOAP come prerequisito
essenziale per l’infrastruttura INSPIRE? A me pare una notevole
baggianata, che complichera’ orribilmente la vita a tutti, ma
sicuramente sto perdendo di vista qualcosa di importante.
Qualcuno ha una visione piu’ chiara?Paolo Cavallini
http://www.faunalia.it/pc
Gfoss mailing list: 234 iscritti (13-07-2007)
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Gfoss mailing list: 234 iscritti (13-07-2007)
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
–
Piergiorgio Cipriano
pg.cipriano@gmail.com
Dimenticavo …
Terzo: prima ancora di SOAP c’è da considerare che le IRs di servizi come il WMS fanno/faranno riferimento a standard come ISO19128, che è WMS 1.3.0 !!
Quindi prima di tutto occorre essere compliant con la 1.3.0 (visto che la 19128 è norma europea, e quindi cogente).
Quarto: OGC si sta già muovendo sul tema da qualche anno:
OWS 2 Common Architecture: WSDL SOAP UDDI
http://portal.opengeospatial.org/files/?artifact_id=8348
7.1.2 WSDL for WCS 1.0.0
There is a strong incompatibility between the current OGC WCS GET interface and the possibility of WSDL. The WCS specification 1.0.0 requires the use of arbitrary parameter names (e.g. BAND=…), and the WSDL message definition needs to be exhaustive about the possible parameter names.
…
There is an issue with operations that only provide a binary as response message. This limitation applies to WCS GetCoverage and WMS GetMap. There exists no such thing as an ‘xsd:binary’ type, which would be needed to define the response message part.
WMS Change Request: Support for WSDL & SOAP
http://portal.opengeospatial.org/files/?artifact_id=9541
This change proposal is an outcome of the Common Architecture thread of the OpenGIS Web Service 2 initiative. The aim is to add support for a standard WSDL description of the WMS interface in version 1.3.1.
…
Annex shall include WSDL definition and schema folder shall include wms_abstract.wsdl and wms.wsdl, as well as the common schemas as provided by OWS 2 Common Architecture work.
pg
---------- Forwarded message ----------
From: Piergiorgio Cipriano <pg.cipriano@gmail.com>
Date: Jul 13, 2007 12:24 PM
Subject: Re: [Gfoss] SOAP?
To: “G. Allegri” < giohappy@gmail.com>, Paolo Cavallini <cavallini@faunalia.it>
Cc: gfoss italia < gfoss@faunalia.com>, discussione@freegis-italia.org, forumigt@forumigt.it
Paolo, Giovanni,
pensare adesso che SOAP sia un prerequisito essenziale mi sembra per lo meno prematuro.
Primo: i giochi di INSPIRE sono ancora aperti, quanto è ora in circolazione è una serie di documenti in bozza (draft1). Nel suo post Jo scrive " As it stands, the draft Rules …", ed infatti si tratterà di una draft1 da commentare come SDIC o LMO, per tirare fuori una draft2 da commentare successivamente con consultazione pubblica.
Quindi, appena saranno pubblicate i draft sui network service cerchiamo tutti di mandare più commenti possibile! (*)
Secondo: INSPIRE si rivolge agli Stati membri, che dovranno mettere in pratica sia la parte legislativa (recepire la direttiva) che la parte tecnica (recepire le IR). Chissà cosa viene fuori da noi con il Sistema Pubblico di Connettività ??
pg
(*) a proposito: perchè non registrare GFOSS come SDIC ?? … Sempre che si riesca a rintracciare da qualche parte il presidente di Gfoss.it !!
On 7/13/07, G. Allegri < giohappy@gmail.com> wrote:
Sul precedente thread il commento di Lorenzo era positivo… Non dico
che SOAP non debba essere previsto, considerando che in certe
applicazioni distribuite è lo standard, ma quello che non capisco è
perché debba essere reso necessario. Tanti hanno scelto altre vie,
come ad esempio servizi di tipo RESTful, quindi ho l’impressione che
l’introduzione di SOAP si tradurrà in complesità (e ritardi) per
molti.
Ripeto, niente in contrario a SOAP di per sé… Ma personalmente avrei
accelerato su altri aspetti di INSIPRE.giovanni
Il 13/07/07, Paolo Cavallini <cavallini@faunalia.it > ha scritto:
Che ne pensate di questa trovata di mettere SOAP come prerequisito
essenziale per l’infrastruttura INSPIRE? A me pare una notevole
baggianata, che complichera’ orribilmente la vita a tutti, ma
sicuramente sto perdendo di vista qualcosa di importante.
Qualcuno ha una visione piu’ chiara?Paolo Cavallini
http://www.faunalia.it/pc
Gfoss mailing list: 234 iscritti (13-07-2007)
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Gfoss mailing list: 234 iscritti (13-07-2007)
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
–
Piergiorgio Cipriano
pg.cipriano@gmail.com
–
Piergiorgio Cipriano
pg.cipriano@gmail.com
Sul precedente thread il commento di Lorenzo era positivo...
Alla FAO stiamo sviluppando parecchio su OWS (WMS, WFS, ecc.).
Quando si tratta di far parlare le macchine fra di loro su una rete e spostare un bel po' di dati il sistema in testo semplice (XML) risulta come un collo di bottiglia.
Soap permette di muovere dati in formato binario e questo ha per lo meno il vantaggio di essere più efficiente in termini di prestazioni.
Penso (nessuna certezza) che il riferimento di INSPIRE a Soap sia più o meno così: "vogliamo una tecnologia per muovere i dati in maniera binaria, la più usata è SOAP: vogliamo SOAP".
Magari la vogliono anche perchè non è facile usare un DRM con il testo semplice...
Lo scopriremo presto.
So che ci sono contro ad usare Binary ma ce ne sono anche ad usare simple text. La cosa importante è che le specifiche siano ben pensate e scritte e poi c'è solo da aspettare che le implementazioni vengano fuori.
In ogni modo l'aggiunta delle interfaccia SOAP non vuol dire che non si possa continuare a supportare l'interfaccia XML.
Un client come OpenLayers, per esempio, non potrebbe più funzionare senza una interfaccia testuale.
ciao
Lorenzo
Grazie per le puntuali precisazioni. Ammettete però che in questo
momento c'è un bel caos a giro!
Mi rileggerò con più attenzione i draft...
Il 13/07/07, Lorenzo Becchi<lorenzo@ominiverdi.com> ha scritto:
> Sul precedente thread il commento di Lorenzo era positivo...
Alla FAO stiamo sviluppando parecchio su OWS (WMS, WFS, ecc.).
Quando si tratta di far parlare le macchine fra di loro su una rete e
spostare un bel po' di dati il sistema in testo semplice (XML) risulta
come un collo di bottiglia.
Soap permette di muovere dati in formato binario e questo ha per lo meno
il vantaggio di essere più efficiente in termini di prestazioni.
Penso (nessuna certezza) che il riferimento di INSPIRE a Soap sia più o
meno così: "vogliamo una tecnologia per muovere i dati in maniera
binaria, la più usata è SOAP: vogliamo SOAP".
Magari la vogliono anche perchè non è facile usare un DRM con il testo
semplice...
Lo scopriremo presto.
So che ci sono contro ad usare Binary ma ce ne sono anche ad usare
simple text. La cosa importante è che le specifiche siano ben pensate e
scritte e poi c'è solo da aspettare che le implementazioni vengano fuori.In ogni modo l'aggiunta delle interfaccia SOAP non vuol dire che non si
possa continuare a supportare l'interfaccia XML.
Un client come OpenLayers, per esempio, non potrebbe più funzionare
senza una interfaccia testuale.ciao
Lorenzo_______________________________________________
Gfoss mailing list: 234 iscritti (13-07-2007)
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Grazie per le puntuali precisazioni. Ammettete però che in questo
momento c'è un bel caos a giro!
Mi rileggerò con più attenzione i draft...
è vero, c'è casino ma io lo valuto un buon casino.
si possono già fare tante cose interessanti con gli OWS e aggiungendo le interfaccie binarie si potranno fare tante altre belle cose.
Nemmeno le soluzioni attuali sono complete ma questo è un ambiente che da poco sta crescendo in maniera esponenziale.
E poi c'è modo di intervenire e far aggiustare il tiro dello sviluppo delle specifiche, basta sapere di che si parla.
pensa che Google ha presentato il primo draft per inserire KML fra gli standard OGC.
faccio fatica a valutare tutte le possibili implicazioni...
ciao
Lorenzo
Concordo, è un casino, buono o cattivo resta sempre un casino!
Hai ragione Lorenzo, c’è modo di intervenire e far aggiustare il tiro delle specifiche, basta fare pressione sia con i commenti (quando ci saranno le consultazioni) sia con i referenti nei vari DT (*).
Concordo anche con chi ha scritto (Theodor? Carsten? Patrick?) questo post (http://www.gisblog.net/news/ogc-tc-meeting-paris/ ):
No fierce discussions, no arguments, nothing at all. I wonder how standards can be developed in such boredom
E con Jo (walsh) che mi ha appena risposto:
I get the sense the experts are scared to make binding decisions; especially about the higher-level stuff like network services, where there really is no technological consensus yet.
…
i want to keep going with the FOSS SDIC and particularly i want to write short syntheses of the technological specifics for non-domain-experts. I realise with relief it is not just from an
internet wonk’s perspective that the GI community can seem to be in a platform ghetto, to benefit so much from just a bit of outside reflection.
i hear there is a big row about SOAP inside OGC right now. they have formed two special subcommittees one for SOAP and one for REST so they can have a live action role playing version of ‘SOAP v REST’.
Meanwhile INSPIRE can be used as a testbed for GI industry standards that havent been proven through wide usage yet. Alessandro Annoni said this, more or less verbatim, at the UNSDI thing in Rome back in March 
(*) gli “expert” italiani nei vari DT sono:
- Stefano Nativi (Metadata)
- Maico Centis (Metadata support, Monitoring and Reporting support)
- Claudia Pegoraro (Data Specifications)
- Corrado Iannucci (Network Services support)
- Dimitri Dello Buono (Monitoring and Reporting support)
E buon finesettimana.
pg
On 7/13/07, Lorenzo Becchi <lorenzo@ominiverdi.com> wrote:
Grazie per le puntuali precisazioni. Ammettete però che in questo
momento c’è un bel caos a giro!
Mi rileggerò con più attenzione i draft…è vero, c’è casino ma io lo valuto un buon casino.
si possono già fare tante cose interessanti con gli OWS e aggiungendo le
interfaccie binarie si potranno fare tante altre belle cose.
Nemmeno le soluzioni attuali sono complete ma questo è un ambiente che
da poco sta crescendo in maniera esponenziale.
E poi c’è modo di intervenire e far aggiustare il tiro dello sviluppo
delle specifiche, basta sapere di che si parla.pensa che Google ha presentato il primo draft per inserire KML fra gli
standard OGC.
faccio fatica a valutare tutte le possibili implicazioni…
ciao
Lorenzo
Gfoss mailing list: 234 iscritti (13-07-2007)
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
–
Piergiorgio Cipriano
pg.cipriano@gmail.com
Grande PG,
ottimo punto della situazione.
Io ne ho parlato un po' con Jeroen Ticheler (GeoNetwork chief) questa mattina alla FAO. Settimana prossima approfondiremo.
Anch'io penso che sia l'occasione migliore per rimboccarsi le maniche e mettere su un SDI, basato sulle specifiche, che funzioni davvero.
Io proseguo il mio lavoro di immersioni in queste maledette/benedette specifiche, manteniamo alto il livello di informazione.
grazie
Lorenzo
Piergiorgio Cipriano wrote:
Concordo, è un casino, buono o cattivo resta sempre un casino!
Hai ragione Lorenzo, c'è modo di intervenire e far aggiustare il tiro delle specifiche, basta fare pressione sia con i commenti (quando ci saranno le consultazioni) sia con i referenti nei vari DT (*).
Concordo anche con chi ha scritto (Theodor? <http://www.gisblog.net/about/>\* Carsten? Patrick? <http://www.gisblog.net/about/>\*\) questo post (http://www.gisblog.net/news/ogc-tc-meeting-paris/):
No fierce discussions, no arguments, nothing at all. I wonder how standards can be developed in such boredomE con Jo (walsh) che mi ha appena risposto:
I get the sense the experts are scared to make binding decisions; especially about the higher-level stuff like network services, where there really is no technological consensus yet.
...
i want to keep going with the FOSS SDIC and particularly i want to write short syntheses of the technological specifics for non-domain-experts. I realise with relief it is not just from an
internet wonk's perspective that the GI community can seem to be in a platform ghetto, to benefit so much from just a bit of outside reflection.
i hear there is a big row about SOAP inside OGC right now. they have formed two special subcommittees one for SOAP and one for REST so they can have a live action role playing version of 'SOAP v REST'.
Meanwhile INSPIRE can be used as a testbed for GI industry standards that havent been proven through wide usage yet. Alessandro Annoni said this, more or less verbatim, at the UNSDI thing in Rome back in March(*) gli "expert" italiani nei vari DT sono:
- Stefano Nativi (Metadata)
- Maico Centis (Metadata support, Monitoring and Reporting support)
- Claudia Pegoraro (Data Specifications)
- Corrado Iannucci (Network Services support)
- Dimitri Dello Buono (Monitoring and Reporting support)E buon finesettimana.
pg
On 7/13/07, *Lorenzo Becchi * <lorenzo@ominiverdi.com <mailto:lorenzo@ominiverdi.com>> wrote:
> Grazie per le puntuali precisazioni. Ammettete però che in questo
> momento c'è un bel caos a giro!
> Mi rileggerò con più attenzione i draft...è vero, c'è casino ma io lo valuto un buon casino.
si possono già fare tante cose interessanti con gli OWS e
aggiungendo le
interfaccie binarie si potranno fare tante altre belle cose.
Nemmeno le soluzioni attuali sono complete ma questo è un ambiente che
da poco sta crescendo in maniera esponenziale.
E poi c'è modo di intervenire e far aggiustare il tiro dello sviluppo
delle specifiche, basta sapere di che si parla.pensa che Google ha presentato il primo draft per inserire KML fra gli
standard OGC.
faccio fatica a valutare tutte le possibili implicazioni...
:-)ciao
Lorenzo_______________________________________________
Gfoss mailing list: 234 iscritti (13-07-2007)
Gfoss@faunalia.com <mailto:Gfoss@faunalia.com>
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss--
Piergiorgio Cipriano
pg.cipriano@gmail.com <mailto:pg.cipriano@gmail.com>
fa piacere avere conferme ogni tanto
Da Arnulf Christl
"The Mapbender project was urged by some customers to look into implementing SOAP bindings for OGC standards because some industries communicated that this is the only way to implement security required for Digital Restrictions Management for geodata"
fonte:
http://wiki.osgeo.org/index.php/Representational_State_Transfer
http://wiki.osgeo.org/index.php/Digital_Restrictions_Management
ciao
Lorenzo
Lorenzo Becchi ha scritto:
fa piacere avere conferme ogni tanto
Da Arnulf Christl
"The Mapbender project was urged by some customers to look into implementing SOAP bindings for OGC standards because some industries communicated that this is the only way to implement security required for Digital Restrictions Management for geodata"
Confermo. GeoServer ha avuto alcune richieste di realizzare i wrapper
SOAP intorno alle chiamate WFS perché esistono alcuni router/firewall pensati espressamente per applicare politiche di sicurezza
a livello del protocollo SOAP.
Trovo che la cosa sia alquanto imbarazzante, visto che esistono altri
(assodati) modi di applicare politiche di sicurezza, ma tant'è, anche
così va il mondo...
Ciao
Andrea
Lorenzo Becchi ha scritto:
Sul precedente thread il commento di Lorenzo era positivo...
Alla FAO stiamo sviluppando parecchio su OWS (WMS, WFS, ecc.).
Quando si tratta di far parlare le macchine fra di loro su una rete e spostare un bel po' di dati il sistema in testo semplice (XML) risulta come un collo di bottiglia.
Soap permette di muovere dati in formato binario e questo ha per lo meno il vantaggio di essere più efficiente in termini di prestazioni.
Penso (nessuna certezza) che il riferimento di INSPIRE a Soap sia più o meno così: "vogliamo una tecnologia per muovere i dati in maniera binaria, la più usata è SOAP: vogliamo SOAP".
Mbah, francamente c'e' qualcosa che non mi torna.
La necessità di fornire una alternativa compatta al GML è sacrosanta
se vogliamo veder decollare l'uso di WFS nell'uso quotidiano e/o in
internet, però non capisco cosa ci azzecca SOAP con questo.
Mi spiego, già oggi si possono ritornare vari formati da WFS,
Geoserver ritorna Shapefile e vogliamo (in un modo o nell'altro)
poter ritornare anche altri formati binari col tempo. Ma lo facciamo
senza dover richiudere il tutto in una scatoletta di sapone
Ignoro completamente i motivi che stanno dietro alla scelta di SOAP,
ma mi vien da dire che la gran pubblicità fatta da Microsoft, i
suoi strumenti di sviluppo pensati per sviluppare velocemente client
e server che usano SOAP non siano del tutto estranee a questa decisione
Ciao
Andrea
Mbah, francamente c'e' qualcosa che non mi torna.
La necessità di fornire una alternativa compatta al GML è sacrosanta
se vogliamo veder decollare l'uso di WFS nell'uso quotidiano e/o in
internet, però non capisco cosa ci azzecca SOAP con questo.
Ciao Andrea,
penso che tu abbia ragione sulla storia del SOAP.
Ho visto che molti spingono per REST ma, non avendoci mai messo le mani sopra, non ho idea di cosa sia.
tu lo vedi come una alternativa?
ce ne sono altre?
ciao
Lorenzo
Il sabato 14 luglio 2007, Lorenzo Becchi ha scritto:
> Mbah, francamente c'e' qualcosa che non mi torna.
> La necessità di fornire una alternativa compatta al GML è sacrosanta
> se vogliamo veder decollare l'uso di WFS nell'uso quotidiano e/o in
> internet, però non capisco cosa ci azzecca SOAP con questo.Ciao Andrea,
penso che tu abbia ragione sulla storia del SOAP.
Ho visto che molti spingono per REST ma, non avendoci mai messo le mani
sopra, non ho idea di cosa sia.
Mi intrometto
Detto in poche parole, REST mappa i record e le tabelle in URL (o URI), e le
operazioni CRUD (Create Retrieve Update e Delete) in metodi del protocollo
HTTP: rispettivamente PUT GET POST e DELETE.
A me piace molto, mi sembra semplice ed efficace.
tu lo vedi come una alternativa?
ce ne sono altre?
Ci sarebbero anche XML RPC, che è simile a SOAP ma un po' meno complicato (e
ha una storia e una filosofia diversa) e CORBA.
Una delle più esilaranti storielle su SOAP:
http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-stands-for-simple/
O se avete tempo....
http://www.google.com/search?hl=en&q=SOAP+vs+REST
Sono reduce di un bel litigio con SOAP, e la conclusione è che che sono
perfettamente d'accordo con chi (non mi ricordo più dove l'ho letto) afferma
che lo scopo di SOAP è di vendere servizi di consulenza e tool appositi e non
di semplificare la vita agli sviluppatori. La cosa buffa è che i miei
interlocutori (mondo C#) invece di usare i tool appositi si sono ridotti a
scrivere XML a mano facendo una marea di typo nei tag e creando XML non
valido... valli a capire 
Ciao
--
Alessandro Pasotti
itOpen - "Open Solutions for the Net Age"
w3: www.itopen.it
Linux User# 167502
Concordo con Andrea a Alessandro. Sarà per ignoranza (non ho fatto granché con SOAP finora, perché non mi è servito), ma vedo nelle soluzioni RESTful una maggiore snellezza e, permettetemi, la semplicità di ridare lustro a strumenti esistiti da sempre, l’http, senza dover imbustare tutto in scatole sempre più complesse da gestire e implementare…
A parte un discorso di integrazione con soluzioni già adottate da alcune aziende (e so che non è poco!), ora come ora vedo in SOAP solo una complicazione eccessiva…
Comunque ormai tra SOAP e REST sembra esserci una battaglia ideologica, anche se le due soluzioni, pur sovrapponendosi per tanti possibili usi, hanno anche le rispettive peculiarità. …
Il 14/07/07, Lorenzo Becchi <lorenzo@ominiverdi.com > ha scritto:
Mbah, francamente c’e’ qualcosa che non mi torna.
La necessità di fornire una alternativa compatta al GML è sacrosanta
se vogliamo veder decollare l’uso di WFS nell’uso quotidiano e/o in
internet, però non capisco cosa ci azzecca SOAP con questo.Ciao Andrea,
penso che tu abbia ragione sulla storia del SOAP.
Ho visto che molti spingono per REST ma, non avendoci mai messo le mani
sopra, non ho idea di cosa sia.
tu lo vedi come una alternativa?
ce ne sono altre?ciao
Lorenzo
Gfoss mailing list: 234 iscritti (13-07-2007)
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Lorenzo Becchi ha scritto:
Mbah, francamente c'e' qualcosa che non mi torna.
La necessità di fornire una alternativa compatta al GML è sacrosanta
se vogliamo veder decollare l'uso di WFS nell'uso quotidiano e/o in
internet, però non capisco cosa ci azzecca SOAP con questo.Ciao Andrea,
penso che tu abbia ragione sulla storia del SOAP.
Ho visto che molti spingono per REST ma, non avendoci mai messo le mani sopra, non ho idea di cosa sia.
tu lo vedi come una alternativa?
E' controversa, nel senso che è si basata su semplici principi, ma
a volte anche strozzata dagli stessi. Non sembra esserci ancora
accordo su come muovere un grosso volume di Feature da un
server verso i client.
Un esempio di questa problematica è qui sul blog di Paul Ramsey:
http://geotips.blogspot.com/2007/04/rest-feature-server.html
ce ne sono altre?
Mah, non so, ma il fatto è che stiamo deviando, occupandoci della
scatola e non del contenuto. Al di la che tu ti voglia "riposare" o
"insaponarti", tutti gli esempi che ho visto usano una qualche forma
di trasferimento dati testuale.
Quello che manca è una alternativa seria e binaria a GML.
I signori di Cubewerx hanno provato a spingere sul binary xml
(quindi, binary GML) ma non mi pare abbiano avuto grande successo...
Ciao
Andrea
Il martedì 17 luglio 2007, Andrea Aime ha scritto:
[...]
Mah, non so, ma il fatto è che stiamo deviando, occupandoci della
scatola e non del contenuto. Al di la che tu ti voglia "riposare" o
"insaponarti", tutti gli esempi che ho visto usano una qualche forma
di trasferimento dati testuale.
Sei sicuro? Ho visto saponette piene di allegati binari, in cui di fatto
l'unica cosa che usano di SOAP è l'envelope e il protocollo di trasporto.
Questo è il modo migliore per dire: usiamo SOAP, siamo standard e
interoperabili!! Poi dentro c'è fuffa binaria e proprietaria.
Quello che manca è una alternativa seria e binaria a GML.
I signori di Cubewerx hanno provato a spingere sul binary xml
(quindi, binary GML) ma non mi pare abbiano avuto grande successo...
Scusate, forse sto andando un po' OT o semplicemente non ci ho capito molto,
però se il problema è l'inefficienza del XML in termini di occupazione di
banda, non si risolve in buona misura (g)zippando il tutto?
Rimarrebbero i cicli di CPU per le operazioni di marshalling/unmarshalling,
forse è questo che preoccupa?
DRM a parte, ovviamente.
Ciao
--
Alessandro Pasotti
itOpen - "Open Solutions for the Net Age"
w3: www.itopen.it
Linux User# 167502
Alessandro Pasotti ha scritto:
Il martedì 17 luglio 2007, Andrea Aime ha scritto:
[...]
Mah, non so, ma il fatto è che stiamo deviando, occupandoci della
scatola e non del contenuto. Al di la che tu ti voglia "riposare" o
"insaponarti", tutti gli esempi che ho visto usano una qualche forma
di trasferimento dati testuale.Sei sicuro? Ho visto saponette piene di allegati binari, in cui di fatto l'unica cosa che usano di SOAP è l'envelope e il protocollo di trasporto. Questo è il modo migliore per dire: usiamo SOAP, siamo standard e interoperabili!! Poi dentro c'è fuffa binaria e proprietaria.
Bleah, no, io voglio un binario standardizzato, non proprietario
Quello che manca è una alternativa seria e binaria a GML.
I signori di Cubewerx hanno provato a spingere sul binary xml
(quindi, binary GML) ma non mi pare abbiano avuto grande successo...Scusate, forse sto andando un po' OT o semplicemente non ci ho capito molto, però se il problema è l'inefficienza del XML in termini di occupazione di banda, non si risolve in buona misura (g)zippando il tutto?
Rimarrebbero i cicli di CPU per le operazioni di marshalling/unmarshalling, forse è questo che preoccupa?
Tra uno e l'altro carichi parecchio la CPU sia del server che del client in effetti, diciamo che arrivi a farti una server farm prima con questo
approccio (ti servono tante CPU prima). Comunque hai ragione, è una soluzione disponibile oggi, ed è anche l'unica seria per distribuire GML.
C'e' un altro aspetto da considerare: mai provato a costruire un parser
GML3? Non ce ne sono molti in giro, perché è maledettamente difficile
scriverne uno generale e anche in grado di gestire grossi volumi di dati
senza essere memory bound.
In teoria mi piacerebbe vedere un protocollo binario ben supportato
da vari linguaggi, qualcosa tipo Hessian (http://www.caucho.com/hessian/), e in grado di trasportare, se non
tutto, almeno una porzione significativa dei dati che
possono essere codificati in GML3.
Mah, magari mi sto compliando la vita per nulla... la mia allergia
all'XML non vuole proprio passare
Ciao
Andrea
Il martedì 17 luglio 2007, Andrea Aime ha scritto:
Alessandro Pasotti ha scritto:
> Il martedì 17 luglio 2007, Andrea Aime ha scritto:
>
> [...]
Mah, magari mi sto compliando la vita per nulla... la mia allergia
all'XML non vuole proprio passare
io invece sono allergico ai binari: faccio una fatica maledetta a leggerli 
Per allenarmi, volevo comprarmi questo:
http://www.thinkgeek.com/homeoffice/lights/59e0/
Disclaimer: qui si veleggia verso i 40°C e il mio cervellino bolle già a
30°
--
Alessandro Pasotti
itOpen - "Open Solutions for the Net Age"
w3: www.itopen.it
Linux User# 167502
On 7/17/07, Andrea Aime <aaime@openplans.org> wrote:
Alessandro Pasotti ha scritto:
> Il martedì 17 luglio 2007, Andrea Aime ha scritto:
>
> [...]
>> Mah, non so, ma il fatto è che stiamo deviando, occupandoci della
>> scatola e non del contenuto. Al di la che tu ti voglia "riposare" o
>> "insaponarti", tutti gli esempi che ho visto usano una qualche forma
>> di trasferimento dati testuale.
>
> Sei sicuro? Ho visto saponette piene di allegati binari, in cui di fatto
> l'unica cosa che usano di SOAP è l'envelope e il protocollo di trasporto.
> Questo è il modo migliore per dire: usiamo SOAP, siamo standard e
> interoperabili!! Poi dentro c'è fuffa binaria e proprietaria.Bleah, no, io voglio un binario standardizzato, non proprietario
Ovviamente lo standard SOAP gestisce gli allegati da specifica, il
problema è che ci sono dei gravissimi problemi di incompatibilità tra
le implementazione with attachment .Net e quelle java (sia JWSDP che
Axis) e questo costringe spesso a dover lavorare a basso livello per
fare una chiamata, addirittura creando anche l'header a mano come
stringhe perchè ci sono differenze nel numero dei return tra il
termine dell'header e l'inizio del pacchetto SOAP...insomma non la
vedo come una soluzione interoperabile al 100%...
>> Quello che manca è una alternativa seria e binaria a GML.
>> I signori di Cubewerx hanno provato a spingere sul binary xml
>> (quindi, binary GML) ma non mi pare abbiano avuto grande successo...
>
> Scusate, forse sto andando un po' OT o semplicemente non ci ho capito molto,
> però se il problema è l'inefficienza del XML in termini di occupazione di
> banda, non si risolve in buona misura (g)zippando il tutto?
>
> Rimarrebbero i cicli di CPU per le operazioni di marshalling/unmarshalling,
> forse è questo che preoccupa?
La tecnologia FastInfoset è stata implementata proprio per questo
motivo (credo che in qualche post precedente qualcuno ne parlasse come
binary XML) si è creato un algoritmo ad hoc per gli xml che abbia il
miglior bilanciamento tra compressione e tempo di
compressione/decompressione
Tra uno e l'altro carichi parecchio la CPU sia del server che del client
in effetti, diciamo che arrivi a farti una server farm prima con questo
approccio (ti servono tante CPU prima). Comunque hai ragione, è una
soluzione disponibile oggi, ed è anche l'unica seria per distribuire GML.C'e' un altro aspetto da considerare: mai provato a costruire un parser
GML3? Non ce ne sono molti in giro, perché è maledettamente difficile
scriverne uno generale e anche in grado di gestire grossi volumi di dati
senza essere memory bound.
In teoria mi piacerebbe vedere un protocollo binario ben supportato
da vari linguaggi, qualcosa tipo Hessian
(http://www.caucho.com/hessian/), e in grado di trasportare, se non
tutto, almeno una porzione significativa dei dati che
possono essere codificati in GML3.Mah, magari mi sto compliando la vita per nulla... la mia allergia
all'XML non vuole proprio passare
Nono intervengo sulla diatriba tra SOAP e REST altrimenti non ne esco
più cmq entrambe hanno danno il loro meglio per determinate aree di
applicazioni...ho letto con molto gusto questo articolo su zdnet:
http://blogs.zdnet.com/Newton/?p=17
mi piacerebbe tanto che REST non diventasse the next buzzword...ma
forse questo commercialmente è inevitabile
Ciao
Simone