Ben Ramsey raccoglie, in “Making the Most of HTTP In Your Applications“, metodi, codici di risposta ed headers HTTP: per sfruttare appieno ciò che il protocollo offre e non limitarsi a POST, 200-OK, 404-Not Found e 500-Internal Server Error.

—-><—-

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

App Engine è l’offerta PaaS (Platform As A Service) di Google per lo sviluppo e l’esecuzione di applicazioni web.

Fondata sull’infrastruttura di Google, garantisce load balancing, fault tollerance e ragguardevole scalabilità – tutto in automatico.

Include una base dati che poggia su BigTable: un sistema distribuito (usato ad esempio in Finance, Earth e nell’indicizzazione) per la gestione di grosse quantità di dati (ordine di Petabytes). Questa base dati non è relazionale, ma a coppie chiave-valore: non contempla quindi le joins.

L’autenticazione con Google Accounts, l’invio di e-mail tramite Google Mail, la manipolazione di immagini e l’uso di Memcached sono solo alcune delle API che il framework mette a disposizione.

Ad oggi, Python è l’unico linguaggio di programmazione previsto. Il Software Development Kit (SDK) simula in locale l’intera piattaforma.

Ci sono alcuni vincoli, ad esempio:

• La persistenza dati può avvenire solo sulla base dati inclusa
• L’applicazione può essere invocata solo con protocollo HTTP o HTTPS
• Il codice è eseguito solo a fronte di una richiesta HTTP
• L’invocazione di web services ha un time-out di pochi secondi

I primi 500 Mb di spazio e banda/CPU sufficiente per 5 milioni di visite al mese sono gratuiti.

—-><—-

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

Mark Masterson condivide un’interessante presentazione – “How to build your app quickly (and cheaply?) using the cloud” – in cui analizza PaaS (Platform As A Service) e IaaS (Infrastructure As A Service) (vedi “Cloud Computing: una classificazione“) per lo sviluppo e l’esecuzione di applicazioni web.

La presentazione caratterizza PaaS (Platform As A Service) con:

• Vincoli sul linguaggio di programmazione e sulla progettazione
• Modello di programmazione, d’alto livello, già stabilito
• Dettagli, di basso livello, già risolti dalla piattaforma

La consiglia nel caso in cui manchi l’esperienza o si aspiri all’esercizio in tempi brevi.

Caratterizza IaaS (Infrastructure As A Service), invece, con:

• Assenza di vincoli sul linguaggio e sulla progettazione
• Modello di architettura, d’alto livello, già stabilito
• Dettagli, di basso livello, da risolvere in autonomia

La consiglia nel caso in cui si desideri maggiore libertà e controllo, o si voglia riutilizzare qualche “componente” di cui già si dispone.

—-><—-

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

Lamia Youseff (University of California, Santa Barbara), Maria Butrico (IBM T.J. Watson Research Center) e Dilma Da Silva (IBM T.J. Watson Research Center), in “Toward a Unified Ontology of Cloud Computing” propongono una classificazione del Cloud Computing.

—-><—-

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

Christian Heilmann, in “Yahoo For The Masses“, sintetizza l’offerta di YDN (Yahoo! Developer Network), la piattaforma di Yahoo! per gli sviluppatori.

Interfaccia Utente:

• Design Pattern Library: raccolta di patterns e stencils per risolvere problemi comuni
• YUI (Yahoo! User Interface Library): framework per il design ed il layout

Performance:

• Exceptional Performance Tips: raccolta di suggerimenti e best practices
• YSlow: plug-in di Firefox per analizzare le prestazioni di pagine web

API:

• BOSS (Build Your Own Search Engine): la ricerca di Yahoo! con interfaccia REST (REpresentational State Transfer), RDF (Resource Description Framework) e Microformats
• YQL (Yahoo! Query Language): framework per il mashup , in stile SQL

—-><—-

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

L’IDL (Interface Description Language) è un linguaggio con cui descrivere interfacce; vi si ricorre quando si desidera esporre – solitamente in modalità RPC (Remote Procedure Call) – un componente software ad altri sistemi, anche se sviluppati con linguaggi di programmazione diversi. L’IDL è paragonabile ad una lingua franca tra linguaggi di programmazione differenti: tipi semplici e complessi, parametri di input e di output, operazioni, ecc. espressi secondo il linguaggio di programmazione dei sistemi coinvolti, sono tutti ricondotti ai corrispondenti costrutti dell’IDL, che diviene così il linguaggio comune per questa comunicazione. CORBA (IDL) e WSDL sono esempi di IDL.

Facebook, tempo fa, ha aperto il codice dell’IDL che usa al suo interno: Thrift.

Thrift è quindi un linguaggio con cui definire interfacce: tipi semplici e complessi, tipi strutturati e operazioni con parametri di input e di output. Con il compilatore che include, si genera poi, a partire dalle interfacce così descritte, data-bindings e stubs, lato server e client.

Thrift è indipendente da trasporto, protocollo e serializzazione: non ne impone di specifici ma ne stabilisce l’interfaccia in modo da poter essere adattato o esteso. Di alcuni trasporti (file, memoria, socket e pochi altri) ne include l’implementazione.

Thrift, infine, è compatibile sia in avanti che all’indietro: i campi non attesi ma presenti nel pacchetto serializzato sono semplicemente ignorati, quelli attesi, ma non presenti, lasciati vuoti e il fatto segnalato. Questa caratteristica è soddisfatta sia per le strutture che per i parametri dei metodi; potrebbe però non essere garantita nel caso in cui un server obsoleto non riceva un campo rimosso da un nuovo client.

Thrift nasce da esigenze ben precise: l’interoperabilità tra un certo numero di linguaggi (Java, C++, PHP, Python e altri), la generazione automatica del codice di “traduzione” tra formati d’interscambio e nativi, il volersi sottrarre all’aggiornamento contemporaneo di tutti i sistemi e il desiderio di concentrarsi sulla logica di business piuttosto che sui dettagli d’infrastruttura.

Facebook impiega Thrift in un elevato numero di sistemi, tra cui: ricerca, logging, gestione degli annunci pubblicitari e applicazioni mobili.

Thrift è un progetto Open Source ospitato su Apache.

—-><—-

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

Google, tempo fa, ha aperto il codice di Protocol Buffers, il formato dati che usa al suo interno. L’accoglienza, stranamente, non è stata delle migliori: in molti si sono chiesti se Google non avesse semplicemente reinventato la ruota.

Protocol Buffers comprende un linguaggio con cui esprimere strutture dati indipendenti dall’implementazione e dal trasporto (rete, disco, ecc.), un compilatore con cui generare il data-binding per un certo numero di linguaggi (Java, C++, Python e altri) e librerie con cui serializzare, de-serializzare e manipolare il pacchetti dati.

Google afferma che questo formato è efficiente (veloce nella serializzazione e nella de-serializzazione), compatto (pacchetto binario dalle dimensioni molto contenute) e compatibile, sia con le versioni precedenti che con quelle successive (i campi sconosciuti sono ignorati, a quelli mancanti è assegnato l’eventuale valore di default); comunque un benchmarking non è mostrato ed è consigliato un confronto con il formato già in uso (che magari si pensa di sostituire).

I dati serializzati con Protocol Buffers possono anche essere salvati su disco o su una base dati, unica accortezza quella di far riferimento alla definizione della struttura: il pacchetto dati serializzato, infatti, non è autodescrittivo (sui documenti è comunque descritta una strategia per conseguire qualcosa di simile).

Protocol Buffers è nato non per competere con JSON (JavaScript Object Notation) , XML, ASN.1, ecc. ma per soddisfare alcuni requisiti – prestazioni, riduzione del traffico rete e spazio disco, efficienza negli aggiornamenti del software e generazione dei data-binding – anche a rischio di perdere i vantaggi della standardizzazione e della leggibilità propri, ad esempio, di XML.

—-><—-

Sullo stesso argomento:

• O’Reilly – Interview: Google Open Sources Protocol Buffers
• Matt Cutts – Cool: Google Releases Protocol Buffers Into the Wild
• Dive into mark – Protocol buffers: the early reviews are in

—-><—-

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

Se si ricercano i dati solo per chiave, se non si eseguono join o se si possiedono parecchi dati e non si desidera amministrare repliche e partizioni, potrebbe aver senso usare una base dati a coppie chiave-valore: qualcosa, ossia, molto simile ad una tabella hash distribuita.

Richard Jones di Last.fm ha pubblicato un interessante articolo – Anti-RDBMS: A list of distributed key-value stores – in cui sintetizza le caratteristiche di un certo numero di basi dati chiave-valore open source: Project Voldemort, Ringo, Scalaris, Kai, Dynomite, ThruDB, CouchDB, Cassandra, HBase e Hypertable. Tra questi, CouchDB, ThruDB, MemcacheDB, Project Voldemort e Dynomite, sembrano i più promettenti.

Project Voldemort, in particolare, è scritto in Java ed usato da Linkedin; automaticamente replica, partiziona ed esegue il caching dei dati, non ha un singolo punto di fallimento, persiste su Mysql o BerkleyDB ed è rilasciato con licenza Apache 2.0.

—-><—-

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

Gnip è un servizio di publish-subscribe sul web: raccoglie e riespone dati (eventi, attività, ecc.) tramite API.

Le sue API sono sufficientemente REST: i verbi (GET, POST, PUT, DELETE e HEAD) seguono la semantica imposta dalle specifiche HTTP, il payload è XML, il content-type conguo (application/xml) e le risorse identificate da URI.

Chi intende pubblicare o prelevare eventi, attività, ecc. su Gnip, lo fa quindi invocando API, ma Gnip, in più, consegna dati “a domicilio”: contatta eventualmente la URL comunicata ed esposta da chi sottoscrive.

Gnip, stranamente, non adotta Atom: i dati ritornati, infatti, sono strutturati secondo un formato proprietario che contiene – compresso e codificato base64 – l’originale struttura dati (così come ricevuta da chi la pubblica). Ancora più strano, non annovera XMPP (Extensible Messaging and Presence Protocol): semplicemente ancora troppo poco diffuso per essere considerato (questa la risposta sulla FAQ).

Il beneficio di Gnip è nel risparmio di risorse conseguente all’abbandono del modello polling a favore del pushing: chi pubblica, infatti, invoca Gnip solo se ha dati da comunicare, chi sottoscrive – se decide di essere invocato – li riceve solo quando Gnip li possiede (e comunque può imporre filtri per prelevare/ricevere i soli cui è interessato).

Dal blog degli autori si apprende la semplice ma efficace architettura di Gnip: la mancanza di un DBMS – rimpiazzato da file-system (Amazon S3) e cache distribuita (Terracotta) – e l’esecuzione delle trasformazioni subito dopo l’ingresso dei dati – non prima della loro uscita.

—-><—-

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

Da circa due settimane è in atto una bagarre senza fine a seguito dell’articolo “Soa is dead, long live services” pubblicato da Anne Thomas Manes sul blog di Burton Group: la SOA (Service Oriented Architecture), come sinora fatta in buona parte dei casi, è dichiarata morta; l’orientamento ai servizi, invece, necessario e inevitabile, ora più che mai.

—-><—-

Per approfondire:

• InfoQ – Debate: Is SOA Dead?
• Service Architecture – SOA: In a recession its even more about the services
• SOA Infrastructure Blog – Goodbye SOA, we hardly knew you
• Service-Oriented Architecture – Manes: let’s get more ‘concrete’ about service orienting
• Ajaxonomy – Is SOA Dead?
• ZapThink – Research: The Rumors of SOA’s Demise…

—-><—-

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