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.
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.
Per ulteriori informazioni consultare la guida al tool Creazione di un modello del servizio in RSA.
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.Nome | Tecnologia | Input | Output | Commenti |
---|---|---|---|---|
sp_get_custlist_by_phone | Procedura SQL Server Stored | phonenum (char 10) | Elenco di:
custid (id) |
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 |
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.
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.
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.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.
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.
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.
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.
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.
Per ulteriori informazioni consultare la linea guida Dai servizi ai componenti del servizio.