пользователей от действий и повреждения или подделки сообщений. Тем не менее, не забывайте, что все меры по обеспечению безопасности негативно сказываются на производительности.
Если взаимодействия между сервисом и потребителем осуществляются без посредников, таких как другие серверы и маршрутизаторы, можно использовать защиту на транспортном уровне, такую как протоколы IPSec или SSL. Однако если сообщение проходит через одного или более посредников, всегда должны применяться меры защиты на уровне сообщения. Если используется защита на транспортном уровне, сообщение дешифруется и вновь шифруется на каждом посреднике, что представляет угрозу безопасности.
Для обеспечения максимальной безопасности используйте оба типа защиты, на транспортном уровне и на уровне сообщения. Защита на транспортном уровне поможет защищать данные заголовков, которые не могут быть зашифрованы при использовании защиты на уровне сообщения.
При проектировании сервисов для экстрасети или типа «бизнес-бизнес» используйте косвенную аутентификацию на основе сообщений с сертификатами X.509. В сценарии «бизнес-бизнес» сертификат должен быть выпущен коммерческим центром сертификации. Для сервисов экстрасети можно применять сертификаты, выпущенные сервисом сертификации организации.
Преобразование сообщений
При передаче сообщений между сервисом и потребителем существует множество сценариев, когда сообщение требуется преобразовать в формат, понятный потребителю. Обычно это происходит в случаях, когда потребители, не имеющие возможности использовать обмен сообщениями, должны обрабатывать данные, извлекаемые из системы, использующей обмен сообщениями. Для обеспечения доступа к каналу сообщений для таких потребителей могут использоваться адаптеры и трансляторы для преобразования данных сообщения в формат, понятный каждому потребителю. При проектировании стратегии преобразования сообщений руководствуйтесь следующими рекомендациями:
Выясните, есть ли необходимость в преобразовании. Если такая необходимость имеется, выберите походящие шаблоны для преобразования сообщений. Например, шаблон Normalizer может использоваться для преобразования семантически эквивалентных сообщений в общий формат. Используйте каноническую модель только в случае крайней необходимости.
Обеспечьте преобразования в соответствующем месте, чтобы избежать повторных обработок и ненужных издержек.
Определяйте формат сообщения с помощью метаданных и храните эти метаданные во внешнем хранилище.
Применяйте такие механизмы, как BizTalk Server, который может осуществлять преобразования сообщений для широкой номенклатуры форматов и типов клиентов.
Шаблоны обмена сообщениями
Шаблон обмена сообщениями определяет взаимодействие между сервисом и его потребителем. Это взаимодействие представляет контракт между сервисом и потребителем. Консорциум W3C описывает два шаблона для SOAP-сообщений: Request-Response и SOAP Response. Другая группа стандартизации, OASIS, выработала для сервисов Язык выполнения бизнес-процессов (Business Process Execution Language, BPEL). BPEL определяет процесс для обмена сообщениями бизнес-процесса. Кроме того, другие организации определяют специальные шаблоны обмена сообщениями для обмена сообщениями бизнес-процессов. При проектировании шаблонов обмена сообщениями руководствуйтесь следующими рекомендациями:
Выбирайте шаблоны, соответствующие имеющимся требованиям и не вводящие дополнительных сложностей. Например, не используйте сложный шаблон обмена сообщениями бизнес-процесса, если достаточно шаблона Request-Response. Для однонаправленного обмена сообщениями используйте шаблон Fire and Forget.
При использовании техник моделирования бизнес-процесса существует опасность создания шаблонов обмена на основании этапов процесса. Шаблоны должны поддерживать операции, объединяющие этапы процесса.
Не изобретайте собственные, а применяйте существующие стандарты для шаблонов обмена сообщениями. Это обеспечит создание основанного на стандартах интерфейса, который будет понятен многим потребителям. Иначе говоря, потребители охотнее будут взаимодействовать с основанными на стандартах контрактами, а не изучать и принимать нестандартные контракты.
Передача репрезентативного состояния
Передача репрезентативного состояния (Representational State Transfer, REST) – это архитектурный стиль, основанный на HTTP, работа которого во многом напоминает Вебприложение. Но вместо пользователя, взаимодействующего с Веб-страницами и перемещающегося по ним, в этом случае приложения взаимодействуют и перемещаются по REST-ресурсам, используя ту же семантику, что и Веб-приложение. В REST ресурс идентифицируется Унифицированным идентификатором ресурса (Uniform Resource Identifier, URI), и действия, которые могут быть осуществлены по отношению к ресурсу, описываются с помощью HTTP-команд, таких как GET, POST, PUT и DELETE. Взаимодействие с REST-сервисом происходит путем выполнения HTTP-операций по отношению к URI, который обычно представлен в форме URL. В результате операции возвращается представление текущего состояния этого ресурса. Кроме того, результат может включать ссылки на другие ресурсы, к которым можно перейти из текущего ресурса.
Наиболее распространенное заблуждение о REST в том, что он подходит только для CRUDопераций с ресурсом. REST может использоваться с любым сервисом, который может быть представлен как конечный автомат. Иначе говоря, если сервис может быть разложен на различимые состояния, такие как извлечен и обновлен, вы можете преобразовать эти состояния в действия и продемонстрировать, как каждое из состояний может привести к одному или более состояниям. Вспомните, как UI Веб-приложения представляет конечный
автомат. При доступе к странице отображаемые данные представляют текущее состояние этих данных. Пользователь может иметь возможность изменять это состояние, обновляя поля формы через операцию POST или переходя к другой странице, используя ссылки, включенные в текущую страницу. Сервис, использующий REST, работает по такой же схеме в том смысле, что приложение может осуществлять операцию GET над ресурсом для получения его текущего состояния, менять состояние ресурса с помощью операции PUT или переходить к другому ресурсу, используя ссылки, предоставляемые текущим ресурсом.
В сервисах, поддерживающих REST, имеется и состояние приложения, и состояние ресурса. Клиент сохраняет состояние всего приложения, тогда как на сервере хранится только состояние ресурса. Каждый запрос клиента к серверу должен включать все необходимые серверу данные для полного понимания данного запроса. Иначе говоря, клиент должен передавать в запросе все данные, касающиеся состояния приложения. Затем, на основании ответов сервера, клиент может принимать решения о том, как изменять состояние ресурса. Передача состояния приложения при каждом запросе обеспечивает возможность масштабирования приложения, поскольку в этом случае можно добавлять множество идентичных Веб-серверов и балансировать нагрузку таким образом, что клиенту нет необходимости привязываться к одному конкретному серверу или состоянию любого совместно используемого приложения.
REST-сервис обладает качествами безопасности и идемпотентности. Безопасность означает способность многократно повторять запрос и получать один и тот же результат без каких-либо побочных эффектов. Под идемпотентностью подразумевается такое поведение, когда многократное повторение вызова приводит к тем же результатам, что и однократный вызов. Эти качества повышают устойчивость к ошибкам и надежность, потому что, даже несмотря на ненадежность HTTP, вы можете безопасно повторять запрос, если сервис не отвечает или возвращает ошибку.
При проектировании REST-ресурсов руководствуйтесь следующими рекомендациями:
Используйте диаграмму состояния для моделирования и описания ресурсов, которые будет поддерживать REST-сервис. Не используйте состояние сеанса в REST-сервисе.
Выработайте подход для идентификации ресурсов. Хорошей практикой является использование значимых имен начальных точек и уникальных идентификаторов REST в качестве части общего пути конкретных экземпляров ресурсов. Избегайте включения действий в URI с помощью значений QueryString.
Определитесь с тем, должны ли поддерживаться несколько реализаций для разных ресурсов. Например, решите, должен ли ресурс поддерживать формат XML, Atom или JavaScript Object Notation (JSON), и сделайте его частью запроса к ресурсу. Ресурс может предоставляться и как (например) http://www.contoso.com/example.atom, и как http://www.contoso.com/example.json. Не используйте значения QueryString для определения действий с URI. Все действия должны основываться на HTTP-операции, выполняемой по отношению к URI.
Не злоупотребляйте операцией POST. Хорошей практикой является использование конкретных HTTP-операций, таких как PUT или DELETE, это обеспечит создание дизайна на основе ресурсов и использование унифицированного интерфейса.
Применение протокола приложений HTTP позволит использовать общую инфраструктуру Веб (кэширование, аутентификацию, общие типы представления данных и т.д.).
Обеспечьте безопасность запросов GET в том смысле, чтобы они всегда возвращали один и тот же результат. Сделайте запросы PUT и DELETE идемпотентными, т.е. повторяющиеся идентичные запросы должны приводить к тому же эффекту, что и одиночный запрос.
Слой сервисов
Слой сервисов включает компоненты, определяющие и реализующие сервисы для приложения. В частности, этот слой содержит интерфейс сервиса (составленный из контрактов), реализацию сервиса и трансляторы, которые преобразуют внутренние бизнессущности в и из внешних контрактов данных. При проектировании слоя сервисов руководствуйтесь следующими рекомендациями:
Не реализуйте бизнес-правила в слое сервисов. Слой сервисов должен заниматься только управлением запросами к сервису и преобразованием контрактов данных в сущности для использования бизнес-слоем.
Доступ к слою сервисов должен определяться политиками. Политики обеспечивают потребителям сервиса способ описания требований к подключению и безопасности, а также других деталей, связанных с взаимодействием с сервисом.
Размещайте основные компоненты слоя сервисов в отдельных сборках. Например, интерфейс, реализация, контракты данных, контракты сервисов, контракты сбоев и трансляторы – для каждого из них должна быть создана собственная сборка.
Взаимодействие с бизнес-слоем должно осуществляться только через общеизвестный открытый интерфейс. Слой сервисов никогда не должен обращаться к компонентам базовой бизнес-логики.
Слой сервисов должен знать, какие бизнес-сущности используются бизнес-слоем. Обычно это обеспечивается созданием отдельной сборки, в которую помещаются все бизнес-сущности, совместно используемые слоем сервисов и бизнес-слоем.
SOAP
SOAP – протокол обмена сообщениями, при использовании которого сообщение формируется как XML-конверт, содержащий заголовок и тело. В заголовке могут размещаться сведения, внешние по отношению к осуществляемой сервисом операции. Например, заголовок может включать данные, касающиеся безопасности, транзакции или маршрутизации. Тело содержит контракты, представленные в форме XML-схем, которые определяют сервис и действия, которые он может осуществлять. По сравнению с REST, SOAP обеспечивает большую гибкость в выборе протоколов, позволяя использовать более высокопроизводительные протоколы, такие как TCP. SOAP поддерживает стандарты WS-*, включая безопасность, транзакции и надежность. Безопасность и надежность сообщения гарантирует, что сообщения не только