Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Спецификации и стандарты 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, хотя большинство разработок на сегодняшний момент основаны на этом повсеместно используемом протоколе..





  
10 '2006
СОДЕРЖАНИЕ

инфраструктура

• Коммутаторы для центров обработки данных

• Организация подходящей сетевой инфраструктуры для RFID

• Тестируем корпоративные продукты wiki

• Лучшие экспонаты выставки Interop Las Vegas 2006

• NAS для масс

информационные системы

• Дорожная карта Unix

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

• ESB как становой хребет SOA

сети связи

• IMS для корпоративных пользователей

кабельные системы

• Многомодовое «меню»

• Заземление в центрах обработки данных

• Аутентификация отправителей e-mail и борьба со спамом

защита данных

• Азы протокола WPA2

• Настройка групповой политики в Active Directory

новые продукты

• Новые мощные серверы компании R-Style Computers


• Калейдоскоп



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх