□ HTTP. Адреса для подключений по протоколу HTTP представляют собой URL-адреса и имеют вид http: <сервер> :<порт>/<служба>. Для установки SSL-соединений еще также может использоваться и такой формат:

https : <сервер>: <порт>/<служба>

Если за хостинг службы отвечает IIS, на месте <служба> указывается файл с расширением .svc (.svc-файлы являются аналогом . asmx-файлов, которые применяются в Web-службах). Адреса IIS, скорее всего, будут включать больше подкаталогов, чем в данном примере, т.е. наверняка будут иметь больше отделенных символом / разделов перед именем файла . svc.

□ TCP. Адреса для подключений по протоколу TCP имеют вид:

net.top: <сервер>:<порт>/<служба>

□ Именованный канал. Адреса для подключений по именованному каналу выглядят похожим образом, но не предусматривают указания номера порта, т.е. имеют такой вид: net .pipe: <сервер> :<порт>/<служба>.

Адрес службы является базовым адресом, который можно использовать для создания адресов для конечных точек, представляющих операции. Например, адрес операции может выглядеть как net .pipe: <сервер>: <порт>/<служба>/<операция1>.

Для примера предположим, что требуется создать WCF-службу с одной операцией, имеющей привязки для всех трех перечисленных здесь протоколов. Базовые адреса этой службы тогда могут выглядеть следующим образом:

http: www.mydomain.com/services/amazingservices/mygreatservice.svc net.top: myhugeserver:8080/mygreatservice net.pipe: localhost/mygreatservice

Адреса для ее операции тогда, соответственно, могут выглядеть так:

http: www.mydomain.сот/services/amazingservices/mygreatservice.svc/greatop net.top: myhugeserver:8080/mygreatservice/greatop net.pipe: localhost/mygreatservice/greatop

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

Из-за того, что привязки обладают такой замечательной степенью гибкости, в .NET Framework предлагается несколько предопределенных привязок, которые можно использовать как непосредственно в том виде, в каком они есть, так и в качестве отправных точек и затем настраивать до получения требуемого поведения. У этих предопределенных привязок имеются определенные возможности, которых нужно обязательно придерживаться. Каждая из них представлена соответствующим классом в пространстве имен System. ServiceModel. Все они перечислены в табл. 35.L

Многие из перечисленных в этой таблице классов привязок имеют схожие свойства, которые можно использовать для их дополнительной настройки. Например, у них есть свойства, которые можно применять для настройки значений тайм-аута. Более подробно об этом будет рассказываться чуть позже в этой главе при рассмотрении кода.

Таблица 35.1. Предопределенные привязки в .NET Framework

Привязка

Описание

BasicHttpBinding

WSHttpBinding WSDualHttpBinding

WSFederationHttpBinding

NetTcpBmding

NetNamedPipeBinding

NetPeerTcpBinding

NetMsmqBinding И MsmqlntegrationBindmg

Простейшая HTTP-привязка. Используется Web-службами по умолчанию. Имеет ограниченные возможности в плане обеспечения безопасности и не предусматривает никакой поддержки для транзакций

Более усовершенствованная версия HTTP-привязки, способная применять все дополнительные функциональные возможности, которые были представлены в WSE

Расширяет возможности wsHttpBindmg, включая в их число возможности дуплексной связи. При дуплексной связи сервер помимо обычного обмена сообщениями может инициировать и другие сеансы связи с клиентом

Расширяет возможности wsHttpBinding, включая в их число возможности федераций. Федерации позволяют третьей стороне реализовать технологию единого входа (Single Sign-On) и другие специфические меры безопасности. Данная тема является сложной и в настоящей главе не рассматривается

Применяется для сеансов связи по протоколу ТОР и позволяет настраивать безопасность, транзакции и так далее

Применяется для сеансов связи по именованным каналам и позволяет настраивать безопасность, транзакции и т.д.

Позволяет транслировать сеансы связи нескольким клиентам и представляет собой еще один сложный класс, который в настоящей главе не рассматривается

Эти привязки применяются с системой MSMQ, которая тоже в настоящей главе не рассматривается

Контракты

Контракты позволяют определять то, как именно могут использоваться WCF-службы. Они бывают нескольких видов.

□ Контракт службы. Позволяет добавлять общую информацию о службе и предоставляемых ею операциях. Например, это могут быть сведения об используемом службой пространстве имен. Службы обладают уникальными пространствами имен, которые применяются при определении шаблона для SOAP-сообщений во избежание возможных конфликтов с другими службами.

□ Контракт операции. Позволяет задавать, как должна использоваться операция. Это подразумевает указание параметров и возвращаемого значения для лежащего в основе операции метода, а также любой необходимой дополнительной информации, вроде того, должен ли этот метод возвращать сообщение с ответом.

□ Контракт сообщений. Позволяет указывать, каким образом должна форматироваться информация внутри SOAP-сообщений, например, должны ли данные включаться в заголовок или в тело SOAP-сообщений. Подобное может быть полезно при создании WCF-службы, пригодной для интеграции с унаследованными системами.

□ Контракт неполадок. Позволяет указывать ошибки, которые может возвращать операция. При использовании .NET-клиентов такие ошибки могут приводить к генерации исключений, которые можно перехватывать и обрабатывать обычным образом.

□ Контракт данных. В случае использования сложных типов, вроде определяемых пользователем структур или объектов, в качестве параметров или возвращаемых типов для операций, для них нужно обязательно определять контракты данных. Контракты данных позволяют определять типы на основе данных, которые они должны предоставлять через свои свойства.

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

Шаблоны передачи сообщений

в предыдущем разделе было сказано о том, что в контракте операции можно указывать, должна ли данная операция возвращать какое-то значение, а в разделе, посвященном привязкам - о том, что с помощью привязки WSDualHttpBinding можно обеспечивать дуплексную связь. И то и другое является разновидностью шаблонов передачи сообщений, каковые бывают трех видов.

□ Шаблон передачи сообщений запроса и ответа. Представляет собой обычный шаблон передачи сообщений, в котором каждое сообщение, отправляемое службе, приводит к отправке ответного сообщения обратно клиенту. Это вовсе необязательно означает, что клиент должен дожидаться ответного сообщения, поскольку операции могут, как обычно, вызываться асинхронно.

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

□ Двусторонний, или дуплексный, шаблон передачи сообщений. Является более совершенным шаблоном, в котором клиент, по сути, выступает в роли сервера, а также клиента, и сервер - в роли клиента, а также сервера. После настройки он позволяет клиенту и серверу отправлять друг другу сообщения, которые могут быть, а могут и не быть ответными. Это аналогично созданию объекта и подписке на предоставляемые этим объектом события.

То, как эти шаблоны передачи сообщений используются на практике, будет показано позже в этой главе.

Механизмы поведения

Механизмы поведения (behaviors) представляют собой способ применения дополнительной конфигурации, которая не должна предоставляться службами и операциями непосредственно клиенту. За счет снабжения механизмом поведения службы можно управлять тем, как должен создаваться экземпляр данной службы, как она должна использоваться в отвечающем за ее хостинг процессе, как должна участвовать в транзакциях, каким образом в ней должны обрабатываться проблемы, связанные с многопоточностью и т.д. За счет снабжения механизмами поведения операций можно управлять тем, должен ли во время их выполнения использоваться режим заимствования прав (impersonation), какое влияние они должны оазывать на транзакции и т.п.