Esempio: esempio di modello SOA

Descrizione del problema Inizio pagina

In questo esempio verranno trattati i problemi di un rivenditore che ha scelto di implementare nuovamente determinate funzioni utilizzate dalle applicazioni nei terminali POS (Point-of-Sale) come servizi. Oggigiorno l'applicazione commerciale viene sviluppata come un'applicazione monolitica con componenti uniti molto strettamente ma con alcuni componenti che risiedono sugli ISS(In-Store Servers) ed alcune richieste vengono sempre inoltrate dall'ISS ai server ubicati in una posizione centrale nell'impresa. Il problema è che l'infrastruttura del negozio in generale e l'applicazione commerciale in modo più specifico possono essere difficili da mantenere a causa della stretta unione tra i componenti e dell'utilizzo di protocolli e della tecnologia proprietari nello sviluppo e nelle connessioni tra i componenti.

Nelle precedenti generazioni di sistemi di negozi venivano utilizzate macchine proprietarie e a bassa capacità per i terminali POS ed esistevano restrizioni sulla banda larga all'interno ed all'esterno dei negozi - queste restrizioni oggigiorno non sono più valide. Tenendo presente quanto detto e lo spostamento esistente verso l'architettura orientata al servizio all'interno dei sistemi backend dell'impresa, si è deciso che alcune delle capacità fornite dall'ISS e dai server centrali saranno esposte all'applicazione commerciale come servizi.

Ambito ed obiettivi del progetto Inizio pagina

Inizialmente le capacità da considerare sono state scelte per la condivisione di un pattern comune poiché attualmente richiedono una logica nell'applicazione commerciale per inviare una query a più di un'origine di dati per le informazioni. Così, i servizi proposti non solo forniscono un'interfaccia comune ma escludono anche l'applicazione commerciale dalla conoscenza esplicita della posizione dei dati e dal dover trattare con più protocolli. A questi servizi si accederà sul RMI dall'applicazione commerciale al servizio ISS ed utilizzando SOAP su JMS dall'ISS al servizio centrale.

Identificazione del servizio Inizio pagina

Di seguito verranno descritti i passi intrapresi dal team di architettura formato da membri dell'organizzazione IT propria dei rivenditori e consulenti esterni come esperti nello sviluppo delle soluzioni orientate al servizio. Si noti che i passi seguenti non sono intesi a rappresentare una serie raccomandata di attività RUP, ma catalogano semplicemente le attività di un progetto reale.

E' importante notare che questo progetto serve a migliorare l'implementazione tecnica delle funzioni attualmente esistenti e quindi non include una grande quantità di tempo utilizzato nella modellazione o nell'analisi del business poiché è possibile riutilizzare i modelli creati per l'applicazione commerciale originale. L'insieme corrente di modelli (alla sinistra del diagramma in basso) segue la struttura mostrata di seguito, mostrando un modello di casi d'uso RUP, un modello di analisi per i componenti comuni dell'applicazione commerciale seguito dal modello di progettazione dettagliato ed infine un insieme di modelli di implementazione per i team di sviluppo Java.

Il diagramma è descritto nel contenuto testuale.

Il modello del servizio è stato introdotto (alla destra del diagramma in basso) come perfezionamento del modello di analisi in un insieme di servizi con i propri modelli di implementazione. E' ora possibile modificare la progettazione dell'applicazione commerciale per mostrare l'utilizzo di questi servizi comuni e la relazione tra l'applicazione commerciale ed i modelli Java del servizio.

Creazione del modello del servizio

Il modello del servizio di supporto del negozio è stato creato secondo il profilo UML per i servizi software ed un modello di maschera (incluso in RAS), come precedentemente descritto. Il modello è stato identificato come un perfezionamento del modello di analisi, come mostrato precedentemente. Come è possibile vedere la struttura viene presentata in un diagramma di sintesi che mostra le dipendenze tra le viste raccomandate dalla maschera.

Il diagramma viene descritto nel contenuto testuale.

Il diagramma si collega accanto ai pacchetti di viste consentiti per la navigazione rapida e verrà completato nelle sezioni seguenti.

Per ulteriori informazioni consultare la guida al tool Creazione di un modello del servizio in RSA.

Identificazione delle partizioni del servizio (zona)

Si deduce chiaramente dalla descrizione precedente del problema che esistono alcuni modi possibili per guardare al partizionamento del sistema, ad esempio si potrebbe introdurre le partizioni che rappresentano la gestione dell'inventario, la gestione del servizio/garanzia, le operazioni POS (point-of-sale) (ricerca del prezzo, dell'utente.) tuttavia queste non sono questioni principali per l'architetto e così le partizioni aggiunte al modello rappresentano le zone logiche per i servizi forniti all'interno del negozio i a livello di impresa.

Il diagramma viene descritto nel contenuto testuale.

Quando si dice che queste sono partizioni logiche si identifica che la partizione dei servizi del negozio contiene un insieme di servizi di cui viene eseguita un'istanza a livello di negozio, nulla da dire sulla distribuzione fisica di questi servizi (server singolo, cluster, ecc.). Queste partizioni logiche vengono fornite per gli architetti per rappresentare gli aspetti significativi della soluzione.

Si noti inoltre che nella figura precedente l'architetto ha introdotto un elemento supplementare, la stessa applicazione commerciale, per consentire le descrizioni delle comunicazioni tra l'applicazione ed i servizi. L'applicazione commerciale è un componente UML 2.0 con l'Utente del servizio stereotipo.

Per ulteriori informazioni consultare il concetto Partizionamento della soluzione.

Analisi delle funzioni esistenti

Il passo successivo è quello di analizzare l'implementazione corrente dell'applicazione commerciale, per visualizzare i dettagli dell'accesso al database identificati nell'istruzione del problema precedente. E' stata quindi sviluppata la tabella seguente (si noti che contiene solo i dettagli per le ricerche dell'utente e dell'inventario).
 
Nome Tecnologia Input Output Commenti
sp_get_custlist_by_phone Procedura SQL Server Stored phonenum (char 10) Elenco di:
custid (id)
custname (char 40)
Questa procedura memorizzata restituisce un elenco di dettagli sugli utenti per numero di telefono, l'elenco potrebbe essere presentato all'utente per la selezione. La chiamata sp_get_cust_details viene utilizzata per restituire un record utente singolo.
sp_get_cust_details Procedura SQL Server Stored custid (id) Record utente i dettagli di un utente vengono restituiti, il nome, l'indirizzo le informazioni sul contatto, e così via.
CUST_QUERY IBM MQSeries phonenum (char 10)
return-queue-name (char 120)
id-correlazione (char 120)
N/A In questa coda l'applicazione pone i dettagli dell'utente da interrogare, il messaggio viene spedito al centro dove il server invia un messaggio di risposta alla coda di restituzione identificata.
<return-queue-name> IBM MQSeries N/A id-correlazione (char 120)
Elenco dei record dell'utente
Quando si restituiscono i record dell'utente il messaggio di restituzione contiene anche l'ID di correlazione per garantire che la risposta possa essere associata ad una richiesta data. Ciò consente al server interno del negozio di avere una coda di restituzione singola per tutti i terminali, il terminale esegue una query per un messaggio di risposta con il relativo ID di correlazione.
sp_get_invstate_for_sku Procedura SQL Server Stored sku (char 13) Record dell'inventario
INVENTORY_QUERY IBM MQSeries sku (char 13)
return-queue-name (char 120)
id-correlazione (char 120)
N/A
<return-queue-name> IBM MQSeries N/A Record dell'inventario

Come è possibile vedere queste voci rappresentano l'implementazione esistente, che verrà sostituita con una nuova implementazione, tuttavia lo scopo e la funzione verranno mantenuti.

Sviluppo iniziale della specifica di servizio

L'attività Identificazione del servizio introduce alcune tecniche per l'identificazione dei servizi e le operazioni sui servizi, richieste per supportare una soluzione. Nel caso di questo esempio si osservi un modello di servizio precedente, la trasformazione della funzionalità esistente in un modello del servizio ed in modo specifico in una tecnologia di implementazione del servizio. In questa trasformazione l'aspetto principale è quello di sviluppare l'insieme di Specifiche di servizio che forniranno i contratti per i servizi che implementano le funzioni su descritte. Il diagramma seguente mostra le tre specifiche di servizio attualmente vuote, create in questa fase, una per ogni servizio discusso nell'introduzione.

Il diagramma viene descritto nel contenuto testuale.

Successivamente si analizzeranno i pattern di utilizzo possibili per i servizi, ad esempio è possibile disporre realmente di due servizi, uno interno al negozio ed uno d'impresa, dove la logica per l'accesso al database e l'accesso all'impresa sono entrambe incapsulate nel servizio interno al negozio. In alternativa, si potrebbe scegliere di disporre di un servizio di facciata nel negozio che incapsuli la logica e chiami due servizi simili, uno che incapsuli l'accesso al database locale ed il secondo all'impresa. La seconda scelta aggiunge flessibilità nella modifica della logica che accede ai due negozi, tuttavia aggiunge inoltre costi di overhead e di comunicazione per una funzione relativamente semplice. Così, per la ricerca dell'utente e dell'inventario è stata scelta la prima opzione. Finora i dettagli della distribuzione dei servizi e dei provider non sono stati decisi, l'identificazione del servizio è ancora valida se focalizzata sulle specifiche di servizio.

Per identificare i ruoli e le responsabilità di questi servizi si utilizza una Collaborazione del servizio e specialmente un diagramma di una struttura composta UML 2.0 che rappresenta la configurazione dei servizi per la ricerca dell'utente. Il diagramma della struttura è mostrato in basso ed è possibile visualizzare la parti UML 2.0 che rappresentano ciascun elemento della collaborazione. Si noti che i connettori tra l'applicazione commerciale e il servizio interno al negozio e tra il servizio interno al negozio ed il servizio d i impresa sono stereotipati come Canale del servizio ed indicano i binding da utilizzare (RMI o JMS come precedentemente identificato). Il binding per il connettore tra il servizio interno al negozio ed il componente del database locale (in un secondo momento) non è definito.

Il diagramma viene descritto nel contenuto testuale.

Un elemento chiave da indicare qui è che LocalCustomerLookupProvider è un servizio generato, è un servizio wrapper sottile intorno ad una query database, esiste una singola operazione che rappresenta una selezione SQL. Questo approccio è stato scelto durante l'accesso diretto al database per mezzo del servizio di ricerca utente interno al negozio per consentire al servizio locale di includere regole del business aggiuntive o per diventare un servizio più completo in un secondo momento.

Tuttavia, questo diagramma mostra solo la struttura della collaborazione, il diagramma di interazione seguente (diagramma di sequenza UML 2.0) rappresenta le comunicazioni reali tra i servizi. Si noti che è stata aggiunta l'operazione getCustomerByPhone alla specifica di servizio. Si noti inoltre che UML 2.0 consente la specifica di un "frammento" facoltativo di un diagramma di sequenza,indicando in questo caso che si comunica solo con il servizio dell'impresa se la ricerca locale non riesce.

Il diagramma viene descritto nel contenuto testuale.

La combinazione di diagrammi di struttura statica di comunicazione consente di documentare la composizione e la collaborazione del servizio e di avere identificato in questo caso solo la necessità di un'operazione singola sulla specifica di servizio.

Per ulteriori informazioni consultare l'attività Identificazione del servizio.

Progettazione del servizio Inizio pagina

Prendendo il modello dall'attività di identificazione del servizio si trasferisce l'identificazione di un insieme di servizi candidati nella progettazione dettagliata dei servizi che si intende creare. Il primo passo è di progettare le specifiche di servizio che realizzano le specifiche precedenti; come è possibile immaginare vi sono decisioni da prendere sul modo in cui i servizi realizzano le specifiche di servizio dal modello precedente. In questo esempio c'è una struttura ragionevolmente semplice, ma che sarà probabilmente comune a molti progetti. In questo caso c'è un Provider del servizio singolo che presenta un servizio singolo che è la realizzazione di una specifica singola. E' certamente possibile che vi sia più di un servizio per provider. Sono state notate inoltre alcune relazioni di utilizzo tra i servizi in questo modello, tali dipendenze sono importanti per comprendere il modo in cui è possibile che i servizi evolvano nel tempo.

Il diagramma viene descritto nel contenuto testuale.

Questa struttura consente di spostarsi di più nello spazio di distribuzione, mentre il modello è ancora una vista logica dei servizi, poiché i provider del servizio rappresentano le unità di distribuzione per il modello del servizio. I provider del servizio sono richiesti anche per la definizione dei servizi composti poiché uno stesso servizio (una porta UML 2.0) non è in grado di possedere la struttura richiesta per descrivere la composizione.

Progettazione del messaggio

Non è stato detto nulla in precedenza, nell'attività di identificazione del servizio, circa i messaggi reali scambiati tra le operazioni descritte sulle specifiche di servizio. Questo può essere un approccio comune, per catturare le responsabilità dei servizi in termini di operazioni che differiscono la progettazione dettagliata dei messaggi fino ad un secondo momento - in alcuni casi questo approccio è inverso, dove le strutture del messaggio sono note prima del tempo e quindi aggregate ad un insieme di operazioni.

In questo caso è possibile utilizzare un modello di dominio sviluppato come parte del modello di analisi del componente (risorsa sviluppata precedentemente) e così il modello del messaggio non viene creato dal nulla ma identifica un sottoinsieme di modello di dominio da riutilizzare. L'esempio in basso mostra questa relazione, le classi di dominio sono completamente ignare della tecnologia e della piattaforma, d'altra parte si presume che i messaggi siano oggetti di trasferimento dei dati, strutture passate tra i servizi. Così piuttosto che modificare il modello del dominio, verranno creati i messaggi al di "fuori" della struttura della classe, composta da elementi all'interno.

Il diagramma viene descritto nel contenuto testuale.

Per ulteriori informazioni consultare il concetto Progettazione del messaggio.

Realizzazione del servizio Inizio pagina

In questo caso l'attenzione verrà focalizzata sulla realizzazione del servizio di ricerca dell'utente interno al negozio; questo servizio è tipico nella trasformazione dal modello del servizio al modello di progettazione. La stessa trasformazione viene documentata in una linea guida e risulta nella struttura del modello seguente.

Il diagramma viene descritto nel contenuto testuale.

Mentre questo è ancora un modello di progettazione è possibile, utilizzando i tool, trasformare questo modello ulteriormente nell'implementazione EJB mostrata in basso. Fondamentalmente questa implementazione viene trasformata dalla classe CustomerByPhone precedente e i messaggi che descrivono in dettaglio l'utente vengono trasformati nel bean entità utilizzato per inviare una query al database.

Il diagramma viene descritto nel contenuto testuale.

Per ulteriori informazioni consultare la linea guida Dai servizi ai componenti del servizio.