Di tutto di più: la cantina della nonna
Abbiamo parlato di architetture web2.0, abbiamo parlato di mashup e dei tool per crearli facilmente, spesso abbiamo citato RSS e Atom ma senza concentrarci sull’importanza che questi due formati hanno nei servizi online, quale tassello vanno a ricoprire nelle WOA.
Sulla scia delle mode nel campo delle tecnologie informatiche, e guidati dalla necessità di comprendere meglio i nuovi servizi offerti dai provider (anch’essi vittime delle stesse mode), alcuni mesi fa in Cantina abbiamo deciso di testare un software di virtualizzazione dei server.
Siamo quindi partiti facendo una ricerca delle tecnologie disponibili, focalizzando la nostra attenzione su soluzioni per Linux. Dal documento risultante, ci siamo resi conto che avevamo due strade: (continua…)
Nel precedente Post ho buttato una domanda nel mezzo, non per trovare una risposta ma per intavolare una discussione:)
“quando è necessario usare SOAP al posto di REST?”
…ma la discussione non ha portato ai frutti sperati, perchè come diceva il saggio la domanda era mal posta, oggi provo a riproporre la domanda ed ad accennare una risposta (insomma come da Marzullo):
“quando è meglio usare REST al posto di WS-*?”
e non solo perchè a 4 gg dal compleanno (grazie grazie) sono già senza voce e malaticcio come se la vecchiaia arrivasse a quintali.
girovagando per la rete mi sono imbattuto nel sito in oggetto. ne parlano in tanti, chi bene chi male. ci sono flame e fior di discussioni. Un buon punto di aprtenza è questo, contiene sia un video che illustra come utilizzare il servizio, che un po’ di gente che ci ha lavoricchiato sopra.
voi siete impazienti e vi chiedete: “ma di che servizio stai parlando?”. bè, Ning vuole essere una piattaforma per sviluppare in modo visuale e via web delle applicazioni, sempre web, di social network.
Un web service tipicamente risponde con un xml di output, che deve essere letto dall’applicazione client che ha effettuato la richiesta.
Ultimamente molti (Yahoo, Google,…) stanno pensando di fornire anche un ulteriore formato di risposta per i proprio WS, cioè JSON.
JSON è semplicemente una rappresentazione di oggetti basata su un sottoinsieme del linguaggio javascript, ma che è leggibile da quasi tutti i linguaggi di programmazione.
Si può stabilire una corrispondenza tra l’xml di risposta e l’oggetto JSON, ad esempio stabilendo che un tag “risposta” viene rappresentato dall’oggetto JSON “Result” (Esempio di risposta JSON).
Questa risposta può essere letta e inserita all’interno della pagina html che ha effettuato la richiesta senza bisogno di parserizzare l’xml di risposta.
Inoltre è possibile, attraverso una tecnica nota come Dinamic Script Tag, fornire una funzionalità simile a quelle dell’oggetto XmlHttpRequest, ovvero la possibilità di aggiornare componenti sulla pagina client senza bisogno di ricrearla interamente, secondo i dettami di web 2.0 e delle Rich Internet Applications.
I vantaggi di JSON sono:
A mio parere JSON dovrebbe essere utilizzato in alternativa all’xml come formato di risposta di un web service. In pratica si aggiunge alla classica notazione xml per la risposta del ws anche la notazione json; in questo modo il web service mantiene l’espressività dell’xml e la velocità e compattezza di json.
L’utilizzo di JSON è spiegato molto bene in questa pagina:
http://developer.yahoo.com/common/json.html
Riferimenti:
http://www.json.org/JSONRequest.html
http://www.phpday.it/site/wp-content/uploads/2006/05/ws_phpday_2006.pdf
http://programmazione.it/index.php?entity=eitem&idItem=35215
E’ da un pò di tempo che volevo scrivere un articolo sulle architetture basate su REST. In primo luogo perchè nel mio primo post ho menzionato tante tecnologie e volevo piano piano coprirle tutte con articoli ad hoc e poi perchè credo che per risolvere problemi non sempre è necessario ricorrere a soluzioni tecnicamente “imponenti” e dal nome altisonante (pensate solo a quanti standard ruotano intorno alle SOA: SOAP, WSDL, UDDI, ebXML, BPEL, WS-*…) a volte bastano soluzioni “più semplici” architetturalmente ma non meno valide.
Dunque innanzitutto REST (che sta per Representational State Transfer) è un stile architetturale che cerca di “ingabbiare” le caratteristiche del Web che ne hanno decretato il suo successo. Ammetto che la frase sembra un pò da fanatico ma se andiamo a prendere la definizione di REST data dal suo ideatore Roy Fielding:
“Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use.”
erano quelli di definire l’architettura stato-transazionale che “movimenta” il web.
Se pensiamo ad un web service sviluppato con SOAP non dovremmo dimenticarci che dopotutto si sta parlando di un risorsa che ha un URL (o meglio URI) e che riceve in input e restituisce in output un XML su HTTP. E allora perchè invece di usare SOAP non usiamo un xml senza vincoli standard e si si potesse far leva sulle peculiarità del protocollo HTTP: per esempio HTTPS e HTTP authentication per gestire la sicurezza end-to-end o l’HTTP caching per migliorare le performance della risorsa; ecco questo in sintesi è REST, veramente molto in sintesi dato essendo una serie di principi architetturali questi non si esauriscono con 3 parole, ma neanche con un tomo di specifiche, verificare per credere nella tesi di dottorato di Fielding.
Nel prossimo articolo parlerò più approfonditamente del perchè nelle WOA viene usato REST, per ora vi lascio con uno spunto di riflessione, quando è necessario usare SOAP al posto di REST?…di seguito trovate un interessante traccia nel blog del progetto Glassfish
Tempo fa avevo parlato dell’applicazione dei principi WOA ai problemi enterprise. In quest’ottica oggi vi presento QEDWiky, un’altra proposta IBM (tempo fa Gabriele aveva parlato di ADIEU) per la creazione di applicazioni attraverso l’integrazione di servizi. QEDWiky, molto in salsa Web 2.0, nasce con l’obiettivo di realizzare un ambiente collaborativo e nel quale sia possibile sviluppare semplici mashup. QEDWiky (dove QED sta per Quick and Easily Done) si propone come un framework wiky che permette agli utenti business e agli sviluppatori di creare le proprie applicazioni in maniera collaborativa e veloce, attraverso la fusione di widget.
Osservando la pagina del sito IBM:
http://services.alphaworks.ibm.com/qedwiki/
è evidente lo sforzo del colosso nel tentativo di mimetizzarsi nel mondo del social networking (già il titolo con suffisso -wiky la dice lunga):
1) aggiunta dei link digg e del.icio.us
2) disponibilità della intro su YouTube
3) … (lascio a voi riempire i puntini)
Se anche un’azienda come IBM sta cercando di applicare il paradigma WOA negli ambienti enterprise credo proprio che oramai il processo sia irreversibile.
PS. da pochi giorni è apparsa sul sito IBM la notizia che Yahoo Pipes è integrabile con QEDWiky
Leggendo di self-webprogramming nel post di Simone, mi è partita una considerazione, che stavo scrivendo come commento ma che, per dimensione e contenuto, si è evoluto in un post vero e prorpio…
Mi sembra che ci sia la tendenza generale in atto, non reversibile, auspicata, oltre che auspicabile, di coinvolgere sì l’utente finale, ma più che con un coinvolgimento di stampo “sviluppistico”/”programming” ne vedrei uno di tipo “adattivo”.
Se guardiamo cosa “ha”, non è, successo nell’informatica troviamo:
Portando invece la considerazione sul piano dei sistemi informativi aziendale, e più specificatamente del BPM, inteso nel senso del Business Process Management, già nel 2001/2002 si prevedeva che gli utenti avrebbero avuto bisogno di maggiori libertà, che gli strumenti si sarebbero dovuti evolvere per assisterli nella modifica dei loro sistemi informativi e che le metodologie di progettazione (non quelle in uso nello sviluppo ma nella consulenza) si sarebbero dovuto adeguare ad un mondo in cui l’utente avrebbe avuto una maggiore centralità.
Chiudo qui il post aprendo una parentesi sul concetto di utente: quando si parla di utente, in quelle considerazioni si intendeva l’essere umano utilizzatore esperto di dominio. Questa è una distinzione importante perché ora come ora, si tratta più che altro di un “cliccatore” di tasti, addestrato per seguire sequenze specifiche e predeterminate, almeno in parte, dallo sviluppatore, dal sistemista o, più importante e grave… dal consulente che personalizza il sistema dell’azienda…
Durante la passata settimana si è parlato tanto di mushup:
Se fossimo nell’ambito SOA, e volessi parlare di aggregatore di servizi, penseremo ad orchestrazione di WS, a modellazione di Workflow attraverso BPEL e BPM (Gabriele corregimi dove sbaglio), ma queste sigle a volte ci fanno pensare a cosa complicate da gestire e che rischiano di far spendere grossi somme alle aziende con pochi risultati; allora torniamo al semplice, torniamo al WOA.
Come integro? come faccio dei mashup tra servizi? esiste un BPEL? e uno strumento grafico per disegnare i miei processi e che mi orchestri i miei servizi web?
Da un paio di giorni la risposta è si, è uscito Yahoo Pipes (tanto per dimostrare che nn leggo solo di Google) un drag-n-drop web editor che permette di connettere flussi di dati provenienti da servizi web (in questo caso solo Feed, ahime) processarli e presentare il risultato in vari formati. Ancora nn vi ho stupiti?… e se aggiungo che è possibile aggiungere dei form per ottenere degli input da parte degli utenti (per evidenziare che nn si possono implementare solo soluzioni batch ma anche interattive) e che è possibile applicare dei filtri predefinit ai flussi ( (sort, unique, join, count, truncate) e anche creare filtri definiti dall’utente stesso, applicare costrutti di programmazione come loop e if…e ancora analisi del contenuto, traduzione in qualunque lingua, geocodifica di indirizzi (Gianni cosa significa spiegalo tu che ci chiami anche le tue api).
E il tutto come dice il titolo user friendly, anche un utente base può creare la propria applicazione, certo il costrutto loop (anche se a noi può sembra assurdo) non è immediato a tutti e l’uso dei parametri di get per creare degli url per richiamare una pagina web nn sono per utenti alle prime armi…ma è comunque un primo grande passo per far diventare il web una piattaforma di sviluppo vicina all’utente finale
La cosa più stravolgente è la semplicità, trascini i vari moduli (si va dai moduli predefiniti per accedere a yahoo search, flickr e google base alla possibilità di creare fonti dati nuove attraverso l’uso di RSS, Atom, RDF) disegni il flusso e aggiungi i filtri…e il gioco è fatto…
Le possibilità sono infinito basta andare a fare browsing tra le pipe già disponibili sul sito, sviluppate da altri utenti e che si possono riutilizzare per nuove entusiasmanti idee…
Oggi concludo qui ma finito a leggere iniziate a chiedervi se vale più la pena sviluppare applicazioni web per l’utente finale o questo è il primo passo verso il self-webprogramming…