Security & Architecture : Architetture applicative

Mettiamo un po’ di nuvole sotto l’albero

mfontana — Wed, 23 Dec 2009 07:04:20 GMT

Cosa mettere sotto l’albero di natale se non un po’ di risorse per tutti i gusti su Windows Azure Platform?

Come prima risorsa, senza dubbio, voglio segnalare il libro di Roberto Brunetti di Thinkahead (sito rigorosamente su Azure :-) dedicato a sviluppatori e progettisti che si avvicinano alla nuova piattaforma per il “cloud” per la prima volta.
Il libro infatti tratta in modo semplice e chiaro l’architettura e le tecniche per lo sviluppo di applicazioni accompagnando la teoria con esempi semplici di utilizzo dei servizi offerti.

L’ho letto in un baleno (non è il solito TOMO da 1000 pagine, ma bensì 220 pagine) e la cosa che mi ha colpito maggiormente è la semplicitià con cui Roberto introduce tutti gli argomenti (anche quelli meno ovvi e semplici)… in definitiva, un “must-have” per tutti coloro che vogliono capire come funziona il mondo e le architetture delle “nuovole”…

I temi principali trattati:

Introduzione al Cloud Computing;

Il sistema operativo Windows Azure;

Progetti hosted service e cloud storage;

Dettagli sull'accesso e organizzazione delle risorse;

Software Development Kit per Visual Studio;

Development Fabric e Development Storage;

La piattaforma e i servizi disponibili;

.NET Services Solution;

Service Bus;

Access Control;

SQL Azure.

Passando invece alle risorse on-line segnalo un bel post del mio collega Steve che ha fatto un’ottima catalogazione di vari link su Windows Azure suddivisi per

Business Content
Technical Content
Architectural Content
Developer Content

Buone feste tra le nuvole :-)

--Mario

Versione RTM di Windows Identity Foundation

mfontana — Thu, 19 Nov 2009 13:30:33 GMT

Durante la prima keynote del PDC 09 Bob Muglia ha annunciato la disponibilità di WIF (Windows Identity Foundation) in versione RTM !!!.

mentre qui Vittorio presenta il corso su Identity Developer Training Course su Channel9.

Forse è stato il passaggio da RC a RTM più veloce della storia del mondo MS :-) solo 11 giorni !!

--Mario

PS: sono di poche parole perchè sto preparando le 3 sessioni dei TechDays, guarda caso su Claims-Based Security e scenari federati ovviamente con WIF & C… presto nuovo materiale…

ARCast.TV : Michael Stiefel on Software as a Service in the Cloud

mfontana — Tue, 10 Nov 2009 05:26:00 GMT

Nuovo episodio della serie Architect Innovation Café sulle architetture SaaS in the Cloud. Un interessante video per capire meglio come approcciare allo sviluppo con Windows Azure.

ARCast.TV Special - Michael Stiefel on Software as a Service in the Cloud

Windows Identity Foundation - Scaricate La Release Candidate !!

mfontana — Mon, 09 Nov 2009 14:14:17 GMT

Da tempo si era detto che Geneva Framework si sarebbe chiamato WIF (Windows Identity Foundation) ed ora finalmente ci si può lavorare con la versione RC scaricandola da qui.

Maggiori dettagli sull’annuncio sul blog di team.

Vittorio invece ci ricorda che a fronte della versione RC di WIF sono stati aggiornati l’ Identity Training Kit, il sample FabrikamShipping e il controllo Claims-Driven Modifier Control.

Infine mi aggrego anch’io sempre a Vittorio consigliando di visionare il breve video (circa una mezzoretta) sulle novità della versione RC direttamente dal team di sviluppo ovviamente su channel9.

Buona visione!

--Mario

The Architecture Journal : Model-Driven SOA with “OSLO”

mfontana — Tue, 03 Nov 2009 19:46:40 GMT

Da vari mesi incontro clienti che vogliono saperne di più su “OSLO”…
In un contesto MDA (Model-Driven Architecture) consiglio il seguente articolo comparso poco tempo fa su The Architecture Journal dal titolo esplicativo…

Summary: Service-oriented architecture (SOA) must evolve toward a more agile design, development, and deployment process. Most of all, it must close the gap between IT and business. This article presents a map between modeling theory (model-driven development and model-driven SOA) and possible implementations with the next wave of Microsoft modeling technology, codename “Oslo.”

Article : http://msdn.microsoft.com/en-us/architecture/aa699436.aspx

--Mario

CxO Level Discussion about Cloud Computing

mfontana — Mon, 26 Oct 2009 10:00:00 GMT

Interessante l'intervista al mio amico Miha (guru nel mondo delle architetture) sul cloud computing e l'impatto nelle architetture applicative...

What are the business considerations of risks and benefits when considering cloud computing options, strategies, and trends? Check out this discussion between Miha Kralj and Zhiming Xue.

ARCast.TV - CxO Level Discussion about Cloud Computing

--Mario

Microsoft Federation Gateway

mfontana — Thu, 15 Oct 2009 04:55:00 GMT

L’amico Vittorio ha pubblicato un nuovo episodio della ormai famosa serie “The Id Element” :-)

Jorgen Thelin, Senior Program Manager, looks after key identity services in Microsoft such as Windows Live ID and the Microsoft Federation Gateway (MFG).

In today's interview Jorgen describes the role of MFG, and touches on the many wonders it enables: using AD accounts to SSO (single sign on) access to Microsoft Business Online Services such as Dynamics CRM, allowing the 550 million owners of a Live ID account to gain access to your federated applications developed with Windows Identity Foundation, and much more.

Iniziano gli Architect Innovation Café

mfontana — Wed, 14 Oct 2009 04:55:00 GMT

Cari architetti IT da questo mese (27 e 28 Ottobre) fino a Giugno 2010 inizia una serie di webcast dedicati agli architetti. Questa tipologia di webcast ha lo scopo di aiutare chi fa il lavoro di architetto IT nel capire i nuovi trend di mercato, le nuove tecnologie e come quest’ultime possano integrarsi con le esigenze del proprio business.

Ogni webcast sarà comunque registrato e disponibile per il download. Potete trovare la programmazione al seguente link : http://blogs.msdn.com/sac/pages/architect-cafe.aspx.

Each month through June 2010, we’ll bring you a 90-minute Architect focused Webcast to educate on the latest trends/topics and how new technologies can align with your business needs.

October 27, 2009 at 11:00am – 12:30pm PST

Title: An Architect’s perspective on Silverlight 3

Presenter: Tim Heuer

Abstract: Many .NET developers are becoming more and more interested in the Rich Internet Application development space, and in particular Silverlight. In this session we will step back from a detailed implementation technology and take a higher level look at Silverlight from the architect’s perspective. We will discuss the types of applications where Silverlight makes sense and some scenarios where Silverlight may not be the appropriate technology. We will also delve into some of the architectural decisions that the architect must consider when writing applications for this platform and where some of the tradeoffs may lie.

Event ID: 1032427862

Link to Register: An Architect’s perspective on Silverlight 3

October 28, 2009 at 11:00am – 12:30pm PST

Title: Deploying Windows 7 from an Infrastructure Architect’s Perspective

Presenter: Doug Klokow

Abstract:

We’ll discuss 5 key areas centered on deploying Windows 7: Developing business justification – Evaluate the capabilities provided by Windows 7 and develop a plan for how to realize business value from these solutions; Where are you today – Explore the differences of preparing for Windows 7 based on your current desktop operating system; Application readiness – Explore the tools and resources available to gain insight into your readiness to deploy Windows 7, Internet Explorer 8, and/or Office 2007/2010; Deployment readiness – Explore the tools and resources available to create a design and deployment solution for your enterprise; Training your employees – Discuss available resources for training your IT Staff and End Users.

Event ID: 1032427863

Link to Register: Deploying Windows 7 from an Infrastructure Architect’s Perspective

SPEAKER BIOS

Tim Heuer

I currently work for Microsoft as a program manager for Microsoft Silverlight, a web technology aimed at delivering rich internet experiences to users. Before this current role, I was a developer evangelist for Microsoft serving the Arizona, Nevada, New Mexico, Colorado, Montana and Utah areas aiming to strengthen and support communities and software developers in these geographies.

Doug Klokow

Part of Microsoft Consulting Services for 9 years focused on client desktop deployment solutions. He is part of the Virtual Deployment Practice that is focused on driving early customer deployment on Microsoft client technologies and is also supporting Microsoft’s Desktop Virtualization capabilities and service offerings.

Re-Architecting Applications for Internazionalization

mfontana — Tue, 13 Oct 2009 20:37:00 GMT

18 min video !

IF you are interested to know how to plan and get started with the process of internationalizing applications, how applications are typically re-architected for internationalization, what tests are conducted once they are internationalized, and what tools and resources are available to facilitate application internationalization, this video is made for you.

--Mario

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

Video intervista : Cloud Computing e Windows Azure secondo David Chappell

mfontana — Tue, 30 Jun 2009 15:41:45 GMT

Segnalo questo nuovo breve video (14min circa) su Channel9 dove David parla del Cloud Computing e di Windows Azure.

mentre qui potete trovare il suo whitepaper sempre sul tema Azure Services Platform.

--Mario

L' Application Security è indietro 10 anni rispetto al Software Development ?

mfontana — Tue, 16 Jun 2009 08:01:00 GMT

“In evolutionary terms, the information security field is more than a decade behind software development” con queste parole inizia un interessante articolo di Gunnar Peterson dal titolo “Service-Oriented Security Indications for Use”. In sistesi Gunner sostiene che a partire dagli anni 90 abbiamo assistito a molteplici evoluzioni nel campo del software development mentre in ambito security siamo rimasti pressochè fermi, immobili.

Io mi trovo pressochè d’accordo con lui anche se man mano proseguivo nella lettura dell’articolo le ragioni del mio essere d’accordo divergevano sempre più da quelle presentate da Gunner. Mi spiego meglio.

In sintesi Gunner sostine cha se dal lato applicativo c’è stata una forte evoluzione partendo dagli anni 90 con lo sviluppo delle prime Web Applications con CGI, passando poi per l’era ASP/JSP, le 3-tiers Apps nel 1998 per arrivare agli anni 2000 dove si inizia a progettare con SOAP, XML e REST per arrivare agli albori del Web 2.0, dal lato security non siamo mai andati oltre i firewalls e SSL. Su questo sono d’accordo anche se a mio avviso è necessario fare un ulteriore distinguo tra le definizione di standard per la sicurezza e relativa adozione di quest’ultimi da parte dell’industria per capire meglio il fenomeno. Infatti non è vero che lato security non c’è stata innovazione!

Tra il 2001 e il 2002 sono comparsi i primi draft delle specifiche che volevano andare oltre la sicurezza del protocollo SSL e di infrastruttura (comunque lato sicurezza applicativa i firewall erano già bypassati con l’introduzione di SOAP/XML, fino alla comparsa delle prime versioni capaci di fare content control su formati XML based). Nacque il così detto stack WS-* ovvero l’insieme di tutte quelle specifiche dedicate prevalentemente al mondo dei Web Services (non solo in ambito Security) e che oggi si riconoscono perchè iniziano tutte con WS- !!

Quindi già dai primi anni del nuovo millennio abbiamo assistito alla comparsa di specifiche che volevano in qualche modo superare i limiti imposti da SSL e indirizzare il problema della sicurezza nel messaggio non solo tra due end-point ma fino al raggiungimento del destinatario finale. Questo scenario diventò sempre più importante in scenari SOA dove la sicurezza è o dovrebbe essere gestita più da un punto di vista delle operations che tecnologico e dove i servizi possono essere distribuiti in security context diversi e/o geograficamente. Una breve analisi del concetto di infrastruttura applicativa a servizi e relativi modelli di autenticazione li potete trovare in questi post : cosa intendiamo per infrastruttura applicativa, autenticazione a livello di canale, autenticazione a livello applicativo, autenticazione a livello di messaggio. Già a partire da Dicembre 2002 con WSE 1.0 (per chi lavorava in ambito .NET) erano a disposizione di architetti e developers i primi bit per disegnare e soprattutto implementare scenari basati su queste nuove specifiche (WS-Security, WS-Routing (ora chiamata WS-Addressing) e poco più.

Questo lato innovazione. Lato adozione lo scenario è effettivamente diverso; tali innovazioni non furono prese molto in considerazione per vari motivi (novità, poca esperienza, pigrizia (tanto c’era SSL) e a mio avviso perchè negli anni le vere potenzialità che possono fornire le architetture a servizi come SOA/EDA sono sempre state sottovalutate. Personalmente lavoro con le specifiche WS-* dalla primissima BETA di WSE (Luglio/Agosto 2002) e ho realizzato molte soluzioni in ambito Enterprise e posso riassumere la mia esperienza in questo modo:

le competenze sui patterns di sicurezza in ambito SOA sono conosciuti e adottati in bassissima percentuale nella fascia dei grandi clienti e quindi non mi meraviglio che in scenari meno enterprise non ci sia traccia di sicurezza se non con firewalls e SSL. Questo almeno fino ad un paio di anni fa.

Fortunatamente questo scenario sta cambiando… l’adozione di patterns per la federazione via WS-Federation e SAML 2.0 Protocol oltre i modelli basati sulla Claims-Based Security ne sono una conferma. Anche in questo caso però sto notando una adozione prima da parte delle aziende ed enti pubblici e poi man mano in scenari sempre meno Enterprise. Personalmente conto molto sulla “democratizzazione” di questi aspetti di security con il Cloud Computing perchè diventa (fortunatamente) sempre più difficile realizzare soluzioni silos e totalmente custom dove al contrario gli aspetti di interoperabilità, sicurezza e distribuzione geografica sono un must fin dalle prime fasi della progettazione!!

Altro ambito in cui negli ultimi anni sto iniziando a vedere un discreto aumento di sensibilità in tutti i settori del mercato IT è quello legato alle best practices sullo sviluppo di codice sicuro. Da qui l’adozione di modelli derivanti dal SDL – Security Development LifeCycle – (ad esempio qui trovate i tool per integrare i principi del SDL con i vari aspetti dell’ ingegneria del software via Visual Studio Team System) e degli sforzi di OWASP – Open Web Application Security Project - per rendere esplicite le best practices in questo ambito.

Quindi tornando all’articolo in oggetto non credo che il mondo della sicurezza sia stato alla finestra a guardare il resto dell’ IT che si evolveva restando inerte. Credo invece che l’intriseca fatica nel capire le evoluzioni in ambito sicurezza legate alla complessità dei nuovi scenari architetturali abbia di fatto rallentato se non fermato per anni l’adozione in ambito IT. Da qui il mio essere d’accordo con l’articolo ma per ragioni diverse.

Mi piacerebbe molto sapere cosa ne pensate :-)

--Mario

Nuovi Samples con la CTP3 di “Velocity”

mfontana — Wed, 10 Jun 2009 18:37:19 GMT

“Velocity” è il codename di un sistema distribuito di in-memory caching molto utilie nel disegno di applicazioni capace di mettere in share qualsiasi tipo di oggetto (CLR, rows, XML, binari, ecc…). L’architettura di Velocity permette quindi di “condividere” la memoria tra macchine fisiche dando al client l’impressione di accedere ad una singola cache.

Per chi vuole una presentazione più completa di Velocity può iniziare da questo post sul blog di team.

Detto questo, oggi sono disponibili nuovi samples dedicati alla CTP3 che si possono scaricare da codeplex.

--Mario

Microsoft Enterprise Service Bus (ESB) Guidance 2.0

mfontana — Wed, 10 Jun 2009 08:00:00 GMT

Chi sa esattamente e senza ombra di dubbio cosa è un ESB - Enterpise Service Bus - alzi la mano… perchè io non la alzo proprio :-). Non so se vi è mai capitato di leggere le definizioni di ESB proposte da vari vendor. Spesso sono tutte molto, ma molto differenti l’una dall’altra. Questo è dato dal fatto che la maggior parte dei vendor hanno adattato la definizione di ESB alle proprie esigenze e soprattutto agli aspetti e alle architetture dei propri prodotti di EAI (Enterprise Application Integration) per riproporli nell’era delle SOA (Service Oriented Architecture) .

Detto questo, facendo un minimo comune divisore tra le mille definizione un ESB, in una architettura SOA, rappresenta una infrastruttura (a servizi) dedicato ai Message Transportation Patterns come ad esempio il Message Broker pattern, Message Filter pattern, Message Translator pattern, Content Enricher pattern e Protocol Adapter pattern, ecc… Infatti nelle attuali SOI (Service Oriented Infrastructure) un ESB deve garantire il “message flow” corretto tra servizi eterogenei e interfacce che magari nel tempo possono non essere più facilmente allineate.

Questo è il motivo per cui Microsoft fino alla comparsa di WCF non ha mai parlato espressamente di ESB.

Ma allora perchè Microsoft ha associato la guidance a Biztalk ?

Perchè Biztalk è grado fin dalle prime versioni di gestire il message routing ma è solo con l’integrazione di WCF che Biztalk (o meglio parte di Biztalk) può essere considerato e gestito come un ESB.

La guidance 2.0 comprende le seguenti macro funzionalità :

Endpoint run-time discovery and virtualization
Loosely coupled service composition.
Dynamic message transformation and translation.
Dynamic routing
Centralized exception management
Quality of service
Protocol transformation
Extensibility

Le principali informazioni per architetti e sviluppatori la potete trovare aqui sul BizTalk Developer Center mentre la guidance può essere scaricata al Download Center.

Comunque io, quando penso all’ ESB, la prima cosa che mi viene in mente è questa …

CIN-CIN ALLA VOSTRA … !! :-) :-) :-)

--Mario