Security & Architecture : .NET 4

WS-Discovery enhanced

mfontana — Tue, 13 Oct 2009 07:23:42 GMT

Continua la saga su WS-Discovery scritta sempre da Alessio Mannelli. Per chi si fosse perso la prima puntata può leggerla qui.

Recap

Ben ritrovati in questa serie di post dedicati alla specifica WS-Discovery. Nella puntata precedente abbiamo fatto conoscenza del modello, dei messaggi e delle interazioni basiche fondamento della specifica.

Abilitare scenari di composizione dinamica, sia a design-time, ma soprattutto a runtime, sono il fulcro alla base della specifica.

In questa nuova puntata andremo a conoscere il supporto di rete previsto in WS-Discovey, il Discovery Proxy, come gestire il concetto degli Scopes, ed introdurremmo gli scenari applicativi che implementeremo nella prossima puntata della serie WS-Discovery.

Supporto di rete

Abbiamo già visto nella prima puntata le due modalità operative presenti in WS-Discovery, ad-hoc e managed. La prima si basa completamente sullo scambio di messaggi in Multicast per tutte le peculiarità di Discovery (Hello/Bye/Probe/Match e relative *Resolve), la seconda si basa sulla presenza di un servizio di rete, denominato Discovery Proxy, al quale inviare i messaggi di ricerca (Probe e Resolve).

La specifica identifica le seguenti definizioni per l’invio di messaggi in multicast:

· DISCOVERY_PORT: port 3702

· IPv4 multicast address: 239.255.255.250

· IPv6 multicast address: FF02::C (link-local scope)

I messaggi multicast devono essere inviati utilizzando SOAP over UDP.

Quando la modalità operativa utilizzata è quella ad-hoc, tutti i messaggi di richiesta devono essere inviati come sopra definito, mentre tutte le risposte verranno inviate in unicast al client che ha inviato i messaggi. Per comunicare in unicast verso il client vi sono due possibilità:

· Il client aggiunge un indirizzo di risposta sfruttando l’header di Addressing ReplyTo .

· Il server utilizza l’indirizzo IP e la porta sorgente della connessione UDP ricevuta per rispondere al client.

Nella modalità operativa managed il client dialoga con il Discovery Proxy in unicast, sia in richiesta che in risposta.

Client e Discovery Proxy

Il Discovery Proxy, come già descritto, è alla base della modalità operativa cosiddetta managed.

Un client, se non diversamente istruito, si trova normalmente in un stato nel quale non conosce Discovery Proxy; è possibile, chiaramente che riceva un Hello dal Discovery Proxy, riconoscibile da uno specifico Service Type che lo contraddistingue (d:DiscoveryProxy) nel qual caso modificherà radicalmente il modo con il quale invia richieste di Probe e Resolve, secondo il diagramma a stati sotto descritto:

Quindi, una volta che il client si trova a conoscere un Discovery Proxy comunicherà con lo stesso in modalità unicast, evitando quindi di congestionare la rete con messaggi in multicast.

Un DiscoveryProxy, di contro, quando riceve un messaggio di Probe o Resolve in multicast è tenuto a spedire subito un messaggio di Hello (in multicast a sua volta): questo particolare messaggio modifica lo stato dei client in modo tale che utilizzino solamente i Discovery Proxy di cui si fidano, ed ingnorino di contro i messaggi in multicast dei Target Service.

A questo punto sia i Client che i Target Service indirizzeranno le loro comunicazioni (di ricerca, per il client, di connessione/disconnessione dalla rete, per i servizi) al Discovery Proxy. Eventualmente i messaggi di connessione/disconnessione (Hello/Bye) potranno essere inviati ancora in multicast, da parte dei Target Service: il loro peso specifico è talmente basso, cosi come il numero di messaggi inviati, da essere praticamente trascurabili in uno scenario reale.

Tra i vantaggi di avere un’infrastruttura di Discovery managed vi è anche la possibilità di scavalcare il limite di utilizzo delle comunicazioni multicast (overhead di gestione del routing del protocollo fra tutti): inserire alcuni Discovery Proxy tra le varie sottoreti, e sfruttare il modello di discovery, può portare ad allargare gli orizzonti del proprio ambiente operativo.

In questo modo i client possono trovare ed utilizzare servizi non presenti nelle loro sottoreti, senza rendere difficoltosa la gestione dell’infrastruttura.

Scopes

Come già accennato, gli scopes, di seguito indicati anche come “ambiti”, possono caratterizzare un servizio nel mondo di WS-Discovery. La specifica identifica solamente i metodi specifici con i quali un Target Service deve confrontare i suoi ambiti, con quelli richiesti dal messaggio di Probe ricevuto, per rispondere, eventualmente, con un messaggio di Match (Probe o Request). Ripetiamo la lista dei modelli di confronto utilizzabili, per riferimento:

· http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/rfc3986

· http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/uuid

· http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/ldap

· http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/strcmp0

· http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/none

Per maggiori informazioni sugli stessi il capitolo 5 della specifica entra nei dettagli di ogni modello.

Scenari applicativi di utilizzo di WS-Discovery

Fino a qui abbiamo praticamente visto tutti gli aspetti peculiari della specifica WS-Discovery, cerchiamo adesso di focalizzare l’utilizzo della stessa nel mondo reale, proponendo alcuni scenari che normalmente si propongono in un ambiente orientato ai servizi, e che elaboreremo nella prossima puntata:

1. Ricerca a runtime di un servizio che implementa l’interfaccia che ci interessa.

2. Ricerca a runtime di un servizio che, oltre ad implementare l’interfaccia richiesta, è configurato con uno scope specifico.

Il primo scenario è il più frequente in ambito composizione : configurazione degli indirizzi fisici utilizzati dai servizi nei diversi “ambienti operativi” nei quali l’ applicazione verrà eseguita (sviluppo, pre-produzione, produzione e chi più ne ha più ne metta). Il vantaggio che deriva dall’utilizzo di WS-Discovery come asset fondamentale di tutti i servizi e le applicazioni è evidente: ad ogni modifica di “ambiente operativo” l’applicazione ricercherà il servizio specifico ed utilizzerà l’indirizzo recuperato a runtime per il colloquio.

Chiaramente vi possono essere degli accorgimenti capaci di evitare il “dispendio” di messaggi che la ricerca di un’istanza di servizio può aggiungere all’economia del colloquio applicazione – servizio. Talvolta il peso è trascurabile, quando ad esempio il client ha un ciclo di vita molto elevato, tale per cui il peso aggiunto diventa infinitesimale rispetto al resto del peso di comunicazione; altre volte invece è necessario salvare l’indirizzo del servizio recuperato tramite utilizzo di WS-Discovery per poi riutilizzarlo al riavvio dell’applicazione. In questo modo vi è la possibilità che il servizio recuperato in precedenza non sia più “vivo”, nel qual caso si potrà procedere con una nuova interazione Probe – ProbeMatch.

Il secondo scenario è il più “ambizioso” in determinati contesti. Ipotizziamo di avere alcune istanze di uno specifico servizio, distribuite in modo tale da coprire più segmenti della topologia di rete in esame. Per esempio potremmo avere un servizio locale su una macchina, un servizio su una LAN particolare , ed un servizio al centro. Tutti e tre i servizi implementano la stessa interfaccia e gestiscono gli stessi dati ma, data la loro differente collocazione geografica hanno uno SLA (service level agreement) diverso a seconda dei dati che vengono richiesti.

Facciamo un esempio : il servizio locale alla mia macchina avrà lo stato completo dei dati che si generano dalla macchina stessa, il servizio interno alla LAN ha lo stato completo dei dati che si generano all’interno della LAN stessa, e per finire il servizio al centro ha lo stato completo dei dati che si generano fuori dal contesto applicativo specifico. Ogni “livello” diverso si sincronizza e coordina con gli altri tramite un ulteriore flusso dati (che non analizziamo) che rende possibile, con tempi diversi, l’allineamento dei dati su tutte le istanze del servizio ipotizzato.

A questo punto l’applicazione deve capire se e come le tre diverse istanze di servizio possono aiutarlo nell’esecuzione delle sue funzioni. In alcuni casi un servizio fisicamente “vicino” al client può essere un aiuto, se non altro per il ridotto round trip di rete dell’invocazione. Altrimenti, se l’applicazione capisce di avere necessità di dati con specifico SLA può ricercare uno dei servizi specifici.

Bene, l’utilizzo degli scopes, in questo caso, è l’ausilio tecnico alla problematica. Ogni diversa istanza di servizio viene configurata in diversi ambiti (scopes, per l’appunto). In contesti gerarchici, come l’esempio illustrato, gli scopes possono essere definiti con una convenzione come la seguente:

· Servizio al centro rende disponibile lo scope http://ROOT

· Servizio di “filiale” rende disponibile lo scope http://ROOT/BRANCH

· Servizio locale rende disponibile lo scope http://ROOT/BRANCH/MACHINE

In questo scenario si possono poi utilizzare diverse tipologie di confronto tra gli scopes: la tipologia di esatta comparazione delle stringhe, ad esempio, restituirà solo uno delle tre istanze di servizio, piuttosto che la versione RFC3986, la quale restituisce una istanza se almeno uno dei sotto livelli della risorsa richiesta è confrontabile con quello richiesto; in questo caso se chiedo lo scope ROOT, tutti e tre i servizi dell’esempio risponderanno con i loro dettagli.

Tutto dipende da quali sono le necessità applicative, ma le prospettive offerte dall’infrastruttura sono molto interessanti, e flessibili.

Conclusioni

Con questo secondo post abbiamo esaurito l’overview della specifica, e definito alcuni scenari che reputo interessanti e che saranno la base del terzo ed ultimo post della serie WS-DISCOVERY. Analizzeremo l’implementazione di WS-Discovery inserito nella nuova versione del .Net Framework 4.0, attualmente in versione Beta, e realizzeremo gli scenari proposti. Per avvantaggiarvi vi consiglio di leggere e sottoscrivere http://blogs.msdn.com/discovery/, ne avremo bisogno!

A presto,

Alessio

Understanding WS-Discovery

mfontana — Thu, 23 Jul 2009 20:04:02 GMT

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=us
   ldap:///ou=floor1,ou=b42,ou=anytown,o=examplecom,c=us
   http://itdept/imaging/deployment/2004-12-04
</d:Scopes>
<d:XAddrs>http://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

.NET 4.0 BETA 1 e WS-Discovery

mfontana — Mon, 20 Jul 2009 17:14:25 GMT

WS-Discovery è diventato standard OASIS come specificato nel blog di team.

Ma la cosa, forse, più interessante è che la BETA 1 del framework .NET 4 comprenderà già i bit della specifica OASIS!!

Per maggiori informazioni su WS-Discovery e l’importanza che anche questa specifica ricopre nel mondo dei Web Services vi rimando a “tra poco” con un post dell’ amico Alessio Mannelli sempre su questo canale !!!

Stay tuned :-)

--Mario

David Chappell in : Windows Workflow Foundation 4, Oslo e Dublin

mfontana — Tue, 28 Oct 2008 00:04:36 GMT

Non poteva mancare il nuovo whitepaper di David Chappell su alcune delle novità introdotte oggi al PDC...WF 4.0, Oslo e Dublin... A mio avviso non c'è fonte più chiara di David per introdurre queste nuove tecnologie :-)

Workflows, Services and Models - A First Look at WF 4.0, "Dublin", and "Oslo".

--Mario