Web Services
Nel precedente post ho parlato della lacuna della definizione del contratto nel mondo ROA rispetto al mondo SOA. E' bene che faccia qualche precisazione, ma prima di parlare di questo fatemi fare un escursus sul concetto di contratto e come questo si applichi oggi nel mondo SOA (Service Oriented Architecture).
Se chiediamo ad un avvocato di scrivere un contratto, garantendo un certo introito :-), ci innondera' sicuramente di domande e probabilmente scrivera' 40/50 pagine di documento dove ogni singola parola ha un suo peso specifico. In sostanza la regola e', ogni aspetto non 'normato' o definito rappresenta un threat.
In ambito IT...
ROA sta per Resource Oriented Architecture e si contrappone sotto molti punti di vista a SOA, cioe' Service Oriented Architecture.
In realta' non c'e' un modello migliore dell'altro e so potrebbe tranquillamente affermare che un 'servizio' e' necessario per creare una 'risorsa' ed una 'risorsa' e' necessaria per fornire un 'servizio'. Ciononostante possiamo altresi' affermare che il contesto delle risorse e' decisamente predominante.
Quali sono le caratteristiche di ROA:
Addressability: intesa come capacita' di identificare una risorsa addraverso uno URI ben definito
Statelessness: mancanza di supporto nativo per la gestione dello stato
Connectedness:...
Quando parlo di classe proxy immagino il mondo dei web services ed in particolare il lato client. E' una assunzione assolutamente imprecisa, ma lasciatemi questa piccola deformazione professionale :-)
Detto questo, molto spesso chi consuma web services utilizza nel proprio codice direttamente il servizio e le entità ad esso associate. Vediamo un esempio, il mio web method ritorna un'entità Ordine. Ho tre possibilità:
Uso l'Ordine del mio codice (lato client)
Crea una mia classe ordine mappata sull'Ordine ritornato dal web service
Creo una mia classe ordine partial di Ordine
La prima soluzione è la peggiore perchè solitamente il codice generato dal wsdl.exe (o add...
Quando si parla di scalabilità di un sistema software tutti pensano alle prestazioni. In realtà la scalabilità è un concetto un pò più ampio ed include certamente anche la scalabilità temporale (conosciuta sotto certi versi anche come versioning). Garantire la scalabilità delle nostre applicazioni dal punto di vista delle prestazioni non è una cosa molto difficile, basta conoscere bene la piattaforma tecnologica e sfruttarla al meglio. La scalabilità temporale invece richiede un esercizio un pò più complesso che spesso va al dilà del concepire correttamente i namespace XML oppure gli strong names per gli assemblies. Alex Krapf introduce bene il...
WCF rappresenta senz'altro un salto in avanti molto importante per lo sviluppo di applicazioni enterprise. Infatti va tenuto presente che WCF porta con sè una innumerevole quantità di servizi che sino ad oggi sono implementati con ASP.NET web services, System.Messaging (MSMQ), .NET Remoting, Web Services Enhancement (WSE) e Enterprise Services (COM+).
Data la portata del 'cambiamento' abbiamo pensato bene di confezionare una 3 giorni full immersion su WCF illustrandone quelle che sono le potenzialità, come funziona, come si progetta con WCF, come si implementa con WCF, il porting dalle attuali tecnolgie e così via. Non vogliamo fare il ricettario (se...
L'affidabilità nei web services vuol dire molte cose. Una delle più importanti è sicuramente la certezza della recapitazione del messaggio anche in caso questo messaggio sia partizionato in più parti.
Come consuetudine ogni cosa nel mondo "web services" deve essere regolamentato, per ovvi motivi di interoperabilità. Questo dell'affidabilità non fa eccezzione ed ecco quindi che abbiamo OASIS che si occupa del caso WS Reliable Exchange. Questa specifica nasce un pò da WS-ReliableMessaging e un pò da WS-Reliability e vede insieme sia SUN che Microsoft (fra gli altri).
Fatta questa doverosa premessa, volevo concentrarmi sull'implementazione. WCF implementa il protocollo WS-ReliableMessaging e ci...
Chi sviluppa web services avrà riscontratto che sebbene le tecnologie di base (XML, HTTP, SOAP, WSDL, ecc.) siano nativamente interoperabili, è bene ricordare che le nostre scelte sul type system del messaggio si riflettono sul'interoperabilità. Mi viene in mente, ad esempio, l'uso del DataSet nel messaggio (poco interoperabile).
Un interessante punto di riferimento lo troviamo qui.
SOA si basa essenzialmente su 4 principi fondamentali (Policy-Based Behavior Negotiation, Explicitness of Boundaries, Autonomy e Contract Exchange). All'interno di questi punti si cela il problema dell'identificazione delle entità fra i servizi 8senza ovviamente richiedere la duplicazione delle informazioni).
Vediamo un esempio concreto. Immaginiamo di avere un servizio dei contatti ed un al'tro di processazione ordini. Si immagina pertanto che il servizio degli ordini abbia in qualche modo un riferimento alle informazioni dei clienti (contatti). Ma quale informazione ?
Basterebbe avere un identificativo univoco, che permetta al servizio degli ordini di cercare puntualmente un determinato cliente. Se andiamo a guardare come censiamo...
Sin dalle prime versioni di Visual Studio Team System (parlo della beta 1) ho notato una grossa mancanza: un test type dedicato ai web services. Ho sempre pensato (sperato) che prima o poi l'avrebbero introdotto, ma ahimè siamo arrivati all'RTM e niente.
Quindi, la mia scelta è caduta sullo Unit testing. Perchè unit testing ? Semplice, la classe proxy (del web service) è una classe che può essere testata come un OM, al pari di qualsiasi class library.
Nota: E' importante ricordare che se volete il supporto dei wizard per la generazione automatica dello scheletro delle test classe e test methods dovete...
Durante l'ultimo workshop UGI ho presentato una slide con le tecnologie (librerie, framework, servizi) Java e .NET dedicate al mondo dei web services. Ho anche affermato che è bene mantenerle aggiornate pur verificando sempre la compatibilità fra gli aggiornamenti (es. WSE 2.0 e WSE 3.0). Christian ha postato un censimento delle librerie e gli standrd da tenere sempre sott'occhio.
WSE 3.0 arriverà fra circa 2 mesi. L'ultima CTP disponibile è quella di ottobre. Ma quali sono le novità ? Mark Fussel le ha elencate.
Questa è una domanda che spesso viene posta quando ci si trova in zona 'messa in produzione'. Una buona risposta la trovate nella knowledge base dell'MSDN.
Quando vediamo presentazione/demo/articoli sui web services questi sono sempre (o quasi) basati sul pattern di messaggistica request/reply. Si dimentica in molti casi il pattern oneway (tralascio di proposito il duplex). Perchè ?
Secondo me c'è un vero e proprio abuso della risposta. Se sottomettiamo una richiesta d'ordine, creiamo un nuovo contatto nel nostro CMS, sottoponiamo una richiesta di preventivo, ci accorgiamo che spesso questi sono eventi per loro natura asincroni, e allora perchè ci aspettiamo una risposta ? Risposta di che ? Per dire che è stato ricevuto ? Ma se è stato ricevuto (quindi nessun errore di protocollo/canale), chi ci garantisce...
Le statistiche mondiali ci dicono che nei prossimi anni il mondo enterprise userà al 95% sia Java che .NET. L'installato attuale prevede Java, .NET, COM/COM+, .... Far dialogare questi mondi divene sempre più un asset. Ci sono tanti modi per interoperare ed i web services ne sono un esempio.
Il 12 e 13 ottobre UGI organizza un workshop dedicato alla migrazione ed all'interoperabilità. Oltre agli altri valorosi relatori (Andrea, Lorenzo, Mario, Raffaele e Silvano) ci sarò anch'io a proporre una sessione sull'interoperabilità utilizzando i web services.
Sebbene la scelta su .NET e COM/COM+ sia abbastanza univoca, mi piacerebbe sapere che cosa usate (o pensate...
WSE (Web Services enHancements) è ora disponibile in technology preview anche per il framework 2.0. Potete scaricarla gratuitamente dal sito msdn.
Tradurre "dimmi chi sono" in termini informatici significa parlare di identità digitale. Ognuno di noi ha ben più di una identità digitale, quella per accedere al PC di casa, quella per l'ufficio, per il POS della banca, per MSN Messenger, ecc. ecc. Le nostre identità digitali sono veramente tante e spesso è problematico gestirle tutte.
Microsoft ha provato a centralizzare le nostre identità fornendo un servizio chiamato Passport. Ha avuto successo ma solamente per i servizi strettamente legati a Microsoft (Messenger, MSDN, ecc.). Ovviamente non mi sognerei mai di lasciare l'identità digitale che uso per il mio home bancking a Passport...
WS-Management (ultima release febbraio 2005) è una delle pochissime specifiche che coinvolge sviluppatori, sistemisti e hardwaristi (scusate le localizzazioni). Si tratta infatti della possibilità di interagire sui sistemi via remoto (o anche locale) mediante uno standard unico ed approvato da molti (Microsoft, SUN, Dell, Intel,...). L'aspetto interessante è che la prossima release di Windows 2003 (R2) supporterà le specifiche ...
Le specifiche dei web services ono in costante evoluzione, è allora comodo avere sottomano un grafico che ci tenga aggiornati :-)
Ha già qualche mese, ma rimanendo in tema dell'ultimo workshop non potevo non pubblicare la referenza :-)
Durante il VSLive di febbraio si è parlato molto di Indigo, definito come il nuovo sistema di comunicazione proposto da Microsoft. Per chi non ha potuto partecipare alla conferenza, ecco alcuni video...
WS-Eventing è una specifica che definisce il pattern di messaggistica publish/subscribe. Non essendo rattificata da alcun ente 'terzo' non so dire se rimarrà così oppure verranno apportate modifiche, ma rimane comunque una specifica interessante per chi deve gestire questo tipo di problematica (meglio una spefica che niente, no?). Bruce Williams ha scritto una serie di blog in tre parti (parte 1, parte 2 e parte 3) dove illustra in maniera molto semplice la specifica.
Ieri ho annunciato l'arrivo della SP2 di WSE. Preso dalla curiosità, ho creato un banale web service in Visual Studio .NET 2005 con WSE 2.0 ed ha funzionato senza problemi. Una buona notizia per chi ama giocare con WSE ma non vuole perdersi la possibilità di studiare anche il prossimo Visual Studio.
E' uscita la versione definitiva del service pack WSE 2.0. Potete scaricarlo gratuitamente qui. Nel contempo, sono stati adattati i labs (saranno contenti anche gli sviluppatori VB.NET :-))
Inizialmente era dato per improbabile sino al'RTM, ma ecco che ci arriva l'annuncio. WSE2.0 SP2 funzionerà anche con Visual Studio .NET 2005 beta. Non è ancora previsto il supporto ai 64 bit.
Nell'attuale implementazione ASP.NET dei Web Services (serializzazione XML per la precisione) il tipo gYearMonth è mappato sul tipo string. Questa mappatura è stata mantenuta anche nella prossima versione del Framework (2.0). A volte può essere utile mappare implicitamente gYearMonth su un tipo DateTime. In questo post si suggerisce un metodo.
Hervey annuncia la pre-release del service pack 2 di WSE 2.0.
I Web Services hanno vissuto un momento (circa 1/2 anni fa) di grande gloria, si parlava praticamente solo di quello (articoli, workshop, ecc.). Dopo tanta euforia, guardando i numeri nel bel paese (sui newsgroups, forum, ecc.) sembra che non siano più così attraenti.
Mi piacerebbe capire (per chi ha voglia di scrivere) perchè, secondo voi, si non si usano i Web Services in molte realtà. Quali sono le perplessità ? E' un problema di infrastruttura ? Tecnologico ? Di conoscenza ? Di strumenti ?
Le specifiche che ruotano attorno al mondo dei web services non sono proprio poche, come si evice da questo articolo. I protocolli di base (come HTTP, XML, XML schema, ecc.) contano 19 specifiche. Quelle più specifiche dei web services sono 31 !
In più occasioni ho parlato di "contract-first" sui web services (fino alla noia). In tutte le occasioni ho tralasciato un'ipotesi che dovevo, invece, sottolineare. Contract-first significa iniziare dal contratto, che nei web services vien naturale pensare al WSDL. Per la precisione devo aggiungere che definire un contratto significa anche definire una interfaccia (con i necessari attributi), ala OOP.
Omissis ? Ebbè, direi proprio di si. Anche se per vedere veramente all'opera questo modello, dovremo, probabilmente, attendere Indigo.
Nella forma canonica, in ASP.NET, troviamo due message patterns:
One way: invio la richiesta ma non ho alcuna risposta
Request/Response: a seguito di una richiesta ho una risposta
Purtroppo, le due soluzioni non permettono un meccanismo 'asincrono' di comunicazione (duplex message pattern). L'unica asincronicità possibile (forse ;-)) è lato client (per non avere una chiamata bloccante - che blocca la GUI) oppure lato server (banalmente, multi-threading). Per il resto si è soggetti ai problemi classici di timeout.
La soluzione c'è, e bisogna lavorarci un pochetto (ma non è poi così difficile). Spero, a breve (e se interessa) di scriverci un articoletto.
Più volte ho parlato di contract-first, cioè di sviluppare Web Services iniziando dal contratto, aka WSDL. Avendo a disposizione il WSDL è possibile creare il codice della classe proxy con l'utility del framework wsdl.exe oppure la class (astratta) server sempre con la stessa utility (opzione /server). Se volete farlo dall'ambiente di sviluppo, potete scaricare gratuitamente il seguente Add-In.
Come la ncio è un pò vuoto, ma l'idea non è male: http://www.wsefaq.com/ e http://wiki.wsefaq.com/
Un interessante libro sui web service on-line.
WSE 2.0 è la libreria di Microsoft che estende l'attuale implementazione ASP.NET dei web services. In essa troviamo l'implementazione di specifiche sulla sicurezza (OASIS WSSE), uno strumento di diagnostica (tracing sui messaggi SOAP) ed un framework message based (ala SOA).
Avendo ormai 'giocato' con WSE da un pò di tempo, mi sento pronto per tirare qualche conclusione. La libreria (intendo WSE) è sicuramente molto interessante ed apre una strada (che diverrà poi quella di Indigo) verso i 'veri' web services, cioè delle interfacce orientate al messaggio. Ahimè, l'attuale implementazione paga alcune 'deficienze' dovute, per lo più a una mancanza di stabilità nel...