Handling Multiple Contracts with Indigo
(Page 1 of 4 )
In this conclusion to a ten-part series on the Windows Communication Foundation (WCF), aka Indigo, you'll learn about the intricacies of multiple service contracts. 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.
Implementing Multiple Contracts
Designing service contracts is not as simple as just exposing existing business components as services. In all likelihood, services will aggregate calls to many logically related business components. This requires forethought into the use cases through each service. Irrespective of this aggregation and design effort, it is still possible that the functionality exposed by a single service should not be lumped into one big service contract. Here are some cases in which multiple contracts could exist on a single service:
- To separate logically related operations for different features
- To separate queued operations from non-queued operations
- To provide a different entry point for external and internal consumers of the service
If your service contracts are implemented on CLR interfaces (as I've recommended) then implementing multiple contracts on a service is as simple as implementing multiple interfaces. In this lab, each service implements a main service contract (IServiceA andIServiceB, respectively) and an administrative contract (IAdmin).
Contracts can facilitate the logical separation of functionality exposed by a service. For example, in the lab the main service contract for each service holds core business operations for the service. The administrative contract provides a consistent set of administrative functions that any service can expose. Both services implement the same administrative contract, which means both services expose a consistent set of operations, although the internal implementation may be quite different. Because of the presumed sensitivity of administrative operations, the lab exposes these operations over TCP or named pipes, which implies access behind the firewall. To enable internal applications and business partners to access the core service functionality, the main service contracts are exposed over two endpoints: one for TCP or named pipes, the other for Internet access over HTTP.
Hosting Multiple Services
A ServiceHost instance is required for each service type in order to expose endpoints to calling clients. When you host in IIS or WAS, a .svc endpoint is supplied for each service type, with a @ServiceHost directive that links the .svc endpoint to the actual service type. Thus, if you have multiple services to host in IIS, you provide a .svc for each to support message-based activation and configure the service model section as you would for any service type.
In self-hosting environments, you are responsible for initializing eachServiceHostinstance. You can initialize aServiceHostfor each service type as shown here (the complete code listing is shown in Example 1-20 ):
ServiceHost hostA = new ServiceHost(typeof(BusinessServices.ServiceA));
ServiceHost hostB = new ServiceHost(typeof(BusinessServices.ServiceB));
hostA.Open();
hostB.Open();
EachServiceHostis initialized with its own base addresses and service endpoints according to the<service>section with the matching type (see Example 1-19). EachServiceHostcan also be programmatically initialized using the techniques illustrated earlier in this chapter.
Next: Proxy Generation for Multiple Contracts and Endpoints >>
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.
|
|
