system.serviceModel

This configuration section contains all the Windows Communication Foundation (WCF) ServiceModel configuration elements.

XML	Copy Code
<system.serviceModel> <services> </services> <bindings> </bindings> <behaviors> </behaviors> <client> </client> <diagnostics> </diagnostics> </system.serviceModel>

The table below shows the most important elements within this section and a short description of each element.

WCF services are defined in the services section of system.serviceModel element. An assembly can contain any number of services. Each service has its own service configuration section. The section and its content define the service contract, behavior, and endpoint(s) of the particular service.

The behaviorConfiguration attribute is optional. It identifies the service behavior used by a service. The behavior specified by this attribute must link to a service behavior defined in the scope of the same configuration file (i.e. the same file or a parent file).

Each service exposes one or more endpoints defined in an endpoint element. Each endpoint has its own address and binding. All bindings used within the configuration file must be defined in the scope of the file.

Bindings are linked to endpoints through the combination of the attributes name and bindingConfiguration. The binding attribute defines in which section the binding is defined. The bindingConfiguration attribute defines which configured binding within the binding section is used. A binding section can define several configured bindings.

Smartsite web.config

In case of a typical Smartsite iXperion web.config file, the services element within the system.serviceModel section should contain at least one service node for each service listed in Smartsite.config. The example below shows a system.serviceModel section with all the necessary configuration elements for the Smartsite InteropService (all other elements have been left out).

XML

Copy Code

<system.serviceModel>   <services>     <service name="Smartsite.Core.Services.InteropService">       <endpoint address="net.pipe://localhost/test6/InteropService" binding="netNamedPipeBinding"           bindingNamespace="http://Smartsite.Webservices.InteropService"          bindingConfiguration="InteropServiceBinding"          contract="Smartsite.Core.Services.IInteropService" />     </service>   </services>   <bindings>     <netNamedPipeBinding>       <binding name="InteropServiceBinding" maxReceivedMessageSize="1048576">         <readerQuotas maxStringContentLength="1048576" />       </binding>     </netNamedPipeBinding>   </bindings> </system.serviceModel>

Each service node must have a name attribute, which specifies the type of the service to be instantiated (in the format Namespace.Class), in this case Smartsite.Core.Services.InteropService. The optional behaviorConfiguration attribute is not used in this example, but it can be used to refer (by name) to a section within the behaviors section, containing a collection of settings for the behavior of the service (such as whether to enable http get's for meta-data exchange, throttling settings and/or to include exception details when returning fault information).

Every service exposes one or more endpoints, which has its own address and binding. Just add an endpoint element for each endpoint you want to expose. In the above example, the InteropService exposes one endpoint, specifically a named-pipe listener listening on the address net.pipe://localhost/test6/InteropService. (It is recommended to include the sitename in the address, so multiple sites on the same machine can all use the same address-pattern.)

Important: do not specify a hostname that is defined in a local hosts file. Windows Communication Foundation is unable to resolve hostnames defined in the hosts file and it will raise a SecurityException.

When a named-pipe listener is used, the binding attribute must be set to netNamedPipeBinding. Other types of bindings include wsHttpBinding and wsDualHttpBinding, in which case the address should specify a http address.

The bindingNamespace defines the qualified name of the namespace for this binding. The contract attribute specifies the contract this endpoint is exposing (usually an interface implemented on the class specified within the name attribute of the enclosing service element).

The bindingConfiguration attribute links to a configuration section within the bindings section of the system.serviceModel element.

The bindings section holds a collection of standard and custom bindings. Each entry is a binding element that can be identified by its unique name, in the above example InteropServiceBinding. Since the InteropService uses a netNamedPipeBinding, the binding configuration must be enclosed within a netNamedPipeBinding section.