5

1. АРХИТЕКТУРА ПРИЛОЖЕНИЙ WCF

1.1. Основы WCF

При построении распределенной системы WCF обычно создаются три взаимосвязанных сборки.

1.Сборка службы WCF. Эта библиотека *.dll содержит классы и интерфейсы, представляющие некую функциональность, которая предлагается внешним клиентам.

2.Хост службы WCF. Этот программный модуль – сущность, которая принимает в себе сборку службы WCF.

3.Клиент WCF. Это приложение, которое обращается к функциональности службы через промежуточный прокси-класс.

Рис. 1.1. Общая схема взаимодействия хоста WCF и приложения клиента.

Хосты и клиенты взаимодействуют друг с другом, согласовывая так называ-

емые «АПК» («ABC», address, binding, contract) – условное наименование для за-

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

1.Адрес. Описывает местоположение службы. В коде представлен типом System.Uri, однако значение обычно хранится в файлах *.сonfig.

2.Привязка. WCF поставляется с множеством различных привязок, которые указывают сетевые протоколы, механизмы кодирования и транспортный уровень.

3.Контракт. Предоставляет описание каждого метода, представленного службой WCF.

6

1.2.Конечные точки

Вмире WCF термин конечная точка (endpoint) представляет адрес, привязку и контракт, объединенные вместе в один пакет. В XML конечная точка выражается элементом <endpoint> и элементами address, binding и contract.

Каждая конечная точка состоит из следующего.

1.Адрес однозначно определяет конечную точку и указывает потенциальным потребителям на место расположения службы. В объектной модели WCF адрес представлен классом EndpointAddress. Класс EndpointAddress содержит свойство Uri, представляющее адрес службы, и свойство Identity, представляющее удостоверение безопасности службы и коллекцию необязательных заголовков сообщений. Необязательные заголовки сообщений используются для вывода дополнительной и более подробной информации, необходимой для идентификации конечной точки или взаимодействия с ней.

2.Привязка задает способ связи клиента с конечной точкой. В том числе следующее: используемый транспортный протокол (например, TCP или HTTP); используемую в сообщениях кодировку (например, текст или двоичное кодирование); необходимые требования безопасности (например, безопасность сообщений SSL или SOAP). Привязка в объектной модели WCF представлена абстрактным базовым классом Binding. В большинстве сценариев пользователи могут использовать только одну из предусмотренных системой привязок. Дополнительные сведения см. в разделе Привязки, предоставляемые системой.

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

4.Поведения конечной точки можно использовать для настройки локального поведения конечной точки службы. Поведения конечной точки выполняют

7

это путем участия в процессе создания среды выполнения WCF. Примером поведения является свойство ListenUri, позволяющее указывать отличный от адреса SOAP или WSDL адрес прослушивания.

1.3. Контракты

Контракт представляет собой описание сообщений, передаваемых оконечным точкам службы и возвращаемых ей. Каждая оконечная точка определяется своими АПК: Адресуемым местом в сети, куда посылаются сообщения; Привязкой, описывающей способ передачи сообщений, и Контрактом, в котором оговорены форматы сообщений. Служба можно рассматривать как набор оконечных точек, которые реализуют те или иные программно-закодированные алгоритмы.

Это может быть бизнесфункция высокого уровня, например ввод заказа в систему, или более специализированная функция, как, скажем, поиск адреса клиента.

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

ВWCF есть контракты трех видов:

1.Контракт о службе описывает функциональные операции, реализуемые службой. Он отображает методы класса .NET на описания служб, типов портов и операций на языке WSDL. Внутри контракта о службе имеются контракты об операциях, которые описывают отдельные операции службы, то есть методы, реализующие ее функции.

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

3.Контракт о сообщениях описывает формат сообщений протокола SOAP, что находит отражение в определениях сообщений на языках WSDL. Контракт о сообщениях позволяет точно контролировать состав заголовков и тел SOAP сообщений.

8

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

Контракты служб WCF оснащаются различными атрибутами, наиболее часто используемые из которых определены в пространстве имен System.ServiceModel. Когда члены контракта службы (методы в интерфейсе) содержат только простые типы данных (такие как числовые, булевские и строковые), полную службу WCF можно построить, используя одни только атрибуты

[ServiceContract] и [OperationContract].

Как только контракт (или набор контрактов) определен и реализован внутри библиотеки службы, следующий логический шаг состоит в построении агента хостинга для самой службы WCF. Как уже упоминалось, на выбор доступно множество возможных вариантов хостов, и все они должны указывать привязки, используемые удаленными клиентами для получения доступа к функциональности типа службы. Выбор из набора привязок – это область, которая отличает разработку WCF от .NET Remoting и/или разработки веб-служб XML. На выбор в WCF д о- ступно множество возможных привязок, каждая из которых ориентирована на определенные потребности. Если ни одна из готовых привязок не удовлетворяет существующим требованиям, можно создать собственную привязку, расширив тип CustomBinding. Привязка WCF может описывать следующие характеристики:

1.Транспортный уровень, используемый для передачи данных (HTTP, MSMQ, именованные каналы и TCP);

2.Каналы, используемые транспортом (однонаправленные, запрос-ответ и дуплексные);

3.Механизм кодирования, используемый для работы с данными (XML и двоичный);

4.Любые поддерживаемые протоколы веб-служб (если разрешены привяз-

кой), такие как WS-Security, WS-Transactions, WS-Reliability и т.д.

9

Как только контракты и привязки установлены, финальный элемент мозаики состоит в указании адреса для службы WCF. Это важно, поскольку удаленные клиенты не смогут взаимодействовать с удаленными типами, если им не удастся найти их. Подобно большинству аспектов WCF, адрес может быть жестко закодирован в сборке (с использованием типа System.Uri) или вынесен в файл *.config.

В любом случае точный формат адреса WCF отличается в зависимости от выбранной привязки (на основе HTTP, именованных каналов, TCP или MSMQ). На самом высоком уровне адреса WCF могут указывать перечисленные ниже единицы информации.

1.Scheme. Транспортный протокол (HTTP и т.п.).

2.MachineName. Полностью квалифицированное доменное имя машины.

3.Port. Во многих случаях не обязательный параметр. Например, привязка HTTP по умолчанию использует порт 80.

4.Path. Путь к службе WCF

Эта информация может быть представлена следующим обобщенным шаб-

лоном (значение Port необязательно, поскольку некоторые привязки его не используют):

Scheme://<MachineName>[:Port]/Path