[Gfoss] Fwd: SOAP?

[Simone Casciaroli]

On 7/17/07, Andrea Aime <aaime at 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