для всех типов WCF-служб (т.е. и служб с отдельным хостом, и служб с собственным хостом), так и (как будет показано чуть позже) для их клиентов. Предусмотренный словарный запас настолько велик, что позволяет применять практически любую вообразимую конфигурацию к службе и даже расширять этот синтаксис.

Конфигурационный код WCF содержится в конфигурационном разделе <system. serviceModel> файлов Web. conf ig или app. conf ig. В данном примере он содержится в файле Web. conf ig и состоит из двух подразделов.

□ <services>. Здесь определяются входящие в состав проекта службы. Каждая служба определяется в отдельном дочернем разделе.

□ <behaviors>. Здесь определяются механизмы поведения, которые должны использоваться для элементов в разделе <services>. Те механизмы поведения, которые определяются в этом разделе в отдельных дочерних разделах <behavior>, могут использоваться повторно для множества других элементов.

В данном примере в состав проекта входит лишь одна служба. В конфигурационном коде ей присваивается имя и назначается именованный механизм поведения, который определяется в разделе <behaviors>:

<configuration>

<system.serviceModel> <services> <service name= Ch35Ex01.Servicel

behaviorConfiguration= Ch35Ex01.ServicelBehavior >

Элемент <service> содержит два дочерних элемента <endpoint>, в каждом из которых (как нетрудно догадаться) определяется конечная точка для службы. На самом деле эти конечные точки являются базовыми конечными точками службы. Конечные точки для операций выводятся из них.

Адреса конечных точек определяются в атрибутах address. В случае WCF-служб, у которых роль хоста выполняет Web-сервер, эти адреса соотносятся с их . svc-фай-лами. Привязки конечных точек определяются в атрибутах binding, а контракты служб для привязок задаются с помощью имен интерфейсов. Первая конечная точка является главной для службы, поэтому в ней в качестве контракта службы указывается интерфейс IServicel. Еще в ней указывается адрес по умолчанию и привязка типа WSHttpBinding:

<endpoint address= binding= wsHttpBinding contract= Ch35Ex01.IServicel > <identity>

<dns value= localhost /> </identity> </endpoint>

Внутри элементов <endpoint> могут присутствовать различные дополнительные элементы, вроде показанного здесь элемента <identity>, в котором задается адрес базового сервера для конечной точки. Поскольку таковым в данном случае является сервер разработки, в этом элементе используется значение localhost.

Наша демонстрационная служба имеет также и вторую конечную точку, которая находится по адресу тех, что в полной версии звучит как metadata exchange (обмен метаданными). Она используется для предоставления клиентам возможности получать описания WCF-служб. В отличие от Web-служб, WCF-службы не предоставляют клиентам свои описания по умолчанию. Путем добавления конечной точки, использующей контракт IMetadataExchange, описания служб можно делать доступными. Что касается привязок, то для конечных точек, отвечающих за предоставления описаний служб.

можно применять либо привязку mexHttpBinding, либо привязку mexHttpsBinding, либо привязку mexNamedPipeBinding, либо же mexTcpBinding, в зависимости от используемого протокола:

<endpoint address= mex binding= mexHttpBinding

contract= IMetadataExchange /> </5ervice> </services>

В данном примере WSDL-описание службы является доступным. Получается оно присоединением к адресу службы окончания ?wsdl и на самом деле предоставляется механизмом поведения, а не через осуществляющую обмен метаданными конечную точку. Определение этого механизм поведения, который применяется ко всей службе целиком, выглядит следующим образом:

<behaviors> <serviceBehaviors>

<behavior name= Ch35Ex01.ServicelBehavior > <serviceMetadata httpGetEnabled= true />

Этот же механизм поведения еще и включает детали возникновения исключений в любые сообщения о неполадках, которые передаются клиенту, что обычно допускается только на этапе разработки:

<serviceDebug includeExceptionDetailInFaults= false /> </behavior> </serviceBehaviors> </behaviors> </system.serviceModel> </configuration >

Ha этом определение сервера завершено.

В клиентском приложении мы добавили ссылку на данную службу с помощью инструмента Add Service Reference (Добавление ссылки на службу), который использует предоставляемые службой метаданные (т.е. WSDL-файл службы) для создания прокеи-классов. Такой подход не является единственным способом для получения доступа к WCF-службам, но зато он один из наиболее простых. Существует еще один распространенный подход, который заключается в определении контрактов для WCF-службы в отдельной сборке с последующим добавлением ссылки на нее и в проект хоста, и в проект клиента. Такой подход позволяет клиенту тогда генерировать прокси не через предоставляемые метаданные, а непосредственно используя сами контракты.

При желании код, сгенерированный инструментом Add Service Reference, можно просмотреть (открыв всех имеющиеся в проекте файлы вместе, включая скрытые), хотя пока, пожалуй, лучше этого не делать, потому что осталось еще много непонятного кода.

Главное здесь обратить внимание на то, что этот инструмент создает все классы, которые требуются для получения доступа к службе. К их числу относится прокси-класс для службы, содержащий методы для всех предоставляемых данной службой операций (ServiceClient), и клиентский класс, сгенерированный из контракта данных (CompositeType).

Еще этот инструмент добавляет в проект конфигурационный файл арр. conf ig. В нем определяются две вещи:

□ детали привязки для конечной точки службы;

□ адрес и контракт для этой конечной точки.

Детали привязки берутся из описания службы, и при этом в конфигурационный файл клиентского приложения из него копируется каждая конфигурируемая опция:

<configuration> <system.serviceModel> <bindings> <wsHttpBinding>

<binding name= WSHttpBinding IServicel closeTimeout= 00:01:00 openTimeout= 00;01:00 receiveTimeout= 00:10:00 sendTimeout= 00:01:00 bypassProxyOnLocal= false transactionFlow= false hostNameComparisonMode= StrongWildcard maxBufferPoolSize= 524288 maxReceivediyiessageSize= 65536 messageEncoding= Text textEncoding= utf-8 useDefaultWebProxy= true allowCookies= false > <readerQuotas maxDepth= 32 maxStringContentLength= 8192

maxArrayLength= 16384 maxBytesPerRead= 4 096

maxNameTableCharCount= 16384 />

<reliableSession ordered= true inactivityTimeout= 00:10:00 enabled= false /> <security mode= Message >

<transport clientCredentialType= Windows proxyCredentialType= None realm= /> <message clientCredentialType= Windows negotiateServiceCredential= true algorithmSuite= Default establishSecurityContext= true /> </security> </binding> </wsHttpBinding> </bindings>

Эта привязка используется в конфигурации конечной точки вместе с базовым адресом службы (каковым в случае служб с Web-сервером в качестве хоста является адрес . svc-файла) и клиентской версией контракта IServicel: <client>

<endpoint address= http: localhost:5117 3/Servicel.svc binding= wsHttpBinding bindingConfiguration= WSHttpBinding IServicel contract= ServiceReferencel,IServicel name= WSHttpBinding IServicel > <identity>

<dns value= localhost /> </identity> </endpoint> </client>

</system.serviceModel> </configuration>

Инструмент Add Service Reference поработал здесь весьма основательно. На самом деле в большинстве из этих деталей нет никакой необходимости, потому что мы использовали стандартную привязку WSHttpBinding. А это значит, что можно было бы заменить содержимое этого конфигурационного файла следующим кодом:

<configuration> <system.serviceModel> <client>

<endpoint address= http: localhost: 51173/Servicel. svc binding= wsHtt5>Binding contract= ServiceReferencel.IServicel name= WSHttpBinding IServicel >

<identity> <dns value= localhost /> </identity> </endpoint> </client> </system.serviceModel> </confiquration>