C’è una “C” nella parola Soa

In questo spazio (Techne – Con parole mie) i protagonisti della tecnologia raccontano e si raccontano, portando alla luce la miscela virtuosa di tecnica ed esperienza al servizio delle esigenze dell’utenza. Parlano sulla base della conoscenza, evitando di fare riferimento alla propria produzione, bensì portando il discorso su un piano generale e fruibile da tutti.

Quando si progettano architetture orientate ai servizi e i relativi servizi, è importante tenere sempre presente chi “consumerà” tali servizi. I consumatori, infatti, devono conformarsi alle interfacce di ogni servizio usato, invocandolo solo e sempre con i dati esatti e nel formato atteso. Questo implica che, più simili sono i servizi tra loro, più limitato sarà lo sforzo di codifica e “traduzione” che i consumatori dovranno fare.

Utilizzare tecniche di trasformazione unite ad un “semantic data modeling” (anche detto Common Data Model o modello dati concettuale) può facilitare questa attività, sia in fase di progettazione e testing iniziale, che in fase di modifiche in run time.

Le specifiche di interfaccia, i protocolli e i formati-dati utilizzati nelle Soa devono essere definiti per consentire la creazione di servizi “loosely coupled” tra chi fornisce e chi consuma il servizio. Il servizio di fatto deve fornire all’utente un’astrazione che rappresenta una determinata funzione di business così che non si debba preoccupare dei dettagli di implementazione o di come e dove i relativi dati sono archiviati. L’unica cosa che il consumatore deve sapere è come richiamare un servizio utilizzando standard quali Wsdl, Soap, Http e altri.

Una volta implementati servizi “elementari”, è possibile comporre funzioni di business di più alto livello, le cosiddette “applicazioni composite”, invocando tali servizi e orchestrando le reciproche interazioni. È evidente che, quanto prima si possono definire i servizi in linea con questi principi, tanto più agile sarà la relativa architettura “service oriented”; nella pratica si riscontra invece il tentativo di “riadattare” servizi ed applicazioni esistenti, modificando ad hoc un’architettura tradizionale Eai con il rischio di aumentarne ulteriormente la rigidità e i costi di gestione.

Le difficoltà

Esporre un nuovo servizio da un’applicazione esistente non è sempre facile, in quanto questo potrebbe non essere coerente con le interfacce esistenti che spesso sono limitate sia dalle funzionalità dell’applicazione che dal modo in cui i dati possono essere recuperati. A questo proposito far interagire diversi servizi può quindi essere complesso (anche usando protocolli e formati standard per la definizione delle interfacce) in quanto i protocolli e i formati prevedono normalmente la verifica della sintassi dei dati e non del loro significato semantico: ogni applicazione o servizio probabilmente utilizza nomi diversi per cose simili e viceversa. Tali contrasti sono comuni e non si limitano alle architetture orientate ai servizi. Ecco di seguito alcuni esempi.

La maggior parte delle persone dispone di una rubrica sul computer e un’altra sul cellulare, e ha un software che le sincronizza. Sfortunatamente l’inserimento di un nuovo record nei due strumenti è diverso, con variazioni nei nomi e nel numero dei campi. Il software di sincronizzazione sa come mappare i diversi nomi ma non è in grado di associare il contenuto esatto di ogni campo in quanto non ne esegue un’analisi semantica. E’ quindi necessaria una fase di allineamento manuale per rendere i dati sincronizzati coerenti con i campi di ciascuna rubrica.

Molte aziende offrono accesso a un sistema di Crm esterno per i venditori e utilizzano un Erp interno per l’elaborazione degli ordini. Questi due sistemi contengono informazioni diverse sui clienti quindi utilizzare l’interfaccia Web del Crm per ottenere informazioni sul cliente e correlarle con i dati del sistema Erp può non essere così immediato. Come nel caso della rubrica, i formati-dati sono diversi, così come il loro utilizzo e il loro contenuto. Uno tiene traccia dei clienti e delle loro interazioni con i commerciali, l’altro registra ciò che è stato acquistato, quando e a che prezzo. La rappresentazione dei dati della stessa entità “cliente” può quindi essere diversa tra le 2 applicazioni.
Riconciliare o mediare le differenze nei modelli dati e nelle interfacce dei servizi per applicazioni come queste non è sempre semplice.

La definizione del servizio deve quindi partire dal consumatore, raccogliendone le esigenze e le necessità operative e l’architetto deve poi soddisfare questi requisiti all’interno dei vincoli di interfaccia e di funzionalità applicative. In molti casi, invece, chi progetta l’architettura, decide anche quali sono i servizi e questo crea continui cambiamenti in fase di implementazione quando i requisiti di performance e le aspettative del business non sono rispettati. Aggiungendo poi che non sempre tutti i servizi sono “in casa” (ma provengono da partner esterni o divisioni aziendali o consociate estere, ecc), il quadro generale diventa particolarmente complesso.

Le singole trasformazioni possono aiutare

Per uniformare le differenze tra i formati-dati è possibile introdurre all’interno dell’architettura uno strato di mediazione e trasformazione. Quando un servizio viene invocato, questo layer si fa carico della mediazione dei formati-dato, esegue le dovute conversioni e trasformazioni e fornisce al client i dati nel formato atteso.

È possibile sviluppare gli operatori di trasformazione utilizzando XQuery, Xslt o anche funzionalità Java codificate a mano per tradurre il layout e la semantica da un formato dati all’altro. Se si usa un enterprise service bus (Esb) come backbone per un’affidabile comunicazione e gestione dei servizi, è possibile mettere i servizi di trasformazione sul bus. L’Esb può invocare le trasformazioni in maniera automatica a seconda delle necessità.
Quando si crea singole trasformazioni “punto a punto”, il risultato è un set di trasformazioni che legano i servizi “a spaghetti” (A con B, B con C, A con C, etc.): ogni trasformazione svolge un compito specifico, isolato dagli altri. Ora tutto dovrebbe funzionare correttamente.

Ma anche se la trasformazione è necessaria per l’integrazione dei servizi, da sola non è sufficiente. Pur se si utilizzano strumenti efficaci quali DataDirect Stylus Studio o Altova XmlSpy per la loro creazione, disporre di molte trasformazioni “punto a punto” può complicare la situazione.

Primo: si eintroduce il “tight coupling” che le Soa dovrebbero eliminare e, invece di essere agile, la Soa diventa rigida e difficile da modificare.

Secondo: abbiamo passato oltre 50 anni a inventare nuove software e i loro modelli dati con la conseguenza che possono talvolta esserci seri problemi di interoperabilità perché incompatibili.

Terzo: è probabile che operazioni simili vengano ripetute più volte nelle trasformazioni, forse con variazioni non intenzionali, specialmente se vengono create da persone diverse.

Quarto: mantenere centinaia o migliaia di trasformazioni è un impegno significativo e garantirne correttezza, coerenza e aggiornamento è quasi impossibile.

Quinto: le trasformazioni “punto a punto” implicano la conoscenza della semantica dei dati in ogni punto e cioè in tutti i contesti dove questi sono utilizzati; tale conoscenza non è facile da trovare né da mantenere quando i servizi evolvono nel tempo.
Le trasformazioni, quindi, aiutano, ma non sono sufficienti.

Il “Common Data Model” come ancora di salvataggio

Abbiamo evidenziato come avere trasformazioni dati “punto a punto” specifiche per ogni servizio crea vincoli oggettivi e irrigidisce l’architettura con operazioni che impattano pesantemente sulle prestazioni e sull’utilizzo hardware; al contrario se le mappe di ogni servizio vengono riportate all’interno di un modello dati concettuale comune (Common Data Model) è possibile disaccoppiare le trasformazioni dal servizio rendendole il più possibile generiche e “leggere”. Questa procedura riduce notevolmente la quantità di lavoro da fare in quanto, invece di definire trasformazioni per coppie di servizi, si definisce solo la mappatura dei dati per ogni servizio. A questo punto, le necessarie trasformazioni vengono eseguite confrontando le mappatture dei servizi con il modello dati concettuale.

È bene notare che non è necessario trasformare effettivamente da e verso il modello concettuale (proprio in quanto concettuale). Con lo strumento giusto per definire ed estendere il modello dati concettuale e archiviare le relative mappature dei servizi, questo approccio risolve diversi dei problemi accennati in precedenza.

A mano a mano che il modello concettuale viene definito ed esteso, è possibile utilizzare nomi chiari e comprensibili per tutti gli elementi dati indipendentemente da quanto criptici siano nelle interfacce dei servizi. Quando lo stesso elemento dato viene utilizzato in servizi diversi, il tool di modellazione può mostrarli tutti consentendo di visualizzare dove lo stesso elemento viene utilizzato anche se con nomi diversi.

Validazione dei dati

Gli attuali standard di interfaccia dei servizi non hanno le capacità per definire in modo semplice regole o vincoli da applicare ai dati. Per esempio: nel settore della grande distribuzione, un cliente al dettaglio potrebbe non essere abilitato all’utilizzo di ordini d’acquisto, mentre un cliente all’ingrosso con caratteristiche specifiche sì; la validazione di un ordine deve avvenire solo se tutti i campi sono inseriti correttamente; una destinazione di spedizione non può essere assegnata a un ordine fino a che l’indirizzo di recapito non è stato inserito ed è completo di ogni dettaglio; due indirizzi (attuale e futuro) sono necessari in un ordine di trasloco per riallocare il servizio di connessione Adsl.

Un servizio deve sempre validare i dati in input, ma, in sistemi “loosely coupled”, è spesso necessario effettuare la validazione anche dei dati in uscita verso sistemi client, in particolare in quei sistemi che interagiscono con utenti che desiderano un feedback veloce a seguito di un inserimento, per esempio, prima che un ordine venga inviato.
Il “Common Data Model” può essere utilizzato proprio per “filtrare” tali “regole” in modo che possano essere applicate dove necessario in maniera uniforme. Quando la logica di validazione viene generata da queste regole si è anche sicuri che queste sono sempre corrette.

Calcoli

Spesso un dato usato in un servizio può avere un formato diverso rispetto a un altro e i valori possono essere espressi in unità diverse (pollici, millimetri, Fahrenheit, Celsius, libbre, chilogrammi, ecc). Un servizio può definire un valore con tre numeri decimali e un altro come numero intero. Il valore decimale va arrotondato in fase di conversione?

Gli strumenti per la modellazione concettuale dei dati devono essere in grado di definire tali conversioni così come calcoli specifici per le diverse applicazioni di modo che possano essere definite una volta e ripetute ove necessario. Questo facilita la modifica delle conversioni e migliora l’affidabilità generale del sistema.

Esistono modelli dati standard che sono stati definiti per specifici settori quali l’assicurativo (Acord), la sanità (HL7) e le telecomunicazioni (Sid). Tali modelli sono particolarmente articolati e possono contenere oltre 1.000 classi. L’utilizzo di questi modelli, riducendo i tempi di analisi, garantisce la conformità con gli standard di mercato.

Per utilizzare questi standard, è necessario aggiungerli al modello dati concettuale, ma poiché sono spesso ampi e articolati, lo strumento di modellazione deve avere la possibilità di importarli consentendo di aggiungere “strati” al modello generale senza quindi modificarlo (modificare il modello standard comporterebbe di fatto la creazione di un modello proprietario). Tali strati consentono di gestire dati propri non presenti nel modello standard e devono quindi essere integrabili con le mappature generali.

Il Metadata Repository

I metadati (mappature, regole di trasformazione, conversioni di formati-dati, regole di validazione ecc) e gli “artifact” devono essere archiviati in un luogo dove possono essere utilizzati facilmente. Questo è il ruolo del repository di metadati: non semplice “contenitore” ma strumento attivo per la gestione di tutto quanto serve alle trasformazioni.

Quando si utilizza strumenti di modellazione cosiddetti “repository-based”, oltre a una più facile implementazione, anche i costi di manutenzione vengono ridotti. Si possono ottenere i seguenti vantaggi: analisi di impatto automatica, a mano a mano che si progettano modifiche alla Soa, questi strumenti possono fornire report circa le interdipendenze tra servizi e utenti e l’impatto dei cambiamenti proposti; maggiore riutilizzo dei componenti, quando tutte le definizioni dati, trasformazioni, regole di validazione, formati di conversione, così come il codice generato sono archiviati nel repository, è possibile trovare e riutilizzare quanto già sviluppato; correttezza, utilizzando gli elementi definiti nel repository, si incrementa la correttezza, la coerenza e l’affidabilità del sistema e delle applicazioni; tutto ciò, unito all’analisi di impatto, consente di propagare le modifiche architetturali in maniera più controllata.

Conclusione

Le architetture Soa, promettendo una maggiore agilità e una maggiore sinergia tra It e Operation, devono essere approcciate tenendo in stretto legame chi espone e chi consuma i servizi. L’efficienza di questo legame bidirezionale non è però solo basata su problematiche di integrazione applicativa, ma anche su come i dati sono organizzati, gestiti, interpretati e quindi trasformati. Costruire una architettura Soa non può quindi prescindere dall’adozione di un “Common Data Model” e dall’utilizzo di strumenti di modellizzazione e analisi semantica dei dati. Tali strumenti, mediando il significato semantico dei dati di ogni applicazione software, evitano il proliferare di trasformazioni “punto a punto” consentendo al contrario la creazione di servizi di trasformazione generici che quindi risultano riutilizzabili, facilmente controllabili e molto performanti.

(*)Vice President Technology Progress Software