Linea guida: Incapsulamento dati del servizio
Tale linea guida considera l'idea dell'incapsulamento come applicata nello sviluppo orientato all'oggetto e la estende ai servizi. Descrive inoltre il modo in cui un servizio viene effettuato dallo scambio di messaggi, introducendo la metafora di servizi come 'feudi,' che può interagire direttamente solo con 'emissari' noti, che a turno, interagiscano con l'utente.
Relazioni
Descrizione principale

Introduzione

E' stata pratica comune sia nello sviluppo orientato all'oggetto che a quello basato sul componente disporre di una serie di componenti che rappresentano le entità persistenti che risiedono in un database condiviso. Infatti, è stata spesso un punto di vista di molte organizzazioni IT utilizzare uno schema di database singolo che contiene tutti gli elementi persistenti utilizzati nell'impresa. Se ciò ha avuto un successo limitato per alcune organizzazioni, per molte di esse, lo schema di impresa comune non è stato sviluppato. Vi sono molte ragioni per la non riuscita di un approccio, molte non tecniche, ma relative a più applicazioni, l'accesso, il blocco e la modifica degli stessi dati condivisi sono problemi molto difficili da risolvere attraverso i confini organizzativi.

In questa linea guida, verranno trattati due problemi molto collegati: la nozione che un servizio dovrebbe essere un incapsulamento completo dei dati che richiede e che solo la condivisione delle informazioni tra i servizi sia condotta tramite scambio di messaggi.

Tale linea guida fornisce ulteriori dettagli all'argomento relativo all'identificazione guidata dai dati.

Servizi come feudi

Uno dei termini più spesso utilizzato per la descrizione della nozione di sviluppo orientato all'oggetto è la nozione di incapsulamento, che un oggetto dovrebbe incapsulare il proprio stato (dati provati) e la propria logica di implementazione. In un mondo di servizi, la nozione di  Risorsa: Servizio (implementazione) viene separata chiaramente dalla relativa Risorsa: Specifica di servizi. Questa sezione tratterà la necessità di incapsulare lo stato. Questo concetto è stato documentato, inizialmente in [HELLAND] e più recentemente in [SESSIONS] ed è stata focalizzata l'attenzione sullo sviluppo di sistemi autonomi, pertanto sviluppabili più facilmente.

Il diagramma viene descritto nel contenuto testuale.

L'analogia utilizzata comunemente [HELLAND] è che richiedendo una nuova assicurazione si tenda ad utilizzare un agente. L'agente è responsabile del riempimento del modulo per l'applicazione e di solito accede ai dati per tipi di politica e tariffa. L'agente dell'assicurazione agisce come l'emissario per conto del feudo della compagnia di assicurazioni. Infatti la compagnia di assicurazioni potrebbe accettare le applicazioni di politica solo da un agente approvato. Il feudo è responsabile per la distribuzione della politica aggiornata, della tariffa e delle informazioni sul modulo agli agenti oltre che delle applicazioni in elaborazione. Tuttavia, anche se il feudo ha fornito le informazioni sulla politica all'agente e l'agente è stato certificato dal feudo, la prima cosa che fa una compagnia di assicurazioni è convalidare completamente l'applicazione - il feudo non considera ancora attendibile l'emissario.

Le sezioni seguenti descrivono il ruolo dei due elementi principali con più dettagli. Se questo non viene presentato come un modello concreto o come un approccio prescrittivo, i principi contenuti sono importanti nel considerare le soluzioni orientate al servizio.

Ruolo del feudo

Il feudo è un servizio autonomo; consente solo la comunicazione tramite messaggi che si presume in genere essere creati da emissari che agiscono per conto dell'utente. Il feudo è protetto, autonomo e definisce completamente un confine dei dati. Nessuna origine di dati o altri dati persistenti vengono condivisi tra feudi o tra feudi ed altri elementi del software. E' ora possibile che un database singolo sostenga più di un servizio per la persistenza, ma gli spazi diversi di tabella o i contenitori database per ciascun feudo garantiscono l'integrità, la sicurezza dei dati ecc.

Un altro aspetto chiave del modello è quello di assicurare che l'emissario sia in grado di agire come un agente ragionevole, che è in grado di interagire con l'utente con la minima comunicazione richiesta con il feudo e che il feudo distribuirà copie di determinati dati di riferimento agli emissari per l'archiviazione e l'utilizzo localmente. Così come nell'esempio di assicurazione precedente, il catalogo delle politiche disponibili, dei relativi requisiti, restrizioni e prezzi, verrà distribuito periodicamente agli agenti. Naturalmente, è importante che l'agente sia capace di utilizzare queste informazioni, ma anche di capire che queste informazioni sono una copia dei dati e non necessariamente i dati che utilizza il feudo e che le informazioni potrebbero essere scadute. Potrebbero essere aggiornate una volta al mese e se viene ricevuto l'aggiornamento, l'emissario potrebbe non essere capace di eseguire le nuove applicazioni o potrebbe eseguirle in base a dati obsoleti.

Come precedentemente menzionato, il fatto che un emissario agisca per conto di un feudo non implica alcuna relazione protetta tra le due parti. Per accertarsi che l'emissario non è stato usurpato, tutti i messaggi verranno convalidati in base alla sintassi, la semantica e la politica prima di essere accettati.

le responsabilità in dettaglio del feudo sono:

  • Gestione e distribuzione dei dati di riferimento a tutti gli emissari, identificando chiaramente le date effettive dei dati.
  • Gestione dello stato transazionale dei dati; tutte le transazioni vengono gestite interamente all'interno.
  • convalidare tutte le comunicazioni con gli emissari.

Ruolo dell'emissario

L'emissario agisce come un agente e potrebbe essere individuato come componente per l'utente, un componente basato su Internet oppure un componente specificamente distribuito, ma ha la caratteristica che gestisce i dati di riferimento richiesti per compilare i messaggi inviati elaborati dal feudo. E' anche responsabile della gestione delle copie locali dei messaggi per-transazione. Pertanto, ad esempio, gli utenti potrebbero identificarsi come aventi una politica esistente,che è possibile l'emissario ricerchi prima di pre-popolare il modulo con alcune informazioni e memorizzi nella cache questa copia della politica esistente per la durata della transazione di completamento dell'applicazione.

In generale, viene utilizzato un emissario quando la comunicazione tra il feudo e l'utente rappresenta alcune transazioni più complesse che ora l'emissario è in grado di gestire in modo più efficace, come il compilare richieste complesse nell'esempio corrente. Molte organizzazioni oggigiorno utilizzano questo modello, organizzazioni in cui il sistema di completamento dell'ordine che elabora gli ordini e li pianifica per la distribuzione è spesso lo stesso che è stato utilizzato per molti anni. Poiché queste organizzazioni hanno iniziato a vendere i prodotti in modo interattivo sul web, l'applicazione web agisce come un emissario che dispone di una copia locale del catalogo dei prodotti ed aiuta l'utente a preparare un ordine. Naturalmente non è l'applicazione web che elabora l'ordine, ma inoltra semplicemente gli ordini al sistema esistente. Poiché l'emissario completa questo ordine in base ai dati di riferimento, è ragionevole prevedere che l'ordine non verrà rifiutato perché non corretto. D'altra parte, come precedentemente detto, il sistema dell'ordine esistente convalida l'ordine prima di accettarlo.

In dettaglio le responsabilità dell'emissario sono:

  • Agire come un agente, per conto dell'utente, per completare i messaggi ed interagire con il feudo.
  • Gestire, dove appropriato, una transazione logica interrogando i dati di riferimento, popolando i messaggi ed inoltrando le informazioni per conto dell'utente.
  • Gestire una copia locale dei dati di riferimento, eseguendo gli aggiornamenti secondo i suggerimenti del feudo.
  • Gestire la memorizzazione in cache delle politiche su dati sensibili al tempo come identificato dal feudo.

Confini dei dati del servizio

In generale, molte applicazioni vengono sviluppate come insiemi integrati verticalmente di componenti (per ulteriori informazioni, consultare il concetto SOA (Service-Oriented Architecture)). Ciò conduce ad applicazioni con pochi punti naturali di integrazione. L'approccio più comune per l'integrazione, principalmente perché sembra molto facile, è quello di far condividere a due applicazioni o più in archivio dati comune. Pertanto, dove i servizi di inventario e ordinamento condividono la nozione di "Prodotto," accedono alle stesse tabelle nel database. Ciò porta ad alcuni problemi potenziali di simultaneità e di prestazioni e ad interrelazioni che ora uniscono queste applicazioni che influiscono sulla loro evoluzione singola e sull'abilità del business di riospitare, risviluppare o semplicemente modificare una delle applicazioni.

Il diagramma viene descritto nel contenuto testuale.

Per lo sviluppo di soluzioni orientate al servizio, si consiglia che un servizio gestisca un modello di dati specifico, limitato e coerente. Così, l'analisi dell'utilizzo delle due applicazioni precedenti identificare l'utilizzo dei dati da questi ultimi ed il modo in cui possono essere separati per essere gestiti da due servizi autonomi. Ciò non significa che non vi siano interconnessioni tra i modelli di dati poiché sono separati. Ad esempio, sia per il servizio di inventario che per quello di ordinamento sarà necessaria una definizione comune dei prodotti e delle ubicazioni in cui viene memorizzato l'inventario ed in cui sono originati gli ordini.

Gli approcci sono: di creare un terzo servizio per il concetto condiviso (qui, potrebbe essere pertinente un servizio di catalogo dei prodotti) o gestire il concetto in uno dei due servizi. Ad esempio, l'ubicazione potrebbe essere logicamente gestita dal servizio di inventario. Ora, sarà necessario che i messaggi inviati a e da uno di questi servizi contenga l'identificativo per gli elementi condivisi in modo che sia possibile inviare una query o recuperarli se necessario. Ad esempio, nel caso dell'inventario, una query per i prodotti attualmente gestiti da una posizione restituirebbe un elenco di identificativi dei prodotti (e si presume le quantità in magazzino); se vengono richiesti i dettagli relativi ai prodotti, verranno recuperati dal servizio di catalogo del prodotto.

Ovviamente un prodotto di lavoro chiave nell'analisi dei confini dei dati è il Modello dei dati. E' necessario creare modelli dei dati per il database esistente e separare attentamente nel modello di dati fisico o preferibilmente nel modello dei dati logico.

Messaggi del servizio come viste dati

Se tutti i dati vengono memorizzati solo all'interno del servizio e l'accesso viene negato a tutti al di fuori del servizio, tutte le comunicazioni devono avvenire tramite messaggi identificati nella specifica di servizio. Tuttavia, è sempre importante notare che questi messaggi, poiché rappresentano una query e un ritorno di dati dal database all'utente, sono specificamente copie di dati mantenute dal servizio. Pertanto, potrebbero rappresentare realmente uno stato non aggiornato del servizio. Ad esempio, inoltrando una query per la quantità in magazzino del prodotto "234," viene restituito un messaggio che identifica che alla posizione "562" vi è una quantità di "12." L'operazione non riuscirà, se un altro utente prende otto elementi dalla scorta e l'utente originale tenta di acquistare 12 elementi.

Si tratta, in effetti, di problemi di gestione delle transazioni di progettazione e tradizionali; la gestione dell'ambito e dei confini delle transazioni viene resa leggermente più complessa o almeno più visibile per la natura debolmente unita dei servizi e degli utenti dei servizi. Pertanto, è necessario considerare i messaggi non solo  come viste dei dati, ma anche come copie di dati. Sono state redatte diverse guide anche in SOA per riferire come i messaggi possano identificare la propria durata e applicabilità.

Un altro effetto di questa trasformazione nell'approccio basato sulla messaggistica inerente alle soluzioni orientate al servizio è che è possibile adesso focalizzare nuovamente l'idea di un modello di dati comune per le applicazioni in un modello di messaggio comune per l'integrazione. Cioè, laddove possibile, i messaggi definiti per le specifiche di servizio sono basati su strutture comuni, possibilmente separate in uno schema coesivo che è possibile riutilizzare attraverso i servizi. Questo è un approccio di gran lunga più flessibile all'integrazione poiché corrisponde all'approccio di accoppiamento libero degli stessi servizi. Inoltre, la maggior parte delle tecnologie utilizzate nell'implementazione del servizio includono le tecnologie, i tool o i runtime che forniscono le capacità di trasformazione del messaggio in cui lo schema del messaggio non corrisponde esattamente.

Per ulteriori informazioni, specificamente sul leasing e sulla memorizzazione in cache dei messaggi, consultare il concetto Attività: Progettazione del messaggio.

Riferimenti

[HELLAND] Fiefdoms and Emissaries, Pat Helland, Microsoft.

[SESSIONS] Software Fortresses: Modeling Enterprise Architectures, Roger Sessions, Addison Wesley, 2003.