Il Client
Una volta creato il server è il momento di passare alla stesura del codice necessario alla generazione di un client che per semplicità è un'applicazione WinForm. La scelta effettuata in precedenza di fornire un endpoint di esposizione dei metadati permette una facile generazione del proxy che i client devono utilizzare per accedere al servizio. Non solo, oltre al proxy si può generare anche la configurazione in modo da ridurre al minimo il lavoro infrastrutturale dello sviluppatore. L'utility che permette tale magia è SvcUtil.exe. Ad esempio, lanciando il comando "svcutil net.tcp://localhost:8001/chat" si ottiene una classe C# ed un file di configurazione già pronti per l'uso.
Il file di configurazione del client per connettersi al servizio è il seguente:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.serviceModel>
<bindings>
<netTcpBinding>
<binding name="NetTcpBinding_IChat"
<security mode="None"/>
</binding>
</netTcpBinding>
</bindings>
<client>
<endpoint address="net.tcp://localhost:8001/chat/Service"
binding="netTcpBinding" bindingConfiguration="NetTcpBinding_IChat"
contract="IChat" name="NetTcpBinding_IChat" />
</client>
</system.serviceModel>
</configuration>La form che visualizza la chat è la seguente, con alcune omissioni per questioni di semplicità.
public partial class Form1 : Form, IChatCallback {
string name = Guid.NewGuid().ToString();
private void SignIn_Click(object sender, EventArgs e) {
InstanceContext site = new InstanceContext(this);
proxy = new DuplexChannelFactory<IChat>(site, "NetTcpBinding_IChat").CreateChannel();
string[] users = proxy.SignIn(name);
lstbUsers.DataSource = users;
}
private void btnSend_Click(object sender, EventArgs e) {
proxy.SendMessage(name, message.Text);
}
public void ReceiveMessage(string message) {
chat.Text += message + Environment.NewLine;
}
public void UserJoin(string nick) {
chat.Text += nick + " signed in" + Environment.NewLine;
}
public void UserLeave(string nick) {
chat.Text += nick + "signed out" + Environment.NewLine;
}
}Innanzitutto, la form implementa l'interfaccia IChatCallback che è il contratto che specifica i metodi di callback che il server può invocare sul client. Questi metodi in realtà non fanno nulla se non notificare all'utente le connessioni, le disconnessioni e l'invio dei messaggi. Il vero cuore del client è nel metodo SignIn_Click. Infatti , è qui che viene istanziato il canale verso il server e che viene effettuato il SignIn nella chat con conseguente popolamento della lista degli utenti connessi ricevuti dal metodo. La possibilità di ricevere callback dal server sta nella classe DuplexChannelFactory. Questa classe, a differenza di ChannelFactory, istanzia un canale bidirezionale permettendo di avere il doppio colloquio.
Conclusioni
In quest'articolo sono state illustrate caratteristiche avanzate della gestione dei servizi, infatti sono emerse problematiche come callback, sincronizzazione/Thread-Safety, pubblicazione di metadati, ecc. Queste caratteristiche sono facilmente gestibili all'interno di WCF con un dispendio di energie minimo rispetto al passato. Basta pensare a come è possibile fare lo stesso lavoro sfruttando remoting del .NET Framework 1.x o 2.0 e ci si renderà conto che in quel caso la realizzazione è molto più difficile. Per non parlare del P2P, oggetto di discussione in un prossimo articolo, realizzabile con un dispendio di energie ancora più inferiore con risultati prestazionali superiori.
Attenzione: Questo articolo contiene un allegato
Contenuti dell'articolo
- Pagina 1
- Pagina 2
- Pagina 5
- Pagina 6
Aggiungi un nuovo commento »»»
Per inserire un commento, devi registrarti alla nostra community.
Difficoltà
Utilità
Stampa 
Download
10annidi.ASPItalia.com: iscriviti alla competizione e vinci fantastici premi ogni mese!
ciao Stefano, bell'articolo, molto interessante l'invocazione asincrona dei delegati sottoscritti all'evento.- C'é un motivo per cui non hai usato la ...
Continua »»» | Rispondi »»»