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

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