Qualcuno da un po’ di tempo sostiene che è finita l’era dei DBMS. Le argomentazioni a supporto di questa affermazione partono dalla considerazione che questi sistemi sono stati sviluppati intorno agli anni ‘80, per poi essere adattati e aggiornati per poter essere in grado di affrontare le necessità dei giorni nostri. La diffusione degli RDBMS da parte dei pochi vendor in campo (Oracle, IBM, Microsoft) ha conquistato il mercato dei DBMS, imponendo di fatto l’utilizzo del modello relazionale come standard.
Negli anni però, sono emersi alcuni contesti e nuove opportunità tecnologiche che hanno messo in discussione il fatto che tali sistemi possano essere un’ottima soluzione in tutti gli ambiti.

Column-Oriented DBMS

I tradizionali DBMS utilizzano la rappresentazione a due dimensioni tipica delle tabelle, ma serializzano i dati su disco in una dimensione organizzandoli per righe (row store).
I sistemi basati su un approccio column store, pur mantenendo il concetto di tabella, invertono l’organizzazione dei dati su disco memorizzandoli per colonne.
I vantaggi di questo approccio sono particolarmente evidenti in ambiti OLAP, o più in generale quando si ha la necessità di effettuare aggregazioni di dati su una grande quantità di righe e su di un numero ristretto di colonne. La maggiore efficienza è ovviamente dovuta ad un minore accesso al disco.

Main Memory DBMS
La caratteristica di fondo di questi DBMS è quella di utilizzare principalmente la memoria invece che il disco per salvare i dati, migliorando così le performance nei tempi di accesso al dato. Questi sistemi supportano tre delle quattro proprietà delle transazioni (atomicity, consistency, isolation), ma perdono generalmente quella della durability. A questa mancanza sopperiscono attraverso l’utilizzo di un journal file (per lo storico delle operazioni), di memorie non volatili e aumentando la disponibilità dei dati con la replica del database.
Questi DBMS sono particolarmente efficienti negli ambiti OLTP.

XML Server
Nei contesti in cui è necessario memorizzare, gestire, pubblicare e scambiare documenti XML nel loro formato nativo, questa categoria di prodotti offre un engine specializzato al trattamento di dati così strutturati. Nonostante tutti i grandi vendor abbiano esteso i loro prodotti per supportare al meglio documenti XML, l’utilizzo di prodotti specializzati garantisce performance superiori.

L’emergere di queste innovativi approcci alla memorizzazione dei dati non può che far bene al mercato e all’IT in genere, e probabilmente porterà alla diffusione di soluzioni verticali a specifiche esigenze, molto competitivi per costi, semplicità e scalabilità.

Fonti

Cosa accade quando si stabilisce una connessione HTTPS?

In questo articolo di Jeff Moser dal titolo “The First Few Milliseconds of an HTTPS Connection” vengono analizzati tutti i dati scambiati tra il browser ed il server all’atto dello stabilire una connessione sicura.

Un’analisi ben fatta che mi fa ricordare una lezione molto simile ai tempi dell’università.

Altre risorse utili alla lettura dell’articolo:

http://en.wikipedia.org/wiki/Public-key_cryptography

http://en.wikipedia.org/wiki/MD5

http://en.wikipedia.org/wiki/RSA

In questo filmato della QCon London 2008, Joe Walker presenta Comet e DWR.

Comet è una modello di sviluppo di web application basato su AJAX e sulla tecnica del long-polling che permette al server web di inviare dati in modalità push al browser.

DWR è un framework Java per lo sviluppo di Rich Internet Application (RIA) che utilizzano AJAX.
Joe Walker è il fondatore e principale sviluppatore del framework.

Buona visione!

http://getahead.org/blog/joe
http://cometdaily.com
http://cometd.com
http://directwebremoting.org/
http://stefanopedone.wordpress.com/2008/07/22/i-cambiamenti-del-presentation-layer/

La notazione BPMN (Business Process Modeling Notation) nacque qualche anno fa su iniziativa di un consorzio di aziende (BPMI.org) per rispondere al bisogno preciso di definire uno standard per la modellazione dei processi di business. Dopo il rilascio di una prima versione, BPMI.org confluì all’interno di OMG. Attualmente è prossimo il rilascio di una successiva versione dello standard (l’ultima versione di riferimento è la BPMN 1.1).Da subito la notazione ha cominciato a diffondersi negli strumenti di modellazione dei vari vendor, ma parallelamente sono andati emergendo i limiti che la specifica portava con sé:

• Non definisce un formato di interscambio tra i diversi tool di modellazione;
• Non è esplicitamente specificato un metamodello per BPMN;
• La semantica dei costrutti di modellazione non è ben definita e rigorosa;
• Ha dei limiti per la definizione di “coreografie” di processi.

Un formato di interscambio permette l’ esportazione/importazione di un diagramma di processo tra differenti tool di modellazione BPMN. Alcuni utilizzano XPDL allo scopo, ma il mapping con BPMN non è completo, non essendo stato costruito sugli stessi costrutti di modellazione. Attualmente la nuova versione XPDL 2.0 dichiara di supportare pienamente BPMN 1.0.
Inoltre molte compagnie stanno adottando l’infrastruttura di modellazione definita da Eclipse Modeling Framework (EMF) e un formato basato su XMI (XML Metadata Interchange – anch’esso standard OMG).
La specifica BPMN non definisce alcun formato di interscambio.

A monte di questa mancanza c’è la carenza di una esplicita definizione di un metamodello BPMN, cioè di una struttura informativa in grado di contenere l’informazione relativa ad un modello di processo.
Quando uno strumento di modellazione memorizza un diagramma lo fa in conformità con la struttura informativa del metamodello.

Ciò ancora non basta. Perché l’interscambio dei diagrammi di processo sia efficace è necessario che tutti i BPMS (Business Process Management System) interpretino (e quindi eseguino) il modello allo stesso modo. La semantica del processo deve essere chiara e condivisa.

Infine, la specifica BPMN ha delle lacune nella definizione della rappresentazione di processi che coinvolgono scenari B2B, quella che in gergo viene riconosciuta come “coreografia”.
La differenza tra “orchestrazione” e “coreografia” è che con il primo termine generalmente ci si riferisce alla gestione di processi interni all’organizzazione da parte di un unico “orchestratore” (il motore di esecuzione del processo) , mentre con il secondo alla comunicazione tra processi indipendenti e tipicamente esterni, che modellano cioé degli scenari Business to Business (B2B). Nelle grandi realtà aziendali anche le relazioni interdipartimentali sono spesso assimilabili a relazioni di tipo B2B.
BPMN fornisce le swim lane e le pool come unici artefatti in grado di separare le attività che intervengono in questo tipo di comunicazione.

Questi in sintesi gli elementi principali che fanno parte della RFP che OMG ha pubblicato nel giugno 2007 e che stabiliscono la specifica dei requisiti per la nuova versione dello standard in corso di approvazione, BPMN 2.0.

OMG già nel 2003 aveva lanciato una RFP per la specifica di un metamodello di processi di business: il Business Process Definition Metamodel (BPDM). Esso è la base per definire un modello di processo indipendente dalla notazione utilizzata per rappresentarlo. Utilizza il MetaObject Facility (MOF) come base per il metamodello e XML Metadata Interchange (XMI) per la memorizzazione del modello.

Due le principali risposte alla RFP per BPMN 2.0. La prima proposta è la BPMN for Services (BPMN-S), la seconda è a cura di BEA-IBM-Oracle-SAP.
La principale differenza tra le due è in merito alla definizione del metamodello per la notazione.
BPMN-S sceglie sostanzialmente BPDM e fornisce un mapping tra la notazione e il metamodello, giustificando la scelta con l’opportunità di fare in modo che la versione 2.0 sia il punto di raccordo tra BPDM e BPMN 1.x.

Il gruppo BEA-IBM-Oracle-SAP sostiene invece la necessità di creare un metamodello separato per la notazione, che faccia direttamente riferimento alla terminologia della notazione e fornendo poi un mapping tra questo metamodello e quello più generalizzato di BPDM. La motivazione si basa sul fatto che BPDM è un metamodello per un linguaggio astratto di definizione dei processi, mentre nell’altro caso si tratta di uno dei possibili linguaggi concreti.

Per ulteriori approfondimenti:

• BPDM: Advanced Information Modeling and Ontology (C. BOCK)

Negli ultimi anni si sta assistendo lentamente ad un mutamento della consolidata architettura a tre livelli che caratterizza le applicazioni web. Il consolidamento di tecnologie lato client e i nuovi paradigmi architetturali della parte server stanno modificando il posizionamento della logica di presentazione.

La storica “battaglia dei browser” negli anni ‘90 (Microsoft vs Netscape) e le sue successive ripercussioni, hanno fatto sì che la progettazione delle applicazioni web delegasse al client il solo compito di visualizzare pagine HTML, opportunamente popolate e controllate dalla parte server dell’architettura. Il popolamento dei template in base ai dati provenienti dai livelli sottostanti e il controllo del flusso di presentazione sono tutt’oggi compiti che sono affidati alle tecnologie lato server che ne sostengono efficacemente il design, lo sviluppo e l’esecuzione.

Nel tempo però i due domini architetturali (client e server) hanno subìto e continuano a subire dei cambiamenti.
Molte delle divergenze della citata battaglia si sono appianate e parallelamente sono nati dei veri e propri framework che astraggono i problemi relativi al cross-browsing esponendo opportune API.
Tutt’oggi le potenzialità e l’affidabilità del lato client sono aumentate notevolmente e sono in continua crescita.
E’ giusto allora cominciare a pensare che la logica di presentazione cominci a porsi sempre più l’obiettivo di essere dove gli compete, cioé sul client, ambiente vitale della parte “View”.

Questa pretesa di maturità del client d’altronde è coerente con ciò che sta accadendo dalla parte server.
Mi riferisco alle architetture Service Oriented (SOA) mediante le quali la business logic è esposta sempre più come servizio accessibile con interfacce standard. I principi di scambio dati strutturati ed in formato standard tra domini architetturali distinti dovrebbero sempre più essere adottati in riferimento al Presentation Tier.
Inoltre, avere un livello di presentazione “autonomo” nella logica ben si sposa con il principio di basso accoppiamento delle SOA. Qualcuno parla di “front-end Service Oriented“.

Ajax già tutt’oggi permette di accedere direttamente a dei Data Service e visualizzare dinamicamente sulla pagina il risultato della loro elaborazione. Inoltre le possibilità che cominciano ad emergere in merito alla gestione controllata del caching del browser (vedi precedente articolo sulle Offline Web Applications) permette di spostare sempre più il baricentro della logica e del controllo, lasciando al server l’importante compito di fornire accesso a dati opportunamente strutturati. Tutto ciò permette di avere un incremento di velocità nell’applicazione e un carico sulla rete caratterizzato probabilmente dalla stessa latenza ma da una quantità dati certamente inferiore.

Allo stato delle cose però questo mutamento architetturale porta con sé delle incertezze.
Innanzitutto il fatto che inserire logica lato client la rende di fatto “accessibile” a tutti e ciò potrebbe far storcere il naso in diverse situazioni.
C’è poi da dire che, con questo genere di approccio, lo stato dell’applicazione viene mantenuto dal client e anche questo conduce a possibili problemi di sicurezza.
Infine, si dovrebbe garantire di poter ottenere lo stesso grado di ubiquità che offrono le attuali applicazioni web , cioè la possibilità di potervi accedere in maniera coerente da diverse piattaforme e terminali.

Risorse in Rete:

• http://www.dojotoolkit.com/
• http://www.openajax.org/index.php
• http://javascriptmvc.com/
• http://unclescript.blogspot.com/2008/01/end-of-web-frameworks.html
• http://unclescript.blogspot.com/2008/02/end-of-web-server-frameworks-part-ii.html
• http://www.infoq.com/articles/rationalizing-presentation-tier
• http://wisdomofganesh.blogspot.com/2007/10/life-above-service-tier.html

Notizia di qualche giorno fa che due importanti attori del panorama web mondiale hanno adottato Google Gears per la memorizzazione offline di risorse. Si tratta di WordPress.com e di MySpace.com.

WordPress ha annunciato la novità facendo apparire un pulsante “Turbo” sulla barra di amministrazione in alto a destra. La soluzione (che ricorda un po’ il pulsante turbo dei vecchi PC) permette di sfruttare il plugin di Google per scaricare circa 200 file da memorizzare nella cache locale di Gears, in modo da velocizzare l’accesso a tali risorse in fase di utilizzo della piattaforma WordPress.

MySpace ha deciso invece di utilizzare Gears per permettere una migliore ricerca tra i messaggi personali ricevuti.

Come ho scritto nel mio primo articolo sulle Offline Web Applications, si tratta in questo caso solo di uno dei possibili vantaggi apportati da queste estensioni del browser.
WordPress si è tolta di dosso la necessità di rispondere a richieste di file (probabilmente immagini) che evidentemente sono molto utilizzati e abbastanza statici nel tempo.
MySpace non ha fatto altro che spostare lato utente il gravoso compito di svolgere la ricerca lato server sul testo dei messaggi personali.

Certamente ciò permette di velocizzare l’utilizzo delle due piattaforme di blogging, ma c’è da sperare che in futuro altre possibilità offerte da Gears siano sfruttate, come per esempio comporre offline nuovi contenuti da pubblicare in fase di sincronizzazione.
A quanto pare già la successiva versione opensource di WordPress.org (la 2.6) dovrebbe supportare nativamente la presenza di Gears e sfruttare maggiormente le sue potenzialità.

Quando pensiamo a ciò che ha rappresentato l’avvento di Internet e a ciò che è diventato al giorno d’oggi, ci risulta abbastanza facile pensare che la sua importanza crescerà sempre più nel futuro, pur non sapendo quale sarà la precisa direzione.

Questa apparente discrepanza tra la certezza del suo continuo successo e allo stesso tempo la non consapevolezza di come ciò avverrà, in realtà è proprio il punto di forza del Web.
Questa caratteristica deriva dal fatto che Internet è stata costruita con lo scopo di abilitare l’innovazione e non di indirizzarla. Le tecnologie che ne sono le fondamenta (prime tra tutte il TCP/IP) sono state pensate e progettate perché fossero utilizzate ben oltre la loro stessa utilità immediata.
Gli standard di comunicazione sono tali da permettere a chiunque di utilizzarli e di interoperare.

Questa maniera di progettare la Rete come una piattaforma aperta ne ha garantito il successo. Le tecnologie e gli standard hanno permesso un riutilizzo delle informazioni e delle tecnologie stesse in una maniera che gli ideatori della Rete mai avrebbero immaginato.

Tutto ciò grazie a tecnologie abilitanti per l’innovazione.

A queste si contrappongono spesso quelle che Tim Berners-Lee, il padre del WWW, chiama le ceiling technologies, le tecnologie-soffitto. Si tratta di quelle tecnologie che tendono a bloccare l’innovazione, o meglio a limitarla da precise condizioni o a determinati vendor.
Esse non hanno futuro. E se anche garantiscono un immediato ritorno economico, nel lungo periodo sono destinate ad essere tagliate fuori da una piattaforma (il Web) e, ormai più in generale, da un mondo che si fonda sul concetto di comunicazione e interoperabilità, a più livelli e in diverse forme.

La realtà aziendale italiana composta principalmente da piccole e medie imprese (PMI) è uno scenario particolare in cui le soluzioni SOA e le Saas potrebbero trovare terreno fertile.

Come tutti i paradigmi tecnologici legati principalmente alle grandi aziende, si fa fatica a pensare come le piccole imprese li possano adottare a loro vantaggio.
Già il concetto stesso di “architettura” (Service Oriented Architecture) potrebbe far storcere il naso a qualche imprenditore ed indurlo a pensare che forse si tratta di qualcosa per cui non vale la pena investire perché aldilà delle effettive necessità.

Ma come è avvenuto per i sistemi di CRM e per la posta elettronica, che ormai sono componenti essenziali dei
sistemi informativi delle PMI, forse ancor di più l’idea di orientare la piccola e particolare realtà IT fin da subito nella prospettiva dei Servizi potrebbe rappresentare una soluzione efficace.

I principi di fondo alla base di una SOA, infatti, ben si adattano alle PMI, soprattutto in termini di flessibilità, agilità e governo.

Le nuove soluzioni applicative basate su SaaS o simili (Software + Services) inoltre non farebbero altro che aumentare le possibilità di ritorno degli investimenti (ROI) della scelta di pensare il proprio business (più o meno piccolo che sia) e il proprio IT in termini di servizi.

Se però si continua a ridurre SOA ad una nuova sigla con nuove tecnologie per l’integrazione, ecco che forse la distanza da questa tipologia di aziende – in cui di legacy c’è ben poco – non potrà che aumentare.
A questo si aggiunge la confusione che spesso viene mediata dalla moda del “festival degli acronimi” anche su siti web che dovrebbero essere più accreditati a chiarire le idee agli imprenditori italiani.

Nella progettazione di sistemi largamente distribuiti ad alta scalabilità, incombe il vincolo di una legge che regola il compromesso tra disponibilità e consistenza dei dati: il Teorema di CAP.

Eric A. Brewer in una presentazione del 1998 (Lessons from Internet Services: ACID vs. BASE) introdusse questa congettura, in seguito fu dimostrata vera:

Un sistema di dati condivisi è generalmente caratterizzato da tre proprietà: consistenza, disponibilità, tolleranza al partizionamento di rete (Consistency, Availability, tollerance to network Partitions).
Il teorema afferma che si possono avere solo due di queste tre proprietà, sacrificando quindi la terza.

Degli esempi:

• Consistenza e Disponibilità: si tratta di sistemi localizzati che non risentono di partizionamento di rete, come un LDAP, un database centralizzato o un file system. La consistenza è garantita da transazioni 2PC (two-phase commit).
• Consistenza e tolleranza al Partizionamento: sistemi distribuiti, con un elevato partizionamento di rete, in cui il valore della consistenza dei dati è di primaria importanza, a scapito della eventuale elevata latenza e bassa disponibilità (dovuta a politiche di locking pessimistiche).
• Disponibilità e tolleranza al Partizionamento: la disponibilità è il valore principale per questo genere di sistemi. Per questo utilizzano protocolli più ottimistici e un approccio best-effort. Un esempio classico sono i DNS.

I grandi siti web dei nostri giorni, caratterizzate da architetture altamente scalabili e profondamente distribuite con politiche di prossimità geografica, puntano in maniera forte sulla garanzia di alte prestazioni ed estrema disponibilità dei dati. Si trovano quindi nella terza delle situazioni citate.

Lo sforzo di garantire dati consistenti porta questi sistemi ad adottare approcci differenti per l’accesso e l’aggiornamento dei dati.
Si passa dall’approccio transazionale ACID (Atomicity, Consistency, Isolation, Durability) ad un approccio BASE (Basic Available, Soft-state, Eventual consistency).

Per comprendere nel concreto come sia possibile ottenere dati sempre aggiornati e disponibili anche utilizzando l’approccio ottimistico del tipo BASE, consiglio la visione di un intervento di Werner Vogels, CTO di Amazon.com sull’argomento.

La presentazione è disponibile su InfoQ a questo indirizzo:
http://www.infoq.com/presentations/availability-consistency

Link consigliati: http://highscalability.com