martedì 20 febbraio 2007

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

1 commento:

Anonimo ha detto...

Da noi è ribattezzata SOlA, perché pare adatta solo a progetti ENORMI, con molti servizi eterogenei e già implementati; dovendo pensare qualcosa di umano, soprattutto da zero, sembra più una... SOlA.