• Manually creating and consuming WCF services without the help of Visual Studio templates and related tools. This will provide you with a picture of the bare necessities you need to create, host, and consume a WCF service so that you understand the underlying programming model.
• Creating WCF services using various Visual Studio project and service templates, leveraging configuration tools, and generating code to consume services.
• Approaches to assembly allocation and service hosting over various protocols.
• The importance of service metadata for publishing and consuming services.

Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.

You can find the OASIS SOA Reference Model documentation at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm.

• Service boundaries are explicit.
• Services are autonomous.
• Clients and services share contracts, not code.
• Compatibility is based on policy.

Where WCF improves on earlier technologies in support of explicit boundaries is in the way contract design and deployment are handled. With WCF, you explicitly define the contract and opt-in every operation and data element that you intend to expose publicly. WCF also goes beyond location transparency with protocol transparency, meaning you can expose services over any number of protocols.

• The service boundary must act as an independent unit for versioning. Changes to business components may require versioning the service contract, for example.
• The service boundary is the deployment boundary for callers.
• The service must operate in isolation and be fault-tolerant. That is, exceptions behind the service tier should not impact other services.

Atomicity is largely influenced by design, but WCF does enable atomicity by providing a clear approach to contract versioning, a flexible approach to deployment, and certainly handles fault isolation if services are hosted by the same process.

The beauty of WCF is that it uses interoperable contract definitions (WSDL) for all types of services—regardless of the communication protocols used to reach those services.

WCF support for policy is completely hidden from the developer—it is automatically included with the WSDL document based on how you configure WCF service for features such as security and reliability.

Little SOA enables Big SOA.

Each hosting environment has its benefits and appropriate uses, which will be discussed in Chapter 4.

net.tcp://localhost:9000
net.pipe://mymachinename
http://localhost:8000
http://www.anydomain.com
net.msmq://localhost

net.tcp://localhost:9000/ServiceA
net.pipe://mymachinename/ServiceB
http://localhost:8000/Services/ServiceA
http://www.mydomain.com/ServiceA
net.msmq://localhost/QueuedServices/ServiceA

• The transport protocol, which can be TCP, named pipes, HTTP, or MSMQ
• The message encoding format, which determines whether messages are serialized as binary or XML, for example
• Other messaging protocols related to security and reliability protocols, plus any other custom protocols that affect the contents of the serialized message

You’ll explore different ways to work with service metadata throughout this chapter, and Chapter 2 discusses metadata in further detail.

In this chapter, you’ll learn how to apply the metadata behavior to a service, but other behaviors will be explored throughout this book as they relate to each feature.

• Create a new service contract and service implementation
• Programmatically configure a service host, its endpoints, and bindings
• Create a client application and open a client channel proxy to invoke the service

1. In this lab, everything begins from scratch, so you’ll start by creating a new Visual Studio solution. Open a new instance of Visual Studio 2005. Select File -> New -> Project, and from the New Project dialog, create a new Blank Solution in the <YourLearningWCFPath>\Labs\Chapter1 directory. Name the solution ServiceFromScratch. Click OK to create the empty solution.



2. Create the service project. From Solution Explorer, right-click on the solution node and select Add -> New Project. Select the Class Library template, name the project HelloIndigo, and make sure the location path matches the solution at <YourLearningWCFPath>\Labs\Chapter1\ServiceFromScratch. Click OK to create the new project.



3. Now you will create your first service contract. From Solution Explorer, rename the project’s only class file to Service.cs. Open this file in the code window. Add a new interface named IHelloIndigoService in Service.cs. Add a single method to the interface, HelloIndigo, with the signature shown here:

   public interface IHelloIndigoService
   {
        string HelloIndigo( );
   }

4. Add a reference to the System.ServiceModel assembly. From Solution Explorer, right-click References and select System.ServiceModel from the list. You’ll also need to add the following using statement to Service.cs: using

   System.ServiceModel;

5. To turn this interface into a service contract, you’ll need to explicitly decorate the interface with the ServiceContractAttribute. In addition, each method should be decorated with the OperationContractAttribute to include it in the service contract. In this case, you’ll make IHelloIndigoService a service contract and expose HelloIndigo( ) as its only service operation by applying these attributes as shown here:

    [ServiceContract(Namespace="http://www.thatindigogirl.com/samples/2006/06")]
   public interface IHelloIndigoService
   {
      [OperationContract]
      string HelloIndigo( );
   } 

   Providing a namespace for the ServiceContractAttribute reduces the possibility of naming collisions with other services. This will be dicussed in greater detail in Chapter 2.

   
   
6. In the same file, create a service type to implement the service contract. You can modify the existing class definition, renaming it to HelloIndigoService. Then add the IHelloIndigoService interface to the derivation list and implement HelloIndigo( ) with the following code:

   public class HelloIndigoService : IHelloIndigoService
   {
       public string HelloIndigo( )
       {
          return "Hello Indigo";
       }
   }

7. Compile the service project.

1. Go to the Solution Explorer and add a new Console Application project to the solution. Name the new project Host.



2. Add a reference to the System.ServiceModel assembly, and add the following using statement to Program.cs:

   using System.ServiceModel;

3. You will be writing code to host the HelloIndigoService type. Before you can do this, you must add a reference to the HelloIndigo project.



4. Create a ServiceHost instance and endpoint for the service. Open Program.cs in the code window and modify the Main( ) entry point, adding the code shown in Example 1-1. This code initializes a ServiceHost instance specifying the service type and a base address where relative service endpoints can be located. It also adds a single relative endpoint for the service. In this case, a base address is provided for HTTP protocol, and the relative endpoint uses one of the standard bindings, BasicHttpBinding, based on HTTP protocol.



5. Compile and run the host to verify that it works. From Solution Explorer, rightclick on the Host project node and select "Set as Startup Project." Run the project (F5), and you should see console output similar to that shown in Figure 1-17.



6. Stop debugging and return to Visual Studio.

static void Main(string[] args)
{
  using (ServiceHost host = new ServiceHost(typeof(HelloIndigo.HelloIndigoService),
new Uri("http://localhost:8000/HelloIndigo")))
  {
    host.AddServiceEndpoint(typeof(HelloIndigo.IHelloIndigoService),
new BasicHttpBinding( ), "HelloIndigoService");
    host.Open( );

    Console.WriteLine("Press  to terminate the service host");
    Console.ReadLine( );
  }
}

1. Go to Solution Explorer and add a new Console Application to the solution. Name the new project Client.



2. As you might expect, this project also requires a reference to System.ServiceModel. Add this reference and add the following using statement to Program.cs:

   using System.ServiceModel;

3. Copy the service contract to the client. First, add a new class to the Client project, naming the file ServiceProxy.cs. Open this new file in the code window and add the IHelloIndigoService contract metadata as shown in Example 1-2. This service contract supplies the necessary metadata to the client, describing namespaces and service operation signatures.



4. Now you can add code to invoke the service endpoint. Open Program.cs and modify the Main( ) entry point by adding the code as shown in Example 1-3. This code uses the ChannelFactory to create a new channel to invoke the service. This strongly typed channel reference acts as a proxy. The code also initializes an EndpointAddress with the correct address and binding expected by the service endpoint.



5. Test the client and service. Compile the solution and run the Host project first, followed by the Client project. The Client console output should look similar to that shown in Figure 1-18.

using System.ServiceModel;
[ServiceContract(Namespace = "http://www.thatindigogirl.com/samples/2006/06")]
public interface IHelloIndigoService
{
    [OperationContract]
    string HelloIndigo( );
}

static void Main(string[] args)
{
  EndpointAddress ep = new
EndpointAddress("http://localhost:8000/HelloIndigo/HelloIndigoService");

  IHelloIndigoService proxy = ChannelFactory.
CreateChannel(new BasicHttpBinding( ), ep);
  string s = proxy.HelloIndigo( );
  Console.WriteLine(s);

Later in this chapter, you’ll see a scenario in which the service contract and service are decoupled.

• When you apply the ServiceContractAttribute to the service type, the service type name becomes the official name of the service contract. Thus, this is the name that must be provided when you create a new endpoint (see AddServiceEndpoint( )).
• On the client side, the service contract can still be represented as an interface (the client only requires metadata) but the name of that interface (the service contract) must match the new service contract name, HelloIndigoService—instead of IHelloIndigoService. To update the lab, you can rename the interface at the client, or specify a value for the Name property of the ServiceContactAttribute as shown in Example 1-4. Service contracts are discussed in Chapter 2.

The following sample illustrates the coupling of service contracts with service type: <YourLearningWCFPath>\Sample\ServiceContracts\ServiceContractOnServiceType.

// HelloIndigo Project – Service.cs

[ServiceContract(Namespace = "http://www.thatindigogirl.com/samples/2006/06")]
public class HelloIndigoService
{
  [OperationContract]
  public string HelloIndigo( )
  {
    return "Hello Indigo";
  }
}

// Host Project – Program.cs

host.AddServiceEndpoint(typeof(HelloIndigo.HelloIndigoService), new BasicHttpBinding( ),
"HelloIndigoService");

// Client Project – ServiceProxy.cs

[ServiceContract(Name="HelloIndigoService", Namespace = "http://www.thatindigogirl.com/
samples/2006/06")]
public interface IHelloIndigoService
{
    [OperationContract]
    string HelloIndigo( );
}

using (ServiceHost host = new ServiceHost(typeof(HelloIndigo.HelloIndigoService),
new Uri("http://localhost:8000/HelloIndigo")))
{
  host.AddServiceEndpoint(typeof(HelloIndigo.IHelloIndigoService),
new BasicHttpBinding( ), "HelloIndigoService");

  // other code
}

The using statement can be applied to any type that implements IDisposable. At the end of the using statement, Dispose( ) is called within a try…finally block to ensure cleanup even in the case of an exception.

using (ServiceHost host = new ServiceHost(typeof(HelloIndigo.HelloIndigoService)))
{
  host.AddServiceEndpoint(typeof(HelloIndigo.IHelloIndigoService),
new BasicHttpBinding( ), "http://localhost:8000/HelloIndigo/HelloIndigoService");
  // other code
}

using (ServiceHost host = new ServiceHost(typeof(HelloIndigo.HelloIndigoService),
new Uri("http://localhost:8000/HelloIndigo")))
{
  host.AddServiceEndpoint(typeof(HelloIndigo.IHelloIndigoService),
new BasicHttpBinding( ), "HelloIndigoService");
  // other code
}

// Resulting endpoint address
http://localhost:8000/HelloIndigo/HelloIndigoService

Using relative endpoint addressing makes is possible to modify the base URI to move all associated relative endpoints to a new domain or port. This can simplify the deployment process.

host.AddServiceEndpoint(typeof(HelloIndigo.IHelloIndigoService),
  new BasicHttpBinding( ), "HelloIndigoService");

In this chapter, you will employ other standard bindings, but you should look to Chapter 3 for an in-depth discussion of bindings, channels, and overall service model architecture.

• The address of the service endpoint
• The protocols required to communicate with the service endpoint, or the binding
• The service contract metadata as described by the service contract associated with the endpoint

EndpointAddress ep = new
EndpointAddress("http://localhost:8000/HelloIndigo/HelloIndigoService");

IHelloIndigoService proxy = ChannelFactory<IHelloIndigoService>.
CreateChannel(new BasicHttpBinding( ), ep);

You may be wondering: how can the client discover the correct address, binding, and contract associated with a service endpoint? In the next lab, you’ll learn how to generate client proxies and configuration to consume a service without having access to the service code base.