Capitolo 6
Preliminary Infrastructure Prototype
Instantiation/Location/Orchestration
(PIP_ILO)
In questo capitolo mostreremo come il sottosistema Service Locator è inserito all’interno della versione preliminare del prototipo PIP_ILO (Preliminary
Infrastructure Prototype Instantiation/Location/Orchestration) che rappresenta il
core dell’infrastruttura GRASP e riguarda, oltre al Service Locator, anche il Service Instantiator ed il Service Orchestrator. Il PIP_ILO è stato realizzato dai partner del consorzio GRASP assemblando i tre sottosistemi (Instantiator, Locator, Orchestrator) realizzati e testati nella prima fase di realizzazione del progetto.
Nel Capitolo daremo una visione generale dei concetti utilizzati dai partner del consorzio per la realizzazione del PIP_ILO. Tale prototipo deve rispettare dei requisiti funzionali e non, che garantiscono un suo corretto comportamento in determinate situazioni che possono verificarsi nell’ambiente GRASP. Inoltre
presenteremo un’architettura del PIP_ILO che raffigura l’integrazione dei tre sottosistemi (Instantiator, Locator, Orchestrator), e mostreremo anche come essi cooperano per soddisfare l’invocazione di una delle operazioni fornite dal prototipo. Infine, illustreremo i test effettuati dai partner del consorzio GRASP per verificare la congruenza della realizzazione del prototipo con i requisiti (funzionali) preposti. Tali test vogliono verificare come ogni singolo sottosistema si integra nel prototipo e quanto la loro cooperazione sia funzionale per il raggiungimento degli obiettivi del progetto GRASP.
6.1 Descrizione PIP_ILO
L’obiettivo di PIP_ILO e di dare una dimostrazione degli aspetti tecnici e commerciali presenti all’interno del progetto GRASP. Gli aspetti tecnici sono:
• Permettere la creazione dinamica di istanze di servizi (Service
Instantiation).
• Permettere il discovery di locazioni logiche di servizi con specifiche caratteristiche (Service Locator).
• Permettere la combinazione di servizi esistenti per creare un nuovo servizio (Service Orchestrator).
Data la presenza di domini ASP nell’ambiente GRASP, il progetto mette in evidenza gli aspetti commerciali riguardanti l’utilizzo di una Griglia computazionale. A tal proposito sono state definite tre principali strategie atte a sfruttare l’infrastruttura di Griglia. I tre modelli puntano ad incrementare il profitto degli utenti sia riducendo i costi, sia incrementando il volume commerciale. Nella Tabella 6.1 sottostante sono mostrati i tre modelli insieme con le opportunità e le procedure che ciascun modello offre.
Grid User Ridurre i costi Acquistare i servizi e la potenza di calcolo necessari a soddisfare la domanda e ridurre i costi fissi riducendo l’infrastruttura
Grid Enabler Offrire servizi che abitualmente non potrebbero essere offerti oppure si trovano in commercio, ma con prezzi troppo alti.
Creare servizi nuovi o migliori che in precedenza non si era in grado di fornire.
Cercare servizi di Griglia appropriati.
“Orchestrare” i servizi di Griglia esistenti e fornire nuovi servizi.
Grid Service Provider Agire come un fornitore delle componenti per gli utenti del servizio di Griglia. Creare servizi di Griglia che raggruppino servizi base di domini indipendenti e parti di processi business altamente specializzati.
Sviluppare servizi di Griglia e renderli accessibili attraverso interfacce di griglia comuni.
Il PIP_ILO descrive uno scenario dove un provider ASP (Application Service Provision) segue il modello Grid Enabler per offrire un servizio allestito appositamente per l’utente che lo richiede. Lo ASP può essere visto come un centro di spesa che vende i suoi servizi in accordo ad una distribuzione interna dei prezzi.
Il testbed per il PIP_ILO è collocato nel dominio biomedico. In seguito daremo una breve descrizione di tale dominio per permettere una maggiore comprensione del contesto applicativo.
Il nostro scenario è collocato nel sistema sanitario spagnolo. In tale sistema ci sono alcuni centri sanitari (CAP) che sono interessati a fondare un’associazione
di imprese che permetterebbe loro di acquistare i farmaci scontati. Il fatto che differenti laboratori (LAB) offrono sconti diversi in base alla quantità degli ordini
ed al tipo di farmaco ci porta a dover risolvere un problema di ottimizzazione generale. Il massimo sconto che i Lab possono effettuare dipende dalla Tabella 6.1: Modelli di utilizzo della Griglia
combinazione dei differenti ordini emessi dai vari CAP in un unico ordine. L’elaborazione di una tale informazione è fatta da una scuola ufficiale per dottori (COMB) che agisce come un Application Service Provider (ASP).
Riassumendo, abbiamo le seguenti entità:
• CAP: sono dei centri sanitari che ordinano dei farmaci dai laboratori e tentano di ridurne i costi cercando di ottenere il maggior sconto possibile.
• LAB: offrono differenti sconti sui prodotti che vendono. Tali sconti dipendono dalla quantità di un ordine di vendita.
• COMB: è una singola entità che agisce come un ASP, che collega gli ordini e calcola il massimo sconto per l’ordine composto.
• Di solito, COMB inizia a calcolare lo sconto (questa fase è chiamata
processo di previsione) per conto di un utente. Sebbene tale utente
potrebbe essere un membro legittimato di un CAP, come ad esempio un analista finanziario, agisce come un cliente ASP (ASPCLIENT). Il valore aggiunto offerto dallo ASP è l’ottimizzazione degli ordini. Tale ottimizzazione è un processo iterativo che comprende un ripetuto scambio di informazioni tra COMB e i vari CAP. Per far questo è richiesto l’uso di un controller del workflow dei servizi. Dato che il sistema è un ibrido basato su Grid e Web Service, non possiamo usare direttamente un “workflow engine” per Web Service o contare su meccanismi che provengono da domini di Griglia. Perciò è necessario adattare un macchina preposta per la fase di “orchestration” (orchestration engine) a controllare un workflow consistente di Web Service e Grid Service.
Di seguito riassumiamo i passi essenziali del processo di previsione:
1. Un ASPCLIENT legittimato chiede al COMB la previsione dello sconto su un ordine di acquisto.
2. COMB inizializza un workflow che è definito all’interno di un “orchestration engine”.
3. Dovendo rispettare le regole del workflow, lo orchestration engine inizializza e attiva l’esecuzione di un Grid Service per ogni CAP che partecipa all’ordine di acquisto. Inoltre, inizializza e attiva l’esecuzione di un altro Grid Service che è a conoscenza dei dati comuni a tutti i prodotti offerti dai LAB. Tale Grid Service è chiamato
NOMENCLATOR ed è importante per la valutazione dei risultati
intermedi.
4. Il Nomenclator invia dei suggerimenti ai CAP riguardanti gli ordini ottimizzati. I CAP stessi eseguono dei calcoli ulteriori sulle opzioni proposte e forniscono un feedback al Nomenclator. Sulla base dei feedback di tutti i partecipanti (CAP), il Nomenclator continua il processo di ottimizzazione ed invia i risultati ai CAP finché non si ottiene un’ottimizzazione dell’ordine accettata da tutti.
In Figura 6.1 è mostrato quanto sopra esposto.
BUSINESS PROCESS CAP1 CAP2 NOMEN CLATOR COMB
6.2 Requisiti
Il progetto GRASP punta a fornire un’infrastruttura che dia alle compagnie, quali ASP, l’opportunità di sfruttare i vantaggi delle tecnologie di una Griglia
Computazionale (o Grid). Ovviamente, questo comprende l’implementazione di un’infrastruttura che soddisfa alcuni semplici requisiti funzionali e non funzionali. Tali requisiti sono riferiti per lo più a funzioni e caratteristiche tecniche di un’infrastruttura.
Comunque, il successo della tecnologia Grid in un contesto commerciale dipende anche dai requisiti ASP, quali integrazione dei costi, valore aggiunto in relazione ad altre tecnologie, ecc.
Nella Tabella 6.2 sottostante sono illustrati i requisiti funzionali che il prototipo PIP_ILO deve soddisfare. Nella tabella è presente una colonna “ ” in cui sono esposti i requisiti che il PIP_ILO deve soddisfare indipendentemente dal test che viene effettuato. Nella colonna a fianco, invece, sono esposti i requisiti che il PIP_ILO deve soddisfare nel contesto del testbed biomedico.
Requisiti Funzionali
Inst_R1 Istanziare dei servizi di Griglia su macchine hosting senza verificare l’esistenza di tale ambiente hosting.
La orchestration engine che sta lavorando per conto di un COMB, deve istanziare i servizi (Nomenclator, CAP_1, CAP_2) necessari per
elaborare un calcolo. Inst_R2 Indirizzare l’invocazione di un
servizio dal gateway allo specifico servizio in esecuzione
Lo Orchestrator deve essere in grado di stabilire una
interazione tra il Nomenclator ed i servizi CAP.
Loc_R1 Cercare il Locator per
differenti tipi di servizi Lo Orchestrator deve localizzare lo Instantiator per istanziare i servizi di Griglia. Deve essere in grado di cercare i servizi CAP e Nomenclator.
Loc_R2 Controllare i diritti di un
service requestor Il Locator controlla che COMB abbia i diritti per cercare, pubblicare, cancellare un servizio.
Loc_R3 Restituire una lista di servizi
informazioni per invocarli servizi Loc_R4 Pubblicare nuovi servizi nel
sistema Locator (LS) PIP_ILO deve fornire uno strumento per pubblicare i servizi manualmente Loc_R5 Registrare i servizi in maniera
da permettere la
classificazione in categorie
Il Locator deve essere in grado di cercare la categoria “CAP” Loc_R6 Cancellare i servizi dallo LS È necessario riflettere le
variazioni nello scenario come la sostituzione di una
macchina Gateway Orc_R1 Distribuzione dei servizi di
griglia da parte di diversi provider.
COMB deve essere in grado di orchestrare i servizi CAP. Orc_R2 Stabilire uno scambio di dati
asincrono tra i servizi di Griglia “orchestrati”
L’approccio iterativo al calcolo chiede uno scambio di dati asincrono tra Nomenclator ed i CAP e viceversa.Questo potrebbe essere fatto con un orchestrator che opera come intermediario
Requisiti non Funzionali
• L’implementazione di tutti i sottosistemi è basato sulla piattaforma Microsoft .NET.
• L’implementazione dei servizi di Griglia è basata sul framework OGSI.NET fornito dall’Università della Virginia.
• Il servizio Instantiation è un servizio di Griglia. • Il servizio Location è un servizio di Griglia.
• Il sottosistema Location è basato sul server UDDI fornito dalla Microsoft. • Il sottosistema Orchestration è basato su un linguaggio di definizione dei
processi, il BPEL4WS (Business Processing Execution Language for Web
Services) [35] ed usa il BizTalk Server 2004 [36] fornito da Microsoft
come orchestration engine. Tabella 6.2: Requisiti funzionali
6.3 Architettura di PIP_ILO
Le caratteristiche ed i requisiti descritti in precedenza sono rispecchiati nell’architettura illustrata nella Figura 6.2. Assumiamo che il sottosistema Locator ed Orchestrator siano in esecuzione in un ambiente hosting controllato da COMB (d’ora in avanti sarà chiamato ASPCOMB).
Lo scenario PIP_ILO è descritto da una lista di azioni elencate di seguito. Tali azioni saranno mostrate in differenti situazioni con differenti attori appartenenti a diversi sottosistemi.
Lista di azioni per l’esecuzione di un processo di ottimizzazione:
1. ASPCLIENT chiede ad ASPCOMB di iniziare il processo di ottimizzazione.
2. ASPCOMB inizia il workflow per la fase di orchestration.
3. Lo ORCHESTRATOR chiede al Locator gli INSTANTIATOR per i servizi CAP e NOMENCLATOR.
4. Lo INSTANTIATOR istanzia i servizi di Griglia CAP e NOMENCLATOR.
5. Lo ORCHESTRATOR invoca i servizi di Griglia che partecipano al processo di ottimizzazione tramite un proxy Web Service.
ASP COMB
ASP Client
CAP1/2 /Nomenclator Web Service Proxies Client
Interface Orchestrator
Instantiator
CAP 2
Factory
CAP2 Grid Service NOMENCLATOR
CAP 1
Factory
CAP1 Grid Service Locator
6.4 Modello del progetto
Per fornire una descrizione dettagliata della situazione in cui ciascun componente del prototipo può essere impiegato, è necessario dividere PIP_ILO nei suoi sottosistemi per rispecchiare i ruoli mutevoli dei differenti partecipanti durante l’esecuzione del calcolo. Notare che il package “Business Grid Service” non fa parte dell’infrastruttura GRASP, ma contiene una rappresentazione del processo “business” da essa supportato. Nel caso del test per il PIP_ILO bisogna considerare anche i servizi di Griglia CAP e NOMENCLATOR. Nella Figura 6.3 sono mostrati i package che possono essere utilizzati, di cui daremo una spiegazione più approfondita nei paragrafi successivi.
Instantiation
Location Orchestration
ASP System Interface Business Grid Services
Figura 6.2: Blocchi che costituiscono l’architettura del PIP_ILO.
6.4.1 Esempio di utilizzo del package ASP System Interface
Questo package è usato quando il client di ASPCOMB effettua un ordine, come illustrato in Figura 6.4. Dettagli per questa situazione di utilizzo sono descritti nella Tabella 6.3.
ASP Client
Order Calculation
ORDER CALCULATION ASP Client
Inizializzare un processo di ottimizzazione dei costi 1. Verificare il client ASP
2. Iniziare l’esecuzione del processo di calcolo 3. Esporre i risultati
Un Client è registrato come utente dello ASPCOMB
6.4.2 Esempio di utilizzo del package Location
Questo package comprende una coppia di esempi di utilizzo che sono riferiti a due entità, il service Requestor ed il Grid Service Provider (GSP). All’interno del PIP_ILO, lo ASPCOMB è un service Requestor, mentre il Grid service provider rappresenta i CAP. Nella Figura 6.5 è mostrata l’interazione tra queste due entità, inoltre nella Tabella 6.4, Tabella 6.5, Tabella 6.6, Tabella 6.7, Tabella 6.8 sono spiegate dettagliatamente le azioni che tali entità eseguono.
Figura 6.4: Esempio di utilizzo di ASP System interface
Requestor
Search Service
Grid Service Provider (CAP)
Delete Service Check Rights Update Service Directory «uses» «uses» «uses» «uses» Orchestrator on behalf of the ASPCOMB Publish Service «uses» Search Service Orchestrator
Ottenere una lista di servizi che possono partecipare in un processo di ottimizzazione dei costi
1. Usare il “Check Right”
2. Cercare nel service directory i servizi che soddisfano i criteri di ricerca del requestor. Nel contesto del PIP_ILO questo significa cercare tutti i servizi del tipo “CAP” e trovare il service provider giusto. 3. Restituire i servizi trovati al Requestor
Pubblicare i servizi al service Locator Figura 6.5: Esempio di utilizzo del Location
Check Rights Orchestrator
Autenticazione ed Autorizzazione del service requestor 1. Estrarre il requestorId dalla query.
2. Mappare il requestorId al ruolo predefinito1. 3. Restituire il risultato della verifica.
Publish Service CAP
Pubblica un Grid Service sul sistema Locator 1. Usare “Check Rights”.
2. Usare “Update Service Directory”.
3. Restituire la conferma dell’avvenuta pubblicazione.
Delete Service CAP
Rimuove un Grid Service registrato dal sistema Locator 1. Usare “Check Rights”.
2. Identificare il servizio da cancellare tramite un identificatore assegnatogli dal Locator.
3. Usare “Update Service Directory”. 4. Restituire l’esito dell’operazione. Il servizio è registrato.
1 Ruolo predefinito: ruolo (provider, requestor) che un client può assumere. Tali ruoli
sono definiti prima che il processo di ottimizzazione abbia inizio. Tabella 6.5: Esempio di utilizzo del “Check Rights”
Tabella 6.6: Esempio di utilizzo del “Publish Service”
Update Service Directory CAP
Aggiornare il Service Directory per riflettere i cambiamenti richiesti dai provider del servizio CAP.
1. Aggiornare il Service Directory. Nel PIP_ILO questo significa aggiornare un database relazionale.
2. Restituire la conferma al processo chiamante.
6.4.3 Esempio di utilizzo del package Instantiation
Gli esempi di utilizzo dello Instantiation sono importanti per poter istanziare i tre Grid service: Nomenclator, Grid Service CAP_1, Grid Service CAP_2. Lo Orchestrator richiede di istanziare i servizi di griglia e per farlo invoca determinate azioni, come è mostrato in Figura 6.6. Tali azioni sono descritte nelle Tabelle 6.9, 6.10, 6.11 e 6.12. Orchestrator Create Service Instance Choose Factory Invoke Virtual Instance Service Instance Retrieve Real Instance «uses» «uses» Check Rights «uses»
Tabella 6.8: Esempio di utilizzo del “Update Service Directory”
Create Service Instance Orchestrator
Lo Orchestrator invoca il Service Instantiator per creare un’istanza di un servizio.
1. Usare “Check Rights”.
2. Trova o crea un PUC (Personal User Container) per registrare le informazioni riferite al requestor.
3. Usare “Choose Factory”.
4. Crea un’istanza chiamando la factory.
5. Crea un service locator virtuale e registra nel PUC il mapping tra il service locator reale e quello virtuale.
6. Restituisce il locator virtuale allo Orchestrator.
Il sistema Locator ha restituito una lista valida di sistemi Instantiation.
Choose Factory Orchestrator
Lo Instantiator sceglie una factory in base alla richiesta.
1. Lo Instantiator recupera i requisiti specificati dallo Orchestrator. 2. Controlla un file di configurazione che contiene le factory
schierate all’interno dell’ambiente hosting. Nel PIP_ILO le factory sono classificate secondo uno schema fisso (tipo del servizio, service provider Id).
3. Se esiste una factory che soddisfa i requisiti forniti, lo Instantiator recupera il relativo endpoint.
Tabella 6.9: Esempio di utilizzo del “Create Service Instance”
InvokeVirtual Instance Orchestrator
Invoca un’istanza del servizio di griglia in esecuzione che usa un endpoint virtuale.
1. La richiesta è intercettata dal container GRASP. 2. Identificare il PUC del requestor.
3. Usare “Retrive Real Instance:. 4. Invoca l’istanza di un servizio reale.
5. Il container restituisce i risultati allo Orchestrator.
L’istanza in esecuzione deve essere registrata nel PUC del requestor.
Retrieve Real Instance Orchestrator
Il container mappa un service locator virtuale ad un service locator reale. 1. Cerca il service locator nella tabella di mapping.
2. Estrarre e restituire il service locator reale dalla tabella di mapping.
6.4.4 Esempio di utilizzo del package Orchestration
In questo package le entità principali sono il service Provider (ASPCOMB) ed il Process Designer che si occupa di schierare i Web Service proxy per i servizi di Griglia: Nomenclator, CAP_1 e CAP_2. Di seguito nella Figura 6.7 è mostrata l’interazione tra i due attori e le Tabelle 6.13 e 6.14 in cui sono descritte le azioni invocate.
Tabella 6.11: Esempio di utilizzo dello “Invoke Virtual Instance”
Service Provider (ASPCOMB) Execute Process Locator Instantiator Deploy Process Process Designer Deploy Process Process Designer
Schierare un file in un formato comprensibile a BizTalk contenente le regole di interazione del servizio.
1. Sviluppare la definizione del processo. 2. Schierare la definizione del processo.
3. Schierare i web service proxy per il Nomenclator, CAP_1, CAP_2.
Figura 6.7: Esempio di utilizzo dello Orchestrator
Execute Process ASPCOMB
Eseguire un processo di ottimizzazione del costo.
1. Invocare il Locator per recuperare le informazioni per istanziare il grid Service CAP_1.
2. Invocare il Locator per recuperare le informazioni per istanziare il grid Service CAP_2.
3. Invocare il Locator per recuperare le informazioni per istanziare il servizio Nomenclator.
4. Invocare il servizio Instantiator per creare le istanze del Nomenclator, del CAP_1 e del CAP_2.
5. Ripetere le iterazioni del processo di ottimizzazione fino a che l’ottimizzazione sul costo non sia accettata da tutti i CAP. 6. Esporre i risultati in formato XML.
6.5 Test
I test relativi alla struttura del progetto GRASP comprendono tre diverse categorie di test:
Test sui moduli software elaborati dagli sviluppatori di tali moduli tramite un framework fornito da Microsoft, chiamato NUnit [37]. Test su ciascun sottosistema costituente il PIP_ILO elaborati dagli sviluppatori di tali sottosistemi con l’aiuto di test guida.
Test sull’integrazione dei sottosistemi.
I test sui moduli e sul sottosistema sono stati definiti ed elaborati per ogni sottosistema, nel nostro caso i test sul sottosistema Locator sono stati esposti nel Capitolo 5 alla sezione dedicata ai test.
Nella Tabella 6.15 sono esposti i test effettuati sul PIP_ILO. Ciascun test è considerato valido se soddisfa i requisiti funzionali esposti nel paragrafo 6.2. Tabella 6.14: Esempio di utilizzo dello “Execute Process”
!
T_ILO_1 Loc_R1, Loc_R2,
Loc_R3 Search Service, Check rights Valido
T_ILO_2 Loc_R4, Loc_R5 Publish Service Valido
T_ILO_3 Loc_R6 Delete Service Valido
T_ILO_4 Inst_R1 Create Service
Instance Valido
T_ILO_5 Inst_R2 Invoke Virtual
Instance Valido
T_ILO_6 Orc_R1 Order Calculation Valido
T_ILO_7 Orc_R2 Order Calculation Valido
6.6 Schieramento del PIP_ILO
Per comprendere quale possa essere un possibile scenario del PIP_ILO in cui tutti i servizi sono schierati, mostriamo la Figura 6.8 dove il Locator, il Nomenclator, lo Orchestrator ed i servizi CAP sono in esecuzione su differenti macchine.
ASP running: Client interface, Orchestrator engine GSP running: Nomenclator service GSP running: CAP1 service GSP running: CAP2 service Locator ASP client
