Концепция “abc”
В основу технологии WCF положена концепция ABC:
Address
Binding
Contract.
Чтобы использовать сервис, мы должны знать, где он расположен, т.е. знать его адрес (Address). Именно за это отвечает первая буква аббревиатуры ABC. Адреса в WCF имеют вид обычных URI:
http://MyService
https://www.services.com/SomeService.svc
net.tcp://MyHost/MyService
По этому адресу клиент будет обращаться к сервису. Но одного адреса недостаточно. Каким именно протоколом пользоваться при общении с сервисом, какие параметры протокола применять, какая кодировка используется при общении, включена ли безопасность и каковы ее параметры? За все эти вопросы отвечает привиязка (Binding), вторая буква аббревиатуры ABC. Она указывает, будет ли общение клиента и сервиса происходить по протоколу http, tcp или какому-либо другому. Она определяет кодировку сообщений. Она отвечает за механизмы безопасности.
Однако и этого недостаточно. Нужно знать, какие именно методы имеются у сервиса, каковы параметры этих методов. За это отвечает контракт сервиса (Contract), последняя буква аббревиатуры ABC. Собственно контракт мы уже создали. Это наш интерфейс. Слово Contract в названиях использованных аттрибутов указывает на то, что данный интерфейс будет использоваться в качестве контракта сервиса.
Таким образом, нам осталось определить только адрес и привязку. Этим мы и займемся. Но сперва мы должны разобраться с понятием хоста.
Хосты сервисов wcf
Ваш сервис должен где-то размещаться. Само собой, должен быть компьютер, на котором он запущен. Но так же на этом компьютере должна быть запущена инфраструктура WCF, которая управляет всеми соединениями с вашим сервисом. Т.е. должен существовать некоторый процесс, в котором запущен ваш сервис. Именно этот процесс и будет называться хостом. На самом деле хостом может быть что угодно: консольное приложение, WinForms- или WPF-приложение, Windows-сервис, Web-сайт, размещенный на IIS. Некоторое отличие в использовании этих различных хостов существует только в размещении WCF-сервиса на IIS. В остальных же случаях создание сервиса проходит практически одинаково. Начнем рассмотрение с развертывания нашего сервиса в консольном приложении. Это позволит нам не отвлекаться на иные аспекты.
Развертывание wcf-сервиса в консольном приложении
Создадим новое консольное приложение:
Для того, чтобы это приложение могло быть хостом нашего сервиса, добавьте в него ссылку на нашу библиотеку сервиса и на библиотеки WCF. Теперь запустить WCF-сервис очень просто:
using (ServiceHost host = new ServiceHost(typeof(ServiceLibrary.FirstService)))
{
host.Open();
Console.WriteLine("Service host is started. Press ENTER to close it.");
Console.ReadLine();
}
Вот и все, что нужно написать в коде для запуска сервиса. Но где же указания адреса и привязки, спросите вы. Они находятся в конфигурационном файле приложения.
Настройка конфигурационного файла
Добавим в наше консольное приложение конфигурационный файл:
В нем указывается практически вся информация о настройках системы WCF для сервиса. Вот как она выглядит в простейшем случае:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<services>
<service name="ServiceLibrary.FirstService">
<endpoint
address="http://localhost:12324/SimpleService"
binding="wsHttpBinding"
contract="ServiceLibrary.IFirstService"/>
</service>
</services>
</system.serviceModel>
</configuration>
Как видите, в простейшем случае настройка сервиса весьма проста. В элементе service вы в качестве имени сервиса (name) указываете полное имя вашего класса сервиса. Внутри элемента service может находиться несколько элементов endpoint. Каждый из них описывает «точку привязки» или «конечную точку», указывая адрес, привязку и контракт. В качестве контракта укажите полное имя вашего интерфейса сервиса. В качестве привязки binding вы можете указать одну из стандартных привязок: basicHttpBinding, wsHttpBinding, netTcpBinding и некоторые другие. При необходимости вы можете даже создать собственную привязку.
Как я уже сказал, для одного сервиса может иметься несколько точек привязки. Это позволяет вам, например, опубликовать ваш сервис по нескольким адресам, дать возможность обжение с вашим сервисом через несколько привязок. Если ваш класс сервиса реализует несколько контрактных интерфейсов, то вы таким образом можете опубликовать несколько контрактов.