Политики для Web-сервисов

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

Энн Андерсон

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

Имеются разные спецификации, дополняющие базовую архитектуру Web-сервисов средствами защиты, надежного обмена сообщениями и выполнения транзакций. В будущем, вероятно, появятся спецификации для обеспечения секретности, авторизации, управления сеансами и т.д. Трудность состоит в том, что эти спецификации должны иметь множество опций, чтобы справляться с требованиями самых разных приложений. Как потенциальный клиент может узнать, какие опции необходимы для конкретного Web-сервиса или поддерживаются им? Как указать сервису, какие опции нужно поддерживать?

Функциональные уровни

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

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

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

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

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

• уровень привязки к интерфейсу связывает политику с интерфейсом сервиса;
• уровень привязки к домену связывает политику с предметной областью или «доменом» (таким, как аутентификация или надежный обмен сообщениями);
• уровень политики определяет наборы допустимых опций;
• уровень формулировок, или предикатов, определяет отдельные опции политики;
• уровень словарей определяет переменные и значения в опциях политики.

На рисунке эти уровни показаны на примере политики аутентификации, которая гласит: «Используйте либо сертификат X.509 с длиной ключа не менее 1024 бит, либо билет TGT (ticket-granting ticket) протокола Kerberos». Разные цвета текста на рисунке обозначают части политики, относящиеся к различным функциональным уровням.

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

Уровень привязки к интерфейсу (фиолетовый) связывает описание интерфейса Web-сервиса с политикой — в данном случае с помощью идентификатора политики. Он также может связать политику с группой интерфейсов. В этом случае важно знать, дополняет ли групповая политика индивидуальные политики, относящиеся к отдельным интерфейсам в группе, или их отменяет.

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

Уровень политики (черный) — это собственно политика. В языках описания политик, предлагаемых для Web-сервисов, уровень политики предоставляет пакет политик вместе с логическими операторами типа AND и XOR. Он дает возможность разработчикам политики комбинировать опции политик, указанные на следующем уровне.

Уровень формулировок (зеленый) состоит из предикатов, называемых формулировками, которые определяют конкретные опции политики. Этот уровень устанавливает ограничения на переменные и значения, указанные на следующем уровне — в словаре.

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

Используются два подхода к построению формулировок. Например, чтобы сформулировать требование «для аутентификации следует использовать сертификаты X.509 с минимальной длиной ключа 1024 бит», разработчик политики может создать новую структуру XML. В качестве альтернативы допустимо применять язык функций ограничения общего вида. Подобные функции есть, например, в языках XACML (Extensible Access Control Markup Language) [1], XQuery и XPath [2]. При этом подходе мы можем выразить то же самое требование с помощью двух функций ограничения:

Технические комитеты в группах стандартизации, таких как OASIS (Organization for the Advancement of Structured Information Standards) и Консорциум W3C (World Wide Web Consortium), уже определили словари политик для некоторых доменов общего характера. Отраслевые группы, вероятно, дополнят их словарями для собственных отраслевых доменов. Если политики не используют функции ограничения, разработчик словаря должен также определить новые структуры XML, чтобы связать элементы словаря со значениями (как в первом примере), а также определить, как программное обеспечение политики должно интерпретировать эти структуры.

31.10.2006г