Windows Communication Foundation
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:...
WCF (Windows Communication Framework) e' un framework di messaggistica estremamente estendibile. Piu' di un anno fa, parlai della possibilita' di create un Diskette Trasport Channel. In pratica si inserisce un dischetto nel PC client, la richiesta viene salvata sul dischetto, si porta il dischetto sul server e la richiesta viene letta. Quindi si fa il processo inverso se il pattern di messaggistica e' request-reply. Se e' one-way ci possiamo riposare.
Il protocollo e' molto affidabile in quanto si puo' ridondare assumendo piu' personale. Gestendo ferie e malattie si mantiene il servizio sempre attivo. Il punto di fallimento e' potenzialmente l'hardware (qualcosa si...
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...
Il 13 aprile dalle 15:30 alle 16:45 parlerò di servizi :-) In particolare parlerò di come progettare un contratto in modo che sia 'portabile' da ASP.NET 2.0, a WSE a WCF senza dover stravolgere il codice scritto.
Non si parlerà quindi di sicurezza, reliability, scalabilità, ecc. ecc.
Ci vediamo ai community days :-)
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...
Corrado lo ha già annunciato. Aggiungo solamente questo riferimento alle modifiche che trovaremo in WCF.
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.
Tutti i web services implementati con ASP.NET (e/o WSE) adottano SOAP. Se però dobbiamo fare una critica a SOAP allora possiamo dire che è un protocollo a volte troppo 'pesante' per quello che deve fare. Perchè avere un header ed un body se mi server spedire solamente un'informazione banale ? Non basterebbe l'XML (per mantenere comunque l'interoperabilità) senza quegli elementi ed attributi SOAP ?
Questa domanda se la pongono in tanti, ed ecco il perchè di REST e POX. Ma allora perchè SOAP ?
E' bene definire che cosa si intenda per protocolli di integrazione. I protocolli di integrazione (inteso flusso di...
Uno dei nuovi (rispetto alla versione 2000) data source di Reporting Services 2005 è proprio l'XML. L'XML erogato sia attraverso web services ASP.NET (quindi stream SOAP) che su stream XML.
Ecco allora che mi è venuto in mente che in WCF è possibile implementare alcune estensioni che permattano di erogare facilmente servizi in modalità POX/REST. Come ? Beh, Clemens ha fatto molto (ma molto) di più. nelle prossime settimane scriverò un piccolo esempio di servizio per agevolare il lavoro a Reporting Services 2005.
Prima nacque windowsworkflow.net, poi venne windowscommunication.net ... ma windowspresentation.net dov'è ?
Avete mai sentito parlare di security token e security token service ?
Bene, la spiegazione (un pò rozza, ma funziona !) è semplice. Quando abbiamo definito delle claims, ci serve un modo per impachettarle e spedirle. Il pachettino si chiama security token, mentre il servizio che le spedisce si chiama security token service. Semplice no ?
Tutto l'impianto di sicurezza di WCF si basa sul concetto di claim. Partiamo quindi dalla definizione di Claim: "An assertion of the truth of something, typically one which is disputed or in doubt."
Possiamo allora pensare ad una claim come il numero della nostra carta d'identità, il numero della patente, la nostra data di nascita, la nostra user name di dominio ecc ecc. Un insieme di claims possono quindi identificarci univocamente oppure classificarci (es. siamo maggiorenni).
La classe System.Security.Authorization.Claim fornisce un set di claims predefiniti, come il Dns (CreateDnsClaim) il SID windows (CreateWindowsSidClaim) e così via. Per ogni claim abbiamo 3 proprietà:...
Molto spesso capita di sentire domande del tipo: "il mio servizio impiega molto tempo ad eseguirsi e spesso la chiamata va in timeout. Come posso risolvere il probema ?" In WCF òa soluzione potrebbe essere quella di utilizzare il duplex service contract. Dico potrebbe perchè non è l'unica soluzione !
Il message pattern duplex è concettualmente semplice. Definisco un contratto per la chiamata e un'altro per la callback. Lato servizio avremmo quindi una cosa del tipo:
[ServiceContract(CallbackContract = typeof(IContractCallBack))]public interface IContract{ [OperationContract(IsOneWay=true)] void SubmitContract(string contractNumber);}
[ServiceContract()]public interface IContractCallBack{ [OperationContract(IsOneWay = true)] void ContractStatus(string contractNumber, bool isSubmitted);}
public class ContractService : IContract{ IContractCallBack callback;
public...
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...
WCF permette di hostare i servizi in 3 tipi di applicazioni:
IIS (solo protocollo HTTP)
Applicazione Windows (Windows Services, Win Form, Console)
WAS (Web Service Activation) - aka IIS 7
Un interessante blog di uno degli sviluppatori del team spiega le tre alternative.
MSMQ 4.0 propone delle interessanti novità:
Transactional remote receive
Poison message handling
Subqueues
Continuo a pensare che MSMQ sia uno dei miglior servizi di Windows e queste nuove funzionalità non fanno altro che potenziarlo.
Premesso che parlare di performance su un prodotto non ancora uscito potrebbe avere poco senso, è vero però che il tema fa comunque parte del ciclo di sviluppo del prodotto stesso.
Quindi, qualcuno in Microsoft ha pensato bene di pubblicare dei dati (e codice degli esempi) di comparazione fra un servizio ASP.NET 2.0 e un servizio WCF. Il risultato è molto interessante.
E' uscita la prima beta degli addin WCF per Visual Studio 2005. Con questi addin è possibile fare due cose:
Generare il codice della classe proxy e la configurazione del .config
Generare il codice di testing (NUnit), il contratto e la configurazione
Per i dettagli ed il download clicca qui. Ogni commento, suggerimento, notifica errori è benvenuto :-)
REST è praticamente un modo diverso di intendere servizi web (un giorno ne parlerò più compiutamente).
Il concetto alla base di REST è molto semplice: il servizio è erogato su protocollo HTTP con un body interamente XML (non SOAP) e che sfrutta i verbi standard dell'HTTP: GET, PUT, POST e DELETE. Pertanto, se vogliamo informazioni su un contatto potremmo banalmente fare una GET all'URL http://www.miosito.com/servizio/contatti/352453.
Una domanda interessante è quella di sapere se è possibile utilizzare un framework service oriented per implementare REST oppure bisogne scendere a basso livello implementandosi modules o handler per ASP.NET. Clemens (http://staff.newtelligence.net/clemensv/) sta pubblicando una serie...
Per chi ha scaricato la CTP di dicembre 2005 di WCF avrà notato (forse) la mancanza del Data Contract Tool (dc.exe). bene, il tool è stato soppresso, ma non la sua funzionalità.
Infatti è stato sostituito da un comando di svcutil.exe, ed esattamente svcutil.exe /dconly
Michèle ha scritto un interessante (credo - non l'ho ancora letto tutto) articolo sui contratti in WCF.
Al prossimo workshop farò una sessione dedicata a WCF (Windows Communication Foundation). Dato che ho 1 ora e 15 min. mi stavo chiedendo se aveva più senso far vedere tante demo (e poco codice) che evidenzino le peculiarità di WCF oppure soffermarmi sui concetti base e far vedere molto codice.
Suggerimenti ?
Il tool a riga di comando svcutil.exe serve a generare la classe proxy dato l'endpoint (per ora solo HTTP) del servizio WCF.
Al momento presenta due piccole anomalie (devo ancora capire se sono bugs) nella generazione del file di configurazione. Nell'elemento system.serviceModel.client.endpoint lo strumento non genera l'attributo name (utile per leggere automaticamente la configurazione dal file .config) e definisce erroneamente il tipo del contratto.
Infatti, se l'interfaccia del contratto si chiama IGreetingsService lui scriverà
contract="IGreetingsService"
invece di
contract="HelloWorldClient.IGreetingsService, HelloWorldClient"
correggendo a mano il file tutto funzionerà :-)
L'ultima CTP di WCF (e tutto WinFX) durante la fase di setup non registra le estensioni di WCF. Suggerisco pertanto di eseguire sempre, dopi i 4 setup, il seguente comando:
xws_reg.exe /i
In questo modo tutti gli esempi ed il vostro codice potrà funzionare...
Molto probabilmente non se lo è chiesto nessuno, ma per ora mi sono fermato a scrivere codice con Indigo (WCF). Ho deciso così perchè preferisco attendere l'allineamento del codice con l'RC o RTM di Visual Studio 2005. Nel frattempo leggo gli articoli, un buon libro, vari blogs....
Come ci fa notare Andrea, è arrivata la metamorfosi dei nomi, da codename a official product name. Indigo (mi piace troppo!!) diventa Windows Communication Framework (nome autoesplicativo).
Ora mi tocca cambiare il nome della categoria .... sigh!
La gestione delle eccezzioni con i web services oggi è abbastanza semplice, basta create una SoapException e rimandarla al chiamante. Peccato che attualmente non sia possibile definirlo automaticamente nel contratto (WSDL) in quanto non esistono attributi che definiscano la SOAP faults. In Indigo invece è possibile definire a livello di contratto le sezioni fault:
[OperationContract][FaultContract(typeof(DivideByZeroException))][FaultContract(typeof(ArgumentOutOfRangeException))]double Divide(double n1, double n2);
il quale si rifletterà nel WSDL:
<wsdl:operation name="Divide"> <wsdl:input wsa:Action="http://Microsoft.ServiceModel.Samples/ICalculator/Divide" message="tns:ICalculator_Divide_InputMessage" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" /> <wsdl:output wsa:Action="http://Microsoft.ServiceModel.Samples/ICalculator/DivideResponse" message="tns:ICalculator_Divide_OutputMessage" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" /> <wsdl:fault wsa:Action="http://Microsoft.ServiceModel.Samples/DivideByZeroExceptionFault" name="DivideByZeroExceptionFault" message="tns:ICalculator_Divide_DivideByZeroExceptionFault_FaultMessage" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" /> <wsdl:fault wsa:Action="http://Microsoft.ServiceModel.Samples/ArgumentOutOfRangeExceptionFault" name="ArgumentOutOfRangeExceptionFault" message="tns:ICalculator_Divide_ArgumentOutOfRangeExceptionFault_FaultMessage" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" /> </wsdl:operation>
Altra sessione su Indigo, questa volta si parla di security, queueing e reliability. Inutile dire che la sessione è stata molto interessante (per chi interessa Indigo ovviamente) e la chiarezza espositiva (di Steve Swartz) così come delle demo (di Ingo Rammer) è stata notevole.
Le possibilità di configurazione di Indigo sono praticamente illimitate, è possibile modificare la sicurezza, i meccanismi di queueing e reliability al volo senza scrivere codice. Questo, almeno per me, è un punto fondamentale. A me piace scrivere codice applicativo, non sul trasporto :-)
Adesso corro alla prossima sessione....
Prima vera sessione "seria" su Indigo. Due relatori d'eccezzione, Steve Swartz e Christian Weyer.
Si inizia spiegando i concetti base, quelli che spesso crediamo di avere chiari ma poi scopriamo che abbiamo delle falle. Sicuramente Indigo richiede una certa nomenclatura SOA oriented. Si parte dall'endpoint con le sue componenti: contratto, binding e address.
Non poteva mancare l'"Hello World". L'unica nota interessante di questa demo è la pulizia della soluzione. Nel suo piccolo evidenzia come si implementa un progetto SOA con Indigo. "Hello World" è composto da 4 progetti: l'assembly che contiene i contratti (le sole interfacce), l'assembly che contiene i servizi...
Sembra proprio che Indigo piaccia, e probabilmente acquiserà una posizione importante nello scenario enterprise.
Serve una comunicazione completamente asincrona fra servizi ? Bene, MSMQ è la soluzione. Ma per farlo funzionare con Indigo è necessario scaricarsi la versione 3.5 (in beta). Fate molta attenzione alle note prima di aggiornare, le applicazini che usano MSMQ potrebbero non funzionare più.
La digital identity (le nostre login sui vari siti, l'accesso dispoisitivo all'home bancking, ecc. ) sta divenendo sempre più un problema. La cardinalità (almeno la mia) esplode.
L'identity metasystem può essere una risposta al problema. Segue delle leggi ben precise (le riporto integralmente):
User Control and Consent: Identity systems must only reveal information identifying a user with the user's consent.
Minimal Disclosure for a Constrained Use: The identity system must disclose the least identifying information possible, as this is the most stable, long-term solution.
Justifiable Parties: Identity systems must be designed so the disclosure of identifying information is limited to parties having...
Quando implementiamo un web service in ASP.NET il contratto è il documento WSDL generato quando richiamiamo la pagine asmx con l'estensione WSDL (mioServizio.asmx?wsdl). Il WSDL generato spesso non è sufficientemente preciso e quindi si dovrebbe partire dal WSDL per poi generare il codice (contract-first).
Se analizziamo bene, ci rendiamo conto che il WSDL non è sempre sufficiente per descrivere in toto il contratto di un servizio. Fondamentalmente dipende dal message pattern. In ASP.NET sono disponibili due message patterns: one way (invio il messaggio SOAP al servizio e non ho alcuna risposta) e request/reply (invio e ricevo una risposta SOAP). Se usassimo...
Come probabilmente vi sarete accorti con indigo è possibile definire molti aspetti attraverso i files di condifurazione (uno lato server e di riflesso uno lato client). Sebbene i files di configurazione non sia estremamente complessi (impossibili senza la documentazione), esiste un configuratore (ancora incompleto purtroppo, ma è una pre-beta 1!) nella cartella [Program Files]\Microsoft SDKs\WinFX\bin denominato SvcConfigEditor.exe. Basta lanciarlo e configurare :-)
Nella definizione del contratto con i web services in ASP.NET c'è una forte correlazione fra le scelte OO del modello ad oggetti con quelle del modello del messaggio. Se, per esempio, volete visualizzare una proprietà siete tenuti a dichiararla come pubblica. Se dal punto di vosta OO avrebbe senso dichiararla come privata ma dal punto di vista del messaggio averla inclusa allora non resta che implementarsi la serializzazione a mano.
In Indigo non c'è più correlazione. Verranno infatti pubblicate solo le proprietà dichiarate con l'attributo DataMemberAttribute. Quindi la classe:
[DataContract]public class Contatto{ [DataMember] public string Cognome;
public string Nome;
[DataMember] private float...
In precedenza abbiamo già affrontato il tema del binding, sebbene in modo estremamente approssimativo. Il binding è una sorta di stack che definisce come il servizio si espone sulla rete.
Il binding si presenta come una collezione di elementi funzionali che si occupano di trasporto, codifica/decodifica e comportamenti (behaviors). In cima a tutto questo c'è il dispatcher che si occupa di invocare il metodo richiesto.
Il layer di trasporto con la versione 1 di Indigo coprirà i protocolli HTTP, HTTPS, TCP, MSMQ, Named Pipes. In futuro sarà previsto un trasporto in memory per ragioni di performances.
Il layer successivo si occupa di encoding....
Nella puntata di ieri ho presentato una versione (molto early) di un addin per Visual Studio .NET 2005 beta 2 che genera automaticamente una classe proxy per un servizio Indigo. Essendo una versione ancora allo stato inziale, mancava di alcune caratteristiche di configurazione, le quali sono state colmate con l'ultimo aggiornamento disponibile cliccando qui.
Manca ancora una fase di test intensivo e probabilmente di qualche feature interessante. Se avete suggerimenti non esistate a scrivermi.
Giocando con l'estendibilità di Visual Studio 2005 (è decisamente più semplice che in Visual Studio 2003 anche con i bugs da beta 2 :-) ) mi sono promesso di scrivere un piccolo addin che permettesse di emulare l'"Add web reference" per un servizio Indigo. Sebbene non sia completo potete giocarci ed eventualmente mandarmi un feedback scaricandolo da qui.
Quando usiamo i tools wsdl.exe (per i web services in ASP.NET) e/o svcutil.exe (per i servizi Indigo) vuol dire che abbiamo l'intenzione, in linea generale, di generare il codice client di un web service. Se avete l'esigenza che sia la vostra applicazione a generare quel codice, allora poco male, è sufficiente richiamare le stessa classi che i due tools di cui sopra richiamano.
In particolare, per generare il codice del contratto, è sufficiente scrivere il seguente codice:
MetadataResolver resolver = new MetadataResolver(new EndpointAddress(uri));ServiceEndpointCollection endpoints = resolver.RetrieveEndpointsUsingHttpGet();
ServiceContractGenerator generator = new ServiceContractGenerator();Collection<ContractDescription> contracts = resolver.WsdlImporter.ImportAllContracts();foreach (ContractDescription contract in contracts){ generator.GenerateServiceContractType(contract);}
using (StreamWriter writer = new...
Scott Seely, Yaniv Pessach e Brian Nantz hanno iniziato a scrivere un libro su Indigo. E' interessante vedere che metteranno a disposizione parte dei lavoro prodotto attraverso un blog.
Uno degli aspetti più interessanti del self-hosting è la possibilità di poter gestire più endpoints contemporaneamente. Infatti, potremmo definire due scenari di comunicazione (trasporto):
Accesso al servizio da Internet
Access al servizio da un processo locale
Con i web services non vi erano molte scelte (purtroppo), tutto veniva veicolato attraverso il protocollo HTTP e le regole con esso definite (es. WS-*). In Indigo la cosa è molto più semplice, è possibile definire due endpoints specifici ed ottimizzati per ogni esigenza. Basta aggiungerli nella lista dei listeners:
BasicProfileBinding httpBinding = new BasicProfileBinding();Uri httpUri = new Uri("http://localhost:7070/ContactService");
NetProfileNamedPipeBinding pipeBinding = new NetProfileNamedPipeBinding();Uri pipeUri = new Uri("net.pipe://localhost/ContactService");
_host = new...
Nella parte 1 della demo abbiamo visto come sia possibile ospitare un servizio Indigo all'interno di IIS. In questo terzo episodio voglio cambiare host del servizio, ed in particolare voglio che ad ospitare il servizio sia una componente COM+ (Enterprise Services). Essendo una tecnologia estremamente solida (c'è chi afferma che lo sia più di IIS) penso che possa essere decisamente affidabile per opsitare i servizi aziendali.
Iniziamo con il creare una windows library aggiungendo le referenze necessarie: System.EnterpriseServices.dll per COM+ e System.ServiceModel.dll per Indigo rispettivamente. Quindi decoriamo il nostro assembly con gli attributi necessari alla registrazione della componente:
[assembly: ApplicationName("PEWay Indigo Host")][assembly:...
Steve Swartz è PM e architect nel team Indigo, in altre parole una delle colonne portanti. E' interessante vedere una sua introduzione (illustrazione + demo) su Indigo.
Il tracing è sicuramente uno degli strumenti più amati (spesso dimenticati) quando ci si trova con dei problemi da risolvere. In Indigo il sistema di tracing è stato ulteriormente potenziato (anche rispetto a WSE). Infatti è possibile abilitare il trace su ogni singolo messaggio (in ingresso ed uscita) definendo nel file di configurazione i seguenti parametri del listener:
<source name="IndigoMessageLogTraceSource" switchValue="Verbose"> <listeners> <add name="multifile" type="System.ServiceModel.Diagnostics.MessageWriterTraceListener, system.servicemodel, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" initializeData="c:\logs\messages" maxDiskSpace="10000" /> </listeners></source>
e di abilitazione del tracing:
<system.serviceModel> <diagnostics> <messageLogging logEntireMessage="true" maxMessagesToLog="300" logMessagesAtServiceLevel="false" logMalformedMessages="true" logMessagesAtTransportLevel="true" /> </diagnostics></system.serviceModel>
In questo caso tutti i messaggi verranno salvati nella cartella c:\logs\messages (a patto...
I servizi si basano sulla conversazione fra due endpoints. Conversazione significa scambio di messaggi. Lo scambio di messaggi, nel caso dei web services implementati oggi (con ASP.NET 1.x) può avvenire in due modi: one way e request/reply. In altre parole, mando il messaggio e non mi aspetto alcuna risposta, oppure mando la richiesta e mi arriva una risposta rispettivamente.
Indigo introduce un nuovo (concettualmente parlando non è nuovo, ma lo è l'implementazione) pattern di messaggistica: duplex. In pratica è un meccanismo di request/reply differito.
Immaginate di dover fare una richiesta ad un servizio che impiega parecchi minuti per essere eseguito (tanto da...
La CTP di Indigo che possiamo scaricare oggi non è sicuramente definitiva (del resto è una CTP !). L'aspetto interessante di una CTP è quello di poter partecipare attivamente nel dare un feedback affinchè chi lo sta sviluppando possa 'correggere' la rotta per soddisfare quante più esigenze possibili. Ma come dare un feedback, il modo migliore (ad oggi) è postare sul seguente newsgroup: http://msdn.microsoft.com/newsgroups/default.aspx?dg=microsoft.public.windows.developer.winfx.indigo&lang=en&cr=US
Dopo la puntata dedicata al lato server passiamo al lato client. Per creare un client abbiamo il service metadata utility tool (svcutil.exe).
Il Service Metadata Utility Tool è simile (concettualmente) al wsdl.exe usato in ASP.NET. Permette di creare servizi dal metadato e viceversa. Per creare la classe proxy del servizio implementato dobbiamo quindi richiamare il tool da riga di comando:
svcutil.exe /uxs /out:ContactServiceProxy.cs /config:app.config http://localhost/ContactService.svc?wsdl
L'opzione /uxs (che vuol dire usa l'Xmlserializer) è necessaria in quanto abbiamo decorato (imposto) il contratto con questo serializzatore. L'opzione /out serve a definire il nome del file prodotto (altrimenti creerebbe un anonimo file tempuri.org.cs). Infine l'opzione /config:app.config...
Dopo le parole vorrei passare ai fatti :-)
Immaginiamo sia necessario avere un servizio che registri un nuovo contatto e assegni un codice univoco al contatto (uno use case molto semplice). Immaginiamo anche che il servizio possa essere usufruito sia nella nostra intranet, sia attraverso internet, sia sul server locale.
Iniziamo con la definizione del contratto, cioè i messaggi, le operazioni ed il servizio. Dovendo utilizzare questo contratto in più ambiti, decidiamo di creare una class library che contenga solamente il contratto (ed eventualmente la logica di dominio e di persistenza)
Creamo il progetto, aggiungiamo la referenza a System.ServiceModel.dll (contiene le...
Nell scorso "Indigo Watcher" ho parlato di WAS (Windows Activation Services). WAS è fondamentalmente un driver (molto simile a HTTP.SYS di Windows 2003 e Windows XP SP2) che permette di attivare un servizio Indigo su tre tipologie di canali: HTTP (come farebbe IIS), TCP e Named Pipes.
A differenza di IIS, con WAS è possibile instaurare una comunicazione molto efficiente (al pari di COM+) fra servizio e cliente attraverso un canale Named Pipe ed una serializzazione binaria.
Generalmente siamo abituati ad usare IIS come host application dei web services, usare COM+ per gli enterprise services ed usare applicazioni standard (windows forms, console, web e windows service) in ambito MSMQ, e così via. Con Indigo il tutto si unifica in un unico modello. Infatti, è sufficiente dichiarare un host generico (all'interno di qualsiasi applicazione o servizio) perchè si possa iniziare a ricevere ed inviare richieste (sul/sui canale/i deifiniti nel binding). Considerando l'esempio di ieri, si avrebbe:
ServiceHost<CalculatorService> host = new ServiceHost<CalculatorService>();host.Open();Console.WriteLine("Service is running. Press ENTER to exit...");Console.ReadLine();host.Close();
E' importante notare due aspetti: il primo è che non abbiamo bisogno di fornire...
Siamo abituati con i web services in ASP.NET ad utilizzare (spesso incosapevolmente) l'XmlSerializer per serializzare/deserializzare le nostre istanze di classi nel messaggio SOAP. La caratteristica dell'XmlSerializer (fra le altre cose) è di serializzare i tipi primitivi come tipi XML Schema (definiti sotto il namespace http://www.w3.org/2001/XMLSchema). In Indigo, se definiamo il seguente contratto:
[ServiceContract(Namespace="http://Microsoft.ServiceModel.Samples")]public interface ICalculator{ [OperationContract] double Add(double n1, double n2);}
lo schema generato produrrà qualche cosa di veramente nuovo:
<xs:element name="Add"> <xs:complexType> <xs:sequence> <xs:element name="n1" xmlns:q1="http://schemas.microsoft.com/2003/10/Serialization/" type="q1:double" /> <xs:element name="n2" xmlns:q2="http://schemas.microsoft.com/2003/10/Serialization/" type="q2:double" /> </xs:sequence> </xs:complexType></xs:element>
perchè è stato definito il tipo double (primitivo) sotto un'altro namespace ? In sostanza, by default,...
Per poter comunicare con un servizio Indigo è necessario definire almeno un endpoint. Un endpoint è frutto di tre componenti: EndpointAddress, Binding e ContractDescription. Questi tre elementi rispondono a tre domande: "dove ?", "come ?" e "che cosa ?" rispettivamente.
endpointAddress
Contiene l'identificativo (URI) del luogo dove si trova l'indirizzo. Nel caso fosse un web service potremmo avere lo URI definito come http://mioserver/mioservizio.svc (in Indigo su usa di default *.svc - in ASP.NET *.asmx)
L'endpointAddress può contenere molte più informazioni oltre allo URI in quanto riflette le specifiche dell EPR (EndPointReference) di WS-Addressing. Ad esempio è possibile specificare dove inviare l'eventuale messaggio...
Ok, ho installato la CTP di marzo (la prima) e non sono riuscito dal trattenermi di scrivere il mio primo web service ala Indigo. Gli esempi che troviamo usano sempre come applicazione host una Windows application (in alcuni caso una console), io non riuscivo a fare a meno di usare IIS.
Quindi, creati i contratti (Indigo ne prevede tre, di cui 2 obbligatori...ne parleremo un'altra volta) ed il servizio, mi scrivo i parametri dell'endpoint nel web.config.
E' arrivato !! Ed ora si può veramente investigare su come sarà il futuro delle applicazioni entrprise. Nel prossimo futuro pubblicherò i miei commenti su Indigo, per ora vi suggerisco una interessantissima overview.