Valutiamo pragmaticamente alcuni aspetti relativi al riuso e alla granularità dei servizi.
SOA, in quanto collezione di idee e best practices per un‘architettura basata sul concetto di servizio, ci consente di disegnare servizi seguendo regole che ne garantiscano riuso e ne facilitino l‘integrazione.
Introduzione
SOA è una collezione di idee e best practices che definiscono uno stile architetturale basato sul concetto di servizio, e specifica una modalità di costruzione delle applicazioni come composizione di servizi disegnati seguendo regole che ne garantiscano riuso e ne facilitino l‘integrazione.
I servizi devono avere preferibilmente un‘interfaccia a “grana grossa” (coarse-grained), essere componibili, ovvero orchestrabili in processi di business ampi che rompano le tradizionali pile applicative verticali (silos) e devono essere business-driven, cioè avere un significato per gli esperti funzionali: questo implica che i servizi devono essere definiti assieme agli esperti funzionali e di dominio.
Riuso e granularità: un approccio pragmatico
Alcuni dei concetti importanti di SOA sono quindi “servizi riusabili” e di “grana grossa”.
Il termine “riuso” non è assolutamente nuovo nà© tantomeno innovativo.
In passato, infatti, sono stati presentati spesso modelli di sviluppo incentrati su componenti con l‘obiettivo del riuso. La finalità di queste tecnologie è stata il tentativo di creare un mercato di componenti per favorirne la diffusione. Questo tipo di politica è in parte fallita soprattutto perchè i modelli di programmazione proposti hanno portato alla definizione di componenti la cui possibilità di utilizzo era limitata a un certo ambito tecnologico. Dal punto di vista della logica funzionale che questi moduli dovrebbero implementare per essere commerciabili, questa deve essere sufficentemente complessa per giustificarne l‘acquisto: spesso si è verificato che, rispetto a prendere un componente prodotto esternamente, capirne l‘interfaccia e adattarlo ai propri scopi e ai propri processi, è preferibile svilupparsi il componente da zero.
Affinchà© termini come “riuso” e “coarse-grained” non vengano visti come magici, utopistici o altro, è importante capirne bene il significato e soprattutto la loro applicabilità .
Inoltre, mentre oggi è chiaro che la necessità di sistemi informativi complessi è quella di avere componenti in grado di comunicare tra loro in maniera eterogenea e disaccoppiata, le tecnologie orientate al “mercato dei componenti” hanno spesso dato più importanza alla possibilità di riconfigurare i moduli sviluppati per essere utilizzati su applicazioni diverse piuttosto che a sottolineare le possibilità di integrazione.
La letteratura ad oggi è piuttosto avara di informazioni al riguardo.
Molto interessante è l‘articolo Jason Bloomberg di zapThink dal titolo “Should All Services Be Reusable?” [JBZT] e molto importanti sono le considerazioni di Ronald Schmelzer in “Solving the service granularity challenge” [SSGC].
Poniamoci quindi come prima domanda: tutti i servizi devono essere riusabili?
In prima battuta si potrebbe rispondere di sì: visto che uno degli obiettivi di SOA è la costruzione di servizi riusabili, perché non dovrebbero esserlo? Ma nella realtà la risposta non è nà© così immediata nà© tantomeno così scontata.
Innanzitutto la risposta alla domanda è correlata all‘approccio che si utilizza per la definizione dei servizi: Top-Down o Bottom-Up.
Definizione dei servizi: approccio Top-Down e Bottom-Up
Partire dai processi di business significa seguire un approccio Top-Down.
In questo caso si parte dall‘analisi del processo per poi identificare i servizi con un processo suddiviso in due fasi: la prima di analisi, che deve definire un elenco di servizi “candidati” e la fase di design che deve delineare in maniera netta e precisa i servizi e le relazioni di essi con i processi e i componenti attraverso raffinamenti successivi.
L‘altro approccio è quello Bottom-Up dove l”estrazione” dei servizi avviene a partire da software già esistente; cioè si parte dalla situazione già presente e si aggiunge il grado di astrazione necessario (i concetti di SOA) all‘integrazione dei processi che si stanno sviluppando.
Dovendo sviluppare un‘applicazione da zero, l‘approccio più corretto è quello Top-Down. L‘approccio Top-Down parte con il disegno di tutti i processi di business all‘interno di una organizzazione e li decompone fino a identificare aree di ridondanza che identificano i candidati a diventare servizi.
poiché questo approccio si focalizza sulla riduzione delle ridondanze (incrementando il riuso), la questione chiave che gli architetti dovrebbero porsi è se la massimizzazione del riuso è sempre la pratica più importante, oppure se ci sono altre priorità da considerare.
Quindi il riuso non è l‘unico driver architetturale di cui occorre tenere conto mentre si progettano i servizi. Altrettanto importanti sono ad esempio la rapidità (agility) e il parametro cost-effective relativamente al cambiamento e alla manutenzione/evoluzione delle applicazioni.
Con “agility” (o “evolvability”) si intende la caratteristica di un sistema di essere reattivo ai cambiamenti. Nel caso di sviluppo Top-Down i cambiamenti tipici che si affrontano sono i cambiamenti di requisiti.
Ad esempio, se si sta disegnando un servizio utilizzato da una sola applicazione ma con dei requisiti potenzialmente soggetti a forti cambiamenti o addirittura in fase di definizione, può essere meno costoso disegnare un servizio ad hoc per questa applicazione, come ad esempio il servizio 2 utilizzato ad hoc dalla sola applicazione App. E (figura 2).
Un altro esempio in cui il riuso non è al primo posto nei pensieri dell‘architetto è quando il valore dell‘accoppiamento debole è molto importante come ad esempio per le interazioni Business-To-Business (B2B).
In questo caso il valore del disaccoppiamento è implicitamente più alto del valore del riuso. Questo può portare quindi a preferire addirittura servizi disegnati per lo specifico collegamento punto-punto rispetto a una soluzione più “elegante” ma dal grado di complessità tecnico ed economico maggiore, come ad esempio il servizio 3 utilizzato ad hoc dalla sola applicazione App. F (figura 2).
Figura 2 – Tipologie di utilizzo dei Servizi SOA
Visto che è innegabile che l‘Integrazione è una attività difficile e costosa, è importante sforzarsi nel concepire applicazioni perché siano integrabili ed evolvibili; cioè affrontare tali problematiche già nella fase di inception dell‘applicazione. Questo non elimininerà completamente la difficoltà di integrazione, però consentirà di risolvere una serie di problemi nella fase di sviluppo dell‘applicazione (quando cioè toccare il codice costa meno).
Questo concetto molto importante deve essere tenuto in grande considerazioni soprattutto in un approccio Top-Down dove la sua fattibilità è oggettivamente maggiore rispetto all‘approccio Bottom-Up.
Dovendo operare invece su applicazioni già esistenti e che si vogliono conservare per svariate ragioni (p.e.: salvaguardare investimenti pregressi, applicazioni obsolete ma ormai consolidate, budget, …) è consigliabile l‘approccio Bottom-Up.
Seguendo questo procedimento è importante capire quanto dell‘esistente può essere promosso a servizio e con che granularità . Un punto di partenza per definire i candidati ai servizi partendo da una situazione esistente può essere l‘identificazione degli scenari d‘uso più frequenti. Si identifica quindi il codice che in effetti viene maggiormente utilizzato (cioè per la maggior parte del tempo!).
Partendo da una situazione esistente, generalmente complessa, è tutt‘altro che banale identificare i candidati a essere promossi a servizi. Il procedimento sarà impegnativo e soprattutto dovrà essere iterativo.
Una regola iniziale che può essere utile, almeno per “rompere il ghiaccio” allo startup dei lavori, è quella cosiddetta “dell‘80/20”: il 20% delle funzionalità esistenti viene utilizzato per l‘80%; il rimanente 80% delle funzionalità gestisce casi speciali, eccezioni o scenari utilizzati poco frequentemente.
È quindi utile iniziare a concentrarsi in prima battuta ad identificate il 20% del software esistente che indicativamente andrà a comporre il core del Service Layer.
In altre parole: le funzionalità meno utilizzate sono potenzialmente meno riusabili e quindi devono avere una bassa priorità nel processo di Service enablement in chiave riuso.
Figura 3 – La regola dell‘80/20
SOMA (Service-Oriented Modeling and Architecture) è una metodologia che aiuta ad applicare l‘approccio Meet-in-the-Middle atraverso le fasi di
Identification (si individuano i possibili candidati a diventare servizi)
Specification (si decide quali dei servizi candidati precedentemente individuati esportare come servizi veri e propri e per ognuno di essi si specifica quali sono i componenti enterprise che lo compongono)
Realization (si prendono le decisioni operative per la realizzazione dei servizi)
Di fatto si applica un‘approccio iterativo Top-Down / Bottom-Up che, per raffinamenti successivi, migliora il disegno dei servizi: tale approccio può essere identificato come “Meet in the Middle”.
Figura 4 – Le tre fasi principali di SOMA
Progettare con la giusta granularità
Vediamo ora un esempio per chiarire meglio quanto descritto precedentemente.
Supponiamo di avere due servizi che sono composti a loro volta rispettivamente dai servizi A, B, C, D ed E, B, C, F.
Figura 5 – Schema dei servizi dell‘esempio proposto
Si vede come in entrambi i casi, siano utilizzati i servizi B e C.
Prendendo in considerazione un esempio triviale ma didattico potremmo pensare di avere due processi, uno di registrazione utente e uno di gestione di un ordine d‘acquisto.
Supponiamo che entrambi necessitino di controllare la validità sia della e-mail che della carta di credito.
Figura 6 – Esempio proposto
Questo suggerisce di portare a fattore comune i servizi B, C in un nuovo servizio di grana più grossa: il servizio 3.
Figura 7 – Il nuovo Servizio 3
In questo modo la composizione dei servizi 1 e 2 diventa come mostrato in figura 8.
Figura 8 – La nuova composizione dei servizi 1 e 2
Applicando questo concetto all‘esempio pratico vuole dire che al posto di due singoli servizi di controllo email e di controllo carta di credito ne avremo uno solo.
Figura 9 – il nuovo scenario dell‘esempio proposto
Dopo questa fase di refactoring proviamo a chiederci: il Servizio 3 è più o meno riusabile dei singoli servizi B, C e D?
È evidente che il servizio 3 sarà in generale meno riusabile dei singoli servizi che ha aggregato.
È altrettanto vero però, che il servizio 3 è a grana più grossa. Sicuramente esprime funzionalità di business più chiaramente identificabili e quindi ha un maggiore valore. Inoltre, poichè il servizio 3 è composto da (A + B), di fatto i servizi elementari A e B sono ancora disponibili e usabili nel sistema.
Nel caso specifico si è quindi definito un servizio a grana più grossa e con un valore di business maggiore: questo può essere più importante dell‘effettiva possibilità di riuso.
Figura 10 – Riuso e Composizione dei Servizi 1, 2 e 3
Conclusione
In questo articolo abbiamo parlato di un argomento molto importante, complesso e delicato: il corretto design dei servizi SOA.
Servizi di grana troppo grossa posso essere poco riusabili, mentre servizi di grana troppo piccola possono condure al “too-small service nightmare” [DAB].
Abbiamo cercato quindi di fornire delle indicazioni basilari ma più pratiche e pragmatiche possibili.
Applicando correttamente i principi architetturali SOA lo sviluppo di Service-Oriented Business Applications (SOBA), cioè Applicazioni di Business basata su SOA, è realmente possibile.
È importante capire comunque che un‘architettura SOA deve essere un‘architettura dinamica in continua evoluzione, in cui è difficile (e in realtà , non necessario) definire una “ricetta che vada bene per tutte le situazioni”; questo vale anche per la granularità dei servizi, che può essere corretta in un dato momento ma che può essere modificata in seguito (ad esempio, introducendo nuovi processi, possono essere rilevate nuove aree di ridondanza).
Riferimenti
[MOKA_SOA] M. Piraccini – S. Rossini, serie “SOA: dalla teoria alla pratica”, MokaByte 100, 101, 102, 103, 104, 105, 106, 107, 108, 109
[JBZT] Jason Bloomberg, “Should All Services Be Reusable?”, Document ID: ZAPFLASH-2006531 | Document Type: ZapFlash
http://www.zapthink.com/report.html?id=ZAPFLASH-2006531
[SSGC] Ronald Schmelzer, “Solving the service granularity challenge”
http://searchwebservices.techtarget.com/tip/1,289483,sid26_gci1172330,00.html
[DAB] http://darkav.blogspot.com
[SOBA] http://en.wikipedia.org/wiki/Service-oriented_business_application