Спецификации и стандарты Web-сервисов

Архитектура SOA (Service-Oriented Architecture) продолжает набирать силу как новая модель организации взаимодействия разнообразных корпоративных приложений. Однако наводняющие с каждым днем рынок новые SOA-разработки с учетом недостатка информации о них и строгих стандартов вводят ИТ-специалистов в состояние растерянности.

Не имеет значения, разрабатываете ли вы ПО для конкретного предприятия с использованием SOA или собираетесь приобрести пакет программ на базе этой архитектуры, в любом случае вам необходимо разобраться со стандартами для среды Web-сервисов. Вам придется усвоить немало новой информации: од-ни стандарты являются на сегодняшний день краеугольным камнем данной архитектуры — например, WSDL (Web Services Definition Language), SOAP (Simple Object Access Protocol) или WSS (Web Services Security), другие же, как, скажем, WS-Routing, постепенно устаревают и заменяются новыми.

Кузницы стандартов

В сфере разработки и принятия стандартов и спецификаций для Web-сервисов сегодня можно выделить три основные организации: WS-I (Web Services Interoperability Organization), W3C (World Wide Web Consortium) и OASIS (Organization for the Advancement of Structured Information Standards). Основную работу в них выполняют технические комитеты, членами которых являются представители от производителей продуктов на базе Web-сервисов и отраслевые эксперты.

С точки зрения влияния на отрасль вышеназванные организации играют такую же роль, как рабочая группа IETF в выработке стандартов для сети Интернет. Поэтому согласие производителей со стандартами и спецификациями, разработанными этими организациями, формально не обязательно, хотя и всячески поощряется. Даже жестко конкурирующие производители, такие, как Microsoft, IBM, Sun Microsystems и BEA Systems, согласны с важностью соблюдения стандартов на Web-сервисы.

Организация WS-I специализируется на вопросах взаимодействия между конкретными программными реализациями Web-сервисов. Больше всего она известна благодаря своей спецификации WS-I Basic Profile (в настоящее время актуальна версия 1.1), представляющей собой, по сути дела, описание взаимоотношений трех базовых стандартов Web-сервисов: WSDL, UDDI (Universal Description, Discovery and Integration) и SOAP.

WS-I разработала также спецификацию WS-I Basic Security Profile, которая подобна WS-I Basic Profile, но уже дает детальное описание механизмов взаимодействия продуктов, применяющих стандарт WSS, разработанный организацией OASIS.

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

Консорциум W3C является разработчиком основных стандартов для Web-сервисов WSDL, UDDI и SOAP. Он также отвечает за некоторые XML-спецификации, используемые для внедрения стандартов OASIS. В их числе — спецификация шифрования XML Encryption, электронной подписи XML Signature и вспомогательные стандарты, в частности XSL (Extensible Stylesheet Language), XSLT (XSL Transformations), XPath и XQuery.

Тем временем большинство стандартов Web-сервисов, относящихся к специфическим бизнес- или ИТ-функциям, находятся в ведении технических комитетов организации OASIS. Последняя наиболее продуктивная и влиятельная из трех перечисленных, работающих над стандартами для Web-сервисов. Разработанные ею спецификации дали рост целым направлениям разработок, та-ким, как WSS-продукты. OASIS является родоначальником большого числа так называемых WS-стандартов, включая WSS, WS-Addressing и WS-Reliability. Они затрагивают самые разные ИТ-области: от поддержки транзакций до администрирования. На базе же таких стандартов, как WS-Policy, в свою очередь, реализованы разнообразные подмножества стандартов — например, WS-SecurityPolicy и др.

Спецификации OASIS разрабатываются в основном как объектно-ориентированные, поэтому благодаря принципу наследования они легко расширяются. При этом элементы, определенные в дочерних спецификациях, могут иметь свои особенности вне зависимости от их назначения в родительских объектах (вспомните полиморфизм). Кроме того, WS-спецификации предоставляют возможность использования таких общих объектов, как ссылка на место назначения, которая несет в себе информацию о конечной точке доставки, включая ее адрес. Это очень похоже на идентификатор URI (Uniform Resource Identifier), который обязательно содержит в себе информацию об используемом протоколе для соединения с конечной точкой (например, префикс mailto:, http: или ftp:). Этот ссылочный элемент в дальнейшем используется для описания терминальных точек и клиентов в разнообразных спецификациях — в частно-сти, в WS-Addressing или WS-Policy, а также в спецификациях для производных предметных областей, таких, как уже упоминавшаяся ранее WS-SecurityPolicy.

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

Кто важнее

Итак, на каких стандартах и спецификациях вам необходимо сконцентрировать свое внимание в ближайшем будущем? На следующий год вам нужно будет ознакомиться с тремя базовыми стандартами и добавить их к списку характеристик, обязательных для продуктов на базе Web-сервисов. Это WSS, WS-Policy и WS-Addressing.

Стандарт WSS сегодня уже утвержден организацией OASIS, в то время как WS-Policy и WS-Addressing — еще нет, хотя широко используются во множестве комплексных продуктов Web-сервисов и, как ожидается, уже в ближайшее время оба получат статус стандарта.

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

Стандарт WSS, если он правильно внедрен поставщиком услуг обеспечения безопасности, таким, как Data Power, Forum Systems или Reactivity, может облегчить администрирование и значительно повысить производительность напряженных для процессора операций шифрования и дешифрования. Но WSS-сервис можно разместить и на большинстве серверов приложений, используемых предприятиями, включая WebLogic, WebSphere и OracleAS. Независимо от того, где вы применяете меры по обеспечению безопасности Web-сервисов, они должны быть совместимы с WSS.

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

Кроме того, WS-Policy определяет и способ взаимодействия с системой сообщений SOAP. В спецификации OASIS WS-SecurityPolicy, например, описывается, как политика безопасности может применяться к описанию WSDL — в частности, в отношении типов портов, сообщений (входящее, исходящее, об ошибке), соединений и т. д. Спецификация WS-Addressing, в свою очередь, определяет механизм для прикрепления элемента WS-Policy к определенным типам адресов, например, для конечных точек назначения.

В спецификации WS-Policy используются так называемые “утверждения” (assertion) для выдачи инструкций механизму реализации правил системной политики в конкретной предметной области (безопасность, обеспечение секретности и контроль трафика). Так, специальное утверждение в области безопасности может содержать в себе требование, чтобы кредитная карта или номер социального страхования, применяемые при аутентификации пользователя, передавались в шифрованном виде. Спецификация WS-Policy важна для вашей стратегии развития Web-сервисов, потому что она будет использоваться множеством других стандартов и спецификаций для указания того, как определенные правила системной политики должны применяться по отношению к потокам данных во всей вашей сети.

WS-Addressing заменила собой спецификацию WS-Routing. WS-Addressing включает в себя механизм для идентификации сообщений (MessageID), определения получателя (To) и объекта, которому должен быть послан ответ (ReplyTo). Этот механизм встроен в заголовок SOAP и удлиняет входящие, исходящие сообщения и сообщения об ошибках внутри элемента, определяющего тип порта WSDL с помощью атрибута Action. Терминология и использование указанной спецификации сходны с SMTP, поскольку сообщение может проходить через несколько промежуточных пунктов до того, как прийти в точку назначения.

Спецификация WS-Addressing может показаться несколько надуманной: в конце концов, большинство сообщений SOAP и так посылаются по протоколу HTTP, отправитель и получатель известны, а само действие SOAP передается в заголовке HTTP. Но она важна, потому что снимает с SOAP зависимость от транспортного уровня. Если, например, пунктом назначения является JMS (Java Messaging Service), то идентификатор URI не может использовать заголовки HTTP для того, чтобы определить, какую операцию нужно выполнить, и обозначить конечную точку, в которую необходимо в случае, когда это надо, переслать результат. Мне могут возразить, что для этой цели можно использовать заголовки JMS! Конечно можно, но это разрушает основное предположение о том, что архитектура SOAP самодостаточна и не зависит от конкретного транспорта или службы обмена сообщениями.

WS-Addressing устраняет всякую зависимость от транспортных заголовков или передачи специфических параметров при получении доступа к Web-сервисам. Это особенно важно при использовании архитектуры SOA, где не требуется, чтобы сервисы передавались по HTTP, хотя большинство разработок на сегодняшний момент основаны на этом повсеместно используемом протоколе..