Rich client applications. Supponiamo che sappiate cosa sono ed entriamo nel vivo di come realizzare un prototipo con tecnologia Flash.
Al momento, fra le tante cose disponibili, si trovano Flex,un tool spettacolare (non del tutto free) della Adobe e questo (free in alcune versioni/condizioni) che è abbastanza facile da imparare e utilizzeremo in questo esempio.
Obiettivo: realizzare un menu che somigli al DirectoryIndex, ovvero che dinamicamente mostri un link per ogni directory in un certo percorso del server. E’ utile? Bè, proprio per la sua dinamicità permette di essere utilizzato come componente in applicazioni più evolute. E poi permette di dare un tocco grafico che nessuno immagina dietro le quinte il banale comando “ls” 
(continua…)
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…)
Cross-Lab organizza in martedì pomeriggi consecutivi dei seminari sul “tema degli strumenti software per l’interoperabilità”:
- 20/03/07 “Semantic Web ed Integrazione delle informazioni“
- 27/03/07 “Standard per l’e-business: ebXML ed UBL“
Potrebbe valere la pena partecipare (per chi può).
Nel precedente post ho parlato di WS stack senza troppo soffermarmi su cosa questo termine stesse a significare. Con WS stack (o WS-*) si intende raggruppare tutti i protocolli e gli standard che ruotano attorno ai Web Service, fortunatamente per voi (e per me) posso evitare di descrivere personalmente la pletora di standard dato che ho trovato chi lo ha fatto già al posto mia ed in una veste tipografica anche accattivante.
(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-*?”
(continua…)
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
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:
- siti web personalizzabili direttamente da parte dell’utente finale tramite CSS o template (vedi wordpress, joomla ed affini),
- ambienti di lavoro adattabili attraverso lestetica (vedi desktop) o accessibilità alla funzioni (vedi menu, toolbars,…),
- home page personalizzabili con widget, stuff o plug-in che siano (vedi Google, Yahoo e tutti gli altri) che sono una finestra personale sul mondo per accedere a:
- informazioni di tipo push (news, meteo, “NASA Image of the Day”), magari pre-configurate (voglio il tempo a Bologna in gadi Farenheit),
- informazioni di tipo pull (posizione geografica fornendo un IP, WHOIS fornendo un nome di sito, da “Torrent Searches” fornendo una stringa,…) oppure servizi interattivi (calendario personale da Google, GMail, Jeteye).
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…
Una della maggiori critiche mosse allo sviluppo di soluzioni basate su SOA è sicuramente la difficolta nel realizzare progetti in maniera efficace. L’obiettivo di creare servizi generici e fortemente riusabili, coniugata alla necessità di inserirli in un architettura flessibile e allo stesso tempo robusta spesso porta lo sviluppo lontano dall’obbiettivo primario: quello di consegnare, con scadenze prefissate, una prodotto funzionale per il cliente.
Sicuramente in questo campo le tecnologie web hanno qualcosa da insegnare; la quantità di mashup che vengono proposti dagli utenti della rete (proposti come soluzioni a problemi reali) sono sintomo della facilità con la quale è possibile effettuare composizione di servizi, creando applicazioni browser based. Nasce appunto il concetto di Web Oriented Architecture (WOA) come un insieme di tecnologie (HTTP, XML, REST e JSON) attraverso le quali creare widget, mashup o più genericamente applicazioni AJAX.
Vi consiglio un link di approfondimento
http://webservices.sys-con.com/read/233612.htm
…a breve posterò un esempio di applicazione dei concetti Web 2.0 alle applicazioni enterprise
