Преобразование сообщений
Часто при передаче сообщений между сервисом и потребителем приходится преобразовывать их в формат, понятный потребителю. Обеспечить доступ к каналу обмена сообщениями для клиентов, не поддерживающих обмен сообщениями, можно с помощью адаптеров; а для преобразования данных сообщений в формат, понятный всем потребителям, используются трансляторы. При проектировании преобразования сообщений руководствуйтесь следующими рекомендациями:
Определите требования и место выполнения преобразования. Учтите издержки производительности при преобразовании и постарайтесь максимально сократить количество выполняемых преобразований.
Выберите соответствующие шаблоны для преобразования сообщений, такие как
Canonical Data Mapper, Envelope Wrapper и Normalizer. Однако применяйте модель
Canonical Data Mapper только по необходимости.
Определяйте формат сообщения с помощью метаданных.
Рассмотрите возможность использования внешнего хранилища для хранения метаданных.
Интерфейс сервиса
Интерфейс сервиса представляет контракт, предоставляемый сервисом. Контракт определяет операции, поддерживаемые сервисом, и связанные с ними параметры и объекты передачи данных. При проектировании интерфейса сервиса необходимо учесть пересекаемые границы и тип потребителей, которые будут осуществлять доступ к сервису. Например, операции сервиса должны быть операциями уровня приложения и слабо детализированными. Одна из самых больших ошибок при проектировании интерфейса сервиса – интерпретация сервиса как компонента с детализированными операциями. Это приводит к созданию дизайна, требующего большого количества вызовов через физические границы или границы процесса, что может снизить производительность и увеличить задержки при выполнении операций. При проектировании интерфейса сервиса руководствуйтесь следующими рекомендациями:
Используйте слабо детализированный интерфейс для обеспечения пакетирования запросов и максимального сокращения количества вызовов по сети.
Проектируйте интерфейсы сервисов таким образом, чтобы изменения бизнеслогики не оказывали на них влияния. Однако при изменении бизнес-требований, вероятно, это будет просто неизбежно.
Не реализуйте бизнес-правила в интерфейсе сервиса.
Для обеспечения максимальной совместимости с разными типами клиентов используйте параметры стандартных форматов. При проектировании интерфейса не делайте допущений о возможных вариантах использования сервиса клиентом.
Не используйте наследование объектов для реализации контроля версий интерфейса сервиса.
Включайте трассировку и компиляцию в режиме отладки для всех сервисов только на время разработки и тестирования.
Валидация
Для обеспечения защиты слоя сервисов необходимо проверять все получаемые им запросы, в противном случае приложение будет уязвимым и к злонамеренным атакам, и к ошибкам, обусловленным некорректными входными данными. Точного и исчерпывающего определения действительного или злонамеренного ввода не существует, кроме того, риск эксплуатации уязвимостей зависит от того, как приложение использует поступающие данные. При проектировании стратегии валидации руководствуйтесь следующими рекомендациями:
Используйте централизованный подход к проверке, чтобы максимально повысить тестируемость и пригодность для повторного использования.
Ограничивайте, отклоняйте и очищайте все содержимое сообщений, включая параметры. Проводите проверку длины, диапазона, формата и типа.
Используйте схемы проверки сообщений. Валидация с применением схем рассматривается в статье «Message Validation» (Валидация сообщений) по адресу http://msdn.microsoft.com/en-us/library/cc949065.aspx и в статье «Input/Data Validation» (Валидация ввода/данных) по адресу http://msdn.microsoft.com/enus/library/cc949061.aspx.
REST и SOAP
Representational State Transfer (REST)1 и SOAP представляют два разных стиля реализации сервисов. Фактически, REST – это архитектурный шаблон, создаваемый с использованием простых команд и хорошо ложащийся на протокол HTTP. Хотя архитектурные принципы REST могли бы применяться и с другими протоколами, на практике реализации REST используются в сочетании с HTTP. SOAP – это основанный на XML протокол обмена сообщениями, который может использоваться с любым протоколом связи, в том числе и с HTTP.
Основное различие между этими двумя подходами в способе сохранения состояния сервиса. Состояние сервиса не должно рассматриваться как состояние приложения или сеанса; это разные состояния, которые приложение проходит в течение его жизненного цикла. При использовании SOAP переход из состояния в состояние может быть реализован через взаимодействие с единственной конечной точкой сервиса, которая может инкапсулировать и предоставлять доступ ко многим операциям и типам сообщений.
При использовании REST набор операций ограничен, и эти операции применяются к ресурсам, которые предоставляются и доступны через URI (HTTP-адреса). В сообщениях фиксируется текущее или необходимое состояние ресурса. REST хорошо работает с Веб-приложениями, что позволяет обеспечивать преимущество поддержки HTTP не-XML MIME-типам или потоковую передачу содержимого. Потребители сервиса при перемещении по REST-ресурсам
1 Передача репрезентативного состояния (прим. переводчика).
взаимодействуют с URI так же, как обычный пользователь перемещается и взаимодействует с Веб-страницами.
С большинством реализаций сервисов могут использоваться и REST, и SOAP, часто подход с применением REST лучше подходит для публичных сервисов или в случаях, когда доступ к сервису может осуществляться неизвестными потребителями. SOAP намного лучше подходит для реализации широкого диапазона процедурных взаимодействий, таких как интерфейс между слоями приложения. С SOAP вы не ограничены одним только протоколом HTTP. Стандарты WS-*, которые могут использоваться в SOAP, предоставляют стандартный и, следовательно, обеспечивающий возможность взаимодействия метод решения общих проблем обмена сообщениями, таких как безопасность, транзакции, адресация и надежность. REST тоже может обеспечивать такую же функциональность, но в настоящее время эта область практически не стандартизована, поэтому часто приходится создавать собственные механизмы.
В общем, при проектировании взаимодействий на базе SOAP можно использовать те же принципы, чтобы и для REST-взаимодействий без сохранения состояния. В обоих подходах для описания обмена данными (полезной нагрузкой) используются обычные глаголы. В случае с SOAP набор глаголов не является окончательным и определяется конечной точкой сервиса. Для REST набор глаголов ограничен предопределенными словами, отражающими протокол HTTP. При выборе между REST и SOAP руководствуйтесь следующими рекомендациями:
SOAP – протокол, обеспечивающий базовую инфраструктуру обмена сообщениями, на которой могут строиться абстрактные слои. Он обычно применяется как RPCинфраструктура1, передающая запросы и ответы по сети с помощью XMLформатированных сообщений.
SOAP обеспечивает учет таких аспектов, как безопасность и адресация, через внутреннюю реализацию протокола, но требует, чтобы был доступен стек SOAP.
REST – методика, которая может использовать другие протоколы, такие как
JavaScript Object Notation (JSON)2, протокол публикации Atom и собственные форматы Plain Old XML (POX)3.
REST предоставляет приложение и данные как конечный автомат, а не просто конечную точку сервиса. Он позволяет использовать для выполнения запросов и изменения состояния системы стандартные HTTP-методы вызова, такие как GET и PUT. REST по своей природе не сохраняет состояния, поэтому каждый отдельный запрос, присылаемый от клиента серверу, должен содержать все необходимые данные для его интерпретации, поскольку сервер не сохраняет данных о состоянии сеанса.
1Механизм удаленного вызова процедур (прим. научного редактора).
2Объектная нотация JavaScript (прим. переводчика).
3Обычный старый XML (прим. переводчика).
Аспекты проектирования при использовании REST
REST представляет архитектурный стиль для распределенных систем и создан с целью упростить систему путем ее деления на ресурсы. Ресурсы и операции, поддерживаемые ими, представляются и предоставляются как набор URI, передаваемых по протоколу HTTP. При проектировании REST-ресурсов руководствуйтесь следующими рекомендациями
Обозначьте и распределите по категориям ресурсы, которые будут предоставляться клиентам.
Выберите подход для представления ресурсов. Хорошей практикой является использование значащих имен для исходных точек REST и уникальных идентификаторов для конкретных экземпляров ресурсов. Например, http://www.contoso.com/employee/ представляет исходную точку служащий. http://www.contoso.com/employee/smithah01 использует ID служащего для обозначения конкретного служащего.
Примите решение о необходимости поддержки множества реализаций для разных ресурсов. Например, о том, должен ли ресурс поддерживать форматы XML, Atom или JSON, и сделайте это частью запроса к ресурсу, тогда ресурс будет предоставляться в разных форматах (например, http://www.contoso.com/example.atom и http://www.contoso.com/example.json).
Примите решение о необходимости поддерживать множество представлений для разных ресурсов. Например, должен ли ресурс поддерживать операции GET и POST или только GET. По возможности не увлекайтесь применением операций POST и избегайте размещения действий в URI.
Не реализуйте сохранения состояния сеанса пользователя в сервисе и не пытайтесь использовать гипертекст (такой как скрытые элементы управления в Веб-страницах) для управления состоянием. Например, когда пользователь передает запросы, например, для добавления элемента в корзину, сохраняйте данные в постоянном хранилище, таком как база данных.
Аспекты проектирования при использовании SOAP
SOAP – основанный на сообщениях протокол, используемый для реализации слоя обмена сообщениями сервиса. Сообщение представляет собой конверт, в котором содержатся заголовок и тело. Заголовок может использоваться для предоставления сведений, внешних по отношению к операции, осуществляемой сервисом. Например, в заголовок могут быть включены данные безопасности, транзакции или маршрутизации. Тело включает контракты в форме XML-схем, используемые для реализации сервиса. При проектировании SOAPсообщений руководствуйтесь следующими рекомендациями:
Примите решение о том, как будут обрабатываться сбои и ошибки, и как будут возвращаться клиентам соответствующие сведения об ошибке. Более подробно эти вопросы рассматриваются в статье «Exception Handling in Service Oriented Applications» (Обработка исключений в сервисно-ориентированных приложениях)
по адресу http://msdn.microsoft.com/en-us/library/cc304819.aspx.