Architettura centrata sui dati

Nell'architettura data center, i dati sono centralizzati e accedono frequentemente da altri componenti, che modificano i dati. Lo scopo principale di questo stile è raggiungere l'integralità dei dati. L'architettura data-center è composta da diversi componenti che comunicano attraverso archivi di dati condivisi. I componenti accedono a una struttura dati condivisa e sono relativamente indipendenti, in quanto interagiscono solo attraverso l'archivio dati.

L'esempio più noto dell'architettura data-centered è un'architettura di database, in cui lo schema di database comune viene creato con il protocollo di definizione dei dati, ad esempio un insieme di tabelle correlate con campi e tipi di dati in un RDBMS.

Un altro esempio di architetture centrate sui dati è l'architettura web che ha uno schema di dati comune (cioè la meta-struttura del Web) e segue il modello di dati ipermediali ei processi comunicano attraverso l'uso di servizi di dati basati sul web condivisi.

Tipi di componenti

Esistono due tipi di componenti:

  • UN central datastruttura o archivio dati o archivio dati, che è responsabile della fornitura di archiviazione permanente dei dati. Rappresenta lo stato attuale.

  • UN data accessor o una raccolta di componenti indipendenti che operano sull'archivio dati centrale, eseguono calcoli e potrebbero restituire i risultati.

Le interazioni o la comunicazione tra gli utenti che accedono ai dati avvengono solo attraverso l'archivio dati. I dati sono l'unico mezzo di comunicazione tra i clienti. Il flusso di controllo differenzia l'architettura in due categorie:

  • Stile di architettura del repository
  • Stile di architettura della lavagna

Stile di architettura del repository

In Stile architettura repository, l'archivio dati è passivo e sono attivi i client (componenti software o agenti) dell'archivio dati, che controllano il flusso logico. I componenti partecipanti controllano l'archivio dati per eventuali modifiche.

  • Il client invia una richiesta al sistema per eseguire azioni (es. Inserire dati).

  • I processi di calcolo sono indipendenti e attivati ​​dalle richieste in arrivo.

  • Se i tipi di transazioni in un flusso di input di transazioni attivano la selezione dei processi da eseguire, allora si tratta di un database tradizionale o di un'architettura di repository o di un repository passivo.

  • Questo approccio è ampiamente utilizzato nel DBMS, nel sistema informativo della biblioteca, nel repository dell'interfaccia in CORBA, nei compilatori e negli ambienti CASE (computer aided software engineering).

Vantaggi

  • Fornisce funzionalità di integrità dei dati, backup e ripristino.

  • Fornisce scalabilità e riusabilità degli agenti poiché non hanno una comunicazione diretta tra loro.

  • Riduce il sovraccarico dei dati temporanei tra i componenti software.

Svantaggi

  • È più vulnerabile ai guasti ed è possibile la replica o la duplicazione dei dati.

  • Elevata dipendenza tra la struttura dati dell'archivio dati e i suoi agenti.

  • I cambiamenti nella struttura dei dati influenzano fortemente i client.

  • L'evoluzione dei dati è difficile e costosa.

  • Costo dello spostamento dei dati sulla rete per i dati distribuiti.

Stile di architettura della lavagna

In Blackboard Architecture Style, l'archivio dati è attivo ei suoi client sono passivi. Pertanto il flusso logico è determinato dallo stato corrente dei dati nell'archivio dati. Ha una componente lavagna, che funge da archivio centrale di dati, e una rappresentazione interna è costruita e su cui agisce diversi elementi computazionali.

  • Nella lavagna sono memorizzati alcuni componenti che agiscono indipendentemente sulla struttura dati comune.

  • In questo stile, i componenti interagiscono solo attraverso la lavagna. L'archivio dati avvisa i client ogni volta che viene apportata una modifica all'archivio dati.

  • Lo stato corrente della soluzione viene memorizzato nella lavagna e l'elaborazione viene attivata dallo stato della lavagna.

  • Il sistema invia notifiche note come trigger e dati ai client quando si verificano modifiche nei dati.

  • Questo approccio si trova in alcune applicazioni AI e applicazioni complesse, come il riconoscimento vocale, il riconoscimento delle immagini, il sistema di sicurezza e i sistemi di gestione delle risorse aziendali ecc.

  • Se lo stato corrente della struttura dati centrale è il fattore scatenante principale della selezione dei processi da eseguire, il repository può essere una lavagna e questa origine dati condivisa è un agente attivo.

  • Una delle principali differenze con i sistemi di database tradizionali è che l'invocazione di elementi computazionali in un'architettura di lavagna è attivata dallo stato corrente della lavagna e non da input esterni.

Parti del modello di lavagna

Il modello di lavagna viene solitamente presentato con tre parti principali:

Knowledge Sources (KS)

Fonti di conoscenza, note anche come Listeners o Subscriberssono unità distinte e indipendenti. Risolvono parti di un problema e aggregano risultati parziali. L'interazione tra le fonti di conoscenza avviene unicamente attraverso la lavagna.

Blackboard Data Structure

I dati sullo stato di risoluzione dei problemi sono organizzati in una gerarchia dipendente dall'applicazione. Le fonti di conoscenza apportano modifiche alla lavagna che portano in modo incrementale a una soluzione al problema.

Control

Il controllo gestisce le attività e controlla lo stato del lavoro.

Vantaggi

  • Fornisce scalabilità che consente di aggiungere o aggiornare facilmente la fonte della conoscenza.

  • Fornisce la concorrenza che consente a tutte le fonti di conoscenza di funzionare in parallelo poiché sono indipendenti l'una dall'altra.

  • Supporta la sperimentazione per ipotesi.

  • Supporta la riusabilità degli agenti dell'origine della conoscenza.

Svantaggi

  • Il cambiamento di struttura della lavagna può avere un impatto significativo su tutti i suoi agenti poiché esiste una stretta dipendenza tra lavagna e fonte di conoscenza.

  • Può essere difficile decidere quando terminare il ragionamento poiché è prevista solo una soluzione approssimativa.

  • Problemi nella sincronizzazione di più agenti.

  • Le principali sfide nella progettazione e nel test del sistema.