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.
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.
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.
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.
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.
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.
[HELLAND] Fiefdoms and Emissaries, Pat Helland, Microsoft.
[SESSIONS] Software Fortresses: Modeling Enterprise Architectures, Roger Sessions, Addison Wesley, 2003.
|