[Linuxtrent] Re: Sun & Google per AJAX Office: un articolo da non perdere
- From: Guido Brugnara <gdo@xxxxxxxxx>
- To: linuxtrent@xxxxxxxxxxxxx
- Date: Fri, 07 Oct 2005 07:00:47 +0200
Vincenzo D'Andrea ha scritto:
On 10/6/05, Guido <gdo@xxxxxxxxx> wrote:
...
Comunque a parte l'incontro in carne ed ossa, possiamo intanto usare la
mail-list come palestra per la mente ;-)
leggendo la tua lista di specifiche mi vien da pensare ad un approccio
basato su un insieme di servizi (per es. web services) in cui
suddividi quella che una volta si chiamava "applicazione". Almeno
questo è quello che traduco quando leggo di "mattoni" e/o componenti
in un ambiente distribuito web-based.
Quando un cinese tenta di comunicare con un portoghese è assi difficile
che si capiscano. O il cinese impara il portoghese oppure il portoghese
impara il cinese; ma tutti e due sostengono che la propria lingua è
meglio dell'altra e quindi nessuno dei due è molto convinto di dover
studiare una ulteriore lingua. Oppure tutti e due imparano una terza
lingua, cosidetta franca; magari più semplice da imparare per tutti e
due, ma sufficiente per poter sostenere un dialogo tra i due senza che
vi sia ambiguità di interpretazione.
Ogni ambiente nel passato ha usato la propria lingua per comunicare;
compresi i sistemi informatici che essendo appunto costruiti dall'umono
posseggono le stesse virtù e gli stessi difetti.
Internet sta però facendo comprendere all'Uomo che la comunicazione e
l'aggregazione diffusa porta più vantaggi che lo stare chiusi ciascuno
nel proprio orticello e pertanto c'è sempre più necessità di comunicare
e quindi sviluppare sistemi per scambiare informazioni.
C'è chi tenta di imporre la propria lingua (indovinate chi ;-) ed altri
che propongono lingue più o meno franche, spesso condite di forme
dialettali.
Dato che ciascuno di noi vuole mantenere la propria identità (io ci
tengo a parlare Italiano e Perl, per intenderci ;-) , si stanno
affermando delle "lingue" franche per poter comunicare tra sistemi
differenti e di differente dislocazione geografica, appunto i Web
Service ne sono un piccolo sottoinsieme.
Anche i "vecchi" protocolli come ad esempio SMTP, POP sono dei Servizi
di rete; quello che contraddistingue i Web Service è la capacità più o
meno sviluppata di fornire al richiedente le informazioni necessarie per
comprendere le funzioni (metodi) e dati (oggetti) disponibili.
Questa maggiore complessità dell'interfaccia comporta però un costo in
termini di prestazione che, per la mia esperienza non è accettabile nel
caso di una GUI dell'utente.
Daltronde non ho bisogno di una lingua franca per dialogare tra due
"sistemi" che si conoscono e quindi ritengo preferibile che in questo
caso vi sia un dialogo senza mediazioni.
Se però i due componenti possono essere utili in altri ambiti è bene che
possano dialogare attraverso collegamenti (Web Service) che ne estendano
enormemente il campo di applicazione.
Faccio un esempio:
Ci sono molte applicazioni di Calendario con interfaccia WEB, ma non ne
cononsco neanche una che abbia separato l'interfaccia WEB
dall'applicazione sul server utilizzando, ad esempio iCAL (con
collegamento http e/o SOAP).
Credo che nei prossimi anni (speriamo mesi) si affermeranno dei nuovi
servizi che dispongano di metodi ed oggetti iCAL, accessibili via
protocolli HTTP SOAP XML-RPC ecc., ma per ora ci dobbiamo accontentare.
(se qualcuno mi può segnalare un progetto di server iCAL disponibile via
interfaccia Web Service o altro ...)
La mia intenzione è quindi di costruire sì dei mattoni separati ed
interdipendenti, ma che possano tra loro comunicare sia utilizzando un
protocollo leggero che, ad esempio SOAP e/o XML-RPC.
Dato che SOAP, come anche CORBA e RMI, in soldoni non fanno che esporre
oggetti e metodi in modo che ambienti diversi (traduco linguaggi
diversi) possano interagire, posso benissimo stabilire il mio modello di
gestione definendo oggetti e metodi richiamabili attraverso diversi
metodi di trasporto: SOAP, XML--RPC, ecc. da attivare alla bisogna.
Nel mio caso quale trasporto leggero penso di utilizzare direttamente
HTTP (o HTTPS quando serve) e JSON (http://www.crockford.com/JSON/). Il
vantaggio sta nel fatto che usando questa tecnologia puoi trasferire
strutture complesse di dati dal server al client e viceversa
risparmiando conversioni lato client in quanto il formato è praticamente
Javascript.
Un motto scritto dall'Autore di JSON dice "JSON is a better data
exchange format. XML is a better document exchange format. Use the right
tool for the right job."
bye
Guido Brugnara
Componendo ed orchestrando opportunamente i servizi si ottengono poi i
vari sistemi.
molto interessante ....
ciao
v.
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx
Other related posts: