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:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.serviceModel>
    <services>
      <service behaviorConfiguration="myBehave">
        <host>
          <baseAddresses>
            <add baseAddress="net.tcp://localhost:12345/tcp"/>
          </baseAddresses>
        </host>
        <endpoint address="" binding="netTcpBinding" contract="WindowsService1.IServiceClass"/>
        <endpoint address="mex" binding="mexTcpBinding" contract="IMetadataExchange"/>
      </servce>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name="myBehave">
          <serviceDebug includeExceptionDetailInFaults="false"/>
          <serviceMetadata httpGetEnabled="false"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>

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:

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:

//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<WcfClientApplication.TCP.IServiceClass> factory =
                    new ChannelFactory<IServiceClass>("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<CreateDirectoryAndFileCompletedEventArgs>(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<IServiceClass>.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:

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:

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:

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:

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:

Una di queste funzioni è sicuramente il copia/incolla di interi record, funzione che non è presente nella classe DataGridView.

Ma questo non vuol dire che non si possa implementare!

Prima di tutto dobbiamo impostare la proprietà ClipboardCopyMode del DataGridView:

this.dataGridView.ClipboardCopyMode = DataGridViewClipboardCopyMode.EnableWithoutHeaderText;

L’enumerazione DataGridViewClipboardCopyMode contiene quattro valori: con EnableWithoutHeaderText è possibile copiare negli Appunti i valori di testo delle celle selezionate. Il testo dell’intestazione non viene incluso.

Andiamo ora a implementare i metodi Copia e Incolla.
Il metodo Copia è semplicissimo:

private void Copia()
{
    Clipboard.SetDataObject(this.dataGridView.GetClipboardContent());
}

Con questo codice viene copiato nella Clipboard, attraverso il metodo static Clipboard.SetDataObject, i dati che tornano dal metodo GetClipboardContent() della classe DataGridView. Dati che vengono formattati in base al valore della proprietà ClipboardCopyMode.

Purtroppo il metodo Incolla non è così immediato:

        private void Incolla()
        {
            char[] rowSplitter = { '\r', '\n' };
            char[] columnsSplitter = { '\t' };
            string[] campi;
            //Ottengo le informazioni contenute negli appunti
            string appunti = Clipboard.GetText();
            //Divido gli appunti in righe
            string[] righe = appunti.Split(rowSplitter, StringSplitOptions.RemoveEmptyEntries); 

            foreach (string str in righe)
            {
                //Divido la stringa in campi e aggiungo la riga del DataGridView
                campi = str.Split(columnsSplitter);
                if (campi.Length == 2)
                {
                    this.bindingSource.AddNew();
                    DataRowView rowView =
                            (DataRowView)this.bindingSource.Current; 

                    if (campi[3] == String.Empty)
                        rowView[5] = DBNull.Value;
                    else
                        rowView[5] = int.Parse(campi[3]); 

                    if (campi[4] == String.Empty)
                        rowView[4] = DBNull.Value;
                    else
                        rowView[4] = int.Parse(campi[4]);
                }
            }
        }

Il procedimento è però abbastanza semplice: prima di tutto otteniamo i dati presenti nella Clipboard attraverso il metodo statico Clipboard.GetText(). Quindi i dati così ottenuti vengono divisi prima in righe, splittandoli sui valori ‘\r’ ‘\n’, e in seguito vengono splittati in colonne (\t). I dati così ottenuti vengono inseriti nel controllo DataGridView.

A questo punto resta da implementare solo il ContextMenu che conterrà i menu Copia e Incolla con i rispettivi eventi Click che richiamano i metodi Copia e Incolla.

Per fare questo si deve prima aggiungere un ContextMenu al progetto e poi associarlo al controllo DataGridView intercettando l’evento RowContextMenuStripNeeded del DataGridView stesso:

        private void dataGridView_RowContextMenuStripNeeded(object sender, DataGridViewRowContextMenuStripNeededEventArgs e)
        {
            e.ContextMenuStrip = this.contextMenuCopiaIncolla;
        }

Praticamente, ogni volta che si preme col tasto destro sul DataGridView, viene generato l’evento RowContextMenuStripNeeded che imposta la proprietà e.ContextMenuStrip sul contextMenu che contiene i menu Copia e Incolla.

Questo codice è solo un esempio. Il metodo Incolla si può adattare in base alle esigenze: per esempio si può valorizzare la chiave primaria se presente, oppure si può decidere di includere nella ClipBoard anche l’intestazione delle colonne e quindi incollare tutto in Excel.

Condivi questo articolo:

namespace Extensions
{
    static class StringExtension
    {
        ///

        /// Conta quante vocali sono presenti.
        /// 

        public static int ContaVocali(this String str)
        {
            // Codice che conta quante vocali sono presenti in str...
        }
    }
}

All’interno del namespace Extensions è presenta una classe statica StringExtension con un metodo static ContaVocali. Questo metodo è esattamente come un normalissimo metodo statico, con una caratteristica in più: la presenza della keyword this al primo parametro. E’ infatti grazie a questo parametro che viene indicato al compliatore di C# che tipo si vuole estendere, in questo caso la classe String.

Ora si può chiamare il metodo ContaVocali come se fosse un normalissimo metodo di istanza di String:

using Extensions;
static void Main()
{
    string prova = “ciao”;
    int numVocali = prova.ContaVocali();
}

Da notare che ho fatto riferimento al namespace nel quale è contenuto l’extension method, altrimenti non sarebbe stato visibile.

Altra nota da sottolienare è che gli extensions methods non violano il concetto di incapsulamento perché, essendo in realta dei metodi statici, non possono vedere i campi privati di istanza della classe che estendono.

Questa nuova funzionalitàdi C# può sembrare un pò inutile, ma non si deve andare tanto lontano per trovare un loro utilizzo pratico: LINQ si basa fortemente sugli Extensions Methods!
L’importante è saperli usare con moderazione e dove strettamente necessario, ricordando che il miglior modo per estendere un tipo è quello di usare l’ereditarietà.

Condivi questo articolo:

var  i = 5;
var s = “ciao”;
var numeri = new int[] {1, 2, 3};
var conn = new OleDbConnection();

Nonostante sembri il contrario il codice sopra è fortemente tipizzato, perché, come ho già detto, il tipo viene scelto dal compilatore.
Se infatti in Visual Studio si posiziona il cursore sulla parola var, l’IntelliSense ci indica il tipo effettivo della variabile.
Proprio per questo il tipo della variabile non può “variare”:

var i = 5;
i = “Ciao” //Errore: Impossibile convertire in modo implicito il tipo String in int
var i = null; //Errore

Per poter usare le Implicitly typed local variables si devono seguire delle semplici regole:

• Ovviamente, come dice il nome, non possono essere variabili globali ma solo locali;
• La dichiarazione deve includere un inizializzatore. Per esempio il seguente codice darebbe errore:

  var i; //Errore 

• L’inizializzatore deve essere un’espressione. Non può essere un oggetto

  OleDbConnection conn;
  OleDbConnection conn2 = new OleDbConnection();
  var c = conn; //Errore
  var c2 = conn2; //GIUSTO

• Le variabili implicite non accettano valori null

L’utilizzo di var diventa comodissimo nei cicli foreach. Per esempio:

int[] numeri = {1,2, 3};
foreach(var n in numeri)
	//fai qualcosa

Un’ultima osservazione: in C# 3.0 questo codice

            int var = 5;
            var k = var;

funziona perfettamente!

Condivi questo articolo: