There had to be some significant changes made to how a client consumes a service if Microsoft wanted to preserve the boundaries are explicit tenet. If you look at how an ASMX client works today, you do not make any explicit decisions about how you want to communicate with a service. Of course, I should mention that there were not a variety of options like there are today with WCF services.

Another primary tenet of service orientation is that communication is policy-based. The configuration at the client will specify all of the policy settings that have to match the service features in order for communication to occur. The following is an example of a client configuration file (App.config), a simple command window client (ShowMeTheFunny.cs), and a generated proxy class (FamilyGuyQuotes.cs).

App.config

<system.serviceModel>

<client>

<endpoint configurationName="default" address="http://tomlaptop/Service/FamilyGuyQuotes.svc"

bindingConfiguration="IFamilyGuyGoodies" bindingSectionName="customBinding"

contractType="IFamilyGuyGoodies">

<addressProperties identityData="" identityType="None" isAddressPrivate="false" />

</endpoint>

</client>

<bindings>

<customBinding>

<binding configurationName="IFamilyGuyGoodies">

<contextFlow transactions="Ignore" transactionHeaderFormat="OleTx" logicalThreadId="Ignore" locale="Ignore" />

<httpTransport manualAddressing="false" maxMessageSize="65536"

authenticationScheme="Anonymous" bypassProxyOnLocal="false"

hostnameComparisonMode="StrongWildcard" mapAddressingHeadersToHttpHeaders="true"

proxyAuthenticationScheme="Anonymous" realm="" transferTimeout="00:01:00"

useSystemWebProxy="true" />

<textMessageEncoding maxReadPoolSize="64" maxWritePoolSize="16"

messageVersion="Soap11Addressing1" encoding="utf-8" />

</binding>

</customBinding>

</bindings>

</system.serviceModel>

 

ShowMeTheFunny.cs

using (FamilyGuyGoodiesProxy proxy = new FamilyGuyGoodiesProxy("default"))

{

string s = Console.ReadLine();

string result = proxy.GetQuote(s);

Console.WriteLine("Quote From {0} is: {1}", s, result);

}

 

FamilyGuyQuotes.cs (Generated Proxy)

[System.ServiceModel.ServiceContractAttribute(Namespace="http://familyguyquotes")]

public interface IFamilyGuyGoodies

{ [return:]

string GetQuote(string familyGuyCharacter);

}

 

public partial class FamilyGuyGoodiesProxy : System.ServiceModel.ProxyBase<IFamilyGuyGoodies>, IFamilyGuyGoodies

{

public FamilyGuyGoodiesProxy(string configurationName) :

base(configurationName)

{

}

public string GetQuote(string familyGuyCharacter)

{

return base.InnerProxy.GetQuote(familyGuyCharacter);

}

}

What will probably stand out initially with the code above is the confusing nature of the app.config. Not to worry, this is simply the default that is generated from the SvcUtil.exe that comes with WCF. It is my understanding that this will be simplified in an upcoming release.

Notice that it specifies a custom binding for me and set every property possible. What would be better is if it would have allowed me to specify the Basic Profile binding and set the configuration correctly to reflect that. I am sure this is something the WCF team is looking into.

The code that actually invokes the service is very simple. Notice, we specify the configuration section that will give us all of the detail we need to invoke the actual request to the service. This is, of course, a configuration-based approach. Also notice that the service is wrapped in a using() block. This is because services written with WCF have explicit Close() operations that release the resources being held by the client. Please note, this is a subset of the code sample available for download.

The last code snippet above is the generated proxy class named FamilyGuyQuotes.cs. I have removed many of the attributes in this class to help improve readability. If you want to get the full picture, you will need to look at the code available for download. What you should be able to recognize from this snippet is the utilization of generics for creating the proxy as the same type I defined in the service called IFamilyGuyGoodies. You probably will also notice some other significant differences to the ASMX proxies. Notice there are no Begin and End methods defined by default. These methods are only created if you are explicitly using async communication. Also, youll notice I have only used simple types at this time, so there are no data elements defined. If I had, you would have seen that the existing limitations with proxy type creation have been resolved. The proxy types will not use fields when properties are defined; in previous versions of VS.NET, the proxies would be converted to public fields by default. This issue caused some headaches when attempting to bind those types to server controls in ASP.NET.

Doesnt This Seem a Little Excessive?

On the surface this does appear to be a little overwhelming. The configuration is very explicit, and the proxy is using some very new features found in .NET 2.0. I will add that VS.NET 2005 still has very little support for working with WCF services. What you will find is that youll have to spend a lot of time working with the command window, and youll spend some time mapping file types to VS.NET because it really doesnt understand what a .svc is. Fortunately, in my conversations with the WCF team, they have committed to making these things much easier by the time they RTM. The Add Reference capability will be there at some point, and the configuration detail will be simplified to include only those items that are necessary for communication.

What I do hope is that they do not oversimplify things. This is a huge step toward requiring explicit definition of the communications between clients and services. This helps a client reinforce that it does understand its boundaries at the time it adds a reference and wants to start invoking operations.