Следствием стремительно развивающихся технологий являются многокомпонентные системы. Cloud Computing стало доступно массам. Распределенная архитектура теперь является естественной потребностью не только крупных организаций. Сегодня мы рассмотрим систему быстрого развертывания распределенных приложений в домашних условиях.
Мы продолжаем знакомиться со спектром технологий платформы .NET Framework. Одна из прошлых статей была посвящена .NET Remoting – принципу построения сетевых приложений, на основе которого мы построили полноценную систему распределенных вычислений. Однако Microsoft не стала ограничивать фантазию разработчика одним «ремоутингом», который упрощает разработку сетевых приложений и предоставляет широкий инструментарий для обмена данными между клиентской и серверной частью, но все же остается в рамках архитектуры «клиент-сервер». С ростом функционала проектируемого приложения растет количество его функциональных элементов, роль которых уже далека от классического представления.
Целый набор технологий построения безопасных систем с распределенной архитектурой, и в том числе концепция упомянутой Remoting, вошли в состав фреймворка Windows Communication Foundation, который, в свою очередь, входит в .NET Framework. Разработчику предоставляется единая инфраструктура создания, поддержки и развертывания web-служб, каждая из которых функционирует по принципу «способности к взаимодействию», то есть имеет полностью открытые интерфейсы с целью функционирования в совокупности с другими системами без каких-либо ограничений к своей внутренней архитектуре. Таким образом, прослеживается связь с технологией, которая имеет модное название «cloud computing» – служба предоставляется как сервис, а, значит, предоставляются компьютерные ресурсы и вычислительные мощности.
Однако, инструментарий для программирования систем распределенных транзакций – не единственная область WCF. Технология также обеспечивает поддержку для удобной работы в веб-среде. Модель программирования WCF WEB HTTP сочетает в себе необходимые для создания многофункциональных веб-приложений технологии обработки данных: поддержка команд получения/изменения/вызова данных (GET и POST), обработка унифицированных локаторов ресурсов (URI), поддержка нескольких различных типов данных (документы XML, объекты AJAX и JSON, сообщения SOAP). Имеются также средства обеспечения конфиденциальности, целостности и аутентификации. Теперь проблема разграничения доступа к административной части твоей бот-сети не ограничивается банальной передачей пары «логин:пароль» авторизационной форме.
Прежде чем приступить к обзору средств WCF для построения приложений с распределенной архитектурой, рассмотрим подходы к реализации этих архитектур.
Два сапога…
В распоряжении архитектора распределенных систем два подхода: SOAP и REST.
SOAP (Simple Object Access Protocol) – классический подход, в общем случае представляющий собой обмен сообщениями в распределенной инфраструктуре. Одной из реализаций данного подхода является уже упомянутая технология .NET Remoting.
Рассмотрим организацию SOAP на простом примере. Пусть имеется некоторый «Сервис», предоставляющий методы, естественно, с описанной в специальном формате структурой. В нашем случае Сервис предоставляет метод «GetBalance(int AccountID)» получения баланса на запрашиваемом аккаунте. Клиент генерирует специальный запрос и отправляет его в составе HTTP-пакета Сервису:
//стандартные HTTP-заголовки
…
SOAPAction: GetBalance
…
//SOAP-конверт
//тело SOAP-запроса
2
Формат SOAP-ответа формируется аналогичным образом.
Подход REST (Representational State Transfer) – альтернатива SOAP. Данный архитектурный стиль построен на таких стандартах как HTTP, URI, XML. Акцент в этом подходе сделан не на исполнении удаленных сервисов, как в SOAP, а на доступе к необходимым ресурсам с помощью их унифицированных локаторов, называемых URI. Для вызова методов и получения/изменения каких-либо данных происходит обращение с сервису с помощью стандартных HTTP-глаголов (GET, POST, PUT, DELETE). Каждый объект кодируется уникальным URL, например:
www.service-site.com/Accounts/2
Таким образом, данные полученные по указанному URL при повторном обращении к ним могут быть кэшированны.
На первый взгляд, разница не существенна, ведь так или иначе клиент получает необходимые ему данные, однако, результаты проектирования системы в соответствии с этими подходами кардинально отличаются.
Аргумент не в пользу SOAP: обязательный разбор клиентом полученного XML-кода требует определенных трудозатрат, что плохо сказывает на масштабируемости задачи. REST в этом плане более практичен и не требует специальных оптимизационных мероприятий. Выбор того или иного подхода должен быть основан прежде всего на особенностях решаемой задачи.
Вернемся непосредственно к WCF и посмотрим, какой набор инструментов предоставляется разработчику.
Сквозь призму Microsoft
Обмен данными между WCF-клиентом и WCF-сервисом основан на так называемых слоях. Клиент, имеющий в своем распоряжении формат обращения к методам сервиса, генерирует запрос к какому-либо методу. Происходит генерация прокси (а вот и концепция Remoting’а) и передача ему запроса (списка параметров для обращения к методу). WCF кодирует эти параметры, добавляет необходимые атрибуты безопасности (опционально), отправляет в транспортный канал. Далее, сервис в обратном порядке извлекает этот запрос, соответствующим образом обрабатывает (согласно инструкциям метода), и возвращает результат клиенту. Протоколом передачи данных может выступать один из стандартных протоколов: HTTP, TCP, MSMQ и др.
WCF «по умолчанию» основан на SOAP. Однако если использовать только часть определенных слоев, то можно организовать REST-подход.
В Windows Communication Foundation есть три ключевых понятия:
- Адрес (Address);
- Связывание (Binding);
- Контракт (Contract).
Эти три атрибута определяют понятие «оконечной точки» сервиса. Ее «Адрес», как ни странно, определяет адрес нахождения сервиса. Именно для предоставления адресной информации используется URI.
Элементы типа «Связывание» определяет, как будет осуществляться взаимодействие с точкой, то есть какие протоколы будут использоваться на транспортном уровне (например, TcpTransportBindingElement – передача по протоколу TCP), будет ли проверяться надежность передачи сообщения (о чем свидетельствует присутствие элемента ReliableSessionBindingElement) и включена ли безопасность передачи SOAP-сообщений (наличие элемента SecurityBindingElement). Каждый из этих элементов, в сою очередь, может иметь ряд атрибутов, уточняющих специфику конкретного элемента.
Элементы типа «Контракт» представляют собой совокупность Операций, определяющих то, что оконечная точка будет сообщать внешней среде. По сути, Операция – ничто иное, как обмен сообщениями (запрос/ответ) или их односторонняя отправка.
Есть контакт!
Объявление Контракта заключается в создании класса и привязки к нему атрибута ServiceContractAttribute. В свою очередь, метод класса, требующий передачи данных в внешний мир, также должен помечаться атрибутом OperationContractAttribute:
[ServiceContract]
public interface AddIntPoint
{
[OperationContract]
int Add(int x, int y);
}
Как можно догадаться из определения Контракта – в нем должно произойти сложение двух чисел, а вот его реализация:
public class AddService : AddIntPoint
{
public int Add(int x, int y)
{ return x + y; }
}
Теперь класс AddService является классом WCF-сервиса и может быть вызван удаленно клиентской частью.
Следующий код демонстрирует определение оконечной точки:
public class WCFServiceApp
{
//метод определения оконечной точки и запуска сервиса
public void DefineEndpointImperatively()
{...}
//эквивалентная оконечная точка в конфигурационном файле
public void DefineEndpointInConfig()
{...}
}
В функции DefineEndpointImperatively() объявляется экземпляр класса, который реализует нужный функционал, добавляется точка подключения по протоколу HTTP, и происходит запуск службы:
...
ServiceHost sh = new ServiceHost(typeof(AddService));
sh.AddServiceEndpoint(
typeof(AddIntPoint),
new WSHttpBinding(),
"http://localhost/AddService/Ep1");
sh.Open();
...
Следующий фрагмент кода иллюстрирует процесс отправки сообщений клиентом оконечной точке AddIntPoint сервиса:
public class WCFClientApp
{
//инициализация канала передачи данных
public void SendMessageToEndpoint()
{
MathProxy proxy = new MathProxy();
int result = proxy.Add(35, 7);
}
}
Аналогичным образом клиент хранит свою оконечную точку, для поддержки связи с оконечной точной сервиса. Кстати говоря, сервисы могут предоставлять целую коллекцию оконечных точек, а значит предоставляют возможность использовать несколько различных каналов передачи данных (транспортов). Это дает возможность абстрагироваться от канала передачи данных и расширить множество потенциальных клиентских платформ за счет использования различных протоколов передачи данных на транспортном уровне.
Конфигурационный файл сервиса, расположенный вне исходного кода, позволяет легко активировать/деактивировать дополнительные опции сервиса (настройки безопасности, проверка целостности передаваемых данных и т.п.).
К не менее приятным особенностям WCF-сервисов также стоит отнести полную независимость от IIS-сервера (в этом заключается отличие от обычных web-сервисов, работающих исключительно под его управлением). То есть, мы можем поднять консольное приложение в виде сервиса, работающего по HTTP-протоколу.
Что же там – за горизонтом?
К спектру технологий WCF можно подойти с разных позиций: разработка, безопасность, масштабируемость. Охватить детали той или иной области, которую касается Windows Communication Foundation – невозможно в рамках одной статьи. Да мы такой задачи и не ставили. Рассмотрев детали быстрой организации клиент-сервисной (именно сервисной) архитектуры, мы создали плацдарм для дальнейших исследований и непосредственного испытания майкрософтоской технологии в боевых условиях.<
Предоставленный материал представляет собой лишь вводную часть к той длинной истории, которая называется «WCF-сервис и сорок разбойников», коими выступают придуманные тобою сервисы. Ознакомившись с теоретической составляющей и бегло освоив базовые конструкции и детали конфигурации сервисной части, ты получаешь в свое распоряжение мощный инструмент реализации своих самых распределенных идей.
1 comment
Отредактированная версия статьи на официальном веб-ресурсе журнала “Хакер”: http://www.xakep.ru/post/54797/default.asp