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

SOAP полезен при взаимодействии типа RPC между сервисами или отдельными слоями приложения. Он исключителен в обеспечении возможности взаимодействия между новыми и устаревшими системами во внутренней сети. Слой сервисов может быть размещен поверх старой системы, делая возможным взаимодействие с системой через API без необходимости ее переработки для предоставления доступа на базе модели REST-ресурсов. SOAP также пригодится в случаях, когда данные активно передаются одной или более системам, которые могут часто менять протоколы связи. Он также может использоваться, если требуется непрозрачно инкапсулировать данные или объекты и затем сохранять или передавать их другой системе.

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

При проектировании SOAP-сообщений руководствуйтесь следующими рекомендациями:

В SOAP-конверте SOAP-заголовок является необязательным элементом, тогда как наличие SOAP-тела обязательно. В любых схемах сообщений избегайте использования составных типов.

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

Чтобы обеспечить обработку блока SOAP-заголовка, задайте атрибуту mustUnderstand (должен интерпретироваться) блока значение «true» или «1». Ошибки, возникающие при обработке SOAP-заголовка, должны возвращаться как SOAP-ошибка в элементе SOAP-заголовка.

Изучите и используйте стандарты WS-*. Эти стандарты обеспечивают единые правила и методы решения проблем, обычно возникающих в архитектуре, использующей обмен сообщениями.

Валидация

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

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

Проверяйте все вводимые данные на наличие опасного или злонамеренного содержимого и учитывайте то, как предполагается использовать данные. Например, если данные будут использоваться для запросов к базе данных, необходимо обеспечить защиту базы данных от атак внедрением SQL-кода. Это можно реализовать путем применения для доступа к базе данных совместно используемых процедур или параметризованных запросов.

Выработайте стратегии применения подписей, шифрования и кодирования.

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

Более подробно методики валидации рассматриваются в главе 17, «Сквозная функциональность».

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

При проектировании сервиса примите во внимание следующие вопросы, касающиеся выбора технологий:

Для простоты используйте ASMX, но только если доступен Веб-сервер, выполняющий

IIS.

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

Если при использовании Веб-сервисов ASP.NET требуется обеспечить безопасность на уровне сообщений и передачу двоичных данных, используйте Web Service Extensions (WSE).

Если решено использовать WCF, продумайте следующее:

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

SOAP.

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

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

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

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

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

По возможности размещайте слой сервисов на одном уровне с бизнес-слоем, это обеспечит лучшую производительность приложения.

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

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

Конфигурируйте хост сервиса для использования безопасности на транспортном уровне, только если потребители имеют прямой доступ к сервису и запросы не проходят через посредников.

Включайте трассировку и компиляцию в режиме отладки для всех сервисов только на время разработки и тестирования.

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

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

Основные шаблоны проектирования организованы по категориям, таким как Сетевое взаимодействие, Непротиворечивость данных, Структура сообщения, Конечная точка сообщения, Защита сообщений, Преобразование сообщений, REST, Интерфейс сервиса и SOAP, и представлены в следующей таблице. Рассмотрите возможности применения этих шаблонов при принятии проектных решений для каждой из категорий.

	Категория			Шаблоны
Сетевое				Duplex. Двунаправленный обмен сообщениями, при котором и сервис, и
взаимодействие				клиент отправляют сообщения друг другу независимо и без учета того,
				какой шаблон используется, One-Way (Однонаправленный) или Request-
				Reply (Запрос-ответ)
				Fire and Forget. Однонаправленный обмен сообщениями, используемый в
				случаях, когда нет необходимости ожидать ответа.
				Reliable Sessions. Надежная передача сообщений из конца в конец между

	источником и точкой назначения, не зависящая от количества или типа
	посредников между конечными точками.
	Request Response. Механизм двунаправленного обмена сообщениями, при
	котором клиент ожидает ответа на каждое отправленное сообщение
Непротиворечивость	Atomic Transactions (Атомарные транзакции). Транзакции, область
данных	действия которых ограничена одной операцией сервиса.
	Cross-service Transactions (Межсервисные транзакции). Транзакции,
	которые могут охватывать множество сервисов.
	Long-running transactions (Длительные транзакции). Транзакции,
	являющиеся частью бизнес-процесса.
Структура сообщения	Command Message. Структура сообщения, используемая для поддержки
	команд.
	Document Message. Структура, используемая для передачи документов
	или структуры данных между приложениями.
	Event Message. Структура, обеспечивающая надежное асинхронное
	уведомление о событиях между приложениями.
	Request-Reply. Запрос и отклик передаются по разным каналам.
Конечная точка	Competing Consumer. Задает несколько потребителей для одной очереди
сообщения	сообщений и заставляет их конкурировать за право обрабатывать
	сообщения, что позволяет обменивающемуся сообщениями клиенту
	обрабатывать множество сообщений одновременно
	Durable Subscriber. Чтобы обеспечить гарантированную доставку в
	сценарии без подключения, сообщения сохраняются и затем
	предоставляются для доступа клиенту при подключении к каналу
	сообщений.
	Idempotent Receiver. Гарантирует, что сервис обрабатывает сообщение
	только один раз.
	Message Dispatcher. Компонент, рассылающий сообщения множеству
	потребителей.
	Messaging Gateway. Инкапсулирует вызовы, осуществляемые посредством
	обмена сообщениями, в один интерфейс, чтобы отделить их от остального
	кода приложения.
	Messaging Mapper. Преобразует запросы в бизнес-объекты для входящих
	сообщений и выполняет обратный процесс для преобразования бизнес-
	объектов в ответные сообщения.
	Polling Consumer. Потребитель сервиса, который проверяет канал на
	наличие сообщений через равные промежутки времени.
	Service Activator. Сервис, принимающий асинхронные запросы для вызова
	операций в компонентах бизнес-слоя.
	Selective Consumer. Потребитель сервиса, использующий фильтры для
	поучения только сообщений, соответствующих определенному критерию.
	Transactional Client. Клиент, который может реализовать транзакции при
	взаимодействии с сервисом.
Защита сообщений	Data Confidentiality. Использует шифрование на уровне сообщений для
	защиты конфиденциальных данных в сообщении.
	Data Integrity. Гарантированно обеспечивает защиту сообщений от
	повреждения или подделки при передаче.

	Data Origin Authentication. Проводит проверку источника сообщения как
	расширенный метод обеспечения целостности данных.
	Exception Shielding. При возникновении исключения предотвращает
	разглашение сервисом данных о его внутренней реализации.
	Federation. Интегрированное представление данных, распределенных по
	многим сервисам и потребителям.
	Replay Protection. Обеспечивает идемпотентность сообщения,
	предотвращая возможность его перехвата и многократного выполнения
	злоумышленниками.
	Validation. Проверяет содержимое и значения сообщений для обеспечения
	защиты сервиса от неправильно сформированного или злонамеренного
	содержимого.
Преобразование	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. Схема, определяющая структуры данных, передаваемые с
	запросом к сервису.