Creating Services with the WCF
(Page 1 of 4 )

In this third part of a ten-part series on the Windows Communication Foundation (WCF), aka "Indigo," you will learn about message processing, services, 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.

Addresses

Each endpoint is associated with an address, identified by a URI. An address has a scheme, domain, port, and path in the following format: scheme://domain[:port]/ [path].

The scheme indicates the transport protocol being used, such as TCP, named pipes, HTTP, or MSMQ. Respectively, the schemes for these protocols are net.tcp, net.pipe, http, and net.msmq. The domain refers to either a machine name or web domain. Sometimes localhost is used for communications on the same machine. The port can be specified to use a specific communication port other than the default for the protocol identified by the scheme. For example, HTTP defaults to port 80. Here are some examples of valid base addresses before specifying a path:

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

A path is usually provided as part of the address to disambiguate service endpoints. The path does not usually include a filename for self-hosting, but with IIS (as you will see later in this chapter) a physical file is implicitly included in the address. These are valid self-hosting addresses that include paths:

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

When you add endpoints to aServiceHost instance, you must specify a unique address for each endpoint. That means that you must vary at least one of the scheme, domain, port, or path specified.

Bindings

A binding describes the protocols supported by a particular endpoint, specifically, the following:

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

There are a number of predefined bindings (called standard bindings) provided by the service model. These standard bindings represent a set of typical protocols representative of common communication scenarios. Bindings are discussed in detail in Chapter 3.

Metadata

Once the ServiceHost is configured for one or more endpoints, and communication channels are open, service operations can be invoked at each endpoint. This is according to the protocols supported by each endpoint. Clients invoke service operations at a particular endpoint. To do so, they need information about the endpoint, including the address, the binding, and the service contract. Information about service endpoints is part of the metadata for a particular service. Clients rely on this metadata to generate proxies to invoke the service.

Metadata can be accessed in two ways. TheServiceHostcan expose a metadata exchange endpoint to access metadata at runtime, or it can be used to generate a WSDL document representing the endpoints and protocols supported by the service. In either case, clients use tools to generate proxies to invoke the service.

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

Proxies

Clients communicate with services using proxies. A proxy is a type that exposes operations representative of a service contract that hides the serialization details from the client application when invoking service operations. For WCF applications, proxies are based on the service contract, so if you have access to the service contract definition, you can create a proxy instance to invoke the service. Before the proxy instance can be used to call service operations, it must be provided with information about one of the endpoints exposed for that service contract--there is a one-to-one relationship between proxy and endpoint.

Tools also exist to generate proxies and endpoint configurations from metadata. In this chapter, you will learn how to create a proxy manually, without generating metadata, and how to use proxy generation tools. In either case, the client must open a communication channel with the service to invoke operations. This channel must be compatible with the channel exposed by theServiceHostfor communications to work.

Next: Channels >>
 

More BrainDump Articles
More By O'Reilly Media

Comments On: Creating Services with the WCF

· This article is an excerpt from the book "Learning WCF A Hands-on Guide," published...    · I created the WCF service on Windows Vista. As you may have known, Vista has the...   >>> Post your comment now!

Buy this book...

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.