In sintesi Sharp:

• Risponde su come conciliare la modellazione con le moderne tecniche di sviluppo (soprattutto di tipo Agile): modelli semplici che diano uno sguardo d’insieme invece di modelli complessi.

• Richiama alcuni livelli di modellazione propri dello Zachman Framework: The Scope Level, The Conceptual Level, The Specification Level.

• Spiega le motivazioni per cui definisce (IMHO un po’ azzardatamente) BPMN come un “Linguaggio di Programmazione Visuale”.

Nell’articolo troverete sia il video dell’intervista sia la completa trascrizione.

Dopo aver atteso un po’ finché le novità arrivassero anche sugli utenti italiani, di seguito una sintesi ed alcuni commenti all’articolo che gli ingegneri di Twitter hanno pubblicato sul loro blog.

Attirare partner attraverso API più efficienti e affidabili significa consolidarsi sul mercato e guadagnare stima, difesa e diffusione da parte di tutti coloro che fonderanno il loro business anche su Twitter.

Questa caratteristica, che generalmente è attribuibile a tutti i prodotti fondati su una proprietà intellettuale, è unica nel suo genere se si pensa al fatto che il software è soprattutto un bene industriale.

Richiamando alla memoria la teoria delle curve di domanda ed offerta,dei concetti di punto di equilibrio ed elasticità, si dimostra come il mercato software tende verso una “inelasticità” della domanda (vendor lock-in).

Questa condizione dura fino a quando l’offerta è al di sotto dei costi di un cambio di software.

Graficamente questo punto (che l’autore chiama FYO point) è combattuto dai vendor in due modi distinti:

1. Cercando di abbassare il FYO Point dei clienti delle aziende concorrenti;
2. Cercando di ricavare il più possibile dai propri clienti.

Il primo punto è quello che conduce al meccanismo virtuoso della sana concorrenza;

il secondo – quello spesso più diffuso – è tipico di un monopolio: innalzare le barriere in entrata. Ciò si traduce nell’introduzione di formati proprietari, forti dipendenze e bassa interoperabilità.

In questo ambito si inserisce l’open source come naturale conseguenza dell’economia del software, sia dal punto di vista della domanda che da quello dell’offerta.

La domanda di open source parte dai clienti con lo scopo (tra gli altri) di non cadere nel vendor lock-in.

L’offerta di software open source parte da vendor consapevoli dell’assenza di costi variabili e quindi sulla possibilità di basare il loro profitto su beni complementari (assistenza, servizi, moduli aggiuntivi,…) e sulla diffusione della propria tecnologia/piattaforma. Questi prodotti hanno naturalmente la capacità di abbassare drasticamente il FYO Point dei loro potenziali clienti verso le aziende concorrenti.

Fonte: http://dtrace.org/blogs/bmc/2004/08/28/the-economics-of-software/

Un primo aggiornamento dei temi trattati nei miei precedenti articoli su Comet e DWR, I cambiamenti del Presentation Layer, Offline Web Applications.

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

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

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 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.

Proprio in questi giorni si è accesa una particolare discussione sull’argomento, egregiamente sintetizzata da InfoQ.

Opinioni a parte, è interessante la frase con cui B. Lublinsky (autore della sintesi) conclude l’articolo:

This discussion is just one example of the situation that is becoming more and more common in SOA and IT in general. People are using the same words while they really mean different things and keep arguing because they are using different words although in reality they are in complete agreement.

• 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)

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