In this ninth part of a ten-part series focusing on the Windows Communication Foundation (WCF), aka Indigo, you'll learn about endpoints, implementing multiple contracts on a service, hosting two services with multiple contracts, 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.
Exposing Multiple Service Endpoints
So far in this chapter, I have shown you different ways to create services, how to expose a service endpoint and metadata exchange endpoint, how to generate client proxies, how to work with metadata, and how to configure service behaviors. In this section, I'll place the emphasis on endpoints, binding configuration, and allocation of assemblies for a more complex solution.
WCF includes a number of standard bindings that allow you to quickly configure a service for a particular set of protocols. Clients must use compatible protocols when they communicate with each endpoint. Services can expose multiple endpoints for the same service contract in order to expose functionality over different protocols. For example, a service may be called by internal clients over TCP, but by external clients over HTTP. In addition to supporting different protocols, internal and external clients may not have access to the same service contracts. Some operations may be allowed only by clients within the domain, while others are publicly available to remote clients on the Internet.
In this lab you will configure multiple endpoints for a service to support different endpoint and binding configurations. In the process you'll explore the following concepts:
Hosting multiple services
Configuring multiple endpoints for a service
Accessing a service from a Windows client application
Initializing proxies from multiple endpoint and binding configurations
Comparing proxy generation to sharing types between services and clients
Lab: Hosting Multiple Services and Sharing Types
In this lab, you'll modify an existing solution to implement a service contract and an administrative contract on two distinct services. You'll then host each service in the same host process, a console application. An internal client presumed to be behind the firewall will consume each service using network protocols such as TCP and named pipes. This client will have access to service operations exposed by the service contract and administrative contract. An external client, presumed to be accessing the service over the Internet will have access only to operations exposed by the service contract over HTTP. The internal client will share class libraries to access service contracts, while the external client will use traditional methods for generating service proxies.
Implementing multiple contracts on a service
In this section, you're going to implement the predefined service contracts on two distinct services. Each service will expose two contracts: one for business functionality core to the service, the other for administrative functionality. Both services will implement the same administrative contract. This illustrates an example of contract factoring for reuse.
Start by opening the solution\Labs\Chapter1\ MultiContractService\MultiContractService.sln. This solution contains several shell projects, including a service library, a host, and two Windows client applications as follows:
BusinessServiceContracts
A class library containing three contracts:
IAdmin,IServiceA, andIServiceB.
IAdmindefines administrative operations.
IServiceAandIServiceBrespectively
describe functionality to be exposed by
ServiceAandServiceB.
BusinessServices
A class library that will contain two services:
ServiceAandServiceB.
Host
A console application that will host
ServiceAandServiceB.
InternalClient
A windows client application that will access
services behind the firewall.
ExternalClient
A windows client application that will access
services over the Internet.
Putting service contracts into a separate class library facilitates sharing metadata with client applications when you own both sides of the development effort.
The first thing you'll do is provide an implementation forServiceA, which is located in theBusinessServicesclass library. First, take a look at the contracts you will implement. Go to theBusinessServiceContractsproject and open IServiceA.cs; you'll see a contract with two operations. Now open IAdmin.cs and you'll see another contract with two different operations.
To implement these contracts, go to theBusinessServicesproject. First, add a reference to theBusinessServiceContractsproject so you can access the contracts it defines. Then open ServiceA.cs and add ausing statement for theBusinessServiceContracts namespace, as shown here:
using BusinessServiceContracts;
Modify the definition ofServiceAso that it derives fromIServiceAandIAdmin as follows:
public class ServiceA : IServiceA, IAdmin
Implement both contracts implicitly. You can use a shortcut by hovering your mouse overIServiceAand using the smart tag to select "Implement interface IServiceA," as shown in Figure 1-29.
Figure 1-29. Using smart tags to implement an interface
Complete the implementation by adding the code shown in Example 1-17.
Example 1-17. Implementation for ServiceA
public class ServiceA : IServiceA, IAdmin
{
string IServiceA.Operation1()
{
return "IServiceA.Operation1() invoked.";
}
string IServiceA.Operation2()
{
return "IServiceA.Operation2() invoked.";
}
string IAdmin.AdminOperation1()
{
return "IAdmin.AdminOperation1 invoked.";
}
string IAdmin.AdminOperation2()
{
return "IAdmin.AdminOperation2 invoked.";
}
}
Follow a similar set of steps to implementServiceB. Open ServiceB.cs and derive the class fromIServiceB andIAdmin. Implement both interfaces implicitly so that the result looks like the code in Example 1-18. Don't forget to add theusing statement for theBusinessServiceContractsnamespace.
Example 1-18. Implementation for ServiceB
using BusinessServiceContracts;
public class ServiceB: IServiceB, IAdmin
{
string IServiceB.Operation3()
{
return "IServiceB.Operation3() invoked.";
}
string IAdmin.AdminOperation1()
{
return "IAdmin.AdminOperation1 invoked.";
}
string IAdmin.AdminOperation2()
{
return "IAdmin.AdminOperation2 invoked.";
}
}
Verify that theBusinessServicesproject compiles without error.
SOURCE:http://www.aspfree.com/c/a/BrainDump/Multiple-Service-Contracts-and-Indigo/
Exposing Multiple Service Endpoints
So far in this chapter, I have shown you different ways to create services, how to expose a service endpoint and metadata exchange endpoint, how to generate client proxies, how to work with metadata, and how to configure service behaviors. In this section, I'll place the emphasis on endpoints, binding configuration, and allocation of assemblies for a more complex solution.
WCF includes a number of standard bindings that allow you to quickly configure a service for a particular set of protocols. Clients must use compatible protocols when they communicate with each endpoint. Services can expose multiple endpoints for the same service contract in order to expose functionality over different protocols. For example, a service may be called by internal clients over TCP, but by external clients over HTTP. In addition to supporting different protocols, internal and external clients may not have access to the same service contracts. Some operations may be allowed only by clients within the domain, while others are publicly available to remote clients on the Internet.
In this lab you will configure multiple endpoints for a service to support different endpoint and binding configurations. In the process you'll explore the following concepts:
Hosting multiple services
Configuring multiple endpoints for a service
Accessing a service from a Windows client application
Initializing proxies from multiple endpoint and binding configurations
Comparing proxy generation to sharing types between services and clients
Lab: Hosting Multiple Services and Sharing Types
In this lab, you'll modify an existing solution to implement a service contract and an administrative contract on two distinct services. You'll then host each service in the same host process, a console application. An internal client presumed to be behind the firewall will consume each service using network protocols such as TCP and named pipes. This client will have access to service operations exposed by the service contract and administrative contract. An external client, presumed to be accessing the service over the Internet will have access only to operations exposed by the service contract over HTTP. The internal client will share class libraries to access service contracts, while the external client will use traditional methods for generating service proxies.
Implementing multiple contracts on a service
In this section, you're going to implement the predefined service contracts on two distinct services. Each service will expose two contracts: one for business functionality core to the service, the other for administrative functionality. Both services will implement the same administrative contract. This illustrates an example of contract factoring for reuse.
Start by opening the solution
BusinessServiceContracts
A class library containing three contracts:
IAdmin,IServiceA, andIServiceB.
IAdmindefines administrative operations.
IServiceAandIServiceBrespectively
describe functionality to be exposed by
ServiceAandServiceB.
BusinessServices
A class library that will contain two services:
ServiceAandServiceB.
Host
A console application that will host
ServiceAandServiceB.
InternalClient
A windows client application that will access
services behind the firewall.
ExternalClient
A windows client application that will access
services over the Internet.
Putting service contracts into a separate class library facilitates sharing metadata with client applications when you own both sides of the development effort.
The first thing you'll do is provide an implementation forServiceA, which is located in theBusinessServicesclass library. First, take a look at the contracts you will implement. Go to theBusinessServiceContractsproject and open IServiceA.cs; you'll see a contract with two operations. Now open IAdmin.cs and you'll see another contract with two different operations.
To implement these contracts, go to theBusinessServicesproject. First, add a reference to theBusinessServiceContractsproject so you can access the contracts it defines. Then open ServiceA.cs and add ausing statement for theBusinessServiceContracts namespace, as shown here:
using BusinessServiceContracts;
Modify the definition ofServiceAso that it derives fromIServiceAandIAdmin as follows:
public class ServiceA : IServiceA, IAdmin
Implement both contracts implicitly. You can use a shortcut by hovering your mouse overIServiceAand using the smart tag to select "Implement interface IServiceA," as shown in Figure 1-29.
Figure 1-29. Using smart tags to implement an interface
Complete the implementation by adding the code shown in Example 1-17.
Example 1-17. Implementation for ServiceA
public class ServiceA : IServiceA, IAdmin
{
string IServiceA.Operation1()
{
return "IServiceA.Operation1() invoked.";
}
string IServiceA.Operation2()
{
return "IServiceA.Operation2() invoked.";
}
string IAdmin.AdminOperation1()
{
return "IAdmin.AdminOperation1 invoked.";
}
string IAdmin.AdminOperation2()
{
return "IAdmin.AdminOperation2 invoked.";
}
}
Follow a similar set of steps to implementServiceB. Open ServiceB.cs and derive the class fromIServiceB andIAdmin. Implement both interfaces implicitly so that the result looks like the code in Example 1-18. Don't forget to add theusing statement for theBusinessServiceContractsnamespace.
Example 1-18. Implementation for ServiceB
using BusinessServiceContracts;
public class ServiceB: IServiceB, IAdmin
{
string IServiceB.Operation3()
{
return "IServiceB.Operation3() invoked.";
}
string IAdmin.AdminOperation1()
{
return "IAdmin.AdminOperation1 invoked.";
}
string IAdmin.AdminOperation2()
{
return "IAdmin.AdminOperation2 invoked.";
}
}
Verify that theBusinessServicesproject compiles without error.
SOURCE:http://www.aspfree.com/c/a/BrainDump/Multiple-Service-Contracts-and-Indigo/
No comments:
Post a Comment