Определите набор операций, осуществляемых сервисом; структуры данных, передаваемые с запросом к сервису; и ошибки или сбои, возвращаемые запросом к сервису.

Выберите соответствующую модель безопасности для сервисов. Более подробно эти вопросы рассматриваются в статье «Improving Web Services Security: Scenarios and Implementation Guidance for WCF» (Повышение безопасности Веб-сервисов:

сценарии и руководство по реализации для WCF) по адресу http://msdn.microsoft.com/en-us/library/cc949034.aspx.

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

Более подробно REST и SOAP рассматриваются в главе 25, «Проектирование приложений сервисов».

Вопросы выбора технологий

Следующие рекомендации помогут правильно выбрать технологию для реализации слоя сервисов:

Для простоты используйте ASP.NET Web services (ASMX), но только если доступен Веб-сервер, работающий под управлением Microsoft Internet Information Services (IIS).

Используйте сервисы WCF, если требуется реализовать расширенные возможности, такие как надежные сеансы с гарантированной доставкой сообщений и транзакции, трассировка действий, протоколирование сообщений, счетчики производительности и поддержка нескольких транспортных протоколов.

Если для сервиса решено использовать ASMX и требуется обеспечить безопасность на уровне сообщения и передачу двоичных данных, можно применить Web Service Extensions (WSE)1. Однако, как правило, в случае необходимости реализации функциональность WSE следует переходить к WCF.

Если решено использовать WCF для сервиса:

◦Используйте HTTP-транспорт на базе спецификаций SOAP для обеспечения возможности взаимодействия с не-WCF и не-Windows клиентами.

◦Используйте протокол TCP и двоичное кодирование сообщений с безопасностью на транспортном уровне и аутентификацией Windows, если требуется поддерживать клиентов во внутренней сети.

◦Используйте протокол именованных каналов и бинарное кодирование сообщений, если требуется поддерживать WCF-клиентов, размещенных на том же компьютере.

1 Расширения Веб-сервисов (прим. переводчика).

◦Определяйте контракты сервисов, которые используют явную, а не неявную, оболочку сообщений. Это позволит определять контракты сообщений как вход и выход для операций, таким образом, вы сможете расширять контракты данных, включенные в контракты сообщения, не оказывая влияния на контракт сервиса.

Доступные технологии обмена сообщениями представлены в главе 18, «Взаимодействие и обмен сообщениями».

Вопросы развертывания

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

Если это не идет в разрез с требованиями производительности и безопасности среды производственной эксплуатации, развертывайте слой сервисов на одном уровне с бизнес-слоем, это обеспечит максимальную производительность приложения.

Если сервис размещается на одном уровне с потребителем сервиса, используйте именованные каналы или протоколы общей памяти.

Если сервис используется только приложениями локальной сети, используйте для взаимодействия протокол TCP.

Если сервис публично доступен через Интернет, используйте HTTP в качестве транспортного протокола

Более подробно схемы развертывания рассматриваются в главе 19, «Физические уровни и развертывание».

Этапы проектирования слоя сервисов

Проектирование слоя сервисов начинается с определения интерфейса сервиса, состоящего из контрактов, которые планируется предоставлять. Обычно такой подход называют Contract First Design (Контрактно-ориентированное проектирование). Следующий шаг после определения интерфейса сервиса – проектирование реализации сервиса, который используется для преобразования контрактов данных в бизнес-сущности и для взаимодействия с бизнес-слоем. Проектирование слоя сервисов может включать следующие основные этапы:

1.Определение контрактов данных и сообщений, которые представляют используемую для сообщений схему.

2.Определение контрактов сервиса, которые представляют операции, поддерживаемые сервисом.

3.Определение контрактов сбоев, которые возвращают данные об ошибках потребителям сервиса.

4.Проектирование объектов преобразований, которые обеспечивают преобразования между бизнес-сущностями и контрактами данных.

5.Проектирования абстракции, используемой для взаимодействия с бизнес-слоем.

Для разработки Веб-сервисов можно использовать инструменты проектирования, такие как

Web Service Software Factory: Modeling Edition (также известный как Service Factory) от группы patterns & practices. Этот интегрированный набор ресурсов создан с целью обеспечить возможность быстро и единообразно создавать Веб-сервисы с использованием широко известных архитектурных схем и шаблонов проектирования. Более подробно данные вопросы рассматриваются в статье «Web Service Software Factory: Modeling Edition» (Фабрика ПО для разработки Веб-сервисов: издание для построения моделей) по адресу http://msdn.microsoft.com/en-us/library/cc487895.aspx.

Проектирование контрактов сообщений и подход Contract-First рассматриваются в главе 18, «Взаимодействие и обмен сообщениями». Абстракции в многослойных архитектурах посвящена глава 5, «Рекомендации по проектированию многослойных приложений».

Шаблоны проектирования

Основные шаблоны организованы по категориям и представлены в следующей таблице. Рассмотрите возможности применения этих шаблонов при принятии проектных решений для каждой из категорий.

Категория	Шаблоны проектирования
Сетевое	Duplex (Двусторонний обмен сообщениями). Двунаправленный обмен
взаимодействие	сообщениями, при котором и сервис, и клиент отправляют сообщения
	друг другу независимо и без учета того, какой шаблон используется, One-
	Way (Однонаправленный) или Request-Reply (Запрос-ответ).
	Fire and Forget (Отправил и забыл). Однонаправленный обмен
	сообщениями, используемый, когда ожидать ответа нет необходимости.
	Reliable Sessions (Надежные сеансы). Надежная передача сообщений
	из конца в конец между источником и точкой назначения, не зависящая от
	количества или типа посредников между конечными точками.
	Request Response (Запрос-ответ). Механизм двунаправленного обмена
	сообщениями, при котором клиент ожидает ответа на каждое
	отправленное сообщение.
Каналы обмена	Channel Adapter (Адаптер канала). Компонент, который может
сообщениями	выполнять доступ к API или данным приложения и на основании этих
	данных публиковать сообщения в канале, а также может принимать
	сообщения и вызывать функции приложения.
	Message Bus (Шина сообщений). Структурирует связующее
	промежуточное ПО между приложениями как шину связи, что позволяет
	приложениям взаимодействовать, используя обмен сообщениями.
	Messaging Bridge (Мост обмена сообщениями). Компонент,
	соединяющий обменивающиеся сообщениями системы и тиражирующий

	сообщения между этими системами.
	Point-to-Point Channel (Канал «точка-точка»). Передача сообщения по
	каналу «точка-точка» гарантирует, что получит это конкретное сообщение
	только один получатель.
	Publish-Subscribe Channel (Канал публикации-подписки). Создает
	механизм отправки сообщений только приложениям, заинтересованным в
	получении этих сообщений, без идентификации получателей.
Структура сообщения	Command Message (Сообщение с командой). Структура сообщения,
	используемая для поддержки команд.
	Document Message (Сообщение с данными документа). Структура,
	используемая для передачи документов или структуры данных между
	приложениями.
	Event Message (Сообщение о событии). Структура, обеспечивающая
	надежное асинхронное уведомление о событиях между приложениями.
	Request-Reply (Запрос-отклик). Запрос и отклик передаются по разным
	каналам.
Конечная точка	Competing Consumer (Конкурирующий потребитель). Задает несколько
сообщения	потребителей для одной очереди сообщений и заставляет их
	конкурировать за право обрабатывать сообщения, что позволяет
	обменивающемуся сообщениями клиенту обрабатывать множество
	сообщений одновременно.
	Durable Subscriber (Постоянный подписчик). Чтобы обеспечить
	гарантированную доставку в сценарии без подключения, сообщения
	сохраняются и затем предоставляются для доступа клиенту при
	подключении к каналу сообщений.
	Idempotent Receiver (Идемпотентный получатель). Гарантирует, что
	сервис обрабатывает сообщение только один раз.
	Message Dispatcher (Диспетчер сообщений). Компонент, рассылающий
	сообщения множеству потребителей.
	Messaging Gateway (Шлюз обмена сообщениями). Инкапсулирует
	вызовы, осуществляемые посредством обмена сообщениями, в один
	интерфейс, чтобы отделить их от остального кода приложения.
	Messaging Mapper (Преобразователь обмена сообщениями).
	Преобразует запросы в бизнес-объекты для входящих сообщений и
	выполняет обратный процесс для преобразования бизнес-объектов в
	ответные сообщения.
	Polling Consumer (Опрашивающий потребитель). Потребитель
	сервиса, который проверяет канал на наличие сообщений через равные
	промежутки времени.
	Selective Consumer (Избирательный потребитель). Потребитель
	сервиса, использующий фильтры для поучения только сообщений,
	соответствующих определенному критерию.
	Service Activator (Активатор сервиса). Сервис, принимающий
	асинхронные запросы для вызова операций в компонентах бизнес-слоя.
	Transactional Client (Транзакционный клиент). Клиент, который может
	реализовать транзакции при взаимодействии с сервисом.
Безопасность	Data Confidentiality (Конфиденциальность данных). Использует
сообщений	шифрование на уровне сообщений для защиты конфиденциальных

	данных в сообщении.
	Data Integrity (Целостность данных). Гарантированно обеспечивает
	защиту сообщений от повреждения или подделки при передаче.
	Data Origin Authentication (Аутентификация происхождения данных).
	Проводит проверку источника сообщения как расширенный метод
	обеспечения целостности данных.
	Exception Shielding (Экранирование исключений). При возникновении
	исключения предотвращает разглашение сервисом данных о его
	внутренней реализации.
	Federation (Объединение). Интегрированное представление данных,
	распределенных по многим сервисам и потребителям.
	Replay Protection (Защита от атак повторов). Обеспечивает
	идемпотентность сообщения, предотвращая возможность его перехвата и
	многократного выполнения злоумышленниками.
	Validation (Валидация). Проверяет содержимое и значения сообщений
	для обеспечения защиты сервиса от неправильно сформированного или
	злонамеренного содержимого.
Маршрутизация	Aggregator (Агрегатор). Фильтр, обеспечивающий сбор и сохранение
сообщения	взаимосвязанных сообщений, объединение этих сообщений и публикацию
	в выходном канале одного агрегатного сообщения для дальнейшей
	обработки.
	Content-Based Router (Маршрутизатор на основе содержимого).
	Выполняет маршрутизацию каждого сообщения к соответствующему
	потребителю, исходя из содержимого сообщения, например, наличия
	определенных полей, заданных значений полей и т.д.
	Dynamic Router (Динамический маршрутизатор). Компонент,
	выполняющий динамическую маршрутизацию сообщения к потребителю
	на основании оценки условий/правил, заданных потребителем.
	Message Broker (Hub and Spoke) (Брокер сообщений (веерная
	структура)). Центральный компонент, взаимодействующий с множеством
	приложений для получения сообщений из многих источников; определяет
	место назначения сообщения и направляет его в соответствующий канал.
	Message Filter (Фильтр сообщений). На основании заданных критериев
	предотвращает передачу по каналу потребителю нежелательных
	сообщений.
	Process Manager (Диспетчер процесса). Компонент, обеспечивающий
	маршрутизацию сообщений через множество этапов рабочего процесса.
Преобразование	Canonical Data Mapper (Канонический преобразователь данных).
сообщения	Использует общий формат данных для осуществления преобразований
	между двумя несопоставимыми форматами данных.
	Claim Check (Проверка утверждений). Извлекает данные из постоянного
	хранилища по необходимости.
	Content Enricher (Расширитель содержимого). Дополняет сообщения
	недостающими данными, полученными из внешнего источника данных.
	Content Filter (Фильтр содержимого). Удаляет конфиденциальные
	данные из сообщения и максимально сокращает объем сетевого трафика,
	удаляя ненужные данные из сообщения.
	Envelope Wrapper (Оболочка конверта). Оболочка сообщений,
	включающая данные заголовка, используемые, например, для защиты,

	маршрутизации или аутентификации сообщения.
	Normalizer (Нормализатор). Преобразует или трансформирует данные в
	общий формат обмена, если организации используют разные форматы.
REST	Behavior (Поведение). Применяется к ресурсам, выполняющим
	операции. Обычно такие ресурсы не содержат состояния и поддерживают
	только операцию POST.
	Container (Контейнер). Создает шаблон сущности, обеспечивая средства
	для динамического добавления и/или обновления вложенных ресурсов.
	Entity (Сущность). Ресурсы, чтение которых может быть осуществлено
	операцией GET, но изменение возможно только с помощью операций PUT
	и DELETE.
	Store (Хранилище). Обеспечивает возможность создания и обновления
	сущностей с помощью операции PUT.
	Transaction (Транзакция). Ресурсы, поддерживающие транзакционные
	операции.
Интерфейс сервиса	Façade (Фасад). Реализует унифицированный интерфейс для набора
	операций, чтобы обеспечить упрощенный интерфейс и уменьшить
	связанность систем.
	Remote Façade (Удаленный фасад). Создает обобщенный
	унифицированный интерфейс для набора операций или процессов в
	удаленной подсистеме, обеспечивая обобщенный интерфейс для
	детализированных операций, чтобы упростить использование этой
	подсистемы и свести до минимума вызовы по сети.
	Service Interface (Интерфейс сервиса). Программный интерфейс,
	который может использоваться другими системами для взаимодействия с
	сервисом.
SOAP	Data Contract (Контракт данных). Схема, определяющая структуры
	данных, передаваемые с запросом к сервису.
	Fault Contracts (Контракты сбоев). Схема, определяющая ошибки или
	сбои, которые могут быть возвращены из запроса к сервису.
	Service Contract (Контракт сервиса). Схема, определяющая операции,
	которые может осуществлять сервис.

Более подробно шаблоны Duplex и Request Response рассматриваются в статье «Designing Service Contracts» (Проектирование контрактов сервисов) по адресу http://msdn.microsoft.com/en-us/library/ms733070.aspx.

Более подробно шаблон Request-Reply рассматривается в статье «Request-Reply» (Запрос-

ответ) по адресу http://www.eaipatterns.com/RequestReply.html.

Более подробно шаблоны Command, Document Message, Event Message, Durable Subscriber, Idempotent Receiver, Polling Consumer и Transactional Client рассматриваются в статье

«Messaging Patterns in Service-Oriented Architecture, Part I» (Шаблоны обмена сообщениями в сервисно-ориентированной архитектуре. Часть I) по адресу http://msdn.microsoft.com/enus/library/aa480027.aspx.