AJAX e Web Service

[giaros1]

Salve,

sto incominiciando a prendere confidenza con javascript e ... scopro AJAX.

Un oggetto XMLHttpRequest ...
Mi dico fantastico! Sicuramente c'è da qualche parte chi ha sviluppato delle API SOAP per javascript su questa funzionalità.

Ed invece navigo in internet e non trovo praticamente niente, a parte "Clean AJAX" e .NET di Windows (ovviamente basato su ASP).

Non riesco a spiegarmi:
1) c'è uno strumento per scambiare messaggi XML su HTTP (XMLHttpRequest).
2) esiste uno standard per scambiare messaggi ed effettuare RPC attraverso XML su HTTP

perchè non esiste nessun tentativo (open source) di mettere tutto insieme e dare ad AJAX potenza ed interoperabilità ??

Ogni framework sviluppato su AJAX prevede un suo standard per lo scambio dei messaggi (ovviamente da implementare anche lato server): perchè non servirsi di uno standard?


C'è qualcuno che mi sa dare una risposta ???

[artorius]

Mmm o non ho capito io, o non hai chiaro che cosa siano gli standard:

2) esiste uno standard per scambiare messaggi ed effettuare RPC attraverso XML su HTTP

l'hai appena detto: XML-RPC è uno standard. Devi inviare la richiesta ad un server XML-RPC compilant (non so se si dice proprio così, comunque la pagina richiesta deve analizare una richiesta XML-RPC e rispondere nello stesso formato), mandando in POST una stringa che contiene il testo XML nello standard XML-RPC

[QUOTE]perchè non esiste nessun tentativo (open source) di mettere tutto insieme e dare ad AJAX potenza ed interoperabilità ??[/PHP]

Che cosa intendi per potenza ed interoperabilità? Se intendi uno strumento No-Brain come Visual Studio, allora hai voglia, tutti quelli che fanno questo lavoro come professionisti sanno i limiti di una simile interfaccia, e la evitano come la peste.

Ogni framework sviluppato su AJAX prevede un suo standard per lo scambio dei messaggi (ovviamente da implementare anche lato server): perchè non servirsi di uno standard?

Ma tu stai parlando di Client, non Server, e client sono sempre HTML, o meglio XHTML, e Javascript. Al server non gliene importa di cosa capita lato client, si aspetta sempre:
"GET /nome/file.html HTTP/1.1"
o
"POST /nome/file.php HTTP/1.0"
con tutti i valori poi mandati nell'header (Content-type, Content-length, language, parameters).

Cosi come il client, si aspetta una risposta in forma header + body (dove il body può essere HTMl o un altro tipo di stringa).
Le due cose sono separate, quindi bisogna svilupparle in maniera separate.

[giaros1]

Forse non mi sono spiegato bene ...

**********
SOAP
**********
- SOAP è uno standard. Questo è un dato di fatto.
- SOAP definisce il formato e la modalità di scambio dei messaggi tra un client ed un server
- In SOAP, il server (Web Service) esporta un WSDL (diciamo un manifesto) in cui espone tutti i metodi che fornisce: vale a dire metodo, descrizione, argomenti e risultato.

*********
Framework
*********
Detto questo per framework intendo delle api che mascherino l'implementazione di SOAP e che mi consentino di utilizzare il protocollo solo al livello + alto.

Senza questo sarò costretto a scrivere manualmente, nel codice del client, dei messaggi XML ( probabilmente XML-RPC) ed a fare, sempre manualmente, il parse del messaggio XML inviato come risposta dal server.

Normalmente dei framework per Web Service hanno anche delle utility che consento di creare dal WSDL delle classi client: ossia ogni qualvolta chiamo un metodo di queste classi viene invocato il metodo corrisponente sul server e lo strato della comunicazione è completamente trasparente. Avere qualcosa del genere anche per javascript sarebbe il massimo (esistono già per C++,java, etc).


*********
Interoperabilità
*********
Un client SOAP può comunicare con qualsiasi server indipendemente dal linguaggio e dalla piattaforma.


Infine tu dici:

Ma tu stai parlando di Client, non Server, e client sono sempre HTML, o meglio XHTML, e Javascript. Al server non gliene importa di cosa capita lato client, si aspetta sempre "GET /nome/file.html HTTP/1.1"
o
"POST /nome/file.php HTTP/1.0"

Non è esattamente così: il server si aspetta sempre un GET o UN POST ma deve interpretare ciò che c'è scritto dentro, ossia qual'è la richiesta. Es. io ti mando una lettera con una richiesta (GET, POST) ma se te la scrivo in cinese tu non sarai capace di capire quello che voglio. Lo stesso vale per la risposta.
Lo standard è proprio qui: il server dice quali sono le sue funzionalità attraverso il WSDL e qualsiasi client remoto può richiedere quelle funzionalità e comprendere la risposta del server, indipendemente dal linguaggio di programmazione e dalla piattaforma.