BlogServiceHost.Create()

WCF & Azure - Il blog di Fabio Cozzolino

Recent Posts

Tags

My

Twitter

Community

Archives

Email Notifications

Social Bar Widget

June 2007 - Posts

[OT] Il piacere della lettura ...

Mi piace leggere. E molto. Leggo di tutto, dai blog ai giornali, ma i libri ... i libri hanno un fascino tutto loro. L'autore di questo post ha perfettamente ragione: ogni libro è sacro. I miei libri sono sempre come nuovi, sembra quasi che io non li abbia mai usati. Non so perchè ma tendo a mantenerli intatti. Quando sono in libreria li apro con una attenzione tale che sembra quasi io abbia paura di violare qualcosa di ignoto. Non mi piace un genere particolare. Vado dal legal-thriller/thriller fino anche a qualcosa di più leggero. Dai classici ai moderni. Così, come capita. A volte è una copertina a colpirmi, altre semplicemente il titolo, altre ancora il cosiddetto "passaparola". Difficilmente ho abbandonato la lettura di un libro (purtroppo un paio di volte è successo).

Così, ora, ho deciso di tenere traccia dei libri che leggo in questa pagina. Forse non sono tanti, ma tenete presente che circa il 90% dei libri in lista li ho letti negli ultimi 2 anni. Con il tempo ho intenzione di creare delle schede con le mie impressioni su ogni titolo, e magari poter leggere anche i commenti di altri lettori.

Buona lettura ...

[WCF#13] L'Ordine dei Bindings Elements

No, non è un nuovo ordine religioso Big Smile, ma semplicemente l'ordine (nel senso di prima uno, poi l'altro, Stick out tongue) da rispettare per la defininizione dei vari binding elements all'interno di un binding personalizzato. Ogni binding element costituisce uno step ben definito del channel stack. Trasporto, encoding, sicurezza non sono altro che specifici binding element e, come è facile intuire, devono rispettare un preciso ordine durante la ricezione/invio dei messaggi.

Ogni binding di WCF è costituito da una serie di elementi. Tra questi, due sono quelli fondamentali per il corretto funzionamento e sono comuni a tutti i binding: il Trasport Binding Element e l'Encoding Binding Element.

image

Se utilizziamo uno dei binding predefiniti di WCF (WSHttpBinding, NetTcpBinding, ecc...) questi elementi vengono automaticamente inseriti "nel posto giusto". Se, invece, utilizziamo un CustomBinding, allora dobbiamo fare attenzione all'ordine di inserimento nella relativa collection:

// Prepariamo i Binding Elements SecurityBindingElement security = SecurityBindingElement.CreateUserNameOverTransportBindingElement(); TextMessageEncodingBindingElement text = new TextMessageEncodingBindingElement(); HttpTransportBindingElement http = new HttpTransportBindingElement(); // Creiamo il Binding CustomBinding custom = new CustomBinding(); custom.Elements.Add(security); custom.Elements.Add(text); custom.Elements.Add(http);

Se, ad esempio, spostassimo l'HttpTransportBindingElement come primo elemento incappiamo in questo errore:

In Binding 'CustomBinding', TransportBindingElement 'HttpTransportBindingElement' does not appear last in the BindingElementCollection.  Please change the order of elements such that the TransportBindingElement is last.

bye ...

Posted: Jun 27 2007, 12:25 AM by Fabio.Cozzolino | with no comments
Filed under:
WCF Webcast Series

Sul blog di Michele Leroux Bustamante è stato pubblicato l'elenco completo di link ad una serie di webcast su WCF. Anche se in inglese consiglio a tutti di seguirli perchè veramente interessanti.

http://www.dasblonde.net/2007/06/24/WCFWebcastSeries.aspx

Posted: Jun 26 2007, 01:28 PM by Fabio.Cozzolino | with no comments
Filed under: ,
[WCF#12] I DataContracts e le interfacce

I nostri modelli potrebbero portarci, talvolta, ad esporre dai servizi delle interfacce invece che delle classi concrete. Prescindendo dai motivi di tali scelte, una interfaccia non può essere decorata come DataContract semplicemente perchè non vi può essere messo l'attributo DataContractAttribute.

Per raggirare questo problema ed utilizzare una interfaccia come parametro o come return value di una nostra operation, possiamo sfruttare l'attributo ServiceKnownTypeAttribute. Questo attributo ci consente di definire i tipi che devono essere esportati nel contratto del nostro servizio per renderli poi utilizzabili dai diversi client. Provo a spiegarmi meglio con un esempio. Dichiariamo il nostro servizio:

[ServiceContract()] public interface IService { [OperationContract()] [ServiceKnownType(typeof(HelloContract))] string Hello(IHelloContract hello); } public interface IHelloContract { string FirstName{get;set;} string LastName{get;set;} }

Notate l'utilizzo dell'attributo ServiceKnowType. Il tipo HelloContract è l'implementazione dell'interfaccia IHelloContract. Analizzando il WSDL generato dal nostro servizio vediamo come è stato creato lo schema relativo al tipo HelloContract:

<xs:schema elementFormDefault="qualified" targetNamespace="http://schemas.datacontract.org/2004/07/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://schemas.datacontract.org/2004/07/"> <xs:complexType name="HelloContract"> <xs:sequence> <xs:element minOccurs="0" name="FirstName" nillable="true" type="xs:string"/> <xs:element minOccurs="0" name="LastName" nillable="true" type="xs:string"/> </xs:sequence> </xs:complexType> <xs:element name="HelloContract" nillable="true" type="tns:HelloContract"/> </xs:schema>

Infine vediamo il codice generato sul proxy client:

[DebuggerStepThroughAttribute()] [GeneratedCodeAttribute("System.ServiceModel", "3.0.0.0")] public partial class ServiceClient : ClientBase<localhost.IService>, localhost.IService { public string Hello(object hello1) { return base.Channel.Hello(hello1); } }

Notiamo che il parametro che in input sul servizio era di tipo IHelloContract, qui è semplicemente di tipo object. Questo perchè ovviamente WCF non è in grado di riprodurre l'interfaccia sul client, ma è in grado di creare i tipi indicati con il ServiceKnownType:

ServiceClient

Il tutto è usabilissimo dal client:

ServiceClient client = new ServiceClient(); HelloContract hello = new HelloContract(); hello.FirstName = "Fabio"; hello.LastName = "Cozzolino"; string risposta = client.Hello(hello);

Ovviamente nulla ci vieta di modificare il client ed introdurre l'interfaccia come parametro per riprodurre il comportamento lato server. Ma questa è un'altra storia ... Big Smile

bye...

Posted: Jun 16 2007, 07:55 PM by Fabio.Cozzolino | with no comments
Filed under:
DotNetSide su MSDN

C'era una grande mancanza sul sito Microsoft dedicato alle Community Italiane. Ora questo vuoto è stato colmato. Stick out tongue

msdn_community

Grazie a tutti quelli che lo hanno reso possibile !!!

[WCF#11] Il dilemma del WSDL frammentato ...

Seguo costantemente il blog di Christian Weyer ma non so perchè questo post mi era sfuggito. Propone una interessante soluzione al problema del WSDL "frammentato".

Qualche tempo fa, infatti, tutto questo era capitato anche a me. Un client non-.NET non era in grado di ricostruirsi il suo proxy proprio perchè non riusciva a recuperare tutte le informazioni fornite di default dal WSDL prodotto con WCF. Questo è dovuto al fatto che il WSDL viene generato con una serie di import che puntano all'URL dove è posizionato ogni frammento come, ad esempio, i vari schema xsd che definiscono la composizione dei messaggi.

In quella occasione ho semplicemente compattato tutto a manina ed utilizzando il tip descritto in questo post ho pubblicato il WSDL modificato.

Christian Weyer nel suo post propone, invece, l'utilizzo di un IWsdlExportExtension, che io avevo sfruttato per disabilitare WS-Policy, per intervenire nel processo di generazione del WSDL e modificarlo al volo. Soluzione davvero interessante.

Thanks Christian !!! Smile

Posted: Jun 09 2007, 11:21 AM by Fabio.Cozzolino | with no comments
Filed under:
[WCF#10] Considerazioni ...

Da tempo noto come sul web, nei vari forums e blogs, si parla molto spesso di WF (Windows Workflow Foundation) e di WPF (Windows Presentation Foundation), mentre le discussioni su WCF sono molto più rare. Probabilmente questo è dovuto al fatto che c'è dietro molta più curiosità verso queste due tecnologie che di fatto rappresentano una novità (quasi) assoluta.

Personalmente ritengo che l'architettura di WCF abbia qualcosa di semplicemente speciale. Con ciò non voglio assolutamente sminuire WPF e WF, anche perchè le conosco molto poco e perciò potrei facilmente essere smentito. Il grado di estensibilità offerto in WCF, però, è tale che si può fare tutto o quasi.

WCF mi stupisce ogni giorno di più. Qualche piccola pecca c'è, dopotutto siamo alla prima versione, ma mi accorgo che effettivamente tutti gli anni di gestazione passati negli uffici Microsoft hanno dato degli ottimi frutti, regalandoci un framework in grado di rispondere, in un modo o nell'altro, a gran parte delle esigenze di chi sviluppa applicazioni Service-Oriented.

Molta gente sbaglia nel paragonare WCF ai "classici" web service, a .NET Remoting o a qualsiasi altra tecnologia che fino ad oggi abbiamo utilizzato. WCF non intende sostituire tutto quello che c'è, ma ne rappresenta la semplice e naturale evoluzione.

WCF ha le sue applicazioni, così come ASMX, .NET Remoting o Enterprise Services hanno le proprie. Dipende dalla tipologia di applicazione che stiamo sviluppando e dal tipo di evoluzione che probabilmente essa avrà.

Sono considerazioni sparse, lo so, è da tempo che ci pensavo e ho avuto l'occasione di parlarne con qualcuno. Mi interessa sapere cosa ne pensate, ma nel frattempo non posso fare a meno di dire:

Lunga vita a WCF ...

Posted: Jun 03 2007, 08:25 PM by Fabio.Cozzolino | with no comments
Filed under:
[WCF#09] Query XPath sul messaggio

Paolo ha pubblicato qualche giorno fa un post in cui descrive come poter eseguire ricerche XPath direttamente sul messaggio. Il tutto si basa sull'uso della classe XPathMessageContext che consente di utilizzare XPath, appunto, direttamente sui messaggi SOAP. La soluzione è molto interessante e ho deciso di proporne una variante in cui invece di passare dall'XmlDocument si passa attraverso la classe MessageBuffer:

// Utilizza la copia per creare l'XPathNavigator MessageBuffer buffer = message.CreateBufferedCopy(int.MaxValue); XPathNavigator messageNavigator = buffer.CreateNavigator();

In questo modo utilizziamo una classe interna ottimizzata proprio per questo scopo. Da quello che ho potuto testare cambia veramente poco in termini di performance ma possiamo sfruttare la classe interna SeekableMessageNavigator che è appositamente ottimizzata per questo ...

 

bye ...

Posted: Jun 02 2007, 06:48 PM by Fabio.Cozzolino | with no comments
Filed under: