This print for content only-size & color not accurate 7" X 9-1/4" / casebound / malloy

The [ServiceContract] Attribute

In order for a CLR interface to participate in the services provided by WCF, it must be adorned with

the [ServiceContract] attribute. Like many other .NET attributes, the ServiceContractAttribute

type supports a number of properties to further qualify its intension. Two properties, Name and

Namespace, can be set to control the name of the service type and the name of the XML namespace

defining the service type. If you are using a web service–specific binding, these values are used to

define the 
 elements of the related WSDL document. 

Here, we have not bothered to assign a Name value, given that the default name of the service

type is directly based on the C# class name. However, the default name for the underlying XML

namespace is simply http://tempuri.org (which really should be changed for all of your WCF

services). 

When you are building a WCF service that will send and receive custom data types (which we

are currently not doing), it is important to establish a meaningful value to the underlying XML

namespace, as this will make sure that your custom types are unique. As you may know from your

experience building XML web services, XML namespaces provide a way to wrap your custom types

in a unique container to ensure that your types do not clash with types in another organization.

For this reason, we can update our interface definition with a more fitting definition, which,

much like the process of defining an XML namespace in a .NET Web Service project, is typically the

URI of the service’s point of origin, for example:

[ServiceContract(Namespace = "http://Intertech.com")]

public interface IEightBall

{

...

}

Beyond Namespace and Name, the [ServiceContract] attribute can be configured with the

additional properties shown in Table 25-6. Be aware that some of these settings will be ignored

depending on your selection of binding. 

C H A P T E R   2 5