Let's look at the template code for a bit. It's nothing like the ASMX code, because remember — WCF is different. You can get it to do more or less the same thing as ASMX, but it isn't the same technology. Here's what the WCF code looks like:

1 namespace SHARPService
2 {
3     // NOTE: You can use the "Rename" command on the "Refactor" menu to change
   the class name "Service1" in code, svc and config file together.
   public class Service1 : IService1
4     {

5      public string GetData(int value)
6      {
7          return string.Format("You entered: {0}", value);
8      }
9
10     public CompositeType GetDataUsingDataContract(CompositeType composite)
11     {
12         if (composite == null)
13         {
14            throw new ArgumentNullException("composite");
15         }
16         if (composite.BoolValue)
17         {
18             composite.StringValue += "Suffix";
19         }
20         return composite;
21      }
22   }
23 }

There are a few of things of interest here:

The GetDataUsingContract method makes a lot more sense when you take a look at IService.cs below.

1  namespace SHARPService
2  {
3      // NOTE: You can use the "Rename" command on the "Refactor" menu to change
   the interface name "IService1" in both code and config file together.
4    [ServiceContract]
5    public interface IService1
6    {
7
8        [OperationContract]
9        string GetData(int value);
10
11       [OperationContract]
12       CompositeType GetDataUsingDataContract(CompositeType composite);
13
14       // TODO: Add your service operations here
15    }
16    // Use a data contract as illustrated in the sample below to add composite
   types to service operations.
17   [DataContract]
18   public class CompositeType
19   {
20      bool boolValue = true;
21      string stringValue = "Hello ";
22

23      [DataMember]
24      public bool BoolValue
25      {
26          get { return boolValue; }
27          set { boolValue = value; }
28      }
29
30      [DataMember]
31      public string StringValue
32      {
33          get { return stringValue; }
34          set { stringValue = value; }
35      }
36   }
37 }

Hey, lookie here! Decorations for the classes! And the mythical CompositeType! Don't let the name fool you — this code is just a class, like any other class. It is just like the List<T> of Conference types that we returned from the ASMX service. The Framework doesn't have a Conference class — we defined it in the entity Data Model.

Line 4 has a [ServiceContract] attribute that is similar to the [WebClass] of ASMX, and the [OperationContract] too, is similar to [WebMethod], at least in usage.

Then we have the DataContract. This allows us to decorate classes — even in our domain model — with attributes that define which classes and methods get to go out to the service if and when the class is ever called into service (so to speak).

Like we do in Chapter 2, let's just start with a service that returns the list of our conferences. Follow these steps:

Why is this? WCF enables you to use things other than HTTP (the protocol that is the backbone of the Web) for transport of message details. (You can find a few examples in the sidebar, "Using different endpoints.")

The only downside to WCF is the configuration. Because WCF is the be-all and end-all of the remote procedure call in Windows, there are enough configuration options to handle it all. Gets a little chippy at times.

Fortunately, there is the Service Configuration Editor. Shown in Figure 3-5, the Service Configuration Editor allows you to manage the complex options that are WCF's primary power.

Using different endpoints

The whole point of WCF is that you can write one service and then have IIS accept a lot of different protocols calling on the same code. Sure, we can do SOAP, like we did in ASMX. We also can do a lot of other protocols. Here is the breakdown of all the different endpoints, according to MSDN:

• BasicHttpBinding: A binding that is suitable for communicating with WS-Basic Profile conformant Web services (for example, ASP.NET Web services [ASMX]-based services). This binding uses HTTP as the transport and text/XML as the default message encoding.

• WSHttpBinding: A secure and interoperable binding that is suitable for non-duplex service contracts.

• WSDualHttpBinding: A secure and interoperable binding that is suitable for duplex service contracts or communication through SOAP intermediaries.

• WSFederationHttpBinding: A secure and interoperable binding that supports the WS-Federation protocol that enables organizations that are in a federation to efficiently authenticate and authorize users.

• NetTcpBinding: A secure and optimized binding suitable for cross-machine communication between WCF applications.

• NetNamedPipeBinding: A secure, reliable, optimized binding that is suitable for on-machine communication between WCF applications.

• NetMsmqBinding: A queued binding that is suitable for cross-machine communication between WCF applications.

• NetPeerTcpBinding: A binding that enables secure, multiple machine communication.

• MsmqIntegrationBinding: A binding that is suitable for cross-machine communication between a WCF application and existing Message Queuing applications.

• BasicHttpContextBinding: A binding that is suitable for communicating with WS-Basic Profile conformant Web services that enables HTTP cookies to be used to exchange context.

• NetTcpContextBinding: A secure and optimized binding suitable for cross-machine communication between WCF applications that enables SOAP headers to be used to exchange context.

• WebHttpBinding: A binding used to configure endpoints for WCF Web services that are exposed through HTTP requests instead of SOAP messages.

• WSHttpContextBinding: A secure and interoperable binding that is suitable for non-duplex service contracts that enables SOAP headers to be used to exchange context.

So when do you use what? Well, if you want to have two .NET applications communicate, or the layers of a single application communicate, then use NetTcpBinding. If you are cross-platform communicating, then use WSHttpBinding.

Only if for some reason those don't work do you start to look into the others. Oh, and remember that you can have many endpoints for the same service. Don't use SOAP for a data layer. Just make a separate SOAP header if you need cross-platform support.

Figure 3-5. The Service Configuration Editor.

Using the Service Configuration Editor for adding a service endpoint seems more complex than it ought to be. Just follow these steps:

Back in Visual Studio–land, open the Web.Config file in the code editor by double-clicking it in the Solution Explorer. You'll see that the ServiceModel section has been edited with your new endpoint. The code looks like this:

<system.serviceModel>
  <services>
    <service name="SHARPService.Registration">
      <clear />
      <endpoint address="http://localhost" binding="basicHttpBinding"
        bindingConfiguration="" name="SharpHttp" contract="SHARPService.
  IRegistration" />
    </service>
  </services>
  <behaviors>
    <serviceBehaviors>
      <behavior>
        <!-- To avoid disclosing metadata information, set the value below to
  false and remove the metadata endpoint above before deployment -->
        <serviceMetadata httpGetEnabled="true" />
        <!-- To receive exception details in faults for debugging purposes, set
  the value below to true. Set to false before deployment to avoid disclosing
  exception information -->
        <serviceDebug includeExceptionDetailInFaults="false" />
      </behavior>
    </serviceBehaviors>
  </behaviors>
</system.serviceModel>

Now, would that have been easier to do in code? Maybe. Why is the service editor around then? Because when you get a lot of bindings, it can get pretty messy in there. Check out the sidebar on using other bindings to get an idea.

If you use IIS to host the service, deployment of WCF is the same as ASMX. You can effectively copy the .svc and .config files with the compiled binaries and have a working Web application.

The better way to deploy in Visual Studio 2010 is to use the Publish Web tool. If you right-click on the project and select Publish, you'll have the option to set up a repeatable profile so that you don't forget anything. (See Figure 3-8.)

This panel does all the things that you would have to do yourself:

You can set up the profile once, and then reuse it every time you have to re-publish the application. Pretty slick.

All there is left to do is use it.

As one would expect, setting up a service reference for a WCF service is a lot like setting up a reference for an ASMX service. You still right-click and select Add Service Reference, you still get the dialog box shown in Figure 3-9, and you still can reference the service easily in your code.

Two things to remember:

The filename thing is workable, but the binding is important. Keep in mind that the selecting of a binding is invisible to the developer, but it has a significant impact on functionality and especially performance. The decision of which to use is not to be made lightly; it should be done only after much research and needs analysis.

Figure 3-9. Adding the WCF service reference.