Visual C#.it News » C#

WCF – VIII Parte

Sergio79 — Fri, 11 Dec 2009 11:59:25 +0000

WCF e Windows Service
Un aspetto molto interessante di Windows Communication Foundation è la possibilità di ospitare un servizio WCF all’interno di un servizio di Windows.

Questa è decisamente una tecnica fortemente consigliata se il nostro servizio non necessita di un’interazione con alcuna UI e noteremo inoltre come tale soluzione non sia poi così differente rispetto a tutti i precedenti esempi mostrati sin’ora, dove tutti i servizi WCF creati erano ospitati in applicazioni windows e applicazioni web.

il Server
Avviamo VS scegliendo come tipo di progetto “Windows Service”.
Dal Solution Explorer posizioniamoci su Service1.cs e andiamo ad apportare le seguenti modifiche al codice auto generato:

using System.ServiceModel;

namespace WindowsService1
{
    public partial class Service1 : ServiceBase, IServiceClass
    {
        ServiceHost sh = null;

        public Service1()
        {
            InitializeComponent();
        }

        protected override void OnStart(string[] args)
        {
            if (sh != null) sh.Close();

            sh = new ServiceHost(typeof(Service1));

            sh.Open();
        }

        protected override void OnStop()
        {
            if (sh != null)
            {
                sh.Close();
                sh = null;
            }
        }

        public string DoWork()
        {
            return DateTime.Now.ToString();
        }
    }

    [ServiceContract]
    public interface IServiceClass
    {
        [OperationContract]
        string DoWork();
    }
}

Non c’è molto da dire.
E’ stata semplicemente aggiunta l’interfaccia del nostro servizio WCF decorata dai soliti attributi, quindi la sua implementazione è stata riportata nella classe Service1 del servizio di windows, facendo ereditare quest’ultima da ServiceBase e appunto dall’interfaccia del servizio WCF, IServiceClass.
Il metodo DoWork è stato correttamente implementato e infine abbiamo gestito i metodi che verranno eseguiti all’avvio e alla chiusura del windows service.
Non ci resta che aggiungere e impostare correttamente il file di configurazione e per farlo, dal menu Project di VS scegliamo Add New Item, quindi Application Configuration File.
Minimizzando il più possibile, ecco le impostazioni di configurazione da inserire per il nostro servizio WCF:

Un’unica considerazione da fare è in merito a due nuovi elementi, host e baseAddress.
Specificando l’indirizzo in baseAddress evitiamo di scrivere l’intero percorso per sia per l’endpoint del servizio, che per il suo indrizzo mex.
L’ultimo step per la creazione del windows service consiste nella sua configurazione fattibile attraverso l’add installer messo a disposizione da VS, attraverso il quale possiamo imposare il nome del servizio, la sua descrizione, il tipo di account e il tipo di avvio.
Il servizio di windows è pronto, compiliamo il progetto e prepariamoci alla sua installazione tramite l’utility installUtil.
Avviamo dunque il command prompt di VS e digitiamo il seguente comando:

installUtil.exe servicePath\fileName.

Infine, andiamo nel servizio di Windows e avviamo il nostro servizio appena creato.
Nota: a procedura terminata, per disinstallare il servizio di esempio da noi creato basterà riavviare il command propomt di VS e digitare quanto segue:

installUtil.exe /u servicePath\fileName.

Il Client
Avviamo la seconda ed ultima istanza di VS e scegliamo come tipo di progetto una Windows Form Application.
Inseriamo il solito Button, quindi dal menu Project scegliamo Add Service Reference, digitando nella barra degli indirizzi il baseAddress impostato nel server: net.tcp://localhost:12345
Aggiunto il riferimento al servizio non ci resta che aprire una connessione e consumarlo con il metodo DoWork:

ServiceReference1.Service1 s =
                new WindowsFormsApplication1.ServiceReference1.Service1();

            this.Text = s.DoWork();

            s.Close();

Questo codice è ormai familiare: è stata creata un’istanza di Service1, quindi è stato consumato il servizio WCF attraverso la chiamata al metodo DoWork.

Conclusioni
In pochi semplici passaggi è stato illustrato come ospitare un servizio WCF all’interno di un servizio di windows. La procedura dovrebbe risultare abbastanza chiara anche per coloro che non abbiano mai avuto necessità di sviluppare windows services, diversamente basterà fare qualche domanda sul forum di visualcsharp, o commentare questo stesso articolo.

Condivi questo articolo:

WCF – VII Parte

Sergio79 — Mon, 07 Dec 2009 17:20:13 +0000

Sicurezza in WCF
In una tecnologia che permette lo scambio di messaggi SOAP tra clients e servizi risulta essere di estrema importanza la sicurezza legata all’intero processo cui sono sottoposte queste informazioni.
In questo senso WCF integra nella sua piattaforma tecnologie ormai più che consolidate, già esistenti.

Possiamo racchiudere il principio di WCF security in quattro concetti: integrity, confidentiality, authentication e authorization.

Sebbene il WCF security sia un argomento vasto e fondamentale, in questa parte del tutorial si è deciso di affrontare più gli aspetti pratici con il solito progetto di esempio “passo-passo”, piuttosto che dilungarsi troppo sulla parte teorica.

Lo scopo della soluzione che andremo a creare sarà quello di permettere la comunicazione tra client e server esclusivamente previa autenticazione e garantiremo inoltre la sicurezza inerente lo scambio dei messaggi durante il loro intero processo.
L’aspetto più interessante di tutto ciò sarà l’integrazione di un authentication process security completamente personalizzato rendendo il progetto certamente più corposo, ma in grado di offrire al lettore tutti gli strumenti, o quasi, per potersi destreggiare con una certa agilità su questo argomento.

Il Server
Avviamo la prima istanza di VS e creiamo un progetto Web, quindi aggiungiamo subito un servizio WCF e ridefiniamo il metodo DoWork in modo che restituisca una stringa qualunque.
Come detto precedentemente, per poter accedere al servizio ed usufruire del metodo offerto sarà necessario fornire delle credenziali personalizzate, username e password di nostra scelta.
Per rendere questo possibile dobbiamo innanzitutto creare una classe, nel nostro esempio implementata in una dll, che eredita da UserNamePasswordValidator e ridefinirne il metodo Validate.

Avviamo quindi un’altra istanza di VS e scegliamo come progetto una nuova libreria di classi, inserendo questo codice al suo interno:

using System.IdentityModel;
using System.IdentityModel.Selectors;
namespace ClassLibrary1
{
    public class MyValidator : UserNamePasswordValidator
    {
        public override void Validate(string userName, string password)
        {
            if (userName != "user" || password != "pwd")
                throw new Exception("Username o Password non validi.");
        }
    }
}

Compiliamo la libreria e aggiungiamola come riferimento al progetto web.

A questo punto dobbiamo apportare una serie di modifiche al file web.config in modo da istruire correttamente il servizio su come dovrà comportarsi.
In particolare, dovremo specificare che tipo di autenticazione vogliamo utilizzare, quale certificato sfruttare per la crittografia dei dati di accesso e la modalità di sicurezza per i messaggi:

Soffermiamoci sui punti di maggior interesse.
In Behaviors abbiamo aggiunto un nuovo elemento, ServiceCredentials in cui abbiamo specificato il tipo di autenticazione (Custom) e il tipo di convalida per tali credenziali (cioè la classe creata e situata nella dll aggiunta al progetto).
All’interno di ServiceCredentials troviamo poi l’elemento ServiceCertificate che specifica quale certificato utilizzare. Nel nostro progetto il certificato specificato è un certificato di esempio creato da noi e installato sulla macchina su cui stiamo costruendo la soluzione; poco più avanti verrà spiegato in che modo crearlo e installarlo.
L’altro punto di interesse è la sezione relativa al binding, in cui è stato inserito l’elemento security, impostandone la modalità a message e per questi messaggi che tipo di credenziali il client dovrà usare.
Il nostro server è pronto, prima di premdere F5 però, come detto pocanzi dobbiamo installare sulla nostra macchina un certificato di esempio come specificato nell’elemento ServiceCertificate. Per farlo avviamo il command prompt di VS e digitiamo la seguente riga seguita dal tasto invio:

makecert.exe -sr LocalMachine -ss My -a sha1 -n CN=MyServerCert -sky exchange –pe

Il certificato è ora installato, possiamo quindi avviare il nostro server premendo F5.

Il Client
Avviamo ancora una volta Vs e optiamo per la creazione di una Windows Form, quindi inseriamo un Button.
Aggiungiamo il riferimento al nostro servizio in esecuzione e iniziamo a configurare correttamente il client.
Prima di tutto è necessario verificare l’esistenza e la validità del certificato sul server e per farlo, anche in questo caso scriveremo una classe contenuta in un assembly che eredita da X509CertificateValidator.
Creiamo quindi un nuovo ed ultimo progetto di tipo libreria di classi e inseriamo il seguente codice:

using System.IdentityModel.Selectors;
using System.IdentityModel.Tokens;
using System.Security.Cryptography.X509Certificates;

namespace ClassLibrary2
{
    public class MyX509Validator : X509CertificateValidator
    {
        public override void Validate(X509Certificate2 certificate)
        {
            if (certificate == null)
                throw new ArgumentNullException("Nessun certificato rilevato");

            if (certificate.SubjectName.Name != "CN=MyServerCert")
                throw new SecurityTokenValidationException("Certificato non valido");
        }
    }
}

Le istruzioni presenti non fanno altro che verificare l’esistenza di un certificato e la sua validità, cioè la sua corrispondenza al certificato da noi desiderato.
Aggiungiamo un riferimento alla libreria appena creata sulla nostra applicazione e prepariamoci ad esaminare e modificare il solito app.config:


            
                
                    
                    
                    
                                         
                    
                
            
        
      
        
          
            
              
                
              
            
          
        
      
      
            http://localhost:50384/Service1.svc" binding="wsHttpBinding"
                bindingConfiguration="WSHttpBinding_IService1" contract="ServiceReference1.IService1"
                name="WSHttpBinding_IService1" behaviorConfiguration="myClientBehavior">

Un primo sguardo va dato sull’elemento security all’interno del’elemento binding, dove anche qui, come per il server è stata impostata la modalità di sicurezza (message) e la tipologia di credenziali da fornire (userName).
Ancor più interessante è la sezione behaviors, in cui viene specificato il comportamento per un singolo endpoint. E’ stato impostato il nome del behavior ed il tipo di autenticazione attraverso il riferimento alla libreria creata precedentemente.
Nell’ elemento endpoint poi è stato ovviamente inserito l’attributo behaviorConfiguration, specificando così a quale endpointBehaviors fare riferimento ed infine è stato modificato a MyServerCert il valore di value per l’elemento dns.

Non ci resta che gestire l’evento click del Button in questo modo:

ServiceReference1.Service1Client s = new WindowsFormsApplication1.ServiceReference1.Service1Client();
s.ClientCredentials.UserName.UserName = "user";    s.ClientCredentials.UserName.Password = "pwd";
s.Open();
this.Text = s.DoWork();
s.Close();

Anche il client è terminato.
Non ci sono molte considerazioni da fare per questo code snippet: è stata semplicemente creata un’istanza di Service1Client e prima di aprire la connessione e chiamare il metodo DoWork sono state impostate le credenziali di accesso al servizio.
Si noti però che le impostazioni di UserName e Password non sono possibili attraverso il file config, ma solo via codice.
Premiamo F5 e clicchiamo sul Button.
Il risultato dovrebbe essere la visualizzazione della stringa restituita dal metodo esposto nel servizio nella barra del titolo della Windows Form.

Qualcosa in più da sapere…
La piattaforma WCF implementa sistemi di sicurezza in modo efficiente, ma senza introdurre nulla di nuovo, usufruendo così di tecnologie già ben consolidate e conosciute dalla gran parte degli sviluppatori.
Ad esempio, nel nostro progetto avremmo potuto optare per un tipo di autenticazione nativa, come quella di Windows e certamente non sarebbe stata una scelta meno azzeccata o meno sicura di quella custom.
Il fatto di aver voluto utilizzare delle credenziali personalizzate, come Userame e Password trova riscontro in più ragioni: prima fra tutte, si ha avuto modo, nonché necessità di inserire nuovi elementi nel file config sino ad ora mai introdotti nei precedenti tutorial.
Ancora, in tanti e tanti tipi di progetti reali, la volontà di permettere un accesso sicuro client/server attraverso classiche credenziali “nome utente/password” è quasi una costante.
In rete è possibile trovare diverse guide, MSDN è una fonte eccezionale ed inesauribile, libri di testo ne esistono a volontà, eppure non sembra essere così semplice riuscire a trovare un esempio completo in ogni minimo dettaglio sull’utilizzo di credenziali custom in WCF.

Sempre a proposito di security, WCF integra nella sua piattaforma il concetto di Authorization e con esso, è possibile impostare dei criteri di autorizzazione/accesso a determinate risorse del servizio.
Tutto ciò è reso possibile attraverso l’attributo PrincipalPermission applicato a metodi del servizio, ASP.NET Membership e Role Provider, Authorization Manager e Identity Model.

Conclusioni
In questo articolo si è appreso come integrare differenti livelli di sicurezza lato client/server in WCF e se si considerano le sei precedenti pubblicazioni possiamo ritenere di conoscere gran parte degli elementi essenziali per un corretto utilizzo di questa tecnologia.

Condivi questo articolo:

WCF – VI Parte

Sergio79 — Mon, 30 Nov 2009 08:02:25 +0000

Service Behaviors
Il controllo del threading process e la gestione delle istanze di un servizio avviene per mezzo dei Service Behaviors.
Di questi attributi, ne distinguiamo due tipi: service behavior (attributo di classe) e operation behavior (attributo di operazione), entrambi con il loro set di proprietà disponibili.

A differenza di tutti gli altri attributi visti sin’ora, i service e gli operation attributes si applicano alla classe che implementa l’interfaccia del servizio, non all’interfaccia stessa.

Se provassimo ad applicare qualche attributo, durante la digitazione, l’intellisense di Visual Studio ci mostrerebbe tutte le proprietà disponibili ed i possibili tipi di valore da associare.
Riprendendo un esempio già mostrato, vediamo come poter impostare alcuni degli attributi disponibili:

[ServiceContract]
    public interface IServiceClass
    {
        [OperationContract]
        bool CreateDirectoryAndFile(string directoryName, string fileName);
    }

    [ServiceBehavior(AutomaticSessionShutdown=true, ConcurrencyMode=ConcurrencyMode.Single,
        TransactionTimeout="00:01:00")]
    public class ServiceClass : IServiceClass
    {
        [OperationBehavior(AutoDisposeParameters=true)]
        public bool CreateDirectoryAndFile(string directoryName, string fileName)
        {
            try
            {
                Directory.CreateDirectory(directoryName);

                File.Create(directoryName + "\\" + fileName);

                return true;
            }
            catch { return false; }
        }
    }

Come si può notare, è la classe che implementa l’interfaccia ad essere decorata dall’attributo in questione e non viceversa.
Con il parametro AutomaticSessionShutdown impostato a true si determina la chiusura automatica della sessione una volta che il servizio ha elaborato e processato tutti i messaggi.
Il parametro ConcurrencyMode invece determina la gestione del service thread. Impostando tale parametro a ConcurrencyMode.Single si vuole intendere che qualora arrivi un messaggio mentre un altro è già in elaborazione, il nuovo messaggio arrivato non sarà processato fino a quando non sarà terminata l’elaborazione del primo.
L’ultimo parametro per l’attributo ServiceBehavior inserito in questo esempio è TransactionTimeout, che come si evince dal suo nome determina il tempo entro il quale una transazione dovrà essere terminata, nell’esempio il tempo massimo è impostato a un minuto.

Per l’attributo OperationBehavior è stato inserito un solo parametro, l’AutoDisposeParameters impostato a true. In questo caso si specifica che i parametri passati al metodo saranno automaticamente rilasciati.

In questo esempio abbiamo applicato degli attributi attraverso codice, ma è anche possibile e anzi, è prassi piuttosto comune impostare attributi attraverso il file di configurazione.
Ancora una volta l’intellisense di VS ci viene in aiuto..
Riprendendo il primo esempio di servizio WCF mostrato nella prima parte di questo tutorial, vediamo alcuni elementi del file web.config in riferimento ai serviceBehaviors:

serviceMetadata httpGetEnabled="true"
serviceDebug includeExceptionDetailInFaults="true"
serviceThrottling maxConcurrentSessions="3"

Particolare attenzione va rivolta all’attributo serviceThrottling e serviceDebug.
Con maxConcurrentSession impostato a valore 3 per l’attributo serviceThrottling, si specifica il numero massimo di connessioni al servizio per un singolo canale. Infatti, se provassimo a rieseguire il progetto e provassimo a cliccare sul button del nostro client per più di tre volte, l’applicativo andrebbe in blocco.
Il valore di default per questo parametro è 10, impostandolo a 0 invece otterremo l’equivalente di Int32.MaxValue.
Altrettanto interessante è l’attributo serviceDebug in cui è dichiarato il parametro includeExceptionDetailInFaults impostato a true. Tale valore permette permette al client di ricevere messaggi SOAP derivanti da eventuali errori/eccezioni verificatisi nel servizio, essenziale durante il debug del nostro software.

Gestione delle Eccezioni
In WCF le eccezioni gestite, per poter essere inviate al client devono essere convertire in messaggi SOAP, detti anche SOAP fault messages dove ne distinguiamo due tipi, declared e undeclared.
I tipi declared ci permettono di personalizzare un SOAP fault e la loro implementazione avviene mediante l’attributo FaultContract applicato all’operazione desiderata.
Di seguito è riportato un frammento di codice client/server per capirne meglio la sintassi:

//SERVER*****************************
[ServiceContract]
    public interface IService1
    {
        [OperationContract]
        [FaultContract(typeof(Test), ProtectionLevel=System.Net.Security.ProtectionLevel.EncryptAndSign)]
        string DoWork(int x);
    }

[DataContract]
    public class Test
    {
        private string message;

        public Test(string msg) { message = msg; }

        [DataMember]
        public string Message
        {
            get { return this.message; }
            set { message = value; }
        }

public class Service1 : IService1
    {
        public string DoWork(int x)
        {

            if (x < 10) return "ok";
            else throw new FaultException(new Test("Il valore di X è maggiore di 10"));
        }
    }
//*******************************

//CLIENT
try
            {
                ServiceReference1.Service1Client sc = new ServiceReference1.Service1Client();

                MessageBox.Show(sc.DoWork(5));

                MessageBox.Show(sc.DoWork(12));//questa chiamata genera eccezione
            }
            catch(FaultException errorCode)
            {
                MessageBox.Show(errorCode.Detail.Message);
            }
            catch (FaultException unknowFault)
            {
                MessageBox.Show(unknowFault.Message);
            }
        }

Nella parte server abbiamo applicator l’attributo FaultContract sul metodo DoWork, specificando due parametri, typedof(nome Classe) e protectionLevel. Il primo, essenziale per creare una gestione di eccezioni personalizzata, permette all’interno dell’implementazione del metodo DoWork di lanciare un’eccezione FaultException di tipo Test.

Nel client è stato semplice inserito un blocco try – catch per la cattura di due eccezioni: la prima, una FaultException di tipo Test e l’altra, un FaultException generica.

Conclusioni
Abbiamo dato uno sguardo sull’implementazione dei ServiceBehaviors e delle FaultException.
A questo punto del tutorial sarebbe opportuno iniziare a scrivere qualcosa di mano propria e sperimentare quanto più possibile.

Condivi questo articolo:

WCF – V Parte

Sergio79 — Fri, 27 Nov 2009 20:50:34 +0000

Consumare un servizio WCF, un approccio diverso…
Negli esempi visti sino ad ora, quando abbiamo avuto bisogno di consumare un servizio WCF non abbiamo fatto altro che contattare l’endpoint attraverso Visual Studio e successivamente istanziare un oggetto della classe del servizio, proprio come se l’avessimo creata in locale, potendo così usufruire delle operazioni offerte.

Sebbene questo sia il metodo più rapido, ne esiste un altro, impercettibilmente più verboso in termini di codice, attraverso il quale possiamo avere un maggior controllo sul canale di comunicazione.
Riprendendo il progetto di esempio mostrato nella terza parte di questo tutorial, vediamo come modificare il modo in cui connetterci al servizio e come consumarlo:

//aggiungiamo il seguente riferimento
using System.ServiceModel;

//inseriamo un nuovo Button con il seguente codice nel gestore evento Click:
private void button2_Click(object sender, EventArgs e)
        {
            try
            {
                ChannelFactory factory =
                    new ChannelFactory("NetTcpBinding_IServiceClass");
                TCP.IServiceClass channel = factory.CreateChannel();

                channel.CreateDirectoryAndFile("C:\\test", "file.txt");
            }
            catch (CommunicationException exc)
            {
                MessageBox.Show(exc.Message);
            }
            catch (Exception exc)
            {
                MessageBox.Show(exc.Message);
            }
        }

Abbiamo instanziato un oggetto di tipo ChannelFactory, il quale ci mette a disposizione una serie di metodi e proprietà per l’apertura e chiusura della connessione, monitorarne lo stato, o per l’impostazione delle credenziali di accesso al servizio.
Nell’esempio è stato invece utilizzato il metodo CreateChannel per ottenere un’istanza ad uno specifico endpoint, quello del nostro server.
Infine, il servizio è stato consumato richiamando il metodo CreateDirectoryAndFile implementato nel nostro WCF service.
Un’ultima considerazione da fare è in merito alla gestione delle eccezioni, dove oltre alla classica Exception è stata aggiunta la cattura di eventuali eccezioni derivanti dalla conessione vera e propria con CommunicationException.

Metodi Asincroni
WCF offre la possibilità di eseguire operazioni in modo asincrono.
Tale modello di programmazione può essere implementato sia lato server, che client.
Una delle cose sicuramente più interessanti consiste nella possibilità di poter invocare un metodo in modo asincrono attraverso il nostro client, nonostante tale metodo non sia stato implementato in un pattern asincrono lato server.

Vediamo subito una dimostrazione di quanto detto.
Riprendiamo il progetto di esempio sviluppato nella terza parte di questo tutorial, avviamo subito il nostro server con F5, quindi apriamo il progetto client.
Nel Solution Explorer espandiamo l’elemento Service References, quindi tasto destro sul sottoelemento TCP e scegliamo la voce Configure Service Referece …
Nella schermata che ci appare mettiamo una spunta in corrispondenza della voce Generate Asynchronous Operations, quindi clicchiamo su Ok.
Questa semplice operazione ci ha dato la possibilità di usufruire di altri metodi relativi al nostro servizio, quelli per l’esecuzione appunto di operazioni asincrone sulle operazioni da noi già implementate.

Posizionamoci nel gestore evento Click dell’unico Button presente nel progetto, eliminiamo tutte le istruzioni contenute all’interno e inseriamo quanto segue:

ServiceClassClient client = new WcfClientApplication.TCP.ServiceClassClient("NetTcpBinding_IServiceClass");
                
client.CreateDirectoryAndFileCompleted += new EventHandler(client_CreateDirectoryAndFileCompleted);

client.CreateDirectoryAndFileAsync(@"C:\WCF_Folder", "WCF_File_Name.txt");

Non ci resta che implementare il gestore evento CreateDirectoryAndFileCompleted..

private void client_CreateDirectoryAndFileCompleted(object sender, TCP.CreateDirectoryAndFileCompletedEventArgs e)
        {
            bool result = e.Result;

            if (result) MessageBox.Show("ok..");
        }

A differenza del progetto originale, questa volta il metodo responsabile della creazione di cartella e file è stato eseguito in modo asincrono.
Terminata l’operazione, l’evento viene attivato e il risultato (ciò che il metodo restituisce) lo recuperiamo proprio all’interno del gestore evento tramite la proprietà Result dell’oggetto CreateDirectoryAndFileCompletedEventArgs.

Stesso risultato possiamo ottenerlo tramite istanza di ChannelFactory:

//Gestore evento Click

EndpointAddress endpointAddress = new EndpointAddress("net.tcp://localhost:12345/TcpBinding");
IServiceClass client = ChannelFactory.CreateChannel(new NetTcpBinding(), endpointAddress);
IAsyncResult result = client.BeginCreateDirectoryAndFile("C:\\test", "file.txt", CreateDirectoryAndFileCallBack, client);

In questo caso abbiamo utilizzato il metodo BeginCreateDirectoryAndFile, dove il terzo parametro passato è la funzione di callback di seguito riportata:

private void CreateDirectoryAndFileCallBack(IAsyncResult ar)
        {
            bool result = ((TCP.IServiceClass)ar.AsyncState).EndCreateDirectoryAndFile(ar);

            if (result) MessageBox.Show("ok...");
        }

Conclusioni
In questa quinta parte del tutorial abbiamo dato un rapido sguardo sulla classe ChannelFactory e su come poter invocare metodi remoti in modo asincrono.
Come sempre, è possibile approfondire gli argomenti e sperimentare con diversi frammenti di codice o interi progetti attraverso MSDN.

Condivi questo articolo:

Accedere a WPF User Interfaces da threads secondari

Sergio79 — Tue, 24 Nov 2009 12:24:18 +0000

Chi sviluppa abitualmente applicazioni Windows Form ha spesso l’esigenza di implementare uno, o più thread diversi da quello principale, il più delle volte per ragioni di performance e attraverso essi accedere ai controlli dell’applicazione.

Come tutti ben sanno, tale accesso non può essere eseguito in modo diretto, ma tramite il metodo Inoke o BeginInvoke della classe Control:

using System.Threading;

namespace WindowsFormsApplication2
{
    public partial class Form1 : Form
    {
        private delegate void HandledOnLabelUpadte();
        Thread th;

        public Form1()
        {
            InitializeComponent();

            th = null;
        }

        private void button1_Click(object sender, EventArgs e)
        {
            th = new Thread(Start);
            th.Start();
        }

        private void Start()
        {
            this.Invoke(new HandledOnLabelUpadte(OnLabelUpdate));
        }

        private void OnLabelUpdate()
        {
            label1.Text = "Hello!";
        }
    }
}

Al metodo Invoke è stato passato come parametro un delegato che punta alla funzione responsabile dell’aggiornamento del controllo Label.
Nulla di nuovo, questo è ciò che siamo abituati a fare quando intendiamo avere accesso sicuro ad un oggetto Control e suoi derivati.

E in WPF…?
Con l’ultima tecnologia rilasciata da Microsoft dedicata al nuovo tipo di sviluppo di user interface le cose cambiano appena in termini di codice, ma concettualmente non poi così tanto.
L’esempio precedente è qui riproposto in versione WPF Application:

using System.Threading;

namespace WpfApplication1
{
    public partial class Window1 : Window
    {
        private delegate void HandledOnLabelUpadte();
        Thread th;

        public Window1()
        {
            InitializeComponent();
            th = null;
        }

        private void button1_Click(object sender, RoutedEventArgs e)
        {
            th = new Thread(Start);
            th.Start();
        }

        private void Start()
        {
            this.Dispatcher.Invoke(new HandledOnLabelUpadte(OnLabelUpdate), System.Windows.Threading.DispatcherPriority.Normal);
        }

        private void OnLabelUpdate()
        {
            label1.Content = "Hello!";
        }
    }
}

In questo caso è stato utilizzato il metodo Invoke della classe Dispatcher, inserendo un parametro in più inerente la modalità di accesso all’operazione.

La classe Dispatcher offre diverse funzionalità e ci sarebbe molto altro da dire,
su MSDN è possibile trovare documentazione in abbondanza e di facile comprensione.

Condivi questo articolo:

WCF – IV Parte

Sergio79 — Tue, 24 Nov 2009 07:10:42 +0000

Nelle precedenti sezioni abbiamo parlato dei WCF Contracts e del ruolo fondamentale che essi intraprendono in questa tecnologia.
Nei due progetti di esempio inoltre abbiamo avuto modo di mettere in pratica, se pur parzialmente, quanto spiegato in linea teorica riguardo la loro implementazione, in particolare quella dei Service Contracts.
In questa parte del tutorial esamineremo un pò più nel dettaglio i Contracts in WCF prestando particolare attenzione ai loro attributi e inserendo vari code snippet per poter meglio comprendere i concetti che verranno esposti.

Service Contracts e Operation Contracts
I Service Contracts rappresentano l’interfaccia esposta dal servizio e ne definiscono le operazioni o i metodi disponibili, nonchè i patterns inerenti lo scambio dei messaggi, ad esempio se questi sono di tipo simplex, duplex, o request-replay.
Eccone un esempio:

[ServiceContract] //definisce l’interfaccia esposta
Public interface ImyInterface
{
	[OperationContract] //definisce il metodo esposto
	void DoWork();

	double DoAnotherWork();//metodo non esposto dal servizio, quindi non accessibile dalla parte client
}

Parametri per l’Attributo [ServiceContract]
CallbackContract: solitamente utilizzato nelle comunicazioni duplex. Il valore di questo parametro dovrebbe genericamente rappresentare il contratto esposto dall’altra parte, cioè dal client:

[ServiceContract (CallbackContract = typeof(IClientContract))]
Public interface IServerInterface
{
	//…
}

ConfigurationName: utilizzato per ottenere o impostare la locazione dell’elemento < service> nel file di configurazione.

Name: ottiene o imposta il nome per l’elemento in WSDL.

Namespace: ottiene o imposta il namespace per l’elemento in WSDL. Il valore di default è http://tempuri.org.

ProtectionLevel: questo parametro specifica il livello di protezione richiesto (Sign, EncryptAndSign, None), ad esempio se volessimo specificare che venga richiesta solo una semplice autenticazione scriveremmo qualcosa del genere:

[ServiceContract (ProtectionLevel = System.Net.Security.ProtectionLevel.None )]
Public interface IServiceClass
{
	//…
}

SessionMode: specifica un tipo di supporto per le reliable session (implementate nel protocollo WS-Reliable Messaging) che un contratto richiede e che deve poter supportare. Il valore può essere Allowed, NotAllowed e Required:

[ServiceContract (SessionMode = SessionMode.Required )]
Public interface IServiceClass
{
	//…
}

Parametri per l’Attributo [OperationContract]
Action: Ottiene o imposta il WS-Addressing del messaggio richiesto e definisce l’azione che identifica la corrente operazione. WCF usa questa proprietà per determinare a quale metodo inviare il messaggio in arrivo:

[OperationContract (Action = true)]
void DoSomething(int x, int y);

AsyncPattern: specifica che un operazione è asincrona, in tal caso il suo valore sarà true.

IsInitiating e IsTerminating: il parametro IsInitiating verifica se un’operazione è consentita per essere eseguita come prima operazione quando viene creata una sessione.
IsTerminating invece determina se l’operazione eseguita terminerà la comunicazione tra i due punti.

[ServiceContract ]
Public interface IServiceClass
{
	[OperationContract(IsInitiating = true, IsTerminating = false)]
	void Login(user);

	[OperationContract(IsInitiating = false, IsTerminating = false)]
	void DoWork();

	[OperationContract(IsInitiating = false, IsTerminating = true)]
	void Logout(user);
}

Da notare che se si provasse a chiamare come prima operazione DoWork() o Logout(user) verrebbe restituito un errore, la prima operazione dovrà essere necessariamente Login(user).

IsOneWay: specifica se un’operazione restituisce un messaggio di risposta.

Name: ottiene o imposta il nome dell’operazione sovrascrivendo l’elemento in WSDL.

ProtectionLevel: come per ServiceContract.

ReplayAction: specifica un’azione di risposta per i messaggi in arrivo.

Data Contracts
Il Data Contract descrive il dato che sarà scambiato tra le parti. Per poter inziare la comunicazione, le parti devono “accettare” sul tipo di Data Contract, nello specifico in che modo il dato sarà serializzato e deserializzato (Binario e XML).
A differenza del Service Contract, l’attributo Data Contract non può essere applicato a interfacce, ma solo a classi, strutture ed enumerazioni. Nel seguente esempio si definisce un DataContract e i vari DataMember:

[DataContract]
public  class MyClass
{
	[DataMember] public string name;
	[DataMember] public int x;
	[DataMember] public bool isMyFriend;
}

Parametri per l’Attributo [DataContract]
Name e Namespace: come per ServiceContract.

[DataMember]
Questo attributo si applica a tutti i membri definiti nel DataContract.

Parametri per l’attributo [DataMember]
EmitDefaultValue: specifica se il valore di default di un campo dovrà essere serializzato.
In .NET i tipi hanno un valore di default, quindi, se avessimo necessità di ridurre la grandezza di un messaggio potremmo impostare a false questo parametro (di default è true):
[DataContract]
public class MyClass
{
[DataMember] public string name= null;
[DataMember] public int count = 0;
[DataMember(EmitDefaultValue = false)] public string Surname = null;
}

IsRequired: informa il serialization model che un data memeber deve essere presente. A false per ometterlo.

Name: come per operation contract.

Order: specifica l’ordine in cui i data members sono serializzati e deserializzati.

Message Contracts
I Message Contracts permettono di ottenere il controllo più completo sui messaggi SOAP.
Nella maggior parte dei casi non sarà necessario lavorare con i Message Contracts, perché di per sé i Data Contract sono già in grado di offrire tutto quello che ci serve.
Tuttavia, avere un controllo su di un livello più basso renderebbe possibile la comunicazione con client e altri sistemi che utilizzino un particolare tipo di WSDL, o per esempio avere la possibilità di interagire con la struttura dei messaggi SOAP per questioni inerenti la sicurezza.
La forma generica di questi attributi non è diversa dagli altri appena visti:

[MessageContract]
public class MyClass
{
	[MessageHeader]
	public string title;

	[MessageBodyMember]
	public string chapter1;
}

Parametri per l’Attributo [MessageContract]
HasProtectionLevel: determina se è impostato un livello di protezione per il messaggio. Se true, indica un livello di protezione esistente, che può essere Encrypted, Signed, o entrambi.

ProtectionLevel: Specifica il livello di protezione per il messaggio:

IsWrapper: se true, indica che il messaggio è wrappato in un documento XML, che contiene l’elemento un elemento wrapper.

WrapperName: implica la presenza del parametro IsWrapper. Se IsWrapper è impostato a true, WrapperName specifica il nome dell’elemento esterno XML:

[MessageContract (IsWrapped=true, WrapperName=”book”)]
public class Book {…}

WrapperNamespace: “lavora” con IsWrapper e permette di impostare un namespace per l’elemento wrapper.

Message Header
Questo attributo permette di specificare un campo come intestazione del messaggio SOAP.

Parametri per l’Attributo [MessageHeader]
Actor: permette di specificare un particolare endpoint come destinatario del messaggio.

MustUnderstand: utilizzato insieme al parametro Actor. Se true, L’URI specificato in actor deve “capire” l’intestazione associata per poterla correttamente processare.

[MessageContract]
public class MyClass
{
	[MessageHeader(Actor=http://localhost.com/WCF, MustUnderstand=true)]
public string bookName;
}

Name: specifica il nome dell’elemento del message contract, il quale deve essere un nome XML valido.

Namespace: specifica il nome dell’elemento del namespace del message contract.

Relay: specifica se per l’intestazione è necessario eseguire il relaying.

MessageBodyMember
Questo attributo identifica il corpo (body) di un messaggio SOAP.

Parametri per l’Attributo [MessageBodyMember]
Name: definisce il nome dell’elemento per tale membro.

Order: specifica l’ordine in cui ogni membro dovrà essere serializzato nel messaggio SOAP:

[MessageContract]
Public class Books
{
	[MessageHeader]
	public string isbn;

	[MessageHeader(Order=1)]
	public int quantity;

	[MessageHeader(Order=2)]
	public string name;
}

Conclusioni
In questa quarta parte del tutorial abbiamo visto come poter utilizzare gli attributi in WCF ed i loro parametri. Nei prossimi articoli avremo modo di implementare tali attributi in progetti più concreti.

Condivi questo articolo:

WCF – III Parte

Sergio79 — Sun, 22 Nov 2009 13:09:34 +0000

In questa terza e successive parti del tuotiral cercheremo di concretizzare alcuni importanti aspetti teorici definiti nella sezione precedente con esempi pratici.

Un primo frammento di codice è stato riportato nella prima parte del tutorial in cui è stato creato un semplice servizio WCF ospitato in una web application (il server) e consumato da una applicazione windows form (il client) attraverso il protocollo http.

Questa volta, sia il client che il server saranno basati su applicazioni windows e il protocollo di comunicazione utilizzato sarà il TCP, mentre il servizio vero e proprio sarà costruito in una libreria .NET.
Lo scopo del progetto sarà quello di far creare al servizio una directory con un file all’interno secondo le specifiche dettate dal client.

NOTA: nell’esempio sottoriportato sarà volutamente omessa una corretta gestione di eventuali eccezioni sollevate dalle applicazioni al fine di poter focalizzare l’attenzione esclusivamente sugli aspetti inerenti WCF.

Step 1 – Creazione del servizio
Avviamo Visual Studio e scegliamo la creazione di una libreria di classi dando al progetto il nome di WcfLib.
Aggiungiamo un riferimento al System.ServiceModel, quindi rinominiamo al classe auto-generata da VS in ServiceClass.
Non ci resta che scrivere la nostra solita interfaccia, quindi eseguirne la sua implementazione:

//vari using inseriti da VS
using System.ServiceModel;
using System.IO;

namespace WcfLib
{
    [ServiceContract]
    public interface IServiceClass
    {
        [OperationContract]
        bool CreateDirectoryAndFile(string directoryName, string fileName);
    }

    public class ServiceClass : IServiceClass
    {
        public bool CreateDirectoryAndFile(string directoryName, string fileName)
        {
            try
            {
                Directory.CreateDirectory(directoryName);

                File.Create(directoryName + "\\" + fileName);

                return true;
            }
            catch { return false; }
        }
    }
}

Come possiamo vedere abbiamo creato una classe di servizio con un solo metodo all’interno che si occuperà di creare una directory e un file specificati dal client attraverso i parametri che il metodo accetta in ingresso.
Salviamo e compiliamo la soluzione creando così l’assembly WcfLib.dll.

Step 2 – Creazione della Applicazione Host (il server)
Avviamo una seconda istanza di VS e modifichiamo il nome del progetto in WcfServerApplication.
Dal menu project aggiungiamo due riferimenti, uno alla dll creata (WcfLib.dll), l’altro al solito System.ServiceModel.
Aggiungiamo poi una label al nostro form e gestiamo l’evento Form Load e Form Closing:

//vari using inseriti da VS
using System.ServiceModel;
using System.ServiceModel.Description;
using WcfLib;

namespace WcfServerApplication
{
    public partial class Form1 : Form
    {
	  //oggetto service
        ServiceHost sh;

        public Form1()
        {
            InitializeComponent();

            sh = null;
        }

        private void Form1_Load(object sender, EventArgs e)
        {
            try
            {
                //indirizzo URI
                Uri tcpType = new Uri("net.tcp://localhost:12345/TcpBinding");

                //tipo di binding
                NetTcpBinding bindingType = new NetTcpBinding();

                //oggetto behavior utilizzato poi per offrire la possibilità di pubblicare i metadati all'endpoint "mex"
                ServiceMetadataBehavior mBehavior = new ServiceMetadataBehavior();

                //istanza del servizio
                sh = new ServiceHost(typeof(ServiceClass), tcpType);

                //come commentato sulla riga sopra, questa istruzione offre la possibilità di pubblicare i metadati all'endpoint "mex"
                sh.Description.Behaviors.Add(mBehavior);

                //aggiunta di due endpoint al servizio
                sh.AddServiceEndpoint(typeof(IMetadataExchange), MetadataExchangeBindings.CreateMexTcpBinding(), "mex");
                sh.AddServiceEndpoint(typeof(IServiceClass), bindingType, tcpType);

                //avvio del servizio
                sh.Open();

                //la lebel inserita nel form informa che il servizio è in esecuzione
                label1.Text = "Started...";
            }
            catch { label1.Text = "Generic Error"; }
        }

        private void Form1_FormClosing(object sender, FormClosingEventArgs e)
        {
            //chiudo la connessione
            sh.Close();
        }
    }
}

I commenti inseriti spiegano esattamente cosa è stato fatto: abbiamo creato un URI per il servizio, impostato il binding, aggiunto gli endpoint e avviato il servizio. Nel gestore evento di chiusura form poi il servizio viene stoppato.
Premiamo F5 e il risultato dovrebbe essere la visualizzazione del Form con la label che visualizza il testo “Started…”. Ovviamente se riceviamo un warning da parte di eventuali firewall installati nel sistema lasciamo pure che l’applicazione acceda alla porta logica 12345.
Ricordate inoltre che qualora ci fosse già un’applicazione in ascolto su tale porta, l’applicazione server andrebbe in errore. In tal caso cambiate il numero porta (compreso tra 1025 e 65535) e ripremete F5.
Lasciamo la windows form in esecuzione e avviamo una terza e ultima istanza di VS per la scrittura del client.

Step 3 – Creazione della Applicazione Client
Avviata la terza istanza di VS, rinominiamo il progetto in WcfClientApplication e dal menu project, scegliamo Add Service Reference.
Nella maschera che ci si presenta (non nuova agli occhi di chi ha letto la prima parte di questo tutorial) aggiungiamo l’indirizzo del nostro servizio (net.tcp://localhost:12345/TcpBinding) e rinominiamo il namespace da ServiceReference1 a TCP. Infine clicchiamo su GO e poi su OK.
Dal Solution Explorer facciamo doppio click sull’app.config e guardiamo un po’ che cosa contiene.
Rivolgiamo la nostra attenzione su due sezioni, quella relativa all’elemento binding e all’elemento endpoint.
Il primo presenta tutta una serie di proprietà impostate di default da WCF, questo perché nel codice della parte host del progetto ci siamo limitati solo ad istanziare un oggetto NetTcpBinding, senza impostare alcuna proprietà tramite l’oggetto ottenuto (il bindingType).
L’elemento endpoint contiene i soliti elementi, tra cui: address, binding e contract.
Notiamo poi un ulteriore elemento, l’ identity, figlio dell’elemento endpoint.
L’idententy property imposta l’indentià per l’endpoint associato al fine di autenticarlo.
In altre parole, questo valore (opzionale) è usato per verficare la validità del servizio. Questa tecnica di autenticazione è solitamente implementata per la prevenzione contro il “phishing”, dove un client potrebbe essere dirottato su di un diverso/non voluto/errato endpoint.

Dal Solution Explorer posizionamoci ora su Form1 e aggiungiamo un Button, quindi doppio click su di esso:

//vari using di VS
using WcfClientApplication.TCP;

namespace WcfClientApplication
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }

        private void button1_Click(object sender, EventArgs e)
        {
            try
            {
                //istanza
                ServiceClassClient client = new ServiceClassClient("NetTcpBinding_IServiceClass");

                //esecuzione remota del metodo (immettere un path non esistente)
                bool response = client.CreateDirectoryAndFile(@"C:\WCF_Folder", "WCF_File_Name.txt");

                if (response) MessageBox.Show("OK!");
                else MessageBox.Show("Error");
            }
            catch { MessageBox.Show("Error"); }
        }
    }
}

Premiamo F5 e clicchiamo sul Button.
Se tutto è andato per il verso giusto come risultato dovremmo visualizzare una messagebox con su scritto OK!.
C’è poco da dire: abbiamo istanziato un oggetto della classe del servizio e chiamato il metodo implementato passando i due parametri richiesti e verificando il valore restituito.

Conclusioni
In questa terza parte del tutorial abbiamo visto come poter creare e consumare un servizio WCF esclusivamente attraverso codice .NET sfruttando il protocollo TCP.

Condivi questo articolo:

WCF – II Parte

Sergio79 — Sat, 21 Nov 2009 22:31:58 +0000

In questa seconda parte del tutorial prenderemo in esame esclusivamente concetti teorici, in particolare vedremo come si compone l’architettura di WCF.

Architettura WCF
WCF si compone sostanzialmente di quattro elementi:
Contracts – definiscono cosa fà un servizio e le informazioni che renderà disponibili.
Service Runtime – definisce il comportamento del servizio durante la sua esecuzione
Messaging – definisce il protocollo di comunicazione e i patterns dei dati scambiati
Activation e Hosting – definiscono opzioni su come un servizio può essere avviato e dove esso sarà ospitato

Contracts
I contracts definiscono le funzionalità del servizio e le informazioni che renderà disponibili.
WCF mette a disposizione tre tipi di contracts a cui vanno aggiunti aspetti relativi alla sicurezza:
Data: determina i dati che saranno scambiati dal servizio.
Message: fornisce un controllo addizionale sui messaggi, in altre parole permette di personalizzare il tipo di formattazione dei parametri nei messaggi SOAP.
Service: informa i vari clients su cosa l’endpoint ha da offrire.
Policy e Binding: specificano importanti informazioni, tra cui quelle inerenti alla sicurezza.

Service Runtime
Il service runtime è quella parte del WCF che specifica il comportamento del servizio durante la sua esecuzione in cui distinguiamo elementi come Throttling, Error, Metadata, Istance, Transaction, Dispatch e Concurrency behavior, Message Inspection e Parameter Filtering.

Messaging
Il messaging definisce il protocollo di comunicazione e i patterns dei dati scambiati.
Il suo layer è composto da diversi canali come il WS Security, WS Reliable Messaging, HTTP, TCP, Transaction Flow, Named Pipe, MSMQ. Troviamo poi gli encoders che forniscono una serie di econding per i nostri messaggi.

Activation e Hosting
Activation e Hosting definiscono opzioni su come un servizio può essere avviato e dove esso sarà ospitato.
Un servizio WCF può risiedere all’interno di un file EXE, integrato in un’applicazione COM+, o essere eseguito come servizio di windows.

WCF Messages e Transport
I messaggi sono il cuore del WCF, cioè i dati veri e propri che vengono scambiati da un punto ad un altro.
Essi sono tutti SOAP messages formattati in XML. Possiamo quindi intendere un messaggio come un contenitore, il SOAP, al cui interno sono racchiusi gli headers e il body del messaggio.
La comunicazione dei messaggi può avvenire in tre modalità: simplex, duplex e request-reply.
Simplex prevede una comunicazione unidirezionale, il client invia un messaggio al servizio, nient’altro.
Duplex invece implementa una comunicazione bidirezionale, il client può inviare un messaggio al servizio e viceversa.
Request-reply differisce dal tipo duplex in quanto non utilizza una comunicazione bidirezionale: il client invia un messaggio al servizio e resta in attesa della risposta che il servizio invierà.
I protocolli (transport) supportati da WCF per lo scambio dei messaggi sono quattro: HTTP, TCP, MSMQ e Nimed Pipes.
Alcuni di essi integrano una built-in security, HTTPS ad esempio nel caso di HTTP.

Metodologie e Livelli di Programmazione WCF
WCF supporta diversi approcci per lo sviluppo di un servizio, i più comunemente utilizzati sono tre: Declarative, Explicit, Configuration.
Il metodo declarative si realizza attraverso gli attributi usati per definire contracts ed il comportamento del servizio.
Il metodo explicit permette di lavorare sulle classi e interfacce del servizio attraverso Il WCF object model. In altre parole con questo tipo di approccio è possibile ad esempio creare un endpoint, istanziare un servizio ed avviarlo attraverso codice .NET. Questo metodo come è facile intuire offre la massima flessibilità sul WCF programming.
Il Metodo configuration invece fà riferimento al file config di un servzio, attraverso il quale possiamo definire endpoint e altre cose ancora. Uno dei vantaggi sull’utilizzo di questa metodologia sta nel fatto che qualunque tipo di cambiamento sul file config non necessita una ricompilazione del servizio.

La tecnologia WCF offre agli sviluppatori diversi livelli di controllo in riferimento ai tipi di dati, parametri e valori restituiti attraverso il WCF programming model, tra cui: Typed, Untyped e Messaging.
Con un Typed level le operazioni sui servizi sono pressoché identiche a quelle sulle funzioni, con i loro parametri e tipi di dati restituiti.
Al contrario, con Untyped level i parametri e i tipi restituiti di un metodo non sono tipi di dati, ma messaggi.
Infine, con Messaging level è possibile ottenere pieno controllo sotto ogni aspetto sul servizio, come le operazioni sui messaggi , canali e altri dettagli di comunicazione.

Comunicazione tra applicazioni – Endpoint
Come accennato nella prima parte di questo tutorial, per poter comunicare tra loro, le applicazioni che sfruttano la tecnologia WCF utilizzano gli endpoint.
Ogni endpoint è composto da tre elementi: address, binding, contract

Address
La sintassi generica per la creazione di un address è composta da tre elementi:
protocol type – domainname | machinename [:port] – path
L’elenco seguente mostra il formato corretto per ogni tipo di address:
HTTP – http://localhost:8080/MyServicePath
HTTPS – https://localhost:8080/MyServicePath
TCP – net.tcp:// localhost:8080/MyServicePath

Gli indirizzi MSMQ, Named Pipe e IIS differiscono in alcuni aspetti, vediamo quali:

MSMQ
net.msmq://hostname / [private] / queue-name
net.msmq://localhost/msmqshare/MyQueue

Named Pipe
Come per la sintassi generica, ma senza numero porta:
net.pipe://localhost/MyServicePath

IIS
Un indirizzo IIS richiede una virtual directory e il nome file (.svc) del servizio. Se si omette il numero della porta, ne sarà impostata quella di default, la 80:
http://localhost/MyServicePath/MyServiceFileName.svc -> porta 80 impostata di default
http://localhost:8080/MyServicePath/MyServiceFileName.svc -> numero porta specificato, 8080

Binding
Il binding, set di proprietà, definisce in che modo un endpoint comunica con il mondo esterno ed ogni endpoint deve averne uno. WCF definisce nove bindings predefiniti:
BasicHttpBinding, WSHttpBinding, WSDualHttpBinding, WSFederationHttpBinding, NetTcpBinding, NetNamedPipeBinding, NetMsmqBinding, NetPeerTcpBinding, MsmgIntegrationBinding.

Contracts
Come accennato nella prima parte del tutorial, I contracts espongono l’interfaccia del servizio contenente le operazioni offerte. All’inizio di questa seconda parte inoltre abbiamo definito i tre tipi di contracts offerti da WCF, di seguito un breve esempio:

[ServiceContract]
Interface IServiceTest
{
	[OperationContract]
	void FirstMethod();

	[OperationContract]
	string SecondMethod();

	[OperationContract]
	int ThirdMethod(int x);

	void NotSharedMethod();
}

In questo esempio abbiamo definito un Service Contracts, ovvero l’interfaccia esposta dal servizio.
I primi tre metodi dichiarati nell’interfaccia sono decorati dall’attributo OperationContract, il che fa sì che tali metodi siano accessibili dalla parte client che raggiungerà e consumerà il servizio.
L’ultimo metodo non presenta alcun attributo, questo vuol dire che a differenza dei primi tre non sarà accessibile dalla parte client.

Conclusioni
In questa seconda parte del tutorial abbiamo esaminato l’architettura WCF attraverso concetti teorici.
Nei prossimi articoli ci occuperemo di più esempi pratici in grado di comprendere al meglio quanto detto sin’ora.

Condivi questo articolo:

WCF – I Parte

Sergio79 — Fri, 20 Nov 2009 21:23:31 +0000

WCF, acronimo di Windows Communication Foundation è una tecnologia Microsoft disponibile a partire dal Framework 3.0 con il principale scopo di rappresentare un modello di comunicazione tra sistemi distribuiti indipendetemente dalle piattaforme su cui ci si trova. Uno degli aspetti certamente più interessanti è che un servizio WCF può essere esposto attraverso quattro diversi protocolli: HTTP, TCP, MSMQ e Named Pipe.

Diversamente dalle tradizionali guide, libri di testo e tutorial in genere, in questa prima parte dedicata alla comprensione di Windows Communication Foundation verrà da subito presentato un brevissimo esempio su come creare un semplice servizio WCF e in che modo consumarlo.
Successivamente, verranno analizzati gli aspetti fondamentali di ciò che avremo creato.

Costruiamo il primo servizio WCF – (Il nostro server)
Apriamo Visual Studio e creiamo un nuovo progetto di tipo Web Application che chiameremo MyFirstWcfService.
Dal menu Project, scegliamo Add New item, quindi selezioniamo WCF Service.
A questo punto l’IDE di Visual Studio ci presenta l’interfaccia del nostro servizio decorata dall’attributo ServiceContract e un metodo avente come attributo OperationContract.
Modifichiamo tale metodo (void DoWork()) con string DoWork().
Successivamente, dal Solution Explorer espandiamo l’elemento relativo al servizio e cioè Service1.svc, quindi apriamo la classe Service1.svc.cs.
Questa non è altro che la classe creata da VS che eredita dall’interfaccia IService1.cs.
Avendo modificato il metodo dichiarato in tale interfaccia, dobbiamo ovviamente modificarne anche la sua implementazione, quindi da public void DoWork() a public string DoWork() e all’interno scriviamo un’unica istruzione e cioè

return DateTime.Now.ToString();

Questo è tutto, abbiamo creato il nostro primo servizio WCF ospitato in una pagina web.
Premiamo F5 per andare in debug e come possiamo vedere VS ci presenta una pagina web in cui vengono illustrate info su come testare e consumare il servizio.

Consumiamo il nostro primo servizio – (il nostro client)
Il server è in esecuzione (modalità di debug), quindi pronto a ricevere connessione da parte del client che ci accingiamo a creare.
Apriamo ancora VS e creiamo una semplicissima Windows Form che chiameremo Client, quindi dal menu Project scegliamo Add Reference Service.
Ci si presenta una finestra dove inserire l’indirizzo del servizio da raggiungere, indirizzo che troviamo nella barra degli indirizzi del Broswer (quella relativa al debug in esecuzione del nostro server).
Copiamo dunque tale indirizzo e lo immettiamo nell’etichetta Address, quindi clicchiamo su Go.
A questo punto il client parte alla ricerca del nostro servizio ed una volta trovato lo riporta nel riquadro Service. Trovato il servizio clicchiamo su Ok e nel Solution Explorer del nostro client troveremo una nuova voce e cioè ServiceReference1.
Non ci resta altro che consumare il servizio, per farlo aggiungiamo un Button alla nostra applicazione, doppio click su di esso e all’interno del gestore evento client scriviamo quanto segue:

client.Open();
this.Text = client.DoWork();
client.Close();

Anche la parte client è terminata, non ci resta altro che testare il nostro servizio, quindi premiamo F5 anche sul progetto Windows Form e clicchiamo sul Button. Il risultato dovrebbe essere la visualizzazione di data e ora sulla barra del titolo del nostro client.

Abbiamo così creato il nostro primo servizio WCF, lo abbiamo ospitato in una pagina web e infine abbiamo usufruito delle sue funzionalità (in questo caso di un solo metodo, il DoWork) attraverso un client implementato come applicazione windows.

Un po’ di teoria…

Iniziamo a comprendere che cosa abbiamo realizzato analizzando gli aspetti essenziali dei due progetti appena creati.
Dal solution explorer del progetto web apriamo il file web.config, mentre dal solution explorer dell’applicazione windows apriamo l’app.config.
In questi due file di configurazione troviamo un serie di informazioni, tra cui alcune essenziali per il corretto funzionamento della comunicazione tra la parte client e la parte server delle due applicazioni.

La comunicazione tra l’host ed i vari client (possono essere e sono nella realtà più di uno) avviene tramite delle terminazioni dette endpoint.
Un endpoint sostanzialmente “dice” dove si trova il servizio, in che modo lo si deve raggiungere e cosa esso ha da offrire.
Semplificando il tutto possiamo dire che ogni endpoint risponde a tre domande: Dove? Come? Cosa?

I tre elementi fondamentali che formano un endpoint sono:

Address – parametro che identifica la posizione (URI) del servizio e il protocollo utilizzato. (Dove?).
Binding – uno o più elementi per la configurazione del tipo di protocollo di comunicazione utilizzato e per la specifica di impostazioni aggiuntive sul tipo di protocollo scelto. (Come?)
Contract – interfaccia esposta dal servizio che specifica l’elenco delle operazioni offerte. (Cosa?).

Le caratteristiche di ogni endpoint devono essere specificate sia nel file di configurazione dell’applicazione host (il file web.config della nostra applicazione web), sia nel file di configurazione dell’applicazione client (il file app.config della nostra applicazione desktop).

Analisi di web.config
Tutte le impostazioni e configurazioni relative ai servizi WCF, sia client che server, le troviamo all’interno dell’elemento system.ServiceModel.
Esso contiene poi l’elemento services che a sua volta incorpora uno o più elementi service.

Nel nostro web.config troviamo due importanti attributi nell’elemento service e cioè name e behaviorConfiguration.
Il primo, indica il nome univoco del nostro servizio, il secondo invece rappresenta il nome dell’elemento di configurazione relative al servizio.
Nel nostro esempio il valore di behaviorConfiguration è MyFirfWcfService.Service1Behavior, riportato di conseguenza come valore dell’attributo name dell’elemento behavior, figlio di serviceBehaviors, sottoelemento di behaviors.

Come possiamo notare abbiamo poi due elementi endpoint, tra cui uno avente come valore dell’attributo address la parola mex. Il mex address non è altro che un endpoint HTTP usato per ottenere particolari informazioni sul servizio.
Entrambi gli endpoint riportano i tre elementi sopracitati, address, binding e contract.

Analisi di app.config
Localizziamo il solito system.Servicemodel e posizionamici sull’elemento endpoint, dove troviamo address, binding, contract e due attributi in più: name e bindingConfiguration.
Name identifica in modo univoco l’endpoint, mentre bindingConfiguration contiene il riferimento relativo alla sezione sul tipo di binding da utilizzare con il servizio.
Il valore di bindingConfiguration, WSHttpBinding_IService1 è lo stesso valore dell’attributo name dell’elemento binding, figlio di wsHttpBinding contenuto nella sezione bindings.

Sia nella costruzione della parte host, che client in realtà abbiamo potuto realizzare tutto o quasi in modo visuale e i file di configurazione sono stati creati in automatico.
In realtà avremmo potuto aggiungere parecchie features apportando modifiche sui file config, nelle prossime sezioni vedremo come.

Costruzione del servizio
Nel momento in cui abbiamo aggiunto il servizio al nostro progetto web, VS ha creato automaticamente l’interfaccia IService1 con un metodo chiamato DoWork.
Come si può notare, l’interfaccia è provvista dell’attributo ServiceContract, mentre il metodo è decorato dall’attributo OperationContract. Grazie ad essi, possiamo utilizzare la classe che eredita dall’interfaccia IService1 nella parte client e usufruire del metodo DoWork.
Nel nostro esempio abbiamo modificato il metodo DoWork affinchè restituisse un valore e infine abbiamo implementato l’interfaccia nella classe Service1.svc.cs.

Costruzione del client
Per poter usufruire delle funzionalità del nostro servizio abbiamo dovuto aggiungerlo come riferimento, quindi non abbiamo fatto altro che creare un’istanza di Service1Client, aprire la connessione al servizio con il metodo Open, eseguire il metodo DoWork, quindi chiudere la connessione attraverso il metodo Close.

Conclusioni
In questa prima parte abbiamo visto come creare un semplice servizio WCF ospitato in una pagina web e in che modo poterlo consumare, nel nostro esempio attraverso un‘ applicazione Windows Form, esaminando gli elementi essenziali che compongono il servizo.

Condivi questo articolo:

CsharpRepl: la shell interattiva per C#

Antonio Cangiano — Thu, 11 Sep 2008 15:50:47 +0000

Chi programma con linguaggi tipici del mondo Open Source, come Perl, Python, Ruby o Lisp, è abituato da anni ad utilizzare una shell interattiva per provare espressioni ed istruzioni al volo prima di inserirle all’interno di programmi più corposi. Nel caso di Python, il comando è python, mentre nel caso della versione ufficiale di Ruby è irb. Ad esempio, questa potrebbe essere una sessione in Ruby da parte di un principiante:

C:\>irb
>> my_string = "visualcsharp.it"
=> "visualcsharp.it"
>> my_string[0,12]
=> "visualcsharp"
>>

Questo tipo di shell non fa altro che leggere, valutare le espressioni, stamparne il risultato e poi cominciare da capo. Gli anglofoni direbbero che si tratta del cosiddetto read-eval-print loop (REPL).

C# è sempre stato un linguaggio più statico e rigido rispetto ai linguaggi sopracitati, e la mancanza di una funzione eval vera e propria ha fatto sì che per anni i programmatori C# non potessero avvalersi di uno strumento così utile come la shell interattiva. Gli sviluppatori del progetto Mono, port cross-platform del .NET framework, hanno deciso di cambiare lo status quo nella comunità C# introducendo CsharpRepl, un tool che mancava davvero dalla cassetta degli attrezzi dei dotnettari. Il tutto è possibile grazie ad un’opportuna modifica al compilatore, per fargli eseguire il codice generato invece di salvarlo in un file. Con CsharpRepl, sarà ora possibile eseguire snippet di codice senza dover compilare ed eseguire l’intero progetto:

csharp> using System.IO;
csharp> from f in Directory.GetFiles ("/etc")
      >   let fi = new FileInfo (f)
      >   where fi.LastWriteTime > DateTime.Now-TimeSpan.FromDays(7) select f;
{ "/etc/adjtime", "/etc/asound.state", "/etc/mtab", "/etc/printcap", "/etc/resolv.conf" }
csharp>

La pagina del tool ha maggiori informazioni su come installare e usare il comando csharp (che richiede Mono 2.2).

Condivi questo articolo: