Оригинал статьи здесь.

Введение, или зачем нужен сервис-ориентированный подход

$0В этой статье я расскажу о том, что же такое Windows Communication Foundation и зачем он нам нужен. Особо вдаваться в технические подробности я не буду - главная цель моя - показать, что может интересного предложить нам эта новая технология. $0

$0"Сервис-ориентированная архитектура (англ. SOA, service-oriented architecture) — модульный подход к разработке программного обеспечения, основанный на использовании сервисов (служб) со стандартизированными интерфейсами." (©Википедия) $0

$0Зачем же нужен нам этот сервис-ориентированный подход, и какие преимущества он дает разработчикам и производителям программного обеспечения? $0$0Во-первых, применение SOA помогает нам избежать переписывания одного и того же функционала. Сначала для повторного использования кода применяли Dll (все помнят про этот ад), потом MS предложила нам .NET с его точной версионностью сборок. Что у нас есть сейчас? У нас есть веб-службы, которые не только позволяют повторно и многократно использовать уже имеющийся код, но и (не без греха) следить, кто и как его использует (если мы делаем сервис открытым или продаем доступ к нему). $0$0Во-вторых, службы предлагают нам независимость от того, какие платформы используют клиент и сервер. Мы можем обращаться к веб-службе, написанной на .NET из PHP-скрипта, работающего под Апачем на линуксе. Это уже не проблема. $0$0В-третьих, мы повышаем масштабируемость наших систем и продлеваем их время жизни (не давая им умирать) за счет того, что мы можем комбинировать в новые решения уже существующие сервисы, и создавать что-то принципиально новое из уже имеющегося (это то, чего хотят, например, от студентов на конкурсе Imagine Cup). $0$0И в-четвертых (как говорится, last but not least), службы позволяют нам защищать свой код. Да-да, я именно это и сказал. Как? Да все просто. Рассмотрим случай с Windows-приложением. Весь, абсолютно весь ваш функционал находится в руках конечного пользователя. И он, при наличии определенных знаний, может делать с ним (кодом) что угодно. Не секрет, что даже Висту китайцы сломали еще до ее официального выпуска. Большинству из нас живется лучше, ведь мы не пишем операционные системы! Мы можем создавать функционал, который будет спрятан за интерфейсом веб-службы, как за каменной стеной. А Windows- или Web-приложение будет только обеспечивать доступ к данному функционалу и передачу данных. Именно поэтому сейчас так модно словосочетание "тонкий клиент" (на самом деле с тонким клиентом ситуация маленько другая - "тонкость" его заключается в том, что он не держит у себя все данные; в нашем же примере клиент не держит у себя основной функционал). $0

А что же все-таки такое WCF?

$0Взглянем на определение из MSDN: $0

$0“Windows Communication Foundation (WCF) is Microsoft’s unified programming model for building service-oriented applications. It enables developers to build secure, reliable, transacted solutions that integrate across platforms and interoperate with existing investments.”(©MSDN) $0

$0Итак, WCF - это единая программная модель от Microsoft, предназначенная для создание сервис-ориентированных приложений. WCF позволяет разработчикам строить безопасные, надежные решения с поддержкой транзакций, которые могут взаимодействовать с различными платформами и уже существующими решениями. $0$0Вообще, WCF предназначен для создания как сервис-ориентированных приложений, так и распределенных приложений. Никто не мешает нам создать одноранговую сеть с дуплексными связями на WCF. Но все-таки основной ориентацией WCF являются сервисы. $0$0WCF поддерживает основные существующие на данный момент протоколы и технологии для передачи данных, это, конечно, HTTP/HTTPS, старый добрый TCP, именованные каналы, MSMQ, и так далее. Взаимодействовать можно как угодно и с кем угодно. $0$0Какие же есть в нем интересные "фишки"? $0$0Во-первых, это надежные сеансы. Между клиентом и сервером устанавливается сеанс (session, почти как в ASP.NET) и WCF может гарантировать нам 100%-ую доставку сообщений (конечно, за счет производительности). Здесь есть 2 варианта: $0$0$0Неупорядоченный сеанс - если сообщение потерялось, то после обнаружения потери оно будет запрошено заново и доставлено получателю. Сообщения, отправленные после потерянного сообщения, но до обнаружения потери, будут доставлены получателю до доставки потерянного сообщения. $0$0Упорядоченный сеанс - как только обнаруживается пропажа, входящие сообщения ставятся в очередь на принимающей стороне и "замораживаются". Они не будут переданы получателю до передачи потерянного сообщения. Это гарантирует нам, что получатель примет сообщения именно в том порядке, в каком их послал отправитель. Это очень удобно, если нужно передавать большие объемы данных побуферно (например, мы хотим их еще шифровать, при этом скорость уже не так важна, поточность уже не поддерживается, а вот надежность и безопасность - на первом месте). $0$0$0Во-вторых - безопасность. WCF поддерживает различные механизмы аутентификации и авторизации (Windows-авторизация, сертификаты, ASP.NET membership - только скорми ему провайдер). WCF также предлагает цифровую подпись сообщений (SHA-хэши) для гарантии целостности передаваемых данных и шифрование сообщений (TripleDes, Basic, RSA как "key wrap"-алгоритм) для защиты наших данных от посторонних глаз и рук. Вообще, безопасность в WCF делится на два вида - уровня транспорта и уровня сообщений, но об этом в одной из следующих статей. $0

Основные концепции WCF

$0Документов, описывающих основные понятия WCF скопилось уже много на просторах Сети (даже на русском), однако я все же повторюсь, дабы не нарушать целостности статьи. $0$0Рассмотрим сначала понятие конечной точки (это буквальный, но довольно распространенный перевод английского слова endpoint, дальше я буду называть это "точка соединения") - это абстрактный объект, от которого "уходят" данные, и к которому "приходят" данные (некий высокоуровневый аналог TCP-портов). Точка соединения объединяет в себе три "столпа WCF" - адрес, привязку и контракт (address, binding, connection - ABC, "азбука WCF"). $0$0Итак, адрес:$0$0$0$0У точки соединения может быть только один адрес $0$0$0У разных точек соединения может быть один базовый адрес (тогда адреса самих точек соединения будут задаваться относительно этого базового адреса) $0$0С помощью точки соединения адрес однозначно связывается с привязкой и контрактом $0$0$0Привязка, в свою очередь, определяет то, как наша точка соединения общается с окружающим миром. Она позволяет управлять такими вещами, как: сеанс, безопасность, поточность, транзакции, транспорт, кодировка сообщений. $0$0Контракт же, по сути, является интерфейсом службы, помеченным специальным атрибутом ServiceContractAttribute. Он определяет требования службы к безопасности, сеансу, задает параметры операций (начало сеанса, завершение сеанса, является ли операция односторонней, асинхронность операций на сервере). $0$0Например, если контракт требует наличия шифрования, или сеанса, а привязка что-либо из этих двух вариантов не поддерживает, наш сервис не запустится, и это нужно обязательно учитывать. $0$0Когда мы говорим о WCF, мы подразумеваем, что хотим передавать данные. И, конечно, мы хотим, чтобы данные передавались в удобном для нас виде. Так вот, WCF позволяет нам передавать любые объекты. Единственное требование - классы, которые мы опишем для использования при взаимодействии клиента со службой, должны быть помечены атрибутом DataContractAttribute, их поля и свойства - DataMemberAttribute, а члены перечислений - EnumMemberAttribute. Все! Никакой ручной сериализации и прочей "грязной" работы. Три атрибута, и WCF все делает за нас. $0

Хостинг и экземпляр службы

$0Чтобы наш сервис работал, его нужно будет где-нибудь запустить. Для этого есть несколько вариантов:$0$0$0ASP.NET-приложение - сервис входит в состав нашего сайта $0$0IIS - сервис хостится непосредственно в IIS (на самом деле - это тот же ASP.NET-сайт, состоящий из одного сервиса) $0$0Windows-приложение - это может быть что угодно - консоль, WinForms, WPF, и даже служба Windows $0$0$0С первыми двумя вариантами все понятно, а вот для последнего придется познакомиться с классом ServiceHost, но это тема отдельной статьи. $0$0Помнится, в самом начале мы говорили о том, что мы можем разместить наш функционал внутри нашей службы. Где же он? А вот где: мы просто создаем класс, реализующий наш контрактный интерфейс. Готово (конечно, при реализации сложного функционала все происходит не так быстро). $0$0Замечательно, теперь у нас есть объект, выполняющий наши операции. А что, если несколько клиентов соединится с ним и потребует его внимания? Здесь нам на помощь приходит инстанциация. $0

Инстанциация

$0Существует три режима создания экземпляра нашего сервисного объекта:$0$0$0PerCall - экземпляр службы создается для каждого вызова от каждого клиента. Этот режим хорош, наверное, для явно одиночных вызовов: Rss, перевод текста, и так далее. $0$0PerSession - экземпляр службы создается на период действия сеанса. Этот вариант подходит для большинства встречавшихся мне сценариев достаточно продолжительного взаимодействия, так как позволяет хранить на сервисе служебную информацию между вызовами клиента. $0$0Singleton - один экземпляр на всех. Если честно, в голову не приходит ни одного реального проекта, в котором можно подобный режим использовать. Один плюс, который я заметил - к экземпляру службы можно обратиться через его ServiceHost. $0$0

А что клиент?

$0Visual Studio позволяет очень быстро и удобно создавать класс для клиентских объектов - стоит ей скормить точку соединения с метаданными (Add Service Reference в контекстном меню проекта). Также она автоматически определяет все используемые для взаимодействия типы (но все же я советую поместить их в отдельную сборку и использовать ее на клиенте и на сервере). $0$0С помощью клиента можно:$0$0$0Вызывать методы службы $0$0Задавать информацию об учетной записи для авторизации $0$0Выбирать конечную точку, к которой мы хотим подключиться $0$0И многое другое $0$0$0Итак, надеюсь мне удалось донести до читателя, какие возможности нам предлагает технология Windows Communication Foundation. Многие спросят - зачем нам это, ведь есть Remoting? А я отвечу - а сколько времени вы тратите, чтобы сделать, например, поддержку шифрования, когда в WCF это делается в три строчки? И так далее… WCF позволяет нам сохранить время на так называемых "служебных вещах" и сосредоточиться на написании полезного кода.$0$0$0Автор статьи - Кирилл Крючков. Связаться с ним можно по электронной почте Kirill.Kruchkov@gmail.com или через раздел Обратная связь.
Также советуем почитать: Создание простейшей WCF-службы$0