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