Jim Webber, nella presentazione “A Couple of Ways to Skin an Internet-Scale Cat” tenuta al Qcon 2008 di Londra, discute, tra le altre cose, come realizzare un workflow con REST (o, meglio, con la sua implementazione più nota: HTTP).

La presentazione mostra la sequenza di richieste e risposte per ordinare, pagare, ottenere caffé e latte da Starbucks. Il workflow così ottenuto rispetta i vincoli che REST impone: in particolare l’interfaccia uniforme - le risorse sono identificate mediante URI, le operazioni possibili sono predeterminate, hanno semantica nota, indipendente dalle risorse, e le rappresentazioni in risposta contengono le possibili transizioni di stato (come link, annotati per indicare la semantica associata).

Il consumatore, quindi, non conosce a priori la sequenza, il servizio è l’unico a conoscerla; ritornando riferimenti (annotati) guida il consumatore. Supposto che le due parti si accordino preliminarmente sulla semantica e sulla “sintassi” di ogni possibile passo, il servizio potrà, in ogni momento, modificarne la sequenza (nell’ordine o nel numero) senza conseguenze per chi la consuma.

Questo approccio sembra meglio applicabile qualora il colloquio si svolga interamente con un’unica “giurisdizione” (entrati in un ufficio e dovendo trattare con un certo numero di impiegati secondo una sequenza non nota a priori, ciascuno di questi, dopo aver svolto il lavoro di propria competenza, indica il collega con cui proseguire) e serva interazione a passi intermedi (così da non poter essere celati dietro un unico punto di ingresso). Qualora il colloquio avvenga con più “giurisdizioni” sembra irrinunciabile, a meno di compromessi, un coordinatore esterno che smisti.

L’accordo, l’associazione e le annotazioni sulla semantica sembrano d’obbligo: con i link si riesce ad esprimere solo l’interrogazione della risorsa (GET con i parametri riportati dal link stesso nella query string); OPTIONS, da solo, potrebbe non tenere la logica di business separata da quella di comunicazione e non essere sufficiente (in base a quale semantica decidere se eseguire una POST, una PUT o una DELETE?).

Qualunque workflow è risolvibile con questo approccio (continuando a soddisfare i vincoli che REST impone)? Lo stato di una risorsa è sempre nella posizione di indicare operazioni da svolgere su un’altra (che non siano d’interrogazione)?

—-><—-

Hai trovato questo post interessante? Segui il feed e commenta!

I Microformats sono un insieme di formati-dati semplici e aperti, utilizzabili con standard largamente adottati (HTML, XHTML, XML, Atom, ecc.).

Interessanti perché non ambiscono ad affrontare l’intera questione della semantica per il web, si concentrano, invece, su problemi circoscritti e precisi, che risolvono con semplicità: identità (hCard), eventi a calendario (hCalendar), tag (rel-tag), coordinate geografiche (geo), ecc. sono i formati definiti sinora.

La presentazione che allego (condivisa da Mark Meeker su Slideshare), da un’idea di ciò che è stato fatto, di chi lo usa e come.

—-><—-

Hai trovato questo post interessante? Segui il feed e commenta!

Martin Aschoff ha tenuto all’OSCON 2008 (O’Reilly Open Source Convention) una presentazione - “Going Open Source - The 20 Most Important Things To Do” - su cosa fare prima e dopo aver deciso di aprire il codice per fare business.

Prima:

• Raccogliere informazioni sui possibili concorrenti (Sourceforge.net, Eosdirectory.com, ecc.)
• Studiare progetti di successo (siti, strategie, ecc.)
• Scegliere un modello di business (l’Open Source, da solo, non lo è)
• Definire l’insieme delle funzionalità iniziali
• Sviluppare un piano (cautela, stimare il caso peggiore)

Dopo:

• Definire la documentazione
• Scegliere una licenza (meglio se tra quelle più note)
• Sostituire gli eventuali componenti chiusi o incompatibili con la licenza scelta
• “Sistemare” il codice (renderlo più comprensibile, commentarlo, aggiungere le intestazioni, ecc.)
• Scrivere la documentazione (gli sviluppatori non dovrebbero contribuire ai manuali per gli utenti)
• Aprire due siti (quello per il progetto e quello per fare business)
• Pubblicizzare il lancio del prodotto (forum, blog, stampa, ecc.)
• Rendere disponibile il sorgente e i binari (Sourceforge.net o simile)
• Pubblicare la pianificazione per il rilascio di ulteriori funzionalità
• Occuparsi delle pubbliche relazioni (ci saranno da gestire richieste gratuite di supporto)
• Non confondere mai i numeri dei download, con quelli degli utenti e quelli dei clienti

—-><—-

Hai trovato questo post interessante? Segui il feed e commenta!

Prophet è un progetto Open Source nato da alcune constatazioni:

• non si è costantemente collegati ad Internet
• non si ha potere sulle applicazioni che si usano su Internet
• poco si può fare se la nostra applicazione preferita non risponde

Prophet è un database che si può usare off-line e che si sincronizza (con repliche, in modalità peer-to-peer, senza server centrale) quando torna on-line.

Espone API native (in Perl) e simil-REST. Usa il file-system come back-end.

Prophet risolve, in autonomia, i conflitti: ricorda le precedenti modalità di risoluzione e le preferenze - richiede l’intervento dell’utente in caso d’indecisione.

Ogni modifica è memorizzata, ispezionabile e annullabile a ritroso (le repliche  si ottengono proprio eseguendo questi insiemi).

Prophet è progettato per scalare a “livello di team” (ordine dei 50.000 record). Possibili applicazioni, quindi, sono tutti quei “modesti” database “sociali” e, più in generale, quelli di cui si vuole disporre, sul proprio computer, anche quando si è off-line.

—-><—-

Altro materiale sull’argomento:

• http://www.slideshare.net/obrajesse/web-20-is-sharecropping
• http://www.slideshare.net/obrajesse/prophet-a-peer-to-peer-replicated-disconnected-database/

—-><—-

Hai trovato questo post interessante? Segui il feed e commenta!

Vertebra è un progetto Open Source nato con l’obiettivo di automatizzare operazioni su larga scala.

Dalla solita architettura dei prodotti di operation (server centrale e agenti per ogni oggetto da gestire), lo contraddistingue l’essere fondato su XMPP (Extensible Messaging and Presence Protocol) - specifica IETF (Internet Engineering Task Force) per lo streaming di strutture XML.

Vertebra usa Ejabberd (server XMPP/Jabber sviluppato con Erlang) come server centrale: prestazioni elevate sono garantite anche con decine di migliaia di connessioni contemporanee.

Un’unica istruzione è sufficiente ad individuare tutti gli agenti coinvolti e ad avviare l’esecuzione, in parallelo. Per coordinare le operazioni, inoltre, è previsto un workflow.

Trovo questo progetto interessante anche per altri usi: una dorsale fondata su XMPP collega punti di controllo in grado di eseguire operazioni su “oggetti” che il concetto di risorsa astrae.

—-><—-

Altro materiale sull’argomento:

• http://www.slideshare.net/ezmobius/vertebra
• http://www.slideshare.net/jvantuyl/vertebra-bringing-the-cloud-down-to-earth

—-><—-

Hai trovato questo post interessante? Segui il feed e commenta!

Il 21 luglio 2008, Friendfeed, aggregatore di feed provenienti da Youtube, Flickr, Del.icio.us, ecc. ha interrogato Flickr quasi 3.000.000 di volte per ottenere gli eventuali nuovi upload di circa 47.000 utenti: un notevole spreco di risorse (considerato anche che, quel giorno, di quei 47.000, solo 6.000 hanno fatto login su Flickr).

RSS, che permette di implementare il modello publish-subscribe anche su HTTP, determina un notevole spreco di risorse negli impieghi massivi, questa la tesi di Evan Henshaw-Plath e Kellan Elliott-McCrea, autori della presentazione “Building Data Services with XMPP PubSub” tenuta a OSCON 2008 e condivisa su Slideshare, che oltre a riportare questi fatti mostra una soluzione: il publish-subscribe con XMPP.

XMPP (Extensible Messaging and Presence Protocol) è un protocollo per lo scambio real-time di strutture XML. Usato sopratutto per applicazioni di messaggistica istantanea e presenza, prevede lo streaming di strutture XML: il client può inviare all’interno della stessa sessione (singola connessione TCP) un numero non predeterminato di elementi (detti XML stanza), fin quando non decide di terminare con la chiusura del tag <stream>.

I due autori consigliano di veicolare elementi Atom e di implementare componenti (estensione XEP-0114); ricordano, inoltre, l’esistenza di librerie client quasi per ogni linguaggio di programmazione.

—-><—-

Hai trovato questo post interessante? Segui il feed e commenta!

La RFC 2396 (URI - Uniform Resource Identifier) definisce “risorsa” una qualunque cosa che abbia un’identità e che - concettualmente - possa corrispondere ad un’entità o un insieme.

E’ un po’ che mi chiedo se “dietro” una risorsa si possa “nascondere” qualcosa di più “complesso” (una serie di passi, ad esempio, una logica applicativa complicata a piacere, ecc.), continuando, però, a soddisfare i vincoli di REST (mi riferisco, sopratutto, all’interfaccia uniforme e alla mancanza di stato).

Stefan Tilkov, autore dell’articolo “Addressing Doubts about REST” (già citato in un articolo precedente “Letture consigliate su REST“), spiega come REST (REpresentational State Transfer) non sia confinato alle sole operazioni CRUD (Create, Read, Update and Delete): una URI tipo http://example.com/calculation?a=2&b=3, infatti, può corrispondere alla somma tra a e b. L’articolo descrive una soluzione in sintonia con REST (implementato con HTTP): una POST che abbia come effetto la creazione della risorsa-risultato e come ritorno la URI corrispondente (da usare con una GET).

Il libro “RESTful Web Services” di Leonard Richardson e Sam Ruby, nella parte dedicata al disegno di risorse, illustra strategie simili.

Quindi dietro una risorsa si può celare qualcosa di più “complesso” di una “semplice” entità. Tale risorsa, però, non coincide con la risorsa-risultato cercata, è il punto di raccolta delle richieste (”RESTful Web Services” lo definisce factory): accoglie i POST (richiesta di creazione, non sicura, non idempotente), crea la risorsa-risultato (o ne accoda la richiesta) e ne ritorna l’URI da usare con una GET (richiesta di informazioni, sicura, idempotente).

Questo, che sicuramente rispetta i vincoli imposti da REST, mi sembra, oltre che macchinoso, richiedere al client una certa “consapevolezza” (che, in taluni casi, potrebbe rafforzare l’accoppiamento): alla POST deve seguire necessariamente una (o più) GET con cui recuperare la risorsa-risultato (o richiederne lo stato di esecuzione - in tal caso il client deve farsi carico anche di una DELETE per eliminare la risorsa temporanea). Conseguenza dell’interfaccia uniforme (i metodi con semantica indipendente dalle risorse sono generici, non specializzati e, talvolta, impongono al client di soddisfare un flusso di lavoro ben preciso) e della mancanza, per alcune situazioni, di soluzioni REST collaudate.

Un codice 201 (”Created”), in risposta alla POST, che oltre alla URI della risorsa creata riportasse la sua rappresentazione, o un codice 303 (”See Other”) che “inviterebbe”  ad eseguire “automaticamente” una GET verso la URI ritornata (la risorsa-risposta), potrebbero isolare la logica di business del client dalle logiche del colloquio HTTP; sono soluzioni, comunque, da studiare di volta in volta.

—-><—-

Hai trovato questo post interessante? Segui il feed e commenta!

Automatizzare per:

• diminuire i tempi e il rischio

• non ripetersi (è noioso)

• avere più tempo per le idee

• rispondere ai cambiamenti del mercato

• offrire il software in commodity (SaaS - Software as a Service)

La presentazione “Why Startups Need Automated Infrastructures”, tenuta da Adam Jacob al Web 2.0 Expo e condivisa su Slideshare, suggerisce come automatizzare le operazioni sull’infrastruttura (censimento, configurazione, deployment e monitoraggio) utilizzando quasi esclusivamente software Open Source (rispettivamente iClassify, Puppet, Capistrano e Nagios).

Oltre ai prodotti che la presentazione elenca vale la pena considerare anche: Cobbler, Ganglia e God.

La presentazione "Service Component Architecture (SCA) and Java Platform, Enterprise Edition: Integration Inside", tenuta da Ron Barack e Peter Peshev al JavaOne 2008, auspica un container SCA (Service Component Architecture) nativo all'interno della piattaforma Java Enterprise Edition (alla stregua di quelli standard - EJB, Servlet, ecc.).

Tra i benefici indica:

• protocolli, policy, ecc. celati dal modello di programmazione e dall'infrastruttura SCA (anche all'interno dei componenti Enterprise Edition)

• agevole coinvolgimento, nelle composizioni SCA, del codice Enterprise Edition già sviluppato

• utilizzo, anche per i deployment SCA, degli strumenti già consolidati sugli Application Server - monitoraggio, ciclo di vita, ecc.

SCA, in tal modo, diverrebbe un'estensione della piattaforma Java Enterprise Edition, non un concorrente.

Tutti i più grandi produttori di software, Sun compresa, aderiscono all'iniziativa di SCA presso Oasis, vedremo.

—-><—-

Sullo stesso argomento:

• OSOA: SCA & Java EE Integration

• InfoQ: Strengthening the Alliance Between Java EE and SCA

—-><—-

Hai trovato questo post interessante? Segui il feed e commenta!

SCA (Service Component Architecture) è un modello a componenti per applicazioni di business. E’ definito da un certo numero di specifiche Oasis: implementazione dei componenti (Java, C++, BPEL e Spring), modalità di composizione, binding permessi (SOAP, JMS e EJB) e policy (sicurezza e affidabilità).

JBI (Java Business Integration) è un modello a componenti principalmente per soluzioni di integrazione. E’ definito dalle specifiche Java JSR-208 (JBI 1.0) e JSR-312 (JBI 2.0).

La presentazione “The Best of Both Worlds with Java Business Integration and Service Component Architecture”, tenuta al JavaOne 2008 da Jos Dirksen e Tijs Rademakers, suggerisce come queste due tecnologie possano convivere cooperando: un container SCA che “gira” come Service Engine all’interno di un container JBI.

Come beneficio il riuso: ad esempio Binding Component JBI esistenti utilizzabili come binding non previsti dalle specifiche SCA.

E’ da valutare: nel caso dei binding, ad esempio, si potrebbe considerare anche di estendere il container SCA (programmando - se open source si dispone del codice, solitamente modulare e la specifica permette le estensioni) o di utilizzare un broker (intermediario stand-alone - riflettere sulle prestazioni e sull’assetto di produzione).

—-><—-

Hai trovato questo post interessante? Sottoscrivi il feed completo e partecipa alla discussione