UDDI (Universal Description Discovery & Integration) è una specifica di Oasis e costituisce una delle possibili soluzioni al problema del censimento e catalogazione dei servizi in una SOA (Service Oriented Architecture).
Questa specifica definisce le entità e le relazioni con cui rappresentare i dati e le API per crearli, modificarli, interrogarli. I dati descrivono i produttori di servizi (businessEntity), i gruppi di servizi (businessService) e le infomazioni tecniche per accedervi (bindingTemplate). A ciascuna di queste entità si possono agganciare un certo numero di tModel (contenitori di dati o di metadati) utili, tra le altre cose, a definire dei sistemi di catalogazione, le tassonomie.
L’interrogazione dei dati contenuti in un catalogo che implementa la specifica UDDI (solitamente detto registry) avviene mediante modalità simili a quelle che si usano per le pagine gialle: dal produttore a scendere verso i servizi e dalla catalogazione merceologica a salire verso i servizi (ed i produttori). Queste modalità, comunque, sono utilizzabili solo da umani e non da sistemi software: l’architetto scorre il registry UDDI alla ricerca di un servizio e delle informazioni tecniche per potervi accedere; i sistemi software per fare la stessa cosa dovrebbero possedere cognizioni di semantica che al momento non hanno.
Spesso si richiede ai sistemi software che debbano contattare un servizio di determinarne il punto di accesso (endpoint) dinamicamente, a runtime. Questa richiesta si risolve con l’interrogare i registry UDDI mediante la chiave di un preciso servizio o mediante la chiave del tMoldel che raggruppa un certo numero di servizi e ne costituisce la firma (assicurandone l’uguaglianza del bindingTemplate).
Il caso di accesso diretto ad un servizio mediante la chiave può essere utile al fine di scongiurare eventuali cambiamenti di IP o path. Il caso di accesso dinamico ad un gruppo di servizi è invece utile a gestire (lato client) il failover, il bilanciamento del carico, l’invio di un messaggio a più destinatari, la ricezione di un messaggio da più sorgenti. Visto che almeno parte di questi problemi si possono risolvere con l’uso di strumenti già presenti in azienda (DNS, URL rewriter, virtual IP, …) è lecito chiedersi se e quando vale la pena di implementare la logica del discovery dinamico.
E’ chiaro che il registry UDDI come unico tenutario della totalità degli endpoint garantisca notevole coerenza e che l’uso di strumenti come depositari di parte delle URL contribuisca a creare il caos. D’altro canto per talune operazioni risulta più naturale impiegare strumenti specializzati. Può essere quindi utile indagare su ciascun caso.
Modifica dell’IP: assolutamente da risolvere con l’adozione di nomi DNS (da riportare sui WSDL e sul registry UDDI).
Modifica dei nomi DNS: assolutamente da proibire.
Modifica della path o della porta: assolutamente da proibire.
Modifica del provider JMS (qualora sia adottato): da risolvere in altro modo perché implica il deploy dei jar del nuovo provider ed il riavvio della virtual machine JAVA su cui è in esecuzione il consumatore (o l’intermediario).
Modifica del nome JNDI delle destinazioni JMS (qualora sia adottato): assolutamente da proibire.
Gestione del failover e bilanciamento del carico: per questo punto è necessario un discorso più articolato e precisare che si riferisce alla possibilità del consumer di poter invocare, in base a prederminate politiche, uno tra i possibili fornitori del medesimo servizio. La soluzione migliore a questo problema è quella di usare un intermediario nel quale implementare le logiche di interrogazione del registry UDDI, dell’estrazione degli endpoint e della decisione: uno strumento tradizionale come un virtual IP non essendo predisposto per queste operazioni richiederebbe la manutenzione manuale della lista degli endpoint. Da sottolineare, però, specie nel contesto di un enterprise, che la situazione di più fornitori che offrono il medesimo servizio sembra di difficile se non di dannosa attuazione: se accadesse sarebbe solo una duplicazione del servizio e la governance avrebbe fallito; se più istanze fossero offerte dal medesimo fornitore (magari da territori diversi) si tornerebbe nel caso in cui un unico endpoint dovrebbe essere esposto celando eventuali politiche di “prossimità”.
Invio di un messaggio a più destinatari (o ricezione da più sorgenti): il caso per cui il discovery dinamico costituisce la soluzione più elegante, con cui la variazione delle sorgenti o dei destinatari nel tempo non determina la necessità di modificare le configurazioni (a ciascun servizio deve essere associato un comune insieme di tModel che deve essere usato per l’interrogazione).
Il discovery dinamico, al fine di minimizzare l’overhead, implica l’uso di repliche “locali” del registry UDDI (operazione resa più agevole dalla versione 3.0 della specifica); questa strategia, inoltre, risolve il problema dell’unico punto di fallimento costituito dal registry centrale. L’impiego di cache (e delle relative politiche) migliora ulteriormente le performance.
—-><—-
Altre considerazioni:
In contesti ove si interagisce con componenti gestiti da partner o comunque sotto il controllo di “esterni”, il discovery dinamico è solitamente implementato. Questi rapporti, comunque, devono essere regolati da SLA (Service Level Agreement) che possono, benissimo, imporre regole sull’argomento rendendo il discovery dinamico un’inutile complicazione.
Il discovery dinamico, benché in alcuni situazioni possa costituire un elegante soluzione, va usato con parsimonia in quanto induce complessità e degrado delle performance.
—-><—-
Post di altri autori sullo stesso argomento:
—-><—-
Hai trovato questo post interessante? Sottoscrivi il feed completo e partecipa alla discussione
