Веб-сервисы, Программирование, Сервис-ориентированные системы

Основы разработки WCF-служб. Часть 7. Добавление нескольких конечных точек службы

Для приложения c WCF-службой задаем конфигурацию через файл app.config и добавляем к службе несколько конечных точек, работающих с одним и тем же контрактом. Основы разработки WCF-служб. Часть 7. Добавление нескольких конечных точек службы
Иван Артамоновhttps://artamonoviv.ru/images/icon/logo.png
Внимание! Эта статья была опубликована в 2012 году в книге "Разработка распределенных сервисно-ориентированных программных средств". Использование материалов из нее разрешено только при правильной библиографической ссылке (для докладов, курсовых работы, рефератов, дипломных и пр. научных работ) или url-ссылки (для сайтов). Библиографическое описание дано в конце статьи.
PDF-версия статьи: скачать
Для приложения c WCF-службой задать конфигурацию через файл app.config и добавить к службе несколько конечных точек, работающих с одним и тем же контрактом.

Задача: Для приложения, разработанного в рамках статьи Основы разработки WCF-служб. Часть 3. Разработка простой WCF-службы, задать конфигурацию WCF-службы через файл app.config и добавить к службе несколько конечных точек, работающих с одним и тем же контрактом.

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

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

Откройте проект статьи Основы разработки WCF-служб. Часть 5. Размещение службы в отдельном процессе, чтобы приступить к его модификации (если вы не желаете терять код этой работы, то следует скопировать папку проекта в отдельное место).

Откройте код программы и удалите строку, которая отвечает за добавление конечной точки:

Кроме того, у конструктора "ServiceHost" удалим базовый адрес службы, так как мы пропишем его через конфигурационный файл:

В "Обозревателе решений" щелкните правой кнопкой по проекту "d_servicehost" и выберите: "Добавить" : "Создать элемент" : "Файл конфигурации приложения" с именем "App.config". VisualStudio откроет заготовку xml-файла настроек.

Щелкните правой кнопкой по "App.config" и выберите "Изменение конфигурации WCF". Если такого пункта меню нет, то в меню "Сервис" выберите "WCF Service Configuration Editor". Откроется окно редактора. Закройте окно редактора. Повторно вызовете контекстное меню "App.config" и выберите "Edit WCF configuration". Перед вами откроется окно редактора настроек WCF-службы.

Для начала необходимо добавить саму службу. Щелкните на "Создать новую службу…". В появившемся окне выберите библиотеку службы "b_FirstService.dll", которая находится в папке Debug вашего проекта, а в ней класс службы "b_FirstService.WorkBook".

Далее выберите необходимый контракт, в нашем случае это будет: "b_FirstService.IWorkBook".

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

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

Этот тип используется для взаимодействия между WCF-программами, либо программами, которые поддерживают стандарты WS-*. Таким образом, задав несколько простых вопросов Visual Studio, автоматически определит необходимую для нашей службы привязку.
Выберем "Basic Web Service Interoperability".

В следующем окне необходимо ввести адрес первой конечной точки службы. Пусть это будет адрес "basic". Почему же мы не ввели, как и предлагалось, что-то типа "http://…"? Дело в том, что адрес конечной точки можно задать двумя способами: через полный путь или через относительный.

Полный путь – это путь, включающий протокол передачи данных, домен, путь от корня домена до точки, например: "http://yandex.ru/ws/services/basic". Если же выбран относительный путь, то для идентификации точки он добавляется к базовому пути службы.

Например, если базовый путь до службы "http://yandex.ru/ws/services/bookservice", а относительный путь точки "basic", то путь до точки будет выглядеть как "http://yandex.ru/ws/services/bookservice/basic". Поэтому мы в нашем примере ввели "basic", предполагая, что адрес точки будет вычислен исходя из базового адреса службы.

Нажмите <Finish>.

Теперь посмотрите на иерархический список, а точнее на его элемент "Services". Раскройте список и убедитесь, что для службы была создана конечная точка с пустым именем ("Empty Name"), что эта точка расположена по адресу "basic" (этот адрес будет добавляться в конец базового адреса службы), имеет привязку "basicHttpBinding" и реализует работу по контракту "b_FirstService.IWorkBook".

Добавим базовый адрес службы. Как вы помните, когда мы создавали экземпляр класса "ServiceHost", мы задавали для него базовый адрес прямо в коде программы, сейчас мы зададим этот адрес через файл настроек. Для этого перейдем к элементу списка "Host". И для списка "Базовые адрес" или "BaseAdresses" выберем "New…". Давайте введем адрес, отличающийся от привычного. Пусть это будет:

Далее создадим еще конечные точки для одного и того же контракта службы. Перейдите к разделу "Services" и в правой части окна нажмите "Create a New Service Endpoint". В следующем окне оставьте контракт "b_FirstService.IWorkBook" как есть, перейдите далее. Способ коммуникации – "HTTP". Метод взаимодействия "Продвинутый" ("Advanced") и "Симплексное взаимодействие" ("Simplex Communication"). Адрес: "advanced".

Добавьте еще одну конечную точку. Способ коммуникации – "TCP". Адрес: "net.tcp://localhost:9000/bookservice".

Добавьте еще одну конечную точку. Способ коммуникации – "Named Pipes" ("именованные каналы"). Адрес: "net.pipe://localhost/bookservice".

Итак, мы добавили 4 конечных точки. Сохраните конфигурационный файл и закройте редактор конфигурации.
Откройте файл "App.config" как обычный XML-файл. Вы должны увидеть вот это:

Внимание! Если в вашем файле попадаются участки подключения сертификатов X.509 в виде:

то эти участки повсеместно необходимо вручную из файла удалить.

Постройте решение и запустите службу. Если запуск прошел нормально – то файл "App.config" был успешно считан и применен.

Попробуйте запустить клиентское приложение из статьи Основы разработки WCF-служб. Часть 4. Клиент для службы (Скорей всего, клиент находится по адресу: "\c_client\c_client\bin\Debug\c_client.exe"). Поработайте с клиентом и убедитесь, что на все действия он рано или поздно выдает ошибку. Ошибка возникает в тот момент, когда клиент пытается подключиться к службе и отправить ей данные.

В чем же дело? Дело в том, что мы ввели совсем иной адрес для нашей службы, нежели чем тот, которым пользуется клиент. Для того, чтобы "починить" клиентской приложение, откройте его файл настроек "c_client.exe.config" (этот файл копируется из "App.config" во время компиляции программы).

В области "client" необходимо найти конечную точку ("") и изменить ее параметры. В первую очередь адрес и "тип подключения". Откройте файл настроек нашей службы (этот файл, "App.config" должен уже быть открыт у вас в среде Visual Studio). Как вы можете заметить, здесь у нас целых 4 конечных точки. Давайте возьмем для опытов первую из них, с адресом "basic".

Скопируйте значение ее привязки ("binding") в аналогичный атрибут конечной точки клиента. Как вы видите, привязка клиента ("wsHttpBinding") отличается от этой ("basicHttpBinding").

Далее необходимо скопировать адрес, однако здесь есть некоторые сложности. Как уже отмечалось, для первой точки мы ввели ее относительный адрес, который нужно сложить с базовым адресом службы. Базовый адрес: "http://localhost:8080/bookservice", а относительный адрес точки: "basic", поэтому полный путь до точки будет:

Этот адрес и введем в поле адреса настроек клиента.

Теперь необходимо разобраться с настройками привязки. Обратите внимание, что выше блока "client" есть блок "bindings", в котором описываются настройки привязок. Сейчас блок привязок описывает конфигурацию для привязки "wsHttpBinding", которую наш клиент уже не будет использовать. Конфигурация привязки имеет имя и конечная точка обращается в этой конфигурации через атрибут: bindingConfiguration="WSHttpBinding_IWorkBook"

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

Удалите код обращения из конечной точки к конфигурации привязки, а заодно можно удалить и весь блок "bindings", так как он нам более не нужен. Код настроек клиента должен выглядеть примерно так:

Запустите клиента. Он без проблем будет работать с уже запущенной службой.

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

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


Библиографическое описание

Артамонов, И. В. Разработка распределенных сервисно-ориентированных программных средств / Иван Васильевич Артамонов. – Иркутск : БГУЭП, 2012. – 130 с.

URL-ссылка

https://artamonoviv.ru/articles/wcf_tutorial_7/