Understanding WS-Discovery

Da oggi e per i prossimi mesi ogni tanto ospiterò dei post scritti da alcuni colleghi/amici di Microsoft affinchè possano raccontare un po’ della loro expertise e competenza tecnica ottenuta durante le tante attività di consulenza e di supporto sul campo. Ovviamente il tema sarà sempre inerente le architetture applicative e la sicurezza…

In questo post iniziamo con Alessio Mannelli (nella foto, l’unica decente che ho trovato :-)! 
Non è la prima volta che parla su questo “canale”… vi ricordate quell’Alessio Mannelli con il quale quasi un anno fa facemmo un video dove spiegava il funzionamento dei Security Token Services?? Ebbene si, è sempre lui :-) Alessio lavora nella divisione servizi in Microsoft Italia come Senior Developer ed oramai ha un pluriennale esperienza di implementazioni di soluzioni SOA nell’enterprise.

Quindi, non mi dilungo ulteriormente in ciancie e passo la palla ad Alessio per la prima puntata sulla specifica WS-Discovery che tra l’altro è appena stata rettificata come standard OASIS ed è presente nel framework .NET 4.0…

--Mario

La Missione

Tra le tante specifiche che regolano il variegato mondo dei Web Services WS-Discovery è sicuramente una delle più ambiziose:

definire un modello standard per la localizzazione di “servizi”, un modello per essere informati quando un nuovo “servizio” viene fatto partire e quando un “servizio” viene spento.

Un modello quindi per effettuare ricerche di “servizi” e recuperarne caratteristiche specifiche come gli endpoint con i quali è possibile dialogare con gli stessi, i protocolli utilizzabili, e molto altro ancora.

Il modello di Discovery è, o sta diventando, necessario in un mondo dove la “composabilità” delle applicazioni diventa asset fondamentale dell’ecosistema applicativo di una azienda; applicazioni dinamiche per loro natura che, semplicemente, è impossibile connettere a design-time oppure a deployment-time; c’è sicuramente necessità di un modello di “connessione” dinamica a runtime, un modello che valorizzi tutti gli asset di una azienda.

WS-Discovery è anche un facilitatore di scenari dove trovare ed utilizzare servizi all’interno o all’esterno dell’azienda diventa sempre più difficile; strutture verticali aziendali non allineate, poca (talvolta nessuna) Governance dei programmi e progetti in corso, molti fornitori, sono tra le problematiche più classiche che portano alla proliferazione e conseguente non riutilizzo di Web Service.

Per ultimo Discovery si pone l’obiettivo di abbracciare sempre più “elementi” non tradizionali di un modello di software a servizi: stampanti, device RFID, macchine fotografiche digitali, proiettori.

La possibilità di utilizzare un sistema leggero, dinamico, interoperabile per la costruzione di applicazioni composte e distribuite è fondamento della specifica WS-Discovery.

Un servizio “Discoverabile”

Per la specifica WS-Discovery ogni servizio viene identificato sulla base di quattro caratteristiche fondamentali:

- EndpointReference (definito in WS-Addressing)

Un indirizzo che identifichi univocamente il servizio specifico. L’indirizzo non deve essere per forza un indirizzo fisico, anzi la specifica consiglia l’utilizzo di indirizzi logici (eg. Un identificatore universale univoco, GUID, UUID)

- Types (definito in WS-Discovery)

Ogni servizio web implementa uno o più tipologie di portType, cosi come definito dalla specifica di WSDL 1.1: la nomenclatura utilizzata è di tipo Namespace:ServiceTypeName e quasi sempre viene inferita dalle specificità dei contratti implementati nei servizi.

- Scopes (definito in WS-Discovery)

Ogni servizio può identificare uno o più ambiti o contesti nei quali esiste o per i quali è stato configurato.

- XAddrs (definito in WS-Discovery)

Tutti gli indirizzi sui quali il servizio specifico è raggiungibile ed invocabile. Abbiamo quindi un modello per definire completamente uno specifico Servizio:

EndpointReference, l’identificatore univoco

• Types, le tipologie di “contratti” che il servizio implementa
• Scopes, i contesti applicativi del servizio
• XAddrs, gli indirizzi sui quali il servizio è raggiungibile ed invocabile.

<a:EndpointReference>
<a:Address>
uuid:98190dc2-0890-4ef8-ac9a-5940995e6119
</a:Address>
</a:EndpointReference>
<d:Types>i:PrintBasic i:PrintAdvanced</d:Types>
<d:Scopes>
   ldap:///ou=engineering,o=examplecom,c=usldap:///ou=floor1,ou=b42,ou=anytown,o=examplecom,c=ushttps://itdept/imaging/deployment/2004-12-04
</d:Scopes>
<d:XAddrs>https://prn-example/PRN42/b42-1668-a</d:XAddrs>

Il modello di Discovery

La specifica WS-Discovery definisce sei messaggi specifici:

- Hello/Bye – messaggi utilizzati da un servizio per annunciare la sua presenza (Hello) o la sua “dipartita” (Bye).

- Probe/ProbeMatch – Probe viene utilizzato per cercare uno specifico tipo di servizio, ProbeMatch viene utilizzato in risposta alla richiesta.

- Resolve/ResolveMatch – Resolve viene utilizzato per cercare una specifica istanza di servizio, ResolveMatch viene utilizzata in risposta alla richiesta.

Lo scenario di base prevede che i servizi annuncino la loro operatività e quando possibile il loro “scollegamento” dalla rete.(chiaramente nei casi in cui un servizio si spenga per casi eccezionali, difficilmente può inviare un messaggio di Bye, e la specifica non è giustamente prescrittiva in questo senso…)

Figura 1 : Hello e Bye Messages

In figura 1, viene rappresentato lo scenario di base dove l’ipotetico Client riceve i messaggi di Hello dai servizi WS1 e WS2 cosi come riceve il messaggio di Bye dal servizio WS3, il quale nel frattempo si è scollegato dalla rete. Il Client potrà quindi utilizzare le informazioni presenti nei messaggi di protocollo per selezionare il servizio da contattare, qual’ora, chiaramente, implementi le tipologie di servizio richieste.

Quando invece un Client si connette ad una rete, ed è interessato ad uno specifico servizio, può utilizzare i messaggi di protocollo Probe e/o Resolve:

Figura 2 : Probe/Resolve e ProbeMatch/ResolveMath Messages

In figura 2 invece il Client ricerca uno specifico servizio e solo due dei tre servizi presenti e connessi alla rete rispondo con un messaggio di Match. E’ da notare che, nello scenario definito, la richiesta di Resolve difficilmente verrà inviata: ricordiamoci infatti che Resolve serve per richiedere i dati di una specifica istanza di servizio, a differenza di Probe che ricerca istanze generiche che implementino specifiche tipologie di servizio. In questo caso il messaggio di Resolve potrebbe essere utilizzato nel caso in cui, dopo aver ricevuto un ProbeMatch alcune informazioni specifiche (tipo gli indirizzi per il dialogo) non fossero presenti.

Le modalità operative

Le modalità operative definite dalla specifica sono la “ad-hoc” e la modalità “managed” .

La modalità “ad-hoc” non utilizza nessun servizio di rete né server; i messaggi di Hello/Bye/Probe/Resolve vengono inviati in multicast (le relative risposte, dove necessarie, vengono inviate in modalità unicast al client che ha effettuato la richiesta).

La modalità “managed” è supportata da un servizio di rete, denominato Discovery Proxy, che funge da accentratore dei servizi presenti nell’ambiente, e che opera per conto loro nel rispondere alle richieste. Riprenderemo il concetto di Discovery Proxy in un prossimo post, poiché merita sicuramente un approfondimento.

Conclusioni

In questo primo post abbiamo solamente scalfito la superficie della specifica WS-Discovery: vi sono tutta una serie di concetti e di peculiarità proprie della specifica che verranno riprese nella prossima puntata.

Saluti,

Alessio Mannelli