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

Основы разработки WCF-служб. Часть 4. Клиент для службы

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

Основной программный код для клиентской части этой статьи создается в этой статье: Основы разработки WCF-служб. Часть 2. Разработка простейшего приложения.

Задание: Для службы, созданной в предыдущей статье (Основы разработки WCF-служб. Часть 3. Разработка простой WCF-службы), необходимо создать приложение-клиент.

Откройте два окна Visual Studio. Конечно, можно было создавать все проекты в рамках одного решения (solution), но мы поступим проще.

В первом окне Visual Studio откройте созданный в предыдущей работе проект службы. Во втором окне будем разрабатывать клиентское приложение.

Создайте проект простого консольного приложения. Назовите его, например, c_client.

Среда разработки должна будет автоматически создать примерно такой код:

Теперь необходимо добавить все функции взаимодействия с пользователем. Эти функции будут передавать соответствующие команды службе и получать от нее ответы. Откройте код программы, который мы создавали в статье Основы разработки WCF-служб. Часть 3. Разработка простой WCF-службы Часть 2. Разработка простейшего приложения, в любом текстовом редакторе, например, в Блокноте. Код возможно находится по адресу: "/a_console/a_console/Program.cs".

Скопируйте все содержимое функции static void Main(string[] args) в функцию, которая была создана в рамках вашего нового, клиентского приложения.

Теперь давайте отметим те участки кода программы, которые не будут работать или которые нам не будут нужны.

Для начала сразу видно, что код WorkBook workbook = new WorkBook(); работать не будет, так как описание класса WorkBook в рамках новой программы отсутствует. Поэтому очевидно, что нефункционален весь код, который связан с этим классом и его экземплярами:

и

и

Как мы помним, класс "WorkBook" предоставлял возможности для работы со списком книг. Сейчас эти же функции должна выполнять наша служба, а клиентское приложение должно особым образом вызывать эти процедуры. Поэтому мы не будем удалять "неработоспособный" код, а лишь впоследствии "заменим" его на рабочий.

В первом окне, где была открыта служба, запустите ее ("Отладка": "Начать отладку"). Служба будет размещена и появится окно тестового клиента. Более мы не будем возвращаться к этому окну.
Перейдите к окну клиентского приложения. Теперь необходимо каким-то образом связать клиентское приложение и службу.

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

Таким образом, своеобразно реализуется RPC-модель взаимодействия, когда основной код программы работает с локальным объектом, так же как и с удаленным, а само взаимодействие совершает уже прокси-объект-заглушка, действуя "невидимо" для клиентского приложения.

В случае с WCF прокси-объект преобразует передавамые данные под необходимые привязки и в виде XML-сообщения отправляет их службе. Код прокси объекта и конфигурации к нему в виде файла app.config генерируются с помощью утилиты svcutil.exe (входит в состав Microsoft.NET и находится в соответствующей папке основной директории MS Windows) или с помощью команды "Добавить ссылку на службу".

Сгенерируем прокси-класс. Щелкните правой кнопкой по папке "Ссылки" (References) в "Обозревателе решений". Выберите "Добавить ссылку на службу".

Откроется такое окно:

В поле "Адрес" необходимо ввести URL-адрес, по которому расположены метаданные службы. Как уже говорилось, метаданные необходимы для того, чтобы клиенты могли узнать о контрактах и конечных точках службы. Обычно метаданные описаны на языке WSDL.

Благодаря тому, что наша служба в статье Основы разработки WCF-служб. Часть 3. Разработка простой WCF-службы Часть 2. Разработка простейшего приложения создавалась по большей части автоматически, среда Visual Studio самостоятельно создала для нее конечную точку публикации метаданных. Чтобы узнать, по какому адресу расположена эта точка, откройте "Узел службы WCF", иконка которого должна располагаться в системном лотке (около "часов").

В окне "Узел службы WCF" будет единственная строчка с названием нашей службы, состоянием "Запущена" и искомым адресом метаданных. Щелкните правой кнопкой по этой строчке и выберите "Копировать адрес метаданных".

Вставьте этот адрес в поле "Адрес" окна "Добавить ссылку на службу" и нажмите "Перейти". Через несколько секунд VisualStudio подключиться к нашей службе и считает ее метаданные. В списке "Службы" появится наша служба "WorkBook", если раскрыть список, то откроются и все операции, которые поддерживаются контрактом "IWorkBook".

Теперь необходимо назвать создаваемое пространство имен. Назовем его как "WorkBookRef" (от англ. Reference – "ссылка"). Нажмите "ОК".

В течение нескольких секунд VisualStudio должен автоматически создать прокси-класс и файл настроек для него. Кроме того, будут созданы ссылки на все необходимые пространства имен, такие как, System.ServiceModel и System.Runtime.Serialization, а в "Обозревателе решений" появится папка "Service References", в которой будет показана наша ссылка "WorkBookRef". Сделайте двойной щелчок по этой ссылки и откроется "Обозреватель объектов", в котором можно будет увидеть, что же было сгенерировано.

В "Обозревателе объектов" щелкните по элементу "c_client.WorkBookRef" и посмотрите на его содержимое. Здесь был создан класс "Book", который также обладает переменными "author", "name", "comments" и т.д. Был создан интерфейс IWorkBook по контракту службы и был создан прокси-объект в виде класса WorkBookClient.

Этот класс реализует функции AddBooks(), DelBook(), GetBooks(). То есть все те функции, что реализует наша служба. Все эти классы и интерфейсы были созданы на базе wsdl-описания службы, которое расположено по адресу публикации метаданных.

Вернемся к программированию. Перейдем из "Обозревателя объектов" обратно, к коду клиента (вкладка Program.cs). Для начала необходимо подключить сгенерированное пространство имен с прокси-объектами. Для этого пропишем using c_client.WorkBookRef; ниже подключения других пространств имен.
Пространство имен подключено, а, значит, мы можем работать со всеми его классами. Заменим строчку:

на строку:

Таким образом, мы "подменили" класс по работе со списком книг прокси-классом. И прокси-объект будет выступать в роли объекта этого класса, но на самом деле он будет передавать все данные службе на обработку, чтобы ее реальный класс "WorkBook" обрабатывал данные.

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

Обратим внимание на последнюю ветвь xml-файла - "client". Здесь описана конечная точка для клиента. Указан ее адрес ("address"), привязка ("binding"), контракт ("contract"). И указано имя службы в виде name="BasicHttpBinding_IWorkBook". Скопируем это имя ("BasicHttpBinding_IWorkBook") для передачи конструктору класса WorkBookClient, чтобы получилась такая строка:

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

и

и

Попробуйте построить решение ("Построение" - "Построить решение").

Если все было ранее сделано правильно, то решение не должно быть построено из-за ошибки:

Ошибка достаточно логичная и "правильная". Дело в том, что передача данных и описание данных через язык WSDL строго регламентировано. К сожалению, описаны лишь простейшие и типовые структуры данных, а вот для коллекции вида "List", что используется в VisualStudio, места не нашлось.

Поэтому, при генерации wsdl-описания коллекция была заменена "ближайшим соседом", а именно массивом объектов класса. Поэтому прокси-объект был сгенерирован с учетом массива объектов, а не коллекции "List". И, когда наш код программы (мы его перенесли из второй статьи, где не было службы: Основы разработки WCF-служб. Часть 1. Теория WCF.) требует от функции "workbook.GetBooks();" коллекции – среда разработки отвечает адекватной ошибкой.

Изменим код программы на работу с массивом. Для этого вместо:

напишем

Кроме того, для массива нет свойства ".Count", но есть ".Length", поэтому код:

меняем на

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

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


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

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

URL-ссылка

https://artamonoviv.ru/articles/wcf_tutorial_4/