Services and the WCF
(Page 1 of 4 )
In this fourth part of a ten-part series focusing on the Windows Communication Foundation (WCF), aka "Indigo," you'll learn how to create a proxy to invoke a service, how to define a service, and more. This article is excerpted from chapter 1 of the book
Learning WCF A Hands-on Guide, written by Michele Leroux Bustamante (O'Reilly, 2007; ISBN: 0596101627). Copyright © 2007 O'Reilly Media, Inc. All rights reserved. Used with permission from the publisher. Available from booksellers or direct from O'Reilly Media.
Creating a proxy to invoke a service
Now you will create a new console application to test the service. To do this, the client requires metadata from the service and information about its endpoint. This information will be used to initialize a client proxy that can invoke service operations.
Go to Solution Explorer and add a new Console Application to the solution. Name the new projectClient.
As you might expect, this project also requires a reference toSystem.ServiceModel. Add this reference and add the followingusingstatement to Program.cs:
using System.ServiceModel;
Copy the service contract to the client. First, add a new class to theClientproject, naming the fileServiceProxy.cs. Open this new file in the code window and add theIHelloIndigoServicecontract metadata as shown in Example 1-2. This service contract supplies the necessary metadata to the client, describing namespaces and service operation signatures.
- Now you can add code to invoke the service endpoint. Open Program.cs and modify theMain()entry point by adding the code as shown in Example 1-3. This code uses theChannelFactoryto create a new channel to invoke the service. This strongly typed channel reference acts as a proxy. The code also initializes anEndpointAddresswith the correct address and binding expected by the service endpoint.
- Test the client and service. Compile the solution and run theHostproject first, followed by theClientproject. TheClient console output should look similar to that shown in Figure 1-18 .
Example 1-2. Service contract metadata for the client
using System.ServiceModel;
[ServiceContract(Namespace = "http://www.thatindigogirl.com/samples/2006/06")] public interface IHelloIndigoService
{
[OperationContract]
string HelloIndigo();
}
Example 1-3. Code to invoke a service through its generated proxy
static void Main(string[] args)
{
EndpointAddress ep = new
EndpointAddress("http://localhost:8000/HelloIndigo/ HelloIndigoService");
IHelloIndigoService proxy = ChannelFactory<IHelloIndigoService>.
CreateChannel(new BasicHttpBinding(), ep);
string s = proxy.HelloIndigo();
Console.WriteLine(s);
Console.WriteLine("Press <ENTER> to terminate Client.");
Console.ReadLine();
}
Figure 1-18. Output from the Client application
In the next few sections, I will explain in more detail the steps you completed and the features you explored in the lab.
Assembly Allocation
The first thing I'd like to touch on is the allocation of assemblies when you create a new solution that includes services. For example, in this lab you created a new solution with three projects: one for the service, another for the host, and another for the client. Note that the service definition is decoupled from the host project. This is an approach I always recommend because it allows you to host the same service in multiple environments. For example, you may need to expose a service behind the firewall over TCP, and yet also allow remote, interoperable clients to consume it over HTTP. These two approaches require distinct hosting environments (specifically, a Windows service and IIS, as I will discuss in Chapter 4 at length). For simplicity, many examples may couple service and host, but this is merely a convenience--not a practical approach. As such, at a minimum I recommend that you always create a separate project for service contracts and services.
Services are the window through which business functionality is invoked, but business logic has no place in the service assembly. Business functionality should never be coupled with the service implementation because it is possible that multiple services and applications may need to reuse the same business logic. Furthermore, while you may use services to reach that functionality in most cases, what if you needed to expose an Enterprise Service component to interoperate with a particular application or system? If business logic is stored in its own assemblies, this type of sharing is made easy.
Another reason to decouple business logic from service implementation is to improve manageability and versioning. The service tier may need to coordinate logging activities and exception handling around calls to business components, and the service tier may need to be versioned, while business components and associated functionality have not changed. For this reason, I always recommend that business components, data access components, and other dependencies of the business tier also represent a separate set of assemblies in your solution. Figure 1-19 illustrates this breakdown from a high level.
Figure 1-19. Assembly allocation for services, hosts, business components, and data access
There may be times when it is desirable to share the service contracts with client applications. In that case, service contracts and service implementations may also be decoupled. This makes it possible to share the metadata of the service without sharing the implementation.
Later in this chapter, you'll see a scenario in which the service contract and service are decoupled.
Next: Defining a Service >>
More BrainDump Articles
More By O'Reilly Media
|
 This article is excerpted from chapter 1 of the book Learning WCF A Hands-on Guide, written by Michele Leroux Bustamante (O'Reilly, 2007; ISBN: 0596101627). Check it out today at your favorite bookstore. Buy this book now.
|
|
