Narciso Yepes e la chiave del quindici

Narciso Yepes, diventato noto al grande pubblico per aver suonato con la sua chitarra classica il pezzo centrale della colonna sonora di Giochi Proibiti, soleva ricordare di aver imparato le basi da un grande maestro che, però, non era un chitarrista, ma un pianista, Vincente Asencio.
Asencio gli faceva sentire al pianoforte cosa doveva suonare. Quando lui gli diceva che non era possibile ripeterlo con la chitarra, Asencio gli rispondeva che, se non poteva fare nulla con quello strumento, avrebbe fatto meglio a cambiarlo. Così Yepes studiò nuove tecniche, riuscì a ripetere gli esercizi proposti, diventò uno dei massimi virtuosi del mondo, arrivando a tenere concerti con la chitarra estesa da 6 a 10 corde dal liutaio Ramirez secondo i suoi suggerimenti.

Questo aneddoto deve essere molto noto perchè è facile incontrare persone che si immedesimano in Yepes.
Qualche virtuoso esiste anche, ma non è raro vedere usare strumenti sbagliati nei modi e momenti sbagliati, con tentativi di estensione ed estremizzazione, ma senza prima averne approfondito i limiti.

Come chi cerca di usare la chiave del quindici su un bullone da 12 o un martello per svitare un dado, talvolta i risultati possono non essere quelli sperati (ben vengano le eccezioni, ovviamente!).

In questo senso, uno degli esempi più comuni nell'informatica è quello di considerare l'XML come ingrediente fondamentale e irrinunciabile. Non importa per cosa, l'importante è usarlo.

---

Qualcuno di voi sarà anche saltato sulla sedia, ma l'XML, che mi conosce, sa che non deve prendersela, dal momento che gli è ben noto che lo uso con quotidiana assiduità.

Ci frequentiamo almeno dal 1996 1998 e non se la prende se continuo a sottolineare l'ovvio, ovvero che continuare ad evidenziare che è uno standard è utile quanto confondere Java con la sua sintassi di base.

Perchè di standard, nell'XML c'è solo quello: la sintassi.
La semantica bisogna sempre implementarla, come credo sia ben noto.

Dtd o Xml Schema servono per rafforzare la sintassi, anche se a diversi livelli, ma per usare quei dati incastrati tra un tag e l'altro, serve sempre un programmatore.

Spero, infatti, sia a tutti palese che, anche usando l'xsl(t), anche se dichiarativamente, anche se tra mille limiti e salti tripli per fare cose banali in altri ambienti, stiamo sempre scrivendo regole, filtri, semplici trasformazioni, qualche controllo, ovvero: programmando.
A questo proposito, giusto per fare un esempio che mi piace sempre sottolineare, progettare una architettura multilivello, separando bene la presentation dalle business rules e poi decidere coscientemente di buttare la possibilità di usare competenze e strumenti specifici del front-end (esperti di html e javascript, grafici che costano tipicamente meno di programmatori e strumenti WYSIWYG che permettono un disegno rapido) usando xml ed xslt per generare il layout e manutenerlo è veramente un peccato.

Senza considerare che il carico (sia in termini di heap che di cpu) per il parsing ed applicazione delle regole rischia spesso di essere significativo rispetto all'utilizzo di altre tecniche (magari compilate, come una buona vecchia JSP).

Comunque, se il fatto che si debba fornire la semantica programmandola e che sia ragionevolmente sconsigliato sfruttare l'XML come base di un template engine/layout manager fossero gli unici problemi non avrei scritto questo articolo. Si tratterebbe di peccati veniali.

Ciò che mi preme sottolineare è la tendenza all'esagerazione nell'utilizzo di questo seppur utile e versatile strumento.

Per esempio, come strumento per memorizzare dati, in ambiti complessi.
Per fare un esempio pratico: non mi direte che non avete mai visto un CMS xml-based, vero?
Io ho anche visto citare questa feature come elemento distintivo di certi sistemi, laddove il pubblico (e talvolta l'oratore) non era in grado di cogliere che:

• la stessa flessibilità descrittiva si può ottenere anche con un bel database, con la stessa facilità (i casi cui mi riferisco riguardano progetti di una certa dimensione, dove non è neppure messo in dubbio che esistano altre funzionalità per cui è necessario ed irrinunciabile un bel RDBMS)
• ricercare valori di tag in XML salvati sul filesystem non è operazione propriamente performante: per risolvere questo tipo di problema è solitamente necessario ricorrere ad altre strutture architetturali (es: estrazione preventiva dei metadati e loro indicizzazione - non di rado appoggiandosi ad un RDBMS, o, talvolta, addirittura riscrivendo da capo funzionalità che sono oramai consolidate e super-performanti da anni in quei sistemi -, cache multilivello, etc. etc.)
• come sopra citato, per la famosa estensibilità garantita dall'XML bisogna programmare: lo so bene che non è sempre necessario farlo all'aggiunta di un nuovo campo in un CMS, - a patto di rimanere entro certi limiti, beninteso -, ma per quello che mi è capitato di verificare nella pratica o si rientra in situazioni quasi banali e gestibili anche più facilmente su DB, o si devono comunque battere quelle costose 10 benedette dita sui tasti.

Un altro caso tipico è la generalizzazione "hand made", tipicamente in fase di configurazione di un sistema: il costo dell'interprete vale il vantaggio della generalizzazione? ci lamentiamo della reflection e aggiungiamo un intero interprete? anzi, a volte aggiungiamo pure la reflection come modalità di costruzione di oggetti generalizzati nell'xml, da far richiamare in una Factory e/o in un Singleton allo startup?

Non so se vi siete resi conto delle risorse richieste per l'elaborazione, soprattutto usando DOM - a proposito, su .NET c'è il parser SAX, o si va solo di DOM? io non sono riuscito a trovarlo...:

• tempi per il parsing (SAX e DOM)
• tempi per costruirsi gli oggetti (automaticamente nel DOM, spesso 'a mano', più leggeri, con parser SAX based)
• heap che si riempie facilmente (che so: mai provato un out of memory in Java per import dati massivo via XML, passando da un parser DOM?)

Vediamo di esaminare anche i vantaggi, per capire dove ha senso usarlo, almeno IMHO (in italiano verrebbe IMMP, fa schifo, spero lo capiate, senza considerare che la 'M' di 'Modesto' poco mi si addice):

• la standardizzazione di questa sintassi aiuta nell'avere dei parser e ci sono molti casi in cui un parser bell'e pronto è proprio ciò che ha ordinato il dottore (per esempio, per estendere un linguaggio con tag libraries/web controls)
• esistono casi - rari e semplici, purtroppo - in cui una bella trasformazione xslt è comunque decisamente più semplice da scrivere di un programma (es.: per creare dei pdf - xsl-fo - magari a partire da un html: bisogna lavorare un po' sull'xsl, ma fare uno spider che si naviga il sito in un certo ordine e ne produce un libercolo in pdf è alla portata - mi dicono che il Mac lo faccia di default, è vero? per PC, tra gli open source, di decente ho trovato solo HTMLDOC, anche se non si naviga da solo gli url delle pagine - ; ancora: nel passaggio di dati da un sistema ad un altro, spesso è utile trasformare un XML proveniente dall'esterno in un XML in formato già gestito dal nostro sistema, per rielaborarlo senza ulteriori sviluppi e un filtro di questo tipo scritto in xsl è la morte sua).
• laddove le descrizioni dei dati (dai tracciati record alle immagini SVG) sono complesse e questi dati devono essere scambiati tra sistemi o essere alla base di programmi per cui ha poco senso aggiungere un database, l'XML è decisamente più adatto di altri formalismi (es, il vecchio EDI), essendo potenzialmente molto più ricco, espressivo e permettendo di condividere e validare la sintassi in modo più mirato.

Proviamo un piccolo riassunto di casi pratici, relativo ai punti su cui solitamente mi sento o non mi sento di usarlo:

NO

• in generale, per evitare di gestire documenti su DB (es. del CMS) o come modalità di estensione dei campi nel database: non posso fare ricerche e join in modo performante, devo parsare ed intepretare il mio file ogni volta (a meno di pre-parsing ed indicizzazioni di cui si è già parlato - ma come gestite l'indicizzazione? la delegate al DB o la gestite a mano? vi siete ricordati di indicizzare tutti gli elementi e lasciare il testo ad un motore di ricerca full-text? i valori dei tag sono codificati o si tratta di stringhe, pure inserite manualmente?). Indizi del fatto che non va così bene: a parte i tempi di sviluppo di eventuali indicizzazioni e recupero dei dati, dovete usare uno o più livelli di cache e, in caso di miss, la relativa interpretazione porta via 2 ordini di grandezza o più del tempo necessario per recuperare il dato pre-interpretato dalla cache (2 ordini di grandezza è troppo: sarebbe bene che le cache correggano 1 ordine di grandezza, altrimenti è indice di seri problemi nell'operazione fuori cache: se non ci sono alternative, fate bene ad usarle, ma se le alternative ve le siete precluse da soli...).
• XML per memorizzare oggetti:
• non vi piaceva la serializzazione nativa di Java e davvero pensate che questa sia più veloce? provate a fare un profiling e non dimenticate la gestione del versioning delle classi).
• la versione in xml potete passarla come risultato di un Web Service? in linea di principio va bene, ma usare qualcosa di già pronto - es: SOAP - e passare direttamente l'oggetto era troppo standard?
• vi serve per estendere il DB? v. sopra.
• Volete farvi da soli il vostro OODBMS? Forse è il caso di considerare qualcosa di già pronto (ma non prima di aver considerato che, comunque, si tratta di tecnologie ancora molto discusse e, come minimo, un po' immature)
  
• XML alla base dello strato di presentation: in questo caso si ha la perdita di performance per interpretazione vs. compilazione di cui ho già parlato; vi sentite più flessibili nel definire le zone del sito e le pagine? avete contato bene il costo di manutenzione, la flessibilità e quanto vi è costato realizzare un Template Manager di quel tipo, fuori da ogni standard?.

NI [situazioni da pesare, caso per caso: personalmente non ho ancora trovato una regola]

• XML come file di configurazione [rischio: overdesign (in molti casi basta un file di properties) - possibile vantaggio: flessibilità ed espressività (soprattutto quando servono diversi livelli di approfondimento)]
• XML come metadato (es.: base per Xlink o, più in generale, per il Web semantico ed RDF) [rischio: performance povere per mancanza indicizzazione o indicizzazione manuale, difficoltà nell'eseguire query, difficoltà di documentazione - possibile vantaggio: distribuibilità, laddove le performance non sono importanti, maggiore disponibilità di ambienti per eseguire parsing xml rispetto ad installare un RDBMS

SI

• XML per trasferire dati ed aumentare l'interoperabilità tra applicazioni (in tanti sostengono che sia nato per questo ;) ):


• Web Services
• base per Web 2.0, a partire da RSS/ATOM
• come sorgente dati remota (in particolare come RE in REST)
• in generale, per disaccoppiare i sistemi


• XML come base per il formato di memorizzazione di una applicazione standalone laddove usare un DB sarebbe un po' eccessivo (es: state scrivendo Open Office e decidete di salvare in dati in locale, in formato portabile, aperto e facilmente trasformabile; i vostri dati, in questo caso, tipicamente non richiedono ricerche cross tra i diversi xml, al più solo all'interno di uno stesso documento
• come base per definire nuovi linguaggi che richiedano interpretazione ed esecuzione: Apache Ant docet e certamente ha senso, dal momento che, in questi casi, comunque bisogna scrivere un parser ed un interprete e trovarsi con metà del lavoro fatto (e anche bene) non può che far piacere; altri esempi sono linguaggi che descrivono regole inferenziali (es: XML Rule Language in JBoss Rules - ex. Drools - ma, attenzione, nel manuale anche loro stessi dicono: 'There are several scenarios that XML is desirable. However, we recommend that it is not a default choice ...') o linguaggi che descrivono comportamenti che necessitano di un controllo di esecuzione (es: per definire dei workflow o - con un salto di fantasia di un centimetro e mezzo - come base per il governo di un ESB, come nel caso di BPEL).

Avete altri esempi? Avete elenchi di altri metodi architetturali usati malamente?
Non siete d'accordo su quanto ho detto dell'XML e ne volete parlare?
Beh, provate a darmi un feedback, prometto che se ne ho voglia ci penso su...

Bye

Depa

P.S.: poi magari salta fuori che avete ragione voi
P.P.S.: per quanto improbabile, intendo... ;)

[... continua ...] Leggi tutto

Letteratura Fiabesca Applicata all'Informatica

Suppongo siate in pochi ad essere a conoscenza del fatto che le fiabe e, più in generale, i racconti del folclore, sono classificabili secondo un sistema analitico, definito da Aarne e Thompson, che si sono presi la briga di leggersi migliaia di fiabe e di appiccicargli etichette tipo: AT 425A “Il mostro o animale come sposo”, o AT 0151 "Lezioni di musica da animali selvaggi".

Sarà anche probabile che non possa fregarvene di meno di questa notizia e che stiate già per cambiare blog, borbottando che cercherete di fare del vostro meglio per dimenticarvi queste inutili nozioni, come Sherlock Holmes quando Watson gli fece notare che la terra gira attorno al sole ("Uno studio in rosso").

Se decideste davvero di farlo sarebbe solo l'n-esima triste conferma che la scuola non prepara più come una volta, che stiamo perdendo l'interdisciplinarietà e potenziali Leonardo e Galileo, appiattiti in una bruttura informatico-virtuale, per la quale non dovrete stupirvi se incontrerete a breve qualcuno che, usando espressioni care al Manzoni, potrà giustamente apostrofarvi con nel mezzo, vile meccanico.
(se siete riusciti a sopravvivere alle contorsioni e forzature della frase precedente - n-esima triste conferma del fatto che la scuola non sa più insegnare a scrivere in italiano -, forse avrete anche speranze di salvarvi culturalmente, ma dovreste certamente preoccuparvi per potenziali problemi mentali latenti).

Quelli tra voi più illuminati ed abituati a ragionamenti elastici, invece, non si saranno certo fatti sfuggire l'evidente parallelismo tra questo tipo di tipizzazione e quella presente nei linguaggi di programmazione (converrete senza dubbio, invece, che sarebbe un po' forzato trovare somiglianze con i Design Pattern, per i quali potremmo, invece, spingerci a considerare lo Schema di Propp).

Sarà inoltre evidente a tutti che gli spunti provenienti da un umanesimo di alto livello adatti ad introdurre il mio contributo nell'arena della tipizzazione forte o debole nell'informatica avrebbero potuto essere molteplici (dal 'sono un tipo, anzi un topo' di Geronimo Stilton, ad approfondimenti su grammatiche e licenze poetiche, etc. etc.), ad ulteriore dimostrazione che non si tratta di un argomento ormai consunto, ma di parte integrante delle esigenze culturali fondamentali dell'uomo e, pertanto, degno di essere ancora una volta approfondito...

(per il mio e vostro bene, qualcuno mi tolga dalla testa lo scrittore barocco che sta suggerendo queste ultime righe, prima di continuare la lettura)

---

Prima di iniziare la tesi di laurea, pur conoscendo (ovviamente! spero non vi abbia neppure sfiorato il dubbio!) la differenza tra tipizzazione forte e debole (strong and weak o static and dynamic typing), avevo sempre affrontato il problema procedendo per istinto.

Esattamente al contrario del mio tutor, che usava il Common Lisp ricercando strutture e controlli sui tipi di dati come se stesse usando il C, io tendevo a programmare in modo volontariamente non tipizzato.

Quando due uomini forti si scontrano su argomenti così decisivi per il bene della comunità è quasi inevitabile che nasca una discussione (animata, ma divertente): io difendevo la flessibilità che un simile approccio poteva fornire (soprattutto in lisp e, caspita, se non si cerca il massimo della flessibilità proprio nell'AI...) e lui difendeva la correttezza formale ed il controllo a compile-time, necessario, in particolar modo, in caso di sistemi particolarmente complessi (e ulteriormente utile, nel caso si debba lavorare con risorse alle prime armi o quasi, per ridurre significativamente le probabilità di errori).

Ancora oggi, di fatto, mi piace ridurre al minimo i vincoli, soprattutto se posso fidarmi degli sviluppatori del team.
Mi piacciono e ritengo fondamentali i Generics, ma se programmo per mio divertimento (sia per attività AI-related che non), tendo a saltarli apposta e mi gioco con reflection, metadati, valutazione dinamica di espressioni e, in genere, di codice (e perchè no, generato automaticamente) ed ignoro i warning di non tipizzazione delle collection che rischiano di ridurre la flessibilità del mio sistema (ovviamente, il cast automatico delle classi è due volte essenziale).

Cerco la genericità anche a livello di database, nei pochi spazi concessi (se c'è un sistema giustamente tipizzato quello è il DB, converrete). Che so: quanto è meglio poter dire varchar2, al posto che varchar2(20)? oppure, e questo viene condiviso praticamente da tutti, quanto è bella la sintassi che permette di definire, in PL/SQL, una variabile come di tipo tabella.campo%TYPE? E, nonostante il rischio di ridotte performance (ma dipende dai casi) e la complessità nel costruire query dinamiche che siano anche solide, non posso evitare di essere attratto anche da questa ulteriore non tipizzazione.

Senza esagerare, chiaramente: non proponetemi campi di testo o LOB per contenere informazioni aggiuntive, neppure se state pensando di strutturarle in XML (anzi, peggio, se sono strutturate in XML - ma ne parlo un'altra volta, perchè i motivi non c'entrano con questo argomento).

Non sono un estremista, in questo senso: semplicemente ritengo, come in altri casi, che sia essenziale conoscere i pro e i contro di ogni approccio e che, evidentemente, le regole informatiche sono fatte per essere infrante, anche se solo quando si sa esattamente cosa si sta facendo, comprendendone appieno gli effetti collaterali.

Dobbiamo tener presente che siamo comunque costretti a trattare con la tipizzazione dinamica, anche perchè ne siamo circondati. Per esempio:

• http: tutto è stringa (siamo noi che le riportiamo a tipi, una volta che estrapoliamo dalla request, cercando un mapping e binding più o meno esplicito, ma il protocollo non prevede altro)
• Javascript: le dichiarazioni di tipo non esistono e possiamo cambiare allegramente il tipo dati (e nessuno dice che sia corretto o consigliabile o facilmente debuggabile - anzi, già che ci siamo: vi anticipo che ritengo che, laddove si usi Javascript lato client, sia veramente pericoloso ed inutile, per la povertà dell'ambiente di esecuzione, utilizzare coscientemente questa possibilità)
• polimorfismo: nasce per migliorare il riutilizzo di codice: è una sorta di via di mezzo tra tipizzazione forte e debole, no? (tipizzate pure fortemente, tanto io vi referenzio ad un livello più astratto, meno caratterizzato, anche se proprio nelle vostre particolarità...). In realtà tende così tanto alla tipizzazione dinamica che non pochi linguaggi di ampio uso permettono quello che viene chiamato Duck Typing. Che ha un po' a che fare con l'induzione (ricado sempre nell'AI, non c'è verso...). Vi consiglio di approfondire in particolare l'estratto del precedente link riguardante il duck typing in Java e, in particolare, l'articolo di David Orme (il papà di Visual Editor Project di Eclipse) che riporta il pattern e i suoi dettagli implementativi
• etc. etc.

Spingendo all'estremo l'interpretazione del concetto in esame fino alle generiche strutture dati, saltano agli occhi anche le seguenti alternative (da considerarsi come esempi non esaustivi):

• ResultSet vs. Bean ORM: i ResultSet con i loro metadati sono una sorta di interfaccia non tipizzata (che, curiosamente, wrappa dati fortemente tipizzati), con ottimizzazioni basate sulla presenza di metadati, in contrapposizione ad un classico (da Hibernate, per intenderci) mapping tra tabelle e Java Bean
• Bean vs. HashMap: si tratta di una alternativa simile alla precedente, che si può porre laddove preferiate non ricompilare, ma, piuttosto, gestire una configurazione, perdendo in controlli compile-time

Proviamo a ricordare, prendendo spunto dalla solita Wikipedia, le funzionalità principali che sono sostenute dalla tipizzazione forte:

• sicurezza: il compilatore può già identificare codice errato, riducendo i costi di debugging. Posizioni estremiste arrivano a dire che una tipizzazione molto forte potrebbe evitare la gran parte degli errori del codice, nonostante l'esperienza insegni che, pur essendo indubbio il vantaggio fornito in questo senso, solitamente i bug più insidiosi non potranno mai essere individuati dal compilatore (anche perchè, nella maggioranza dei casi si tratterà di interpretazioni di business)
• ottimizzazione: un controllo di tipo statico fornisce al compilatore informazioni fondamentali per creare codice più efficiente. Il vantaggio viene in parte compensato dal fatto che, mentre è innegabile che la generalizzazione implichi solitamente esecuzioni più complesse (quindi più lente - es.: reflection), è anche vero che richiede minori controlli per verificare che i tipi siano o meno rispettati. Inoltre, tipicamente, la tipizzazione debole richiede meno righe di codice sorgente, meno codice da rivisitare, cicli di edit-compile-test-debug ridotti.
• documentazione: i tipi sicuramente aiutano ad indicare chiaramente le intenzioni del programmatore, migliorando complessivamente il passaggio di informazioni
• astrazione e/o modularità: tipi complessi permettono ai programmatori di progettare ad un livello più elevato (es: stringhe e non array di bytes), semplificando la definizione delle interfacce tra componenti e sistemi. Migliorare la definizione delle interfacce è, ovviamente, particolarmente utile (meglio: fondamentale, inevitabile, basilare, essenziale, ...) nell'ambito della progettazione ad oggetti e nel caso di integrazioni con sistemi gestiti da altri team (con contratti chiari e fortemente tipizzati è più facile definire precisamente le responsabilità e ridurre i tempi complessivi, aumentando l'interoperabilità e riducendo le inconsistenze tra i sistemi).

Sempre la stessa voce della Wikipedia ricorda anche, però, che la tipizzazione dinamica si trova spesso nei linguaggi di scripting e nei linguaggi per il RAD (Rapid Application Development)

Per quanto riguarda i linguaggi di scripting, rimanderei alla conversazione tra Bill Venners e Guido van Rossum (il creatore d Python), veramente interessante sia da un punto di vista di progettazione software che da un punto di vista di gestione tecnica di progetto, un must sull'argomento, anche se, come me, non userete mai Python in vita vostra (a meno che non vi paghino bene, intendo...) e non sarete completamente d'accordo con Van Rossum: casomai non lo aveste già capito, personalmente sono per lo strong typing (soprattutto per progetti grossi, team giovani e laddove ci siano molte integrazioni), ma con tante scappatoie per poter lavorare in modo veloce e flessibile, tipiche di un weak o duck typing - leggermente più dinamico rispetto alla posizione espressa da alcuni esponenti di Microsoft, ma non troppo.

Per quanto concerne il RAD: qualcuno potrebbe sostenere che dire 'se volete programmare velocemente, usate dynamic typing' sia una visione errata dello sviluppo veloce, perchè si basa su una ipotesi di partenza che non considera la manutenzione, ma, sostanzialmente, si ferma alla prototipazione e/o primissimi rilasci, senza considerare che, quando cresce la complessità del sistema, è molto facile che si creino errori.
Questa considerazione è vera solo fino al punto in cui si presuppone che chi sta usando il sistema non si accorga del pericolo e non sappia cosa sta facendo. Cosa che può capitare, come già anticipato, se il progetto è grande e composto da molte risorse junior.
Certo che, se si riesce ad impostare un ragionevole modo di lavorare e un controllo appena decente, si possono ottenere tutti i vantaggi della R di RAD e ridurre a quasi nulla i possibili svantaggi.
Non è vero che i costi di controllo sono il prezzo da pagare: quelli fatti bene, con caratteristiche simili a quelli che servono in questo caso, dovrebbero esistere comunque (altrimenti i problemi non tarderanno a farsi vedere, con o senza strong typing).

Ovvero, per dirla con Bruce Eckel (che da anni, oramai, cerca di farci diventare poliglotti informatici), non abbiamo bisogno tanto di una forte tipizzazione, quanto di forti test.
Sorvolando sul fatto che, evidentemente, in Italia la parola test non è facile da tradurre e che, quindi, la frase precedente potrebbe non essere capita da tutti... ;)

La stessa dicotomia non può che porsi anche ad un livello architetturale più alto, come ben evidenziato dalla diatriba tra SOA e REST. Riporterò solo un interessante pezzo tradotto a braccio da un famoso articolo di Steve Vinoski:

Ironicamente, il fatto che SOA prescriva specifici contratti per le interfacce, di fatto insidia il suo obiettivo di separare l'interfaccia dall'implementazione, perchè interfacce specifiche tendono a rivelare più della sottostante implementazione di quanto facciano le interfacce generiche. Inoltre, interfacce specifiche - per definizione - vincolano la loro implementazione perchè modificarle spesso richiede dei cambiamenti nell'interfaccia. [...]
Stranamente, alcuni degli architetti e sviluppatori che conosco che lavorano su grandi sistemi SOA (come quelli di aziende nel campo delle telecomunicazioni e della finanza) si sono inventati per conto proprio i vincoli dell'interfaccia uniforme, senza aver mai sentito parlare del REST. Sfortunatamente l'hanno fatto nel modo più complesso, sviluppando e consegnando dapprima interfacce specifiche per un servizio e poi notando cosa si rompeva quando i loro sistemi crescevano in scala.

Direi che, per ora, mi sembra sufficiente, per farci meditare ancora sull'infinita saggezza popolare nascosta da secoli nella fiaba (della tipizzazione) del (brutto) anatroccolo...

Bye

Depa

[... continua ...] Leggi tutto

SOA (2) - Variazioni Goldberg

[...] l'opera è stata concepita come un'architettura modulare di 32 brani, disposti seguendo schemi matematici e simmetrie che le conferiscono tanta coesione e continuità da non avere eguali nella storia della musica [...]. Così la Wikipedia, riguardo alle Variazioni Goldberg di Bach.

Anche con SOA abbiamo il problema di mettere assieme una architettura modulare, i nostri brani sono i servizi, la coesione e la continuità sono fornite da schemi di processo definiti in un workflow...

Come sarebbe a dire che non sapete cosa sia SOA? A questo punto dovreste, come minimo, avete già letto il mio precedente post introduttivo e la maggior parte di voi saranno stati lì come avvoltoi aspettando che pubblicassi quello sul Web 2.0.
Come sarebbe che non ricordate? (Chi ha detto 'ho rimosso'?)

Capisco che possiate non aver sentito parlare di WOA, SOD e SOR...
Pensate che stia tirando sigle a caso? (Non potete immaginare neppure cosa vi aspetta nel dettaglio di questo post, allora - vendicherò il mio orso dell'altro mio recente articolo sul Web Semantico).

Se non le conoscete perchè leggete solo il mio blog e non vi fidate di nessun altro, certamente non posso biasimarvi...

Però ricordate che a dire bugie vi cresce il naso.
E a non studiare anche le altre fonti, pure le orecchie.

---

Riassunto delle puntate precedenti: abbiamo visto che SOA è una architettura per servizi remoti(zzabili), tipicamente resi disponibili sotto forma di Web Services, prodotti all'interno dell'azienda, ma anche da fonti su Internet.
Abbiamo dato un'occhiata all'architettura, dall'alto di un dirigibile, e abbiamo visto come, di fatto, sia un modo per ripensare il sistema aziendale basandosi su componenti (siccome non è certo una novità, gli cambiamo nome e li chiamiamo servizi), mettendoli in fila con un sistema che è un incrocio tra un motore di workflow ed un EAI (Enterprise Application Integration), chiamato Service Bus o Orchestrator, a seconda dei casi.
Abbiamo anche notato che qualcuno propone servizi già pronti da usare su Web e da essere integrati nei vostri siti e li pubblicizza sotto il nome di Web 2.0.

Abbiamo omesso, (apposta, ma ci torneremo, se non quest'anno, nel prossimo), di dire che il SOA Service Bus potrebbe non esistere, potendosi incastrare i vari servizi in una bella pipe, in cui uno dei servizi usa l'output dell'altro come suo input.

In un modo o nell'altro i servizi si mettono assieme, il risultato delle loro elaborazioni viene presentato in modo uniforme e l'applicazione che ne risulta viene chiamata mashup. A prescindere da tutti i significati e le derivazioni che troverete nel link appena riportato, non so perchè a me viene sempre da tradurlo 'pastrocchio'.

Che alla fine lo sia o meno, al solito, dipende da quanto siamo bravi e attenti nel fare il nostro lavoro, da quanto tempo abbiamo e da quanto era basso il budget o l'offerta: se le fonti sono tante, le API messe a disposizione attraverso i web services (ws, da qui in avanti, se no si fa lunga) potranno seguire differenti filosofie di progettazione, potranno essere più o meno semplici, potranno funzionare o meno, seguendo più o meno fedelmente le rispettive documentazioni (sempre che esista qualcosa cui poter ragionevolmente dare un simile nome).
L'esperienza insegna che l'integrazione di sistemi differenti è, tranne che per operazioni banali, sempre uno dei punti più critici di ogni progetto, è sempre uno dei punti in cui è facile sbagliare le stime. E' sempre bene ricordarlo, quando si progetta un bel mashup. Non tutti sono in grado di mettere assieme tanti moduli come Bach e non subire il severo giudizio della storia...

E' bene notare che, solitamente, si parla di mashup quando più ci si avvicina a servizi destinati ad una presentazione, (più Web 2.0, per intendersi), piuttosto che quando si parla di servizi aziendali in architettura SOA, con tanto di Service Bus, ma non ci stupiremo più di tanto se da qui in avanti le terminologie si mischieranno un po', dal momento che i due approcci tendono a convergere fortissimamente.
Anche per motivi legati alla consumabilità dei servizi (ovvero alla loro utilizzabilità anche da parte dei client più semplici), e in parallelo alla diffusione di interfacce grafiche più ricche su Web (si parla di RIA - Rich Internet Applications), la sigla SOA, con un facile morphing, cambia in WOA (Web Oriented Architecture).

WOA implica maggiore flessibilità e velocità di adattamento, utilizzo di tecnologie più semplici: HTTP, XML più piatto, chiamate ad URI; contrapposte alle complessità di SOAP (peraltro oggi discretamente nascoste da ottimi tool e librerie) come base dei Web Services. Hinchcliffe, nel post sopra citato, nota come l'attuale lista degli standard WS-* sia ormai quasi incomprensibile per il semplice mortale e supporta fortemente (come in quasi tutto il resto dei suoi post) queste tecnologie più alla portata di tutti(anche quando parla di SOA, tende sempre ad omettere l'orchestrator e a far convergere SOA, WOA e Web 2.0 verso lo stesso significato). Il rovescio della medaglia è che, in situazioni con molte differenti fonti di servizi provenienti, bisogna reinventarsi l'interpretazione dell'XML, scambiarsi le specifiche a più basso livello, laddove SOA ci permette di concentrarci sulle interfacce (intese nel senso della progettazione ad oggetti, non nel senso del layer di presentation) e basta.

Siccome questo è il post delle sigle, qualcuno di voi - tra quelli più forti fisicamente, s'intende o, alternativamente, oramai così malridotti che tanto peggio non può andare - si starà chiedendo perchè abbia tirato in ballo alcuni aspetti di REST senza citarlo. Lo faccio ora, così quelli che non hanno capito nulla fino a qui, si confonderanno quel bit in più e non torneranno mai più.

REST sta per REpresentational State Transfer e, in due parole e ben conscio di sminuire alquanto il tutto (ma non potete chiedermi di essere sintetico e di spiegarvi i dettagli: vi fornisco i link apposta), vuol dire che noi abbiamo i dati e, quando ce li chiedono, al posto che creare direttamente una presentazione specifica o inviare interamente dati, inviamo una rappresentazione intermedia, filtrata, dei dati stessi, in modo che il client possa decidere di costruirsi la sua rappresentazione da solo (lasciando aperta la possibilità che la nostra rappresentazione sia già presentabile senza ulteriori engine).
E' più semplice con un esempio: voi puntate ad un URL per avere un feed RSS, vi viene inviato un XML e il vostro client (browser o feed aggregator) mette assieme il tutto e ve lo presenta.
Consiglio, comunque, di seguire il link fornito, non solo perchè il suo autore, Roy T. Fielding, è stato uno dei principali autori e architetti dell'HTTP, ma anche perchè mostra una interpretazione della crescita logica delle principali architetture nel tempo. Non ci stupiremo se Fielding parla di REST come di una architettura e non come una serie di tecniche (quelle che sopra ho contrapposto a SOAP) per supportare l'architettura stessa.

Non si può dire se sia meglio SOAP o REST a priori, è la situazione specifica che decide cosa sia meglio: in un caso siamo più completi e formali, esistono delle librerie di supporto per semplificarci la vita, i protocolli sono già definiti, ci sono modi per gestire sicurezza, attachment, transazionalità ed altro, ma abbiamo la necessità di considerare i client, che dovranno essere compatibili con la nostra specifica e dovremo condividere le interfacce, secondo modalità tipiche dell'OOP, che richiedono un livello di competenza eccessivo, laddove sia sufficiente chiamare un'URL, ottenere un XML e, poniamo, filtrarlo con un semplice XSL o, addirittura, presentarlo direttamente senza rielaborarlo. Normalmente, come accennavo, più andiamo sul front-end più è facile avvicinarsi a REST, più andiamo sul back-end, più ci avviciniamo a WS-SOAP-based.
Inutile dire che, quando i servizi arrivano da Internet, laddove la sicurezza sarebbe da considerare maggiormente, è più facile trovare interazioni più semplici, più basate su REST, che quelle più formali e studiate di SOAP e la gestione di questa delicata problematica è spesso lasciata in secondo piano o trattata puntualmente e differentemente a seconda dei casi.

Ancora, tipicamente avrà più senso parlare di architetture SOA, basate su WS SOAP, laddove l'aspetto aziendale (Intranet/Extranet in senso lato, comprendendo la gestione delle attività operative dell'azienda) sia prevalente e di WOA e REST per architetture che prevedono forti interazioni con l'esterno.

Il che ci porta a fare un passettino indietro: non ci sono solo SOAP e REST, ma, nel caso di integrazioni con sistemi alla base dell'operatività, l'avevo già accennato la prima volta, dovremo accentuare le capacità di EAI dell'Orchestrator o di moduli collegati, con la possibilità di agganciare servizi forniti da un ERP, un CRM o altri sistemi esterni (in altri casi esistono tool che si installano sul sistema esterno e permettono di trasformare - per es., traducendo le API già a disposizione o mediante screen-scraping - i suoi servizi legacy in WS SOAP-based e, quindi, si riesce a far ricadere il tutto nelle casistiche più standard).

Per completare il glossario, restano SOD e SOR. Che sono quasi uno scherzo (non credo che siano termini usati veramente, ritengo siano stati inventati per uno specifico blog, unico punto sul quale li ho trovati citati - e che vi consiglio: un po' ripetitivo, ma solido) che, però, mi serve per introdurre un argomento basilare.

Mentre SOA, (sto rubando l'intera frase dal blog citato), ha a che fare con il fatto di far guidare l'IT dalla visione di business, qualcuno ha trasformato quella visione in bit e bytes e questo è il motivo per cui SOD (Service Oriented Delivery) e SOR (Service Oriented Realisation) sono veramente importanti.

Ovvero: dopo tanto parlare e disegnare macro-architetture, basate su macro-principi, arriva il momento di tirarsi su le maniche e iniziare a pensare ad organizzare il nostro progetto basato su SOA. Basterà utilizzare i task tipici di un progetto Internet/Intranet a cui siamo abituati?
Per finire questo post, mi limiterò ad accennare ad alcuni aspetti importanti di gestione:

• analisi dei processi: è fondamentale (perchè SOA è guidato, come dicevamo, dai principi di business) e deve essere antecedente, il più possibile, all'inizio degli sviluppi: meglio ridurre anche i parallelismi con la fase di analisi tecnica di dettaglio. Conoscere i processi serve, infatti, per identificare le funzionalità atomiche che compongono i processi stessi, cercare di separarle e componentizzarle al fine del riuso. Fin qui niente di diverso rispetto a quanto siamo stati tutti abituati. La differenza sta nell'intensità con cui dovrebbe essere seguito questo approccio, sta nel ricercare la possibilità di creare servizi utilizzabili anche fuori dal sequence diagram in cui li abbiamo disegnati per la prima volta. Questo perchè, altrimenti, il motore di workflow centrale e la gestione a servizi introdurrà solo layer che appesantiranno la struttura, ma i vantaggi che ci resteranno si limiteranno a poco più che una riduzione del carico su un server, perdendoci il vero motivo dell'utilizzo di questa architettura, che è la grandissima flessibilità offerta


• analisi tecnica di dettaglio: l'architettura SOA richiede una maggiore complessità e definizione, quindi sappiate che, nel prendere questa strada, dovete alzare quelle benedette stime relative a questo task. La flessibilità si paga sempre in termini di aumento dei tempi di sviluppo (è un dolore doverlo ricordare, ma sembra quasi che sia vietato considerare stime significative per le analisi tecniche, soprattutto se bisogna metterci una risorsa senior, che costa, nelle stime di progetto - il che porta, inevitabilmente, a trovarsi con il fiato corto e ad un aumento dei costi di sviluppo).


• maggior parallelismo: attenzione a questa ipotesi. E' verissimo che, in una architettura a servizi, ognuno di questi servizi, soprattutto se sono stateless, come spesso suggerito, è, potenzialmente, parallelizzabile. Bisogna, però, tener conto della necessità di integrarli e, quindi, del lavoro da prevedersi sull'orchestrator e in fase di definizione delle interfacce. Inutile ricordare che più aumenta il parallelismo, più aumenta la dimensione del team e il carico di gestione del progetto. Inutile ricordare che, anche procedendo percentualmente, l'ingegneria del software insegna che esiste un limite oltre il quale la gestione salirebbe esponenzialmente e conviene comunque mettere i task in serie, perchè i costa molto meno. Per chiudere l'elenco delle cose che è certamente inutile ricordarvi, permettetemi anche di farvi notare che l'ipotesi di poter fare servizi stateless implica centralizzare parte dell'intelligenza dell'applicazione ed un appesantimento degli sviluppi per continuo passaggio di parametri. Senza considerare che, in un disegno pulito, la gestione della sessione non dovrebbe stare negli strati più alti dell'Application Server, ma tra i servizi e recuperarla potrebbe richiedere ulteriori overhead.


• rework inatteso: se pensate di integrare servizi esposti su Internet, iniziate a mettere in conto un bel po' di contingency, perchè questi servizi possono cambiare senza preavviso. E' facile usarli, solitamente, se ci limitiamo a servizi che impattano solo sulla presentation (widget e compagnia bella), ma se doveste trovare un servizio da integrare per fare qualcosa di serio, pensateci due volte e confrontatelo bene con le stime di cosa comporterebbe rifarlo internamente, tenendo presente queste possibilità di rework


• test: saranno più complessi. Non tanto, come sento suggerire da tutte le parti, per la necessità di automatizzare i test (attività dispendiosa e utile, a mio parere, solo se prevedete di avere potenzialmente molte regressioni, altrimenti costa meno farli fare a qualche umano), quanto per la necessità di testare una ad una tutte le integrazioni con i diversi servizi, soprattutto se ce ne sono di esterni

Pensate che abbia esagerato? Che non dovevo necessariamente raccontare tutto in questo solo post?
Ma se abbiamo solo iniziato, riuscendo a malapena a condividere le basi terminologiche...

Bye

Depa

[... continua ...] Leggi tutto

Timeo Danaos et dona ferentis

Oggi non sono di buon umore, quindi cercherò di trasmettervi questa sensazione, possibilmente cercando di farvi arrabbiare.

Parole crociate. 4 orizzontale, 10 lettere. Definizione: SOA senza A.
Beh, facile: "WebDueZero" (Web 2.0).

Ovvero, là fuori c'è un sacco di gente che vuole fornirvi servizi.
Talvolta pure gratis.
E la piattaforma giusta è proprio quella che volete implementare, proprio nel linguaggio che avete sempre sostenuto.
Visto che avevate sempre avuto ragione voi, alla fine?

Perchè, nonostante la provocazione, non vi state alterando?
Non l'avete capita? (l'introduzione a SOA la potete trovate in un mio post di qualche giorno fa, se vi serve).

E perchè anche se alcuni stanno diventando viola in volto, non sto meglio?
Forse aveva ragione un mio amico: 'mal comune, gaudio zero'...

---

Torniamo a fare i bravi, almeno per un momento.

Partiamo dal primissimo principio che definisce il Web 2.0 (O'Reilly, settembre 2005 - al solito, non starò a ripetervi l'articolo originale: leggetevelo, è importante - dal link sopra trovate anche velocemente una traduzione in italiano): The Web as a Platform.

Ce l'ho solo io, questa sensazione di déjà vu? Non saltano anche a voi in mente i Network Computer?

Era un intorno ragionevolmente stretto del 1994. Il WWW stava nascendo e SUN proponeva Java al mondo. Alcune aziende si riunirono e iniziarono a sostenere che era giunta la fine dei sistemi operativi e che i computer avrebbero trovato tutto ciò che gli serviva, dopo un piccolo boot necessario per far partire browser e JVM.

A me, personalmente, sembra proprio l'evoluzione di quel concetto.
Ora, almeno, abbiamo la banda più o meno necessaria e possiamo connetterci wireless quasi da ovunque o farlo certamente nei prossimi pochi anni.
Il fatto che ora ce la si possa fare deriva dalla certezza che qualcosina già esiste, in questo senso (Google docet).
Il tutto è un po' più realistico, senza dubbio.

Ma Web 2.0 vuol dire un sacco di altre cose.
Soprattutto: cooperazione e collaborazione, condivisione di conoscenza, quello che da anni il Web sta evidenziando come suo peculiare vantaggio rispetto alle tecnologie pregresse, punti che già nel 2000 presentavo come essenziali per il Web ai miei clienti e in conferenze per le PMI (non stupisce che chi ha ideato il Web, avanzi dei dubbi sulla liceità dell'avanzamento del numero di versione alla 2.0).

Questa collaborazione e condivisione, oggi, sta dando origine a nuovi modelli di business (come, ancora? non ci è bastata la prima bolla speculativa?): si parla continuamente di Long Tail, indicando che si possono mettere in gioco quelle forze minuscole e distribuite che, singolarmente non sono in grado di pesare, ma che, se organizzate nel loro insieme, possono essere competitive contro i maggiori player di mercato.

Da cui, la nuova corsa a fornire servizi gratuiti, da parte dei maggiori player, perchè la coda cresca a loro.

Ai tempi della bolla speculativa, si regalavano account di email per contare gli utenti, moltiplicarli per un valore scelto a caso (si sosteneva che ogni utente registrato avrebbe speso, nel breve, da 1000 a 3000 dollari, se non ricordo male), e quindi, dimostrare che la dot-com valeva il corrispondente del prodotto.

Oggi, invece, molto più praticamente, si offrono servizi tecnologici perchè gli utenti possano riempirli con contenuti (pensate a questo blog, come potreste mai farne a meno..) e perchè l'insieme di tutti questi piccoli oggetti possa diventare un enorme fonte di informazioni in grado di veicolare pubblicità o altro (a proposito, facciamo solo di far crescere un po' gli accessi, perchè, allo stato attuale mi negherebbero pure la possibilità di far due euro con l'advertising, su questo blog).

Subito, non tra qualche anno.

E tutti sono contenti: io che faccio i 2 euro, perchè avrei scritto il blog anche gratuitamente e chi mi offre il servizio che ne fa diversi milioni, grazie al lavoro spontaneo di tutti (e senza contare che, magari, oltre al denaro contante, riesce pure ad aggiungere una profilazione dei comportamenti degli utenti, migliorando il database marketing).

Non fraintendetemi, non sono invidioso del fatto che altri facciano più soldi di me: io sto facendo gli affari miei, pubblicando questi post (pensavate lo facessi solo per bisogno di farmi leggere? no: lo scopo è farmi conoscere, così che potrete verificare che, nonostante il discutibile senso dell'umorismo, sono un ottimo consulente e che potrei esservi davvero d'aiuto; l'advertising non c'entra nulla: anche se dovesse mai partire su questo blog - e nutro seri dubbi - non raggiungerebbe mai una dimensione tale, una volta tolte le tasse e lo sbattimento per pagarle, da permettermi di fare una spesa al mese al supermercato).

In effetti, non solo chi pubblica questi servizi (tecnologici o di contenuto), ma un po' tutta la comunità gode dei vantaggi che ne derivano.
Già l'articolo di O'Reilly evidenziava chiaramente la nascita di importanti realtà come Wikipedia (e quanto uso ne faccio, in questi post?), Flickr, del.icio.us., sourceforge. E solo perchè non poteva citare casi più recenti e più sensazionali come YouTube o siti che si sarebbero presto svegliati da una sorta di letargo, come LinkedIn o quelli che sarebbero nati proprio dalla consapevolezza che sarebbe cresciuta una comunità che ha bisogno di servizi di questo tipo per evolvere, come Technorati.

E nascono i widget, piccoli pezzi di tecnologia e di contenuto, che potete integrare nelle vostre pagine, dal blog alla Intranet aziendale (magari in AJAX - cercando di non alzare barriere architettoniche sul Web, laddove possibile, come riportato qui e qui, per fare un esempio - come suggeriscono gli inventori del termine, nonostante io faccia fatica a capire cosa caspita c'entri Ajax in questo discorso: mi sembra come parlare della rivoluzione industriale, sottolineando la fondamentale importanza contestuale dell'invenzione del bullone - serviva per migliorare il marketing?).

Il passo che porta a proporre SOA è breve: se non volete solo dei contenuti via browser e dei widget che vivono per conto loro, ma qualcosa di più professionale ed integrato - magari agganciato anche al vostro backend aziendale preesistente - predisponete i vostri sistemi informativi per tutti i vantaggi di flessibilità e manutenibilità che sono forniti da servizi distribuiti e di indipendenza dalla piattaforma garantita dai Web Services (ah, già, stavamo per dimenticarci, se proprio volete, ci sono anche dei servizi da remoto, gratis e non...).

E comunque, non ci sono alternative: il Web, lo dico da anni, è un male oramai necessario. Quando aprite la vostra azienda, lo sapete che dovrete sostenere il costo degli uffici. Eppure i vostri uffici non sono l'azienda, che, invece, è composta dalle sue risorse. Ma le risorse devono stare dentro a dei muri, al coperto. Così il Web: evolve rapidamente e chiede soldi e continui investimenti. Dovete stargli dietro, per non perdere in competitività. Avrete forse dei vantaggi, ma, più probabilmente, manterrete almeno i muri come tutti gli altri uffici.

Sono di cattivo umore, perchè, sic notus Ulixes, temo i greci, anche quando portano i doni, ma sono incapace, al momento, di vedere il pericolo nel tirarli in cima a la sacrata rocca (e vi rimando ancora all'articolo di O'Reilly per tutti gli altri pro di cui non vi ho parlato e nessun contro).

E vivo la mia schizofrenica vita Web tra questi due contrari in forse in due parti diviso, tra le paure di Lacoonte e la stoltezza dei troiani.

Bye

Depa

P.S.: ferentis, non ferentes nell'originale: correggiamo la Wikipedia?

[... continua ...] Leggi tutto

Non ibernatemi

David Blaine, nel novembre del 2000, si fece rinchiudere vivo in un blocco di ghiaccio da 6 tonnellate in cui stette in piedi per oltre 61 ore, in bella vista a Manhattan's Times Square indossando solo un paio di pantaloni e degli stivali. Lo stunt è noto come Frozen in Time e purtroppo non ne esistono immagini gratuite, quindi ho usato una controfigura e voi dovrete andare sui diversi siti per vedervi quelle vere.
Non ripetetelo a casa, è pericoloso :)

In realtà è un'altra l'ibernazione di cui vorrei parlare, quella che da il nome, appunto, a Hibernate, ovvero la gestione della persistenza di oggetti su RDBMS, con relativi problemi di mapping tra queste due diverse tecnologie, noto anche con la sigla ORM, Object Relational Mapping.

Purtroppo non c'è stato verso di semplificare e rendere più leggero questo post: è una delle cose più pesanti che abbia mai scritto e cita altre fonti che farebbero sembrare dei fumetti i testi di Dostoevskij. Non sto scherzando, siete avvisati.

---

The Vietnam of Computer Science è un post di Ted Neward , oramai citato ovunque si parli di ORM (Object Relational Mapping) seriamente e senza voler proporre un prodotto, in cui vengono chiaramente espressi molti problemi di questa tecnica, in modo molto più colorito di quanto io possa fare (e, fatto curioso, decisamente dilungandosi di più di quanto io possa nemmeno immaginare di fare: se lo leggerete, imparerete ad apprezzare molto le mie doti di sintesi).

Credo che il titolo basti da solo ad indicare la gravità di quanto Ted pensa a proposito dell'ORM, ma vi anticipo subito che, seppur io fossi già d'accordo prima di leggerlo (pur non avendolo mai razionalizzato in modo così completo, prima), ci sono anche posizioni più favorevoli (per es. questa e quest'altra, entrambe di un professionista di grande esperienza e notevoli capacità, con cui ho avuto il piacere di lavorare nel primo progetto della mia carriera).

C'è, onestamente, la possibilità che le diverse posizioni possano derivare dalle personali modalità di crescita tecnica dei singoli: nel mio caso, avendo imparato prima ad utilizzare gli RDBMS e poi le tecnologie OO, tendo a non considerare un problema il dover trattare con il DB, anzi, parto sempre a progettarlo per primo, per mettere le fondamenta ai miei progetti (pur cercando di mantenere disaccoppiati il più possibile i due modelli).

Oggettivamente, comunque, ci sarà pure un motivo se Hibernate si è così diffuso ed ha raggiunto la sua versione 3.2.2 (ad oggi) e se la stessa SUN ha finalmente buttato i vecchi Entity Beans e ha implementato un nuovo tipo di persistenza che tratta anche i POJO, nell'ultima Java EE 5 Platform (a proposito, è mai possibile che non ci sia ancora una sigla più corta, ufficiale, da sostituire al vecchio J2EE? Se la conoscete, per favore, indicatemela).

Certo, il motivo del successo di queste soluzioni potrebbe essere l'intenzione di ridurre i costi (?), evitando di dover gestire a mano l'integrazione via JDBC o ADO ed il relativo mapping e di dover mantenere forti competenze sia su una tecnologia OO che su uno o più RDBMS.
O, ma speriamo che si tratti di casi rari ed isolati, potrebbe essere dovuto alla pigrizia del non voler gestire direttamente il DB e le sue diverse casistiche.

Non voglio rebloggare Ted Neward (peraltro, vista la lunghezza e completezza del suo articolo, sarà comunque difficile non farlo, dovessi anche mettermi a parlare di tecniche di ricamo ai tempi di Napoleone): leggetevelo da soli che vi fa bene (potete saltare la digressione sulla storia della guerra, IMHO).

Vorrei solo riassumere, in modo meno formale e più legato a recenti casistiche reali di progetto, quelli che sono i pro ed i contro, per vedere se e come si possano riuscire a conciliare.

Iniziamo col dire che un RDBMS è più dello schema dei dati in esso contenuto, ma è un engine che offre una serie di servizi (indicizzazione, query, atomicità delle transazioni, etc.) che non è, a mio avviso, pensabile poter perdere e/o dover riscrivere per adattarli al nostro Object Model.

Bisognerà, poi, dire due cose sul design pattern che sta alla base del problema incriminato, in questo caso il DAO.
Dobbiamo cercare di non lasciarci ingannare dall'impostazione dei blueprint di SUN, che vede il DAO, fin da subito, come una soluzione alla necessità di rendere persistenti gli oggetti: inteso in questo senso ricadrebbe subito nel problema ORM e non mi resterebbe che rimandarvi alle rovine di Saigon (anche se il DAO risolve un problema più esteso, disaccoppiando non solo rispetto ad un RDBMS, ma anche rispetto ad una directory LDAP, per esempio).

Il vero punto su cui concentrarsi, e che non esclude il mapping manuale o tecniche ibride, è il disaccoppiamento, appunto, tra storage e regole di business.

Il primo motivo del disaccoppiamento è quello di non far dipendere la struttura delle regole di business dalle particolarità dei singoli storage (es: differenze nella sintassi SQL, laddove non coperta dallo standard; passaggio da un tipo di storage - es: RDBMS - ad un altro - es: LDAP).
Il secondo motivo è la separazione delle competenze e delle responsabilità all'interno del team, per slegare quelle necessarie per l'object model da quelle necessarie per il DB - da qui in poi, quando parlerò di DB, si deve intendere che lo utilizzerò solo come esempio di storage.

Proviamo a tracciare i pro ed i contro di questo pattern:

PRO
- maggior semplicità e naturalezza dell'interfaccia applicativa (API)
- gli sviluppatori delle business rules non necessitano di avere competenza del DB, ma solo del linguaggio (Java o simili)
- gli internals del DB vengono incapsulati (così la struttura del DB e l'engine stesso possono variare, almeno entro certi limiti, indipendentemente dagli altri oggetti)

CONTRO
- la navigazione dei dati è preordinata (o carichi tutti i dati in un colpo solo, anche se non serviranno mai, o si deve preordinare una sequenza o una sorta di dipendenza - questi problemi sono solo parzialmente risolti da vari metodi di lazy loading)
- quindi: il carico sul DB può diventare imprevedibile, dal momento che chi usa il DAO può pensare, dato il contratto, di stare richiedendo un solo, innocuo, campo, mentre il DAO, per recuperarlo potrebbe dover attivare più query in cascata, laddove, magari, una o più delle query intermedie poteva essere inutile per lo scopo specifico
- una modifica alla struttura del DB quasi certamente implica una modifica al DAO e, non si può escludere che sia necessaria una modifica anche sul client.
- si potrebbe obiettare che queste problematiche non esistono o sono molto ridotte se si rende persistente l'intero oggetto come LOB o simili. A prescindere dal fatto che, così facendo, vi giocate la possibilità di fare query utili al vostro cliente, (che domani vi chiederà un nuovo report, incrociando i dati in un modo che su un relazionale sarebbe stato banale e sulle vostre classi e oggetti diventerà un inferno), il punto è che qualcuno, al DB, deve accedere, per esempio, per il primo caricamento dei dati nel DAO o per rendere persistente l'oggetto. Se questo qualcuno dovesse essere Hibernate, ci potremmo trovare nella spiacevole situazione di scoprire che le query che è in grado di eseguire sono solo quelle più standard e a noi servono quasi solo le altre, per questo progetto. Se chiederete aiuto ai vostri DBA, a questo punto, troverete gente che scrolla la testa e corruccia lo sguardo.
- ogni volta che aggiungete uno strato, oltre a nascondervi il reale funzionamento sottostante (nel caso di problemi, lo sapete che bisogna aprire la scatola, vero?), certamente non migliorate le performance, nonostante tutte le cache che vi possano venire in mente
- si riduce moltissimo la possibilità di sfruttare la potenza ed efficienza offerta dall'RDBMS nell'eseguire Stored Procedure
- nel caso i DAO siano usati diffusamente nell'applicazione, eventuali modifiche potrebbero non portare a regression test se l'applicazione è fatta bene, perchè è il contratto che mi garantisce che le modifiche siano invisibili, mentre è ovvio che una modifica alle interfacce potrebbe portare a molti problemi (che, però, dovrebbero essere individuati in fase di compilazione). Può essere buona norma lasciare intatte le vecchie interfacce, deprecarle ed impostarne di nuove, per i nuovi oggetti. Purtroppo, tutte queste precauzioni, spesso, si scontrano con una realtà per cui le applicazioni sono fatte bene, ma non benissimo (e quindi ci sono regression test da considerare) e per cui i metodi deprecati possono perdere così tanto significato da costringere a modificare comunque i client per referenziare i nuovi metodi.

TRADOTTO IN ALTRI TERMINI
- apparente maggior velocità di sviluppo e risorse con skill minori (ovvero, meno costose) in fase iniziale
- apparente disaccoppiamento tra DB e classi
si trasformano in:
- minor flessibilità
- maggiori costi di gestione e manutenzione

Che poi sarebbe la Law of Diminishing Returns di cui parla Ted Neward: In the case of automated Object/Relational Mapping, [...] that early successes yield a commitment to use O/R-M in places where success becomes more elusive, and over time, isn't a success at all due to the overhead of time and energy required to support it through all possible use-cases

Quali metodi ci sono per ridurre gli impatti? Sempre nell'articolo di cui sopra se ne citano 6 (!!) che mi sembrano parecchio esaustivi.
Cito solo il numero 6 (gli altri li avrete certamente già letti da soli) perchè è quello che preferisco e tendo ad usare maggiormente: Integrazione di concetti relazionali in frameworks.
Riassunto e parafrasato per riportarlo sul discorso DAO che abbiamo fatto fin qui, potrebbe suonare come: mantenete il design pattern DAO, ma appoggiandovi su strutture un po' più generiche, evitando di creare classi che rappresentino un concetto che, con quei metodi ed attributi, utilizzerete solo in quel particolare progetto.

Resta vero, peraltro, che ha (molto) senso mantenere l'utilizzo della persistenza (e di oggetti come Hibernate, di conseguenza), soprattutto laddove esistano strutture:
- gerarchiche già in partenza e quindi, con una naturale presenza di una navigazione preferenziale dei dati
- statiche o semistatiche
(che poi è come se vi stessi consigliando di considerare anche la soluzione numero 4, quella denominata Accettazione delle limitazioni dell'ORM)

Casomai non vi basti quanto finora detto e citato, vi rimando anche ad un altro articolo, molto pratico e poco teorico (al punto da evidenziare problemi che sono tipici di un solo ambiente e non dell'ORM in generale), particolarmente interessante laddove riassume i costi di un progetto basato su tali tecnologie e di cui vi suggerisco la lettura anche dei commenti.

Ci sarebbe ancora... no, per stavolta vi grazio :)

Bye

Depa

[... continua ...] Leggi tutto

SOA (1) - Introduzione

E' ora che la smettiate di credere che in questo blog si cazzeggi ed è necessario iniziare a parlare di questioni serie (capisco che l'immagine non aiuti a portarsi in questo spirito, ma fate uno sforzo).

Non sapete cosa sia SOA? Lo sapete, ma vi state ancora ponendo la domanda, basata sul vecchio e facile gioco di parole, se si tratti di SOA o di sòla? Avete riaperto l'allegato tecnico che avete scritto 6 mesi fa e avete trovato, come sostiene il vostro cliente, quella curiosa sigla che non ricordavate di averci messo?

Beh, ecco le risposte brevi:
- SOA sta per Service Oriented Architecture (se siete arrivati qui per il Sistema Olfattivo Artificiale, sono spiacente, vi devo rimandare alla Wikipedia)
- non è 'na sòla
- non posso sapere cosa scrivete sugli allegati tecnici, ma se me lo aveste chiesto prima di scriverlo, vi avrei dato una consulenza...

La risposta lunga?
La divideremo in diverse puntate, ma anche così mi vedo costretto a ricordarvi che il mio concetto di estensione potrebbe non coincidere con il vostro: proseguite a vostro rischio e pericolo (non fatelo se siete in evidente stato di gravidanza).

---

A occhio, tra titolo e abstract potrei aver già perso una dozzina dei miei 20 lettori (no, non sto parafrasando Manzoni: gli accessi da SiteMeter restituiscono quel picco in tutta la sua crudezza, al momento; spero sia rotto SiteMeter, altrimenti dovrei temere che gli oltre 20 miei amici, cui ho segnalato il blog via email e che, in una situazione normale, si sarebbero certo precipitati a leggerlo incuranti di ogni effetto collaterale, siano incorsi negli stessi problemi che hanno impedito a Jack Blues di raggiungere la sua ex all'altare).

Lo spunto per questo post nasce dalla non remota ipotesi che un cliente, come primo requisito, vi chieda che la sua nuova Intranet sia basata su SOA, senza dare significativi approfondimenti sulle funzionalità di interesse. Cosa gli rispondereste?

Come minimo dovreste rispondere che la richiesta è curiosa (se siete dei commerciali siete autorizzati a giri di parole; "nessun problema" è un giro di parole che la prende un po' troppo alla larga, nel caso specifico).
Infatti, come dice il nome, SOA è una architettura, (ovvero, un insieme di tecnologie già esistenti integrate in modo razionale), orientata a fornire e/o ricevere servizi, (ovvero funzionalità generiche, almeno per quanto ne sa l'architettura), fornite da un provider tipicamente da remoto (remoto è un termine generico: potrebbe trattarsi di funzionalità rese da voi stessi disponibili solo all'interno dell'azienda, come pure recuperate da un qualche sorgente su Internet).

Se non vi sembra una richiesta strana, proviamo con una analogia: della casa che state per comprare vi preoccupate della distribuzione delle forze sugli elementi portanti, al posto che interessarvi del numero di piani, bagni e stanze, posizionamento in centro o in periferia, illuminazione etc. etc. ? Se siete ingegneri civili, inventatevi un altro esempio, ovviamente...

Non vi consiglierò mai di non fare una costruzione solida o senza future prospettive di evoluzione, ma a partire dalla cuccia del vostro cane fino alla casa di due piani, non è sempre necessario usare il cemento armato.
Se avete soldi da spendere e vi piace la tecnologia, comunque, mandatemi i vostri riferimenti nei commenti: dopo che vi ho avvisati, non vi posso mica obbligare ad implementare la vostra Intranet in altro modo...

Nel caso la vostra costruzione sia più ardita, invece, è inutile negare che, al momento, SOA sia certamente una delle migliori risposte.

In questa prima puntata non faremo un vero e proprio approfondimento tecnico, per cui vi rimando a link molto più formali e noiosi (anche perchè non basterebbero a me 200 pagine e a voi altri 10 caffè), ma, sapendo che siete dei tipi svegli (o che li eravate prima di arrivare a questo punto), evidenzierò qualche macro-aspetto importante (se non capite qualche sigla, prendete appunti e segnalatemelo alla fine, se trovo il tempo ve la spiego):

1. per lo più i servizi di una architettura SOA sono pensati in termini di Web Services, per massimo riuso, ma l'architettura di per sè non vincola (qualcuno sostiene di sì, altri di no), quindi va bene ogni altra modalità: se insistete con EJB o con COM+ o con chiamate su socket, altre invenzioni o misturoni di tutte le precedenti, è buona lo stesso (in realtà, uno degli scopi riportati qua e là sarebbe pure quello di recuperare servizi già esistenti, anche se nati su tecnologie vecchie ed ambienti legacy)
2. il fatto che i servizi estendano solo il concetto di componenti, già esistente da tempo non dovrà stupirci, perchè abbiamo appena detto che SOA è una architettura, non una tecnologia od una metodologia. In parte ci rincuora, perchè potremo riusare competenze pregresse
3. Il punto centrale è che si tratta di una architettura che sottolinea il concetto di elaborazione distribuita e disaccoppia l'elaborazione dei servizi dalla loro composizione (deve, quindi, prevedere la possibilità di aggiungere servizi come plugin).

Questo, in realtà, è quasi sostanzialmente tutto ciò che è veramente condiviso sull'architettura SOA. Ma continuo con la lista dei macro-punti di interesse, in ordine sparso:

4. ma non ci sarà mica qualcuno che farà pagare, per l'uso di questi servizi? (oh, che sia un caso che si parli così tanto di Web 2.0, in questo stesso periodo? Ci torniamo una delle prossime volte...)
5. è ovvio che, per situazioni non banali, è necessario collegare tra loro i vari mattoni/servizi. Potrebbe essere utile, quindi, una sorta di engine centrale, simile ad un motore di workflow - chiamiamolo orchestrator, per semplicità
6. potrebbe essere interessante pensare ad un linguaggio comune - basato su XML, ovviamente, chiamiamolo BPEL, sempre per semplicità - per aiutarci a definire come questi orchestrator possano attivare i servizi.
7. avrete certamente capito che l'obiettivo è una grossa flessibilità e sarà altrettanto inutile sottolinearvi che si paga in tempi e costi di progettazione e di carico sui server (beh, ma è ovvio che è tutto distribuito... ah, c'è dell'overhead?)
8. bella idea, come mai finora i motori di workflow non sono stati al centro di ogni architettura? (ipotesi di risposte brevi, non leggetele, sono solo miei appunti personali: forse perchè nelle regole di business esistono, spesso, così forti dipendenze da far pensare che l'uso flessibile di un motore di workflow sia un po' come fare overdesign? forse perchè il workflow trova la sua principale applicazione soprattutto in ambienti collaborativi ed in processi di approvazione o investigazione, soprattutto se ancora non molto formalizzati?...)

9. ...

Per evitare di perdere anche gli ultimi due lettori rimasti (bella resistenza, ragazzi), mi fermo e vi rimando, per il momento, a link esterni, per approfondimenti, avvisandovi che scopriremo l'assassino in qualche prossimo post, secondo i seguenti passaggi (di massima):
- considerazioni tecnico-implementative
- problematiche funzionali
- interpretazioni di business
- prodotti Open Source su cui basare la nostra SOA
- ... [e che altro devo inventarmi per farvi seguire questo blog?]

Ah, già, casomai dovessi dimenticarmi di trattarli, fatemi un fischio.

Bye

Depa

[... continua ...] Leggi tutto