Capitolo 5
Caso di Studio: Realizzazione di un
sottosistema Service Locator in ambiente
GRASP
In questo capitolo è descritto il sottosistema Service Locator. In particolare, mostriamo l’architettura di tale sottosistema e le interazioni tra le varie componenti che lo costituiscono. Successivamente illustreremo come il Service Locator è stato implementato e quali operazioni sono state elaborate per il suo corretto funzionamento all’interno dell’ambiente GRASP. Le componenti di tale ambiente sono dei servizi Griglia e come tali devono essere conformi alle specifiche definite da OGSA. Per tale motivo faremo un confronto tra il servizio Griglia ServiceGroup presente nel container del GT3 core ed il Service Locator per vedere se quest’ultimo rispetta le specifiche OGSA.
5.1 Architettura del Service Locator
5.1.1 Overview
In Figura 5.1 è mostrato lo schema del sottosistema Service Locator fornito dall’infrastruttura GRASP. Tale figura mostra delle organizzazioni virtuali (VO), ognuna delle quali include un insieme di Service Provider, che offrono una lista di servizi ai client presenti all’interno della VO.
Ogni organizzazione virtuale stabilirà a priori le infrastrutture, il certificate authority, le directory services da condividere e manterrà anche l’informazione riguardante altre VO con cui si vuole interagire.
E’ necessario che in ogni organizzazione virtuale sia presente almeno un Service Locator (SL) che ha il compito di individuare un servizio appartenente alla stessa organizzazione o ad una organizzazione esterna, e questo è possibile poiché ogni Service Locator può comunicare con altri Service Locator di altre VO.
Le principali funzioni svolte dal Service Locator sono le seguenti:
1. Riceve le richieste per un servizio insieme a specifiche caratteristiche (prezzo, QoS, tipo del servizio) che lo contraddistinguono
2. Esegue la ricerca del servizio all’interno della propria VO e nelle altre VO tramite gli altri Service Locator.
3. Restituisce una lista di Service Provider che offrono i servizi che corrispondono ai requisiti richiesti.
La scelta di uno schema pipeline, dove ogni componente svolge una delle funzioni sopra esposte, permette di sfruttare due livelli di parallelismo. Un Locator può allora eseguire più richieste contemporaneamente e differenti Locator possono elaborare la stessa richieste concorrentemente.
Il Service Locator è esposto come un servizio di Griglia ed usa le funzionalità del sistema operativo sottostante per implementare il pipeline.
Pensando all’implementazione del Service Locator è necessario avere delle linee guida, cioè dei requisiti funzionali da implementare per assicurare un corretto funzionamento del Locator all’interno dell’ambiente GRASP. Tali requisiti possono essere:
1. Dare la possibilità ad un utente del Sottosistema Locator di cercare uno specifico servizio, specificando con quale livello di QoS è stato registrato. 2. Quando si effettua una ricerca di un servizio, il Service Locator deve:
a) controllare i diritti del requestor1;
b) restituire una lista di oggetti, ciascuno dei quali contiene informazioni che descrivono i servizi che soddisfano la richiesta; c) elaborare una ricerca distribuita invocando gli altri Locator nelle
altre VO.
3. Dare la possibilità ad un utente del sottosistema Locator di pubblicare nuovi servizi specificando informazioni riguardanti:
a) il provider,
b) un servizio persistente che possa istanziare il servizio pubblicato, c) tipo, prezzo e QoS del servizio per pubblicarlo all’interno di una
categoria definita a priori.
4. Nella pubblicazione di un servizio, il Sottosistema Locator dovrebbe: a) Registrare il servizio nella propria directory, conformandosi alle
informazioni di categorizzazione fornite dal provider.
b) Restituire un identificatore unico del servizio pubblicato all’interno della directory
5. Un provider dovrebbe avere la possibilità di cancellare i propri servizi dal sottosistema Locator.
6. Un publisher dovrebbe avere la possibilità di aggiornare le informazioni riguardanti i propri servizi pubblicati nel sottosistema Locator.
1 Requestor: può essere un richiedente della propria organizzazione virtuale (VO) oppure, al più, un Locator appartenente ad un’altra VO.
Figura 5.1: Locator schema Service Locator Service Requestor IIS 1 Request Recipient Request Manager Search Result Manager 8 9 3b 2 6 3a Information Service 4 1.1.1 Lo Service List 5a Service Directory 7a 5b IIS Locator2 Directory2 7b V.O.3 IIS Locator3 Directory3 V.O.2
5.1.2 Descrizione del servizio
La Figura 5.1 mostra una possibile architettura per il service location in ambiente GRASP. I principali componenti di tale architettura sono:
- Service Locator, - Service Directory, - Information Service.
Per richiedere un servizio il Service Requestor fa una richiesta (request) avente la seguente struttura:
request = <id, serv> dove:
- id identifica il richiedente del servizio
- serv è una struttura che contiene alcuni attributi che identificano il
servizio richiesto (QoS, prezzo, categoria, ecc.)
Quando il requestor fa una richiesta al Service Locator specifica la sua identità ed alcune proprietà del servizio (ad esempio Category, QoS, Price). Il Locator in Figura 5.1 è realizzato come un pipeline di tre processi, REQUEST RECIPIENT, REQUEST MANAGER e SEARCH RESULT MANAGER.
Il componente REQUEST RECIPIENT riceve ed elabora le richieste provenienti dal Service Requestor della propria organizzazione virtuale o da un Locator appartenente ad un altro VO.
Il secondo componente del pipeline, il REQUEST MANAGER, provvede ad effettuare la ricerca nel proprio Service Directory e ad inviare la richiesta per lo stesso servizio a tutti gli altri Locator attivi.
Il terzo componente del pipeline è il SEARCH RESULT MANAGER che riceve i risultati (Service List) della ricerca locale e remota. Il SEARCH RESULT MANAGER, appartenente al pipeline che ha elaborato la richiesta originale proveniente dal Service Requestor, agisce come un master che concatena tutte le Service List che provengono dagli altri Locator in un’unica Service List che sarà restituita al Service Requestor.
Il Service Directory è un “deposito” in cui è memorizzata l’informazione relativa ai servizi, come la descrizione di tali sevizi ed i puntatori ai Service Provider che li forniscono.
Descriviamo ora una generica interazione tra le componenti GRASP per soddisfare una richiesta di un servizio. È importante notare che i numeri tra parentesi sono quelli illustrati in Figura 5.1 che rappresentano l’azione che si sta eseguendo e le componenti interessate in ciascuna azione.
Il Service Requestor invia una richiesta (request) al Locator sotto forma di un messaggio SOAP (1). Tale richiesta passa attraverso il componente Internet
Information Server (IIS)2 e arriva al componente REQUEST RECIPIENT (2)
dove viene decodificato. Successivamente l’identificatore (id) del requestor è
passato al SEARCH RESULT MANAGER (3a), mentre la struttura serv è
passata al REQUEST MANAGER (3b).
Il REQUEST MANAGER riceve la struttura serv, chiede (4) all’Information Service dell’ambiente GRASP gli indirizzi dei Locator delle altre VO, provvede ad effettuare una ricerca nel proprio Service Directory (5a) e ad inviare una richiesta (5b) a tutti gli altri Locator dell’ambiente GRASP. Tale richiesta, che noi chiameremo request1, è costituita dallo id del Locator interrogato e dalla
struttura serv. Il numero di Locator presenti nell’ambiente GRASP restituito
dallo Information Service al REQUEST MANAGER sarà passato come parametro al SEARCH RESULT MANAGER (6). La ricerca di un servizio è considerata conclusa quando il SEARCH RESULT MANAGER ha ricevuto un numero di Service List pari al numero di Locator dell’ambiente.
L’informazione serv è usata per cercare il servizio all’interno del Service
Directory. Se il servizio richiesto esiste, sarà selezionato ed inserito in una Service List che sarà inviata al SEARCH RESULT MANAGER (7). Tale componente, una volta ricevute le Service List da parte dei Locator appartenenti
2 Internet Information Server (IIS): è presente in ogni computer in cui sia installato un sistema operativo Microsoft e viene utilizzato per ricevere le richieste provenienti dai client.
agli altri VO, invia al Service Requestor (8-9), passando attraverso lo IIS, una Service List data dalla concatenazione di tutte quelle ricevute.
5.1.3 Tecnologie coinvolte
OGSI.NET Framework
L’infrastruttura GRASP è stata sviluppata sul framework OGSI.NET fornito dall’Università della Virginia. Questo framework fornisce un’infrastruttura base per costruire e pubblicare un servizio di Griglia conforme alle specifiche OGSI.
Nell’architettura del Service Locator sarà esposto almeno un servizio di Griglia, il REQUEST RECIPIENT nel front-end della pipeline. Per implementare tale servizio e le altre componenti della pipeline sarà usato il farmework OGSI.NET.
Registro UDDI
Nella fase di progettazione del service Locator abbiamo pensato di implementare il service directory usando i servizi UDDI forniti dalla piattaforma Microsoft. Tali servizi sono progettati per risolvere il problema dell’individuazione dei web service, ma è necessario trovare il modo di integrarli nella nostra architettura e di estenderli per i nostri scopi cercando di ottenere sempre una soluzione che sia conforme alle specifiche OGSA.
5.2 Modello di Implementazione
5.2.1 Diagramma UML del sottositema Locator
In Figura 5.2 è illustrato il diagramma UML [41] delle principali classi del sottosistema Locator, che forniscono le seguenti funzionalità:
• GridServiceSkeleton: fornisce le funzionalità di base di un servizio di
Griglia ed è parte della distribuzione OGSI.NET fornita dall’Università della Virginia.
• ServiceLocator: permette la pubblicazione, la cancellazione,
l’individuazione e l’aggiornamento di un servizio di Griglia nell’ambiente GRASP. Interagisce direttamente con la directory UDDI tramite le operazioni di publish, delete, update, mentre con il Request Manager per elaborare le operazioni di ricerca.
• RequestManager: gioca il ruolo di coordinatore tra un UDDIRequestor e
più RemoteRequestor. Inoltre riunisce le Service List ricevute dai RemoteRequestor in un’unica lista.
• AbstractRequestor: è una classe base astratta per le classi UDDIRequestor
e RemoteRequestor, cioè contiene delle informazioni richiamate da queste classi.
• UDDIRequestor: gestisce la richiesta di un servizio rivolta alla directory
UDDI configurata localmente.
• RemoteRequestor: gestisce le richieste di servizi che devono essere
inoltrate ad altri Locator di altre organizzazioni Virtuali.
• ServiceInfoType: raggruppa tutte le informazioni riguardanti un servizio.
Tali informazioni includono anche quelle usate per categorizzare un servizio, in particolare quest’ultime informazioni sono contenute nella classe ServiceFeaturesType.
• IdentityType: consente di controllare e di verificare l’identità del client che
invoca una delle operazioni del Locator. Il controllo dovrebbe essere elaborato da una classe SecurityType che, al momento, non svolge nessuna azione.
• LocatorRequestType: esegue la ricerca formulata da un client. • PublishRequestType: pubblica la richiesta formulata da un client.
• LocatorWrappedType: contiene la lista di servizi ottenuta dal Service
+SearchService(in searchRequest : GrASP.Base.LocatorProxy.LocationRequestType) : GrASP.Base.LocatorProxy.LocationsWrapperType +PublishService(in publishRequest : GrASP.Base.LocatorProxy.PublishRequestType) : string
+DeleteService(in source : GrASP.Base.LocatorProxy.IdentityType, in serviceKey : string) : bool
+add_Service(in bs : Microsoft.Uddi.Services.BusinessService, in publishRequest : GrASP.Base.LocatorProxy.PublishRequestType, in myConn : UddiConnection, in TModelKey : string) : bool +Create_TModel(in endpoint : string, in myConn : UddiConnection) : string
+CheckIdentity(in source : GrASP.Base.LocatorProxy.IdentityType) : int +Contact_IS() : ServiceLocatorType [ ]
+Insert_TModel(in bs : Microsoft.Uddi.Services.BusinessService, in endpoints : string [ ], in myConn : UddiConnection) : void +ServiceLocator() -myId : GrASP.Base.LocatorProxy.IdentityType -util : GrASP.Base.ServiceLocator.LocatorCommonUtil GrASP.Base.ServiceLocator.ServiceLocator UVa.Grid.OGSIGridServiceLib.GridServiceSkeleton +IdentityType() +id : string +securityInfo : GrASP.Base.LocatorProxy.SecurityType GrASP.Base.LocatorProxy.IdentityType «uses» +ServiceInfoType() +providerId : string +serviceType : string +serviceFeatures : GrASP.Base.LocatorProxy.ServiceFeaturesType +description : string +endpoint : string GrASP.Base.LocatorProxy.ServiceInfoType +LocationRequest() +source : GrASP.Base.LocatorProxy.IdentityType +serviceType : string +serviceFeatures : GrASP.Base.LocatorProxy.ServiceFeaturesType GrASP.Base.LocatorProxy.LocationRequestType +ServiceFeaturesType() +qos : string +category : string -price : string GrASP.Base.LocatorProxy.ServiceFeaturesType +PublishRequestType() +baseRequest : GrASP.Base.LocatorProxy.LocationRequestType +description : string +endpoint : string GrASP.Base.LocatorProxy.PublishRequestType +LocationsWrapperType() +servicesList : ServiceInfoType [ ] GrASP.Base.LocatorProxy.LocationsWrapperType «uses» 1 1 1 1 1 1 1 1 1 1 1 1 «uses» «uses» «uses» «uses» «uses»
+SetTimer(in interval : int) : void +StartSearch() : void
+ReceiveLists(in index : int, in requestorResult : GrASP.Base.LocatorProxy.ServiceInfoType [ ]) : void +GetList() : System.Object.ArrayList
+Timer_Tick(in sender : object, in eArgs) : void
+RequestManager(in myIdentity : GrASP.Base.LocatorProxy.IdentityType, in locatorsList : ServiceLocatorType [ ], in serviceFeatures : GrASP.Base.LocatorProxy.ServiceFeaturesType, in serviceType : string, in util : GrASP.Base.ServiceLocator.LocatorCommonUtil) +MakeNewRequest() : GrASP.Base.LocatorProxy.LocationRequestType -myIdentity : GrASP.Base.LocatorProxy.IdentityType -locatorsList : ServiceLocatorType[] -serviceFeatures : GrASP.Base.LocatorProxy.ServiceFeaturesType -serviceType : string -requestorPool : object[] -servicesList : System.Object.ArrayList -countTh : int -clock -timeout : bool -myRequestor : System.Threading.Thread -util : GrASP.Base.ServiceLocator.LocatorCommonUtil -myReqIsDone : bool GrASP.Base.ServiceLocator.RequestManager +SendRequest() : void +QueryUDDI() : ServiceInfoType [ ]
+MyRequestor(in principal : GrASP.Base.ServiceLocator.RequestManager, in request : GrASP.Base.LocatorProxy.LocationRequestType, in util : GrASP.Base.ServiceLocator.LocatorCommonUtil) +RetrieveServiceInfo(in servInfo : Microsoft.Uddi.Services.ServiceInfo, in myConn : UddiConnection) : ServiceInfoType
GrASP.Base.ServiceLocator.UDDIRequestor
1
* «uses»
+Requestor(in index : int, in principal : GrASP.Base.ServiceLocator.RequestManager, in locatorUrl : ServiceLocatorType, in request : GrASP.Base.LocatorProxy.LocationRequestType, in util : GrASP.Base.ServiceLocator.LocatorCommonUtil) +ForwardRequest() : ServiceInfoType [ ] +SendRequest() : void -locatorUrl : ServiceLocatorType GrASP.Base.ServiceLocator.RemoteRequestor «uses» 1 1 1 1 +SendRequest() #principal : GrASP.Base.ServiceLocator.RequestManager #index : int #request : GrASP.Base.LocatorProxy.LocationRequestType #util : GrASP.Base.ServiceLocator.LocatorCommonUtil GrASP.Base.ServiceLocator.AbstractRequestor «uses»
Ci sono altre classi che sono usate dal Service Locator e che non sono mostrate nel diagramma delle classi per motivi di leggibilità. Le più importanti sono:
• LocatorCommonUtil: fornisce funzioni comuni ad altre classi e capacità di
logging.
• ServiceLocatorType: è parte della distribuzione OGSI.NET e contiene il
GSH ed il GSR di un servizio.
5.2.2 Funzionalità offerte dal Service Locator
Il servizio di Griglia Locator è stato progettato per pubblicare e cercare un servizio all’interno di un service directory. A tal proposito sono state implementate tre PortType (interfacce) che il Locator “espone” ai componenti della VO in cui è allocato o ad altri componenti di altre VO. Le PortType in questione sono:
- Search - Publish - Delete
in particolare, Publish e Delete possono essere invocate solo da Service Provider appartenenti alla stessa VO del Locator, mentre la portType Search può essere invocata da un Service Requestor interno alla VO o da altri Service Locator di altre VO.
Illustreremo le portType sopra esposte tramite dei sequenze diagram che mostrano sia l’interazione tra le classi citate nel precedente paragrafo (e non solo) sia le funzioni utilizzate per adempiere a ciascuna invocazione.
Search
Le interazioni tra le classi del diagramma UML di Figura 5.2 nel caso di una Search sono mostrate in Figura 5.3.
Le principali funzioni coinvolte in Search Sequence Diagram sono le seguenti:
• SearchService(): è chiamato dal client che vuole cercare un servizio
con dei requisiti specifici. Tale client deve fornire informazioni utili per la ricerca, quali il tipo del servizio e/o la categoria, ecc., inseriti come parametri nella struttura searchRequest passata in input alla funzione di ricerca.
• checkIdentity(): consente di identificare il tipo del richiedente (service
provider, service requestor o un altro service Locator).
• Contact_IS(): recupera una lista di service Locator invocando un Web
Service noto (Information Service). Tale lista è restituita a chi invoca la funzione Contact_IS().
• SetTimer(): è chiamata nel RequestManager e consente di settare un
tempo di attesa per la risposta da parte dello UDDIRequestor e dei RemoteRequestor.
• MakeNewRequest(): è chiamata all’interno del metodo StartSearch() e
crea una nuova richiesta per i RemoteRequestor.
• SendRequest(): è chiamata dal RemoteRequestor. Inoltra la richiesta
per la ricerca di un servizio al ServiceLocator.
• SendRequest(): è chiamata dallo UDDIRequestor. Esegue la query alla
directory UDDI attraverso il metodo QueryUDDI.
• QueryUDDI(): crea una connessione alla directory UDDI, esegue le
query e gestisce i risultati per ottenere l’output richiesto.
• ReceiveList(): è invocato da UDDIRequestor e RemoteRequestor per
inviare al RequestManager le liste dei servizi ottenute, inoltre esegue anche la concatenazione di tali liste.
• GetList(): è invocata dal ServiceLocator per ottenere la lista (finale)
requestor non hanno terminato la loro elaborazione o fino a quando il
If requestorType is equal to Service Locator, the current Locator doesn't have to perform a search in other locators SL:ServiceLocator checkIdentity(source) requestorType Contact_IS() localhost.ServiceLocatorType[] requestManager:RequestManager: Thread StartSearch() client:Client final_servicesList searchService(searchRequest) requestor ( n ) :RemoteRequest or QueryUDDI servicesList final_servicesList GetList() myReq:UDDIRequestor UDDI SendRequest() ServiceLocator( n ) SearchService(LocationRequest) servicesList SendRequest() SetTimer(interval)
All the Threads will be run at the same time. These Threads will invoke the Service Locator method SearchService,
only one will invoke the QueryUDDI method on UDDI registry.
RemoteRequestor(index, principal, localhost.ServiceLocatorType locatorUrl, request, util)
UDDIRequestor(index,RequestManager,locator,LocationRequest) RequestManager(myID, locatorsList, searchRequest.serviceFeatures, searchRequest.serviceType, util)
myRequest:LocationRequestType LocationRequestType() myRequest MakeNewRequest() ReceiveLists(index, servicesList) ReceiveLists(index, servicesList)
Publish
La Figura 5.4 mostra alcune classi del diagramma UML di Figura 5.2 (ServiceLocator e LocatorCommonUtil) e altre appartenenti al namespace Microsoft.Uddi. Le interazioni tra tali classi permettono di realizzare la pubblicazione di un servizio nello UDDI.
Le principali funzioni coinvolte in un Publish Sequence Diagram sono le seguenti:
• PublishService(): è invocato da un publisher che intende pubblicare un
servizio. Per la pubblicazione sono necessarie delle informazioni riguardanti sia il servizio che il provider che intende pubblicarlo. In particolare, è necessario specificare lo id del provider e le caratteristiche del servizio, ovvero prezzo, categoria e QoS. Tali informazioni sono memorizzate nel PublishRequestType che è passato in input alla funzione PublishService().
• FindUddiUser(): identifica ed autentica un publisher accedendo ad un
file di configurazione dove sono definiti tutti quelli appartenenti ad una VO. Restituisce un valore booleano che certifica l’esistenza del publisher.
• UddiConnection(): è un metodo della classe UddiConnection,
utilizzato per creare un’istanza di tale classe che sarà poi usata per stabilire una connessione al server UDDI.
• FindBusiness(): è un metodo della classe FindBusiness, utilizzato per
individuare, se esiste, nel server UDDI il business (publisher) che intende pubblicare/cancellare un servizio.
• send(): è un metodo della classe UddiConnection utilizzato per inviare
la richiesta di connessione al server UDDI.
• BusinessEntity(): è un metodo della classe BusinessEntity, che
rappresenta le entità business nello UDDI. Se l’entità business che intende pubblicare un servizio non è presente nello UDDI, tale metodo
è invocato per creare un’istanza della classe BusinessEntity che sarà poi utilizzata per aggiungere una tale entità nel server UDDI.
• SaveBusiness(), BusinesEntities.Add(), send(): metodi della classe
SaveBusiness utilizzati per aggiungere un’entità business nello UDDI o per aggiornare le informazioni riguardanti l’entità stessa.
• FindService(): è un metodo della classe FindService ed è utilizzato per
verificare se il servizio che si intende pubblicare è gia presente nello UDDI.
• DeleteService(): è un metodo della classe DeleteService ed è invocato
per cancellare la “vecchia” versione del servizio che si intende pubblicare. In particolare tale metodo è utilizzato per evitare che ci siano più versioni dello stesso servizio pubblicate dallo stesso business.
• addService(): è una funzione che aggiunge il servizio al business che
Client ServiceLocator
PublishService(publishRequestType)
LocatorCommonUtil
FindUddiUser(pulishRequest.baseRequest.source, username, passw) foundUser
UddiConnection
UddiConnection(url_i,url_p, url_e, username, pass) myConn FindBusiness FindBusiness(namep) fBusiness BusinessList Send(myConn) BusinessList
Verifica della variabile bool “exist” BusinessEntity
Se exist è false, il provider non esiste. Un BusinessEntity deve essere creato
BusinessEntity(namep) be SaveBusiness SaveBusiness() sb BusinessEntity.Add(be) Send(myConn) bDetail businesskey = bDetail.BusinessEntities[0].BusinessKey FindService FindService(publishRequest.baseRequest.serviceType) fService Send(myConn) sList DeleteService DeleteService(serviceKey del Send(myConn) servicekey
Add_Service(bs, publishRequest, tModelKey, myConn) altrimenti, il
provider esiste. Il vecchio servizio viene cancellato
Delete
La Figura 5.5 mostra, come per la funzione Publish, l’interazione tra alcune classi del diagramma UML di Figura 5.2 e altre appartenenti al namespace Microsoft.Uddi. L’interazione tra tali classi permette di cancellare un servizio dallo UDDI. Le principali funzioni coinvolte in un Delete Sequence Diagram sono le seguenti:
• DeleteService(): viene invocato da un provider che intende cancellare
un servizio. Le informazioni necessarie per eseguire tale funzione sono: lo id del provider e l’identificatore del servizio, cioè il “servicekey” rilasciato quando il servizio è stato pubblicato.
• FindUDDIUser(): identifica ed autentica un provider accedendo ad un
file di configurazione dove sono definiti tutti quelli appartenenti ad una VO. Restituisce un valore booleano che certifica l’esistenza del provider.
• UddiConnection(): è un metodo della classe UddiConnection,
utilizzato per creare un’istanza di tale classe che sarà poi usata per stabilire una connessione al server UDDI.
• FindBusiness(): è un metodo della classe FindBusiness, utilizzato per
individuare, se esiste, nel server UDDI il business (publisher) che intende pubblicare/cancellare un servizio.
• send(): è un metodo della classe UddiConnection utilizzato per inviare
la richiesta di connessione al server UDDI.
• GetServiceDetail(): utilizzato per ottenere tutte le informazioni che
descrivono un servizio pubblicato da un provider.
• DeleteService(): metodo appartenente alla classe DeleteService
utilizzato per cancellare un servizio.
• DispositionReport: è una classe che contiene il successo o il fallimento
Client ServiceLocator
DeleteService(source, servicekey)
LocatorCommonUtil
FindUDDIUser(publishRequest.baseRequest.source, username, passw) foundUser
UddiConnection
UddiConnection(url_I, url_p, url_e, username, pass) myConn FindBusiness FindBusiness(namep) fBusiness BusinessList send(myConn) bList GetServiceDetail GetServiceDetail(servicekey) gService send(myConn) sDetail GetServiceDetail DeleteService(servicekey) del send(myConn) DispositionReport ok
Update
Nel Locator, la funzione di aggiornamento di un servizio non è stata realizzata come portType del servizio. In realtà, questa funzionalità viene realizzata “di nascosto” chiedendo la pubblicazione di un servizio. Infatti, quando un provider chiede di pubblicare un servizio che già esiste, tale servizio viene cancellato per far posto al servizio “aggiornato” che si vuole pubblicare (vedere Figura 5.4).
5.2.3 Schema di Categorizzazione
Come già accennato nel Capitolo 3, per facilitare la “catalogazione” dei servizi nello UDDI, è usato uno schema di categorizzazione. Lo schema utilizzato nel service Locator presenta tre differenti categorie (price, qos, service type) ciascuna divisa in alcune sottocategorie in modo da avere diverse opzioni per la pubblicazione e la ricerca di un servizio. La categoria price riunisce i vari “range” di prezzo con cui un servizio può essere pubblicato (o cercato), mentre la categoria qos indica le possibili quality-of-service con cui un servizio può essere pubblicato (o cercato). Infine la categoria service type indica di che tipo può essere il servizio che si intende pubblicare (o cercare).
Per fornire questo modello è stato prodotto un file XML, chiamato GrASP Categorization Schema, ed inserito nel server UDDI. La Figura 5.6 da una visione grafica del GRASP schema.
5.3 Test
Il comportamento del sottosistema Locator è stato studiato tramite dei test che prevedono in input al sottosistema:
• informazioni non conformi ai requisiti richiesti dal sottosistema
(esposti all’inizio del capitolo).
• informazioni conformi a tali requisiti.
Questi test sono stati effettuati per dimostrare che se il sottosistema Locator ha un comportamento conforme alle richieste previste per ciascun test, allora avrà un comportamento analogo con tutti gli input simili a tali test. Nella Tabella 5.1 sono mostrati i test che sono stati effettuati e la relazione tra le funzionalità (ricerca di un servizio, pubblicazione, cancellazione, aggiornamento) ed i requisiti che in ogni test devono essere rispettate. Un test è considerato valido quando una funzionalità soddisfa i requisiti associati a tale test.
Nessun servizio all’interno del Sottosistema Locator soddisfa i requisiti richiesti in input
Ricerca di un servizio Viene restituito un messaggio appropriato del tipo “servizio non trovato”
La richiesta include requisiti di servizi che non sono previsti nel Sottosistema Locator
Ricerca di un servizio Viene restituito un messaggio di “fault”
I requisiti specificati non sono rivolti ai servizi pubblicati nel Sottosistema Locator locale, ma esistono in altri sottosistemi
Ricerca di un servizio Il sottosistema Locator restituisce una lista che include i servizi di altri sottosistemi dove non è incluso nessun servizio della directory locale Differenti richieste con
differenti requisiti specificati Ricerca di un servizio Il restituisce una lista che soddisfa sottosistema Locator le richieste
Il SP tenta di pubblicare un servizio specificando dei requisiti che non sono inclusi
nello schema di
categorizzazione del sottosistema Locator
Pubblicazione di un servizio Il Locator restituisce un messaggio di fault
Il SP che sta pubblicando non ha un ID autorizzato per pubblicare
Pubblicazione di un servizio Il Locator restituisce un messaggio di diniego
Il SP pubblica un servizio specificando dei requisiti conformi allo schema di categorizzazione
Pubblicazione di un servizio Quando si effettua la ricerca di un servizio con caratteristiche simili ai requisiti, il Locator include nella lista il servizio pubblicato
Il SP tenta di cancellare un servizio usando un identificatore non valido
Cancellazione di un servizio Viene restituito un messaggio di fault
Il SP tenta di cancellare un servizio pubblicato da un altro SP
Cancellazione di un servizio Il Locator restituisce un messaggio di diniego
Il SP cancella con successo un
servizio esistente Cancellazione di un servizio Si effettuano due ricerche con gli stessi requisiti, una antecedente e l’altra successiva alla cancellazione. Ciò che si attende come risultato è che il servizio compaia solo nella lista restituita dalla prima ricerca Tabella 5.1: Test eseguiti sul sottosistema Locator
5.3.1 Interfaccia usata per eseguire i Test
Per poter “interfacciare” un client al sottosistema Locator è stata realizzata un’interfaccia grafica che permette di semplificare le richieste di esecuzione delle funzioni esposte nei paragrafi precedenti. La Figura 5.7 mostra tale interfaccia: il Locator Test Client.
Come si può vedere dalla figura, l’interfaccia offre un “text box” in cui inserire l’identificatore di “chi vuol fare cosa”. Gli identificatori che si possono inserire in tale text box sono specificati nel riquadro Legend. Come già Figura 5.7: Locator Test Client
specificato in precedenza solo un provider può invocare tutti e tre i metodi esposti dal servizio di Griglia e raffigurati in figura nel riquadro Invoke Methods in cui è anche presente il riquadro Output in cui saranno riportati i risultati di ogni invocazione. Il Locator Test Client offre la possibilità di specificare, tramite il riquadro Service Features ed il text box Service Type, rispettivamente le caratteristiche (price, qos, Category) ed il nome che un servizio deve avere, sia per la ricerca che per la pubblicazione. Inoltre è possibile cancellare un servizio (lo può fare solo un provider) inserendo nel text box ServiceKey l’identificatore di tale servizio, che è una chiave alfanumerica restituita al momento della pubblicazione del servizio stesso. Infine, l’interfaccia offre la possibilità di dare una descrizione del servizio che si intende pubblicare, tramite il text box Description presente nel riquadro Publish and Additional Paremeters in cui è anche presente un altro text box, ovvero Instantiator Endpoint. In tale text box è inserita di default la URL di un servizio di Griglia appartenente all’infrastruttura GRASP, chiamato Service Instantiator, che ha il compito di creare l’istanza di un servizio richiesto da un client.
Il Locator Test Client viene utilizzato per gestire le informazioni all’interno dello UDDI. Per verificare gli effetti delle operazioni eseguite dal Locator useremo l’interfaccia utente Web-based, che è uno dei metodi utilizzati per accedere allo UDDI (l’altro è l’accesso tramite programma). Questa interfaccia è mostrata in Figura 5.8. In realtà, in tale figura è illustrato lo UDDI “privato” ad uno dei provider inseriti nel sottosistema Locator. Come detto nel Capitolo 4, nell’ambiente GRASP ogni VO può contenere più di un provider, ma un solo service directory, che nel nostro caso è lo UDDI. Per simulare una VO, sono stati inseriti in un file di configurazione due provider con relativi identificatore (dalla Figura 5.7 si nota che i provider autorizzati sono tre), nome e password. I provider usati nei test sono due, i quali sono stati creati come utenti del Windows Server 2003 ed inseriti in un gruppo chiamato uddipublisher. Tale gruppo sarà
inserito tra i “ruoli”3 di UDDI, in particolare nel Publisher’s Group Name che identifica il nome del gruppo di utenti a cui è concesso pubblicare un servizio.
Per accedere all’interfaccia utente UDDI è necessario digitare nella URL di un browser l’indirizzo http://nomemacchina/uddi. L’effettivo accesso a tale interfaccia avverrà solo dopo aver superato una fase di autenticazione realizzata tramite la verifica del nome utente e della password ad esso associata. A livello di codice, questo meccanismo di autenticazione viene realizzato tramite un file di configurazione in cui sono riportati i nomi dei provider.
Se l’utente che intende accedere allo UDDI non è un provider, esso può solo eseguire l’operazione di ricerca di un servizio e quindi non ha bisogno di essere autenticato. Infatti, tale utente accederà ad un UDDI “pubblico” dove è permessa la sola operazione di ricerca.
3 Ruoli UDDI: definiscono il livello di interazione concesso ad ogni utente
In Figura 5.8 è mostrato lo UDDI privato dell’utente “ ” che ha il ruolo
di “ (o provider). Tale ha la cartella Provider vuota poiché non
ha ancora eseguito nessuna operazione di publish sul “proprio” UDDI.
Di seguito mostreremo degli esempi di uso del Locator Test Client e dello UDDI per descrivere il funzionamento del sottosistema Locator nell’esecuzione delle operazioni Publish, Delete e Search.
5.3.2 Esempi
Pubblicazione di un servizio
Per pubblicare un servizio è necessario inserire l’identificatre del provider che deve eseguire l’operazione (che nel nostro caso è “1”), il nome e le caratteristiche del servizio. In questo esempio abbiamo scelto come nome del servizio pippo
che è caratterizzato dai parametri seguenti: QoS = qos [1-10],
Price = price[11-100], Category = Medical. In seguito all’invocazione del
metodo Publish (tramite la selezione del pulsante Publish) è restituita nel riquadro Output una stringa alfanumerica (ServiceKey) che identifica univocamente il servizio pubblicato. Questa descrizione è illustrata in Figura 5.9, mentre in Figura 5.10 è mostrato l’effetto dell’operazione publish sullo UDDI.
Come si può notare dalla Figura 5.10, il servizio pippo è stato inserito al di
sotto del provider “1” che in Figura 5.8 non era presente. Come mostrato dal Publish Sequenze Diagram (Figura 5.4), se un provider autenticato, che non è presente nello UDDI (Figura 5.8), intende pubblicare un servizio, allora deve essere necessariamente “creato” nello UDDI stesso prima che la sua richiesta di pubblicazione venga eseguita. In Figura 5.10 si può notare come le informazioni pubblicate in un UDDI formino una struttura ad albero, infatti il servizio pippo è
il nodo figlio del provider “1”, che rappresenta il nodo root di questa struttura ad albero. Scendendo nell’albero, troviamo il nodo figlio del servizio pippo,
chiamato “binding”, che è lo endpoint del servizio ed è utilizzato per riferire il
servizio di Griglia incaricato di istanziare il servizio qualora venisse richiesto. Figura 5.10: UDDI dopo la Publish
Scendendo ancora nell’albero troviamo il tModel che è il riferimento alla macchina su cui è allocato il servizio di Griglia riferito dal binding.
Le altre informazioni riguardanti il servizio pippo, cioè la descrizione e il
ServiceKey che lo identifica sono raffigurate in Figura 5.11a sotto la voce Detail, mentre le caratteristiche con cui il servizio è stato pubblicato sono mostrate in Figura 5.11b sotto la voce Categories.
Ricerca di un servizio
La ricerca di un servizio viene effettuata fornendo alcune delle informazioni che lo descrivono, quali il nome e le caratteristiche che si vogliono di tale servizio (qos, price e category). Quando non si conoscono alcune di queste informazioni si può ricorrere al carattere jolly “%”. Questo carattere permette di selezionare tutte le opzioni consentite per una data informazione. Quindi se non si conosce niente di un servizio, si può inserire nei campi interessati per la ricerca il valore “%”, come mostrato in Figura 5.12. Il risultato di una tale operazione è dato da una lista contenente tutti i servizi pubblicati nello UDDI da tutti i provider.
L’operazione di Search è consentita a chiunque, sia esso Provider, Requestor o Locator con una sola differenza riguardante i risultati visualizzati nel riquadro Output. Infatti, se la ricerca è fatta da un Provider o da un Requestor il sottosistema Locator contatta lo Information Service (IS) per farsi restituire gli indirizzi degli altri Locator presenti nell’ambiente GRASP in modo da realizzare una ricerca distribuita. Pertanto, nel riquadro Output comparirà una lista con tutti i servizi nell’ambiente che possono soddisfare una richiesta utente. Al contrario se la richiesta è fatta da un Locator, lo IS non viene contattato e di conseguenza la ricerca è ristretta allo UDDI gestito dal Locator che ha ricevuto la richiesta. Figura 5.12: Search generica
In questa implementazione del sottosistema Locator è prevista una sola VO, ma per effettuare i test abbiamo simulato il comportamento dello IS inserendo tre indirizzi di Service Locator che in realtà sono sempre lo stesso. Quindi supponendo di effettuare una ricerca del servizio pippo con tutte le sue
caratteristiche con cui è stato pubblicato si ha:
• se la richiesta giunge da un Provider o da un Requestor allora il
risultato è una lista contenente tre sevizi pippo, come illustrato in
Figura 5.13
• se la richiesta giunge da un altro Locator allora il risultato è una lista
con un solo servizio pippo4, come mostrato in Figura 5.14
4 In Figura 5.14 il risultato è ottenuto dalla ricerca in un solo UDDI, mentre nella Figura 5.13 il risultato è ottenuto dalla concatenazione delle liste restituite dagli altri Locator dell’ambiente GRASP interrogati.
Cancellazione di un servizio
La cancellazione di un servizio può essere eseguita solo dal provider che lo ha pubblicato. L’informazione necessaria per cancellare un servizio è il ServiceKey, cioè la stringa alfanumerica che lo identifica. Tale ServiceKey va inserito nell’omonimo text box del Locator Test Client e, successivamente, bisogna invocare il metodo Delete che cancellerà il servizio dall’UDDI privato del provider che ne ha richiesto la cancellazione. L’invocazione del metodo Delete restituisce nel riquadro Output un valore booleano per segnalare la corretta esecuzione o meno del metodo, come illustrato in Figura 5.15. Inoltre, in
Figura 5.16 è mostrato lo UDDI privato del provider che ha eseguito il comando Delete.
5.4 Conformità del Service Locator alle specifiche definite da
OGSA.
Per verificare se il Service Locator è conforme alle specifiche definite da OGSI abbiamo studiato il comportamento di un altro servizio di Griglia, il ServiceGroup, contenuto nell’ambiente runtime del GT3. E’ stato scelto questo servizio perché è conforme alle specifiche OGSA, come lo è anche l’infrastruttura che lo contiene.
Il ServiceGroup è un’istanza di un servizio di Griglia che “conserva” informazioni riguardanti altri servizi di Griglia5. Tale ServiceGroup fornisce tre
5 Un ServiceGoup può contenere anche un altro ServiceGroup
portType: ServiceGroup, ServiceGroupEntry e ServiceGroupRegistration. Per poter aggiungere, aggiornare o cancellare un servizio viene utilizzato il portType ServiceGroupRegistration che fornisce due operazioni: add e remove. La portType ServiceGroup gestisce un gruppo di servizi di Griglia contenuti nel servizio ServiceGroup, mentre la portType ServiceGroupEntry gestisce ogni singolo servizio presente nel ServiceGroup. La ricerca di un servizio avviene tramite delle query scritte nel linguaggio XPath [34].
Dai vari test e confronti effettuati è scaturito che il Service Locator fornisce le stesse funzionalità del ServiceGroup, ma questa non è una condizione sufficiente per poter dire che tale servizio di Griglia è OGSA-compliant. Infatti, nel ServiceGroup le informazioni di un servizio di Griglia sono gestite tramite il modello dei Service Data [30] che è una delle specifiche definite da OGSA. Tale modello fornisce un meccanismo per chiedere, aggiornare, aggiungere o rimuovere i dati associati ad ogni istanza di servizio di Griglia. Questa specifica nel sottosistema Locator non è stata rispettata, perché le informazioni che sono memorizzate nello UDDI non sono del tipo service data. Di conseguenza, l’attuale implementazione di tale servizio di Griglia non è conforme alle specifiche di OGSA.
