Рис. 10

Типовое приложение со слоем сервисов

Слой сервисов обычно включает следующие компоненты:

Интерфейсы сервисов. Сервисы предоставляют интерфейсы, в которые передаются все входящие сообщения. Интерфейс сервиса можно рассматривать как фасад, предоставляющий потенциальным потребителям доступ к бизнес-логике, реализованной в приложении (как правило, логику бизнес-слоя).

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

Более подробно компоненты, обычно используемые в слое сервисов, рассматриваются в главе 10, «Рекомендации по проектированию компонентов». О проектировании интерфейсов сервисов рассказывает глава 18, «Взаимодействие и обмен сообщениями».

Общие принципы проектирования

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

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

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

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

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

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

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

Создавайте сущности из стандартных элементов. По возможности компонуйте сложные типы и объекты передачи данных, используемые сервисом, из стандартных элементов.

При проектировании учитывайте возможность поступления некорректных запросов. Никогда нельзя делать предположение о том, что все поступающие в сервис сообщения будут корректными. Реализуйте логику валидации всех входных данных на основании значений, диапазонов и типов данных, и отклоняйте недопустимые данные. Более подробно валидация рассматривается в главе 17, «Сквозная функциональность».

Обеспечьте в сервисе функциональность для выявления и обработки повторяющихся сообщений (идемпотентность). Реализация широко известных шаблонов, таких как Receiver и Replay Protection, при проектировании сервиса обеспечит, что дублирующие сообщения не будут обрабатываться, или что повторная обработка не будет влиять на результат.

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

Специальные вопросы проектирования

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

Аутентификация

Авторизация

Сетевое взаимодействие

Управление исключениями

Каналы обмена сообщениями

Структура сообщения

Конечная точка сообщения

Безопасность сообщений

Маршрутизация сообщений

Преобразование сообщений

Интерфейс сервиса

Валидация

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

Аутентификация

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

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

Учтите последствия применения разных настроек уровней доверия для выполнения кода сервиса.

Для обычной аутентификации или при передаче учетных данных в открытом виде используйте такие безопасные протоколы, как Secure Sockets Layer (SSL). Для SOAPсообщений применяйте механизмы безопасности уровня сообщения,

поддерживаемые стандартами WS* (Web Services Security, Web Services Trust и Web Services Secure Conversation).

Авторизация

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

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

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