Publish-Subscribe con XMPP (Extensible Messaging and Presence Protocol)

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!

REST: risorse "complesse"

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 le operazioni

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.