WCF – VI Parte

By Sergio79. Filed under .NET Framework, Articoli, C#, WCF

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: