Canonical data model: design e legame con SOA

Il canonical data model (in seguito CDM) è un meta-modello su cui i diversi team si sono accordati, magari avendolo scelto tra gli standard capaci di rappresentare il dominio dati dell’azienda (un esempio di questi standard è il SID, meta-modello per le aziende di telecomunicazioni, creato dal TeleManagement Forum).

Un CDM è, almeno in parte, astratto, capace di rappresentare il dettaglio di diverse realtà aziendali che condividono il medesimo dominio di business. Al fine di trarne un modello (un’istanza), la “lingua franca” con cui esprimere il particolare dominio aziendale, è necessario partire dallo studio del meta-modello, continuare con la scelta della porzione da usare e terminare con le eventuali estensioni.

Al modello si fa corrispondere ciò che i sistemi dell’azienda espongono (data source) o consumano (data service). Meta-dati collegati mantengono tali corrispondenze ed altro, ma non i dati. Così facendo si è individuato un “vocabolario”, compreso da tutti ed usato per chiarire la semantica dei dati esposti o consumati, che permette di ignorare i dettagli delle strutture di cui altri sistemi, altri team, hanno competenza.

Non è auspicato, in generale, che si espongano (o consumino) strutture dati strettamente derivate dal modello individuato, è necessario, però, che tutti lo abbiano ben compreso e sappiano farvi corrispondere le proprie. E’ preferibile che tali strutture non siano disegnate come perfettamente aderenti al modello perché si avrebbe un notevole accoppiamento, complicando le eventuali modifiche: un cambiamento al modello, probabilmente, si ripercuoterebbe sulle strutture e viceversa. Il forte accoppiamento, inoltre, renderebbe necessaria la modifica delle strutture dati già in essere, creando diffidenza ed ostruzionismo all’adozione del modello; oltretutto si rivelerebbe pressoché impossibile da attuare in presenza di software non sviluppato in casa.

Oltre a chiarire la semantica e conseguire l’indipendenza tra le strutture dati, il modello derivante dal CDM semplifica le integrazioni punto-punto: ogni struttura, infatti, è fatta corrispondere al solo modello e non a tutte le altre.

La presenza di meta-dati in grado di mantenere, oltre alle corrispondenze, informazioni circa vincoli, calcoli, espressioni, cambiamenti di formato, ecc. assicura qualità sui dati ritornati e permette trasformazioni più complesse.

Un engine evoluto, qualora vi siano i presupposti (ad es. chiavi coincidenti o deducibili), permette l’integrazione, real-time, di dati provenienti da più sorgenti, aumentando il valore di ciò che è già presente in azienda. Queste integrazioni diventano fruibili mediante la creazione di nuovi data service (nuove strutture consumabili). L’esposizione di tali strutture, specie se fatto con interfacce standard, risolve il problema dell’integrazione dati con una soluzione molto elegante. Per le motivazioni già espresse, il disegno di tali strutture dovrà essere flessibile e non necessariamente derivato dal modello sottostante, cercando un compromesso tra cosa serve nell’immediato e ciò che servirà in futuro.

L’esposizione di data service è fortemente legata al concetto di orientamento ai servizi di SOA (Service Oriented Architecture). Tali strutture, infatti, svolgono il compito di esposizione dati, disaccoppiano dall’implementazione e sono condivisibili in più contesti (se disegnate attentamente). L’utilizzo del CDM (in una SOA), quindi, implica due livelli di disaccoppiamento: tra l’interfaccia del data service, la sua implementazione e chi la invoca.

SOA presuppone che i servizi, in generale, e quindi anche i data service, siano raggiungibili con interfacce standard (web service, ad esempio, ma non esclusivamente). Una governance adeguata è indispensabile al fine di limitare la proliferazione, la duplicazione e le progettazioni mirate solo a risolvere la contingenza del particolare ristretto contesto.

Il legame tra CDM e SOA si concretizza anche nel concetto di Canonical message, di cui parlerò prossimamente.

—-><—-

Post di altri autori sullo stesso argomento:

• SOA and EDA: how to mediate semantics in an EDA
• Inside Architecture: Canonical Model, Canonical Schema and Event Driven SOA
• InfoWorker Solutions: SOA Canonical “Data” Model
• Real World SOA: Why SOA Governance Needs to do a Better Job with Data
• Real World SOA: Using a Common Data Model with SOA

—-><—-

Hai trovato questo post interessante? Sottoscrivi il feed completo e partecipa alla discussione