SOA: Riuso e granularità dei servizi SOA

Un approccio pragmaticodi e

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.

Figura 1 - Lo stack SOA

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

Condividi

Pubblicato nel numero
116 marzo 2007
Marco Piraccini è nato a Cesena il 09/10/1975. E‘ laureato in Ingegneria Informatica presso la facoltà di Bologna con una tesi sull‘assessment della maturità del processo di testing e in Fisica Computazionale presso la facoltà di Udine con una tesi sull‘uso di GRID per le simulazioni Monte Carlo (nell‘ambito di…
Stefano Rossini è nato a Giussano (MI) il 29/10/1970 e ha conseguito il diploma universitario in Ingegneria Informatica presso il Politecnico di Torino. Ha maturato più di venti anni di esperienza in diversi progetti Enterprise mission-critical ricoprendo i ruoli di IT Program Manager, Project Manager & Software Architect presso importanti…
Ti potrebbe interessare anche