Разработка веб-служб средствами Java. Ильдар ХабибуллинРазработкаWebслужбсредствами
 Скачать 9.24 Mb.
|
|
Элемент определенные в устаревшей версии спецификации "XML Encryption" с идентификатором пространства имен http://www.w3.org/2000/10/xmlenc. По- этому этот элемент вряд ли будет использоваться в современных посланиях. Элемент Он не изменился со времени создания расширения "SOAP Extensions" и вполне может приме- няться в SOAP-посланиях. У третьего элемента нет четкой структуры, в него можно вложить произвольные элементы, идентифицирующие автора послания. Второе расширение протокола SOAP, сделанное фирмами IBM и Microsoft в феврале 2001 года, созданию цифровой подписи. Оно называ- ется "SOAP Security Extensions: Digital Signature" и доступно адре-су Расширение уточняет элемент Extensions". Уточненный элемент тоже содержит вложенный элемент Кроме того, расширение "SOAP Security Extensions: Digital Signature" задает Правила включения Глава 8. Безопасность предоставления услуг 359 послания, и правила обработки промежуточными серверами и Web- службами. Наконец, в июле 2002 года появилось новое расширение протокола SOAP — спецификация "WS-Security", разработанная фирмами IBM, Microsoft и VeriSign. Остановимся на ней подробнее. Спецификация Спецификация "Web Services сокращенно "WS-Security", доступна по адресу Несмотря на свое название, она не вносит какие-то новые правила шифрования или аутентификации. Она определяет всего один элемент Сразу же после выхода спецификации "WS-Security", в августе 2002 года, поя- вилось приложение к ней, названное "WS-Security Addendum". Его можно посмотреть по адресу http://msdn.microsoft.com/webservices/. Оно изменило идентификатор пространства имен, теперь это http://schemas.xmlsoap.org/ ws/2002/07/secext. В приложении исправлены мелкие ошибки и сделаны не- которые дополнения к спецификации "WS-Security". У элемента signature>, определенные в спецификации Encryption" и в рекомендации RFC 3275. Спецификация определяет и неко- торые дополнительные элементы, которые можно вложить в элемент Для аутентификации пользователя по его имени и паролю спецификация определяет С и Необязательный атрибут туре элемента указывает тип записи пароля. Пока он принимает всего два значения: значение по умолчанию — пароль записывается открытым текстом, и значение "PasswordDigest" — записывается дайджест пароля в кодировке Base64. Дайджест создается по алгоритму SHA-1. Приложение к спецификации добавило два необязательных вложенных элемента, применяемых при создании дайджеста пароля: элемент содержит одноразовый 16-байтовый пароль, включаемый в дайджест, эле- 360 Разработка Web-служб средствами Java мент "http://schemas.xmlsoap.org/ws/2002/07/utility"> Глава 8. Безопасность предоставления услуг 361 Для хранения двоичной информации, скажем, сертификата, спецификация "WS-Security" определяет элемент Вот, например, сертификат, полученный по протоколу Х.509, и записанный в кодировке Base64: Id="cert" EncodingType="wsse:Base64Binary"> Спецификация, точнее, приложение к ней, рекомендует хранить сертифика- ты именно в элементе Защищаемые элементы могут располагаться не только внутри элемента Интернета. В таком случае в элемент В КОТОРЫЙ ВКЛа- дываются элементы Ссылки даются в виде строки URI в атрибуте Например: /> 362 Разработка Web-служб средствами Java Элемент обычно вкладываемый в элемент при создании цифровой Элемент разрешается вкладывать не в элемент но и в элементы цифровой Сам элемент рекомендуется вкладывать непосредственно в В элемент При обмене SOAP-посланиями часто имеет значение дата и время отправки послания и его обработки, а также срок действия послания. Приложение "WS-Security Addendum" определяет блок заголовка Этот эле- мент определен в другом пространстве имен с идентификатором В элемент с датой и временем создания, сроком действия и временем об- работки SOAP-послания промежуточным сервером. Дата и время относятся к типу языка XSD. Их рекомендуется отсчитывать по правилам UTC, в противном случае следует использовать атрибут в кото- ром надо записать тип, описанный в схеме XML. Например: 2002-ll-13T08:44:00Z Глава 8. Безопасность предоставления услуг 363 Что дальше? Как видно из предыдущего раздела, спецификация "WS-Security" определяет только самые общие правила составления блоков заголовка SOAP-послания, обеспечивающих безопасность SOAP-послания. Конкретные правила долж- ны быть определены в расширениях этой спецификации. Корпорации IBM и Microsoft работают над дальнейшим развитием и детализацией правил обеспечения безопасности Web-служб. В настоящее время разрабатываются следующие спецификации, расширяющие спецификацию "WS-Security": • Спецификация описывает методы проведения той или иной политики безопасности. Она определяет ограничения доступа, форматы кодирования, используемые алгоритмы шифрования, форматы файлов политики. Спецификация расширяема и может быть дополнена новыми элементами. • Спецификация "WS-Trust" описывает методы установления доверитель- ных отношений между Web-службами, их клиентами и посредниками. Спецификация "WS-Privacy", совместно со спецификациями "WS- Security", "WS-Policy" и "WS-Trust", определяет правила сохранения ком- мерческой тайны предприятия или учреждения при обмене SOAP- посланиями. В дальнейшем IBM и Microsoft планируют выпустить следующий слой спе- цификаций, основанных уже на спецификациях "WS-Policy", "WS-Trust" и "WS-Privacy". Новые спецификации призваны конкретизировать и расши- рить требования предыдущих спецификаций. • Спецификация "WS-Secure Conversation" будет описывать правила обме- на конфиденциальной информацией, аутентификации сообщений, соз- дания ключей и обмена ими. • Спецификация будет рассматривать доверительные от- ношения в разнородных средах и в распределенных приложениях. • Спецификация "WS-Authorization" создаст стандарт для авторизации клиентов и сообщений. Все эти спецификации основаны на известных правилах и алгоритмах шиф- рования, аутентификации, авторизации. Они просто вводят стандарты при- менения этих правил в Web-службах. Работа только началась, нас ждет еще множество решений проблем безопасности Web-служб. ГЛАВА 9 Развитие Web Services Раз вы дочитали книгу до этого места, значит, поняли, что технология Web Services только начинает развиваться. Плодотворная идея предста- вить информацию в виде документов XML и пересылать ее по Интерне- ту, используя только протокол HTTP, находит множество воплощений. Десятки фирм и рабочих групп активно развивают эту технологию. Бук- вально каждую неделю появляются новые программные продукты и но- вые версии старых продуктов. То и дело обновляются протоколы и спе- цификации Web Services и возникают новые спецификации. Расширяется сфера применения Web Services, все больше фирм создают у себя Web- службы. В этой главе я постараюсь дать обзор новейших тенденций развития техно- логии Web Services. Посмотрим сначала, как развиваются "три кита", на ко- торых стоят Web-службы — протоколы SOAP, WSDL и UDDI. Протокол SOAP Близится к завершению работа над версией 1.2 протокола SOAP. Сейчас, когда вы читаете эти строки, уже должна выйти ее окончательная редакция. Описание протокола, сделанное в главе 3, основано на черновой редакции SOAP 1.2, опубликованной в июне 2002 года. Не думаю, что эта редакция будет сильно изменена, поскольку всякие дополнения к протоколу сейчас оформляются в виде отдельных документов — расширений (extensions) про- токола SOAP. В версию SOAP 1.2 внесено много мелких изменений: исключен атрибут из корневого элемента атрибут actor заменен Глава 9. Развитие Web Services 365 атрибутом role, значения атрибута записываются словами "true" и "false". Введены новые элементы и атрибуты, исключен HTTP- заголовок SOAPAction, определен НОВЫЙ MIME-ТИП изменено содержимое элемента Все это подробно изложено в главе 3. Пока не выпущена окончательная редакция SOAP 1.2, производители про- граммных продуктов, реализующих протокол SOAP, вынуждены основы- вать их на версии SOAP 1.1. Впрочем, уже в первой версии Apache Axis реализовано большинство конструкций SOAP 1.2. Как только версия 1.2 будет утверждена, производители сразу же воплотят ее в новых версиях своих продуктов. Протокол SOAP, по-видимому, будет в дальнейшем заменен общим про- токолом пересылки любых документов XML, названным "XMLP" (XML Protocol). Но разработка этого протокола сильно затянулась, она еще не вышла из начальной стадии. Вероятнее всего, Web-службы еще некоторое время будут действовать в рамках протокола SOAP 1.2. Его текущее со- стояние и процесс разработки можно посмотреть на сайте http://www.w3.org/TR/xp/. Описание на языке WSDL Во время написания книги действовала версия 1.1 языка описания Web- служб но в июле 2002 года был опубликован черновой вариант вер- сии 1.2. Он доступен по адресу Основные цели новой версии — привести язык WSDL в соответствие с тре- бованиями схемы XML и описать связь языка с версией SOAP 1.2. Кроме этого, в новую версию введены некоторые новые атрибуты, устаревшие ат- рибуты сделаны необязательными, уточнены многие правила описания Web-служб. Описание языка WSDL, сделанное в главе 4, основано на вер- сии WSDL 1.2. Несмотря на появление версии WSDL 1.2, ее внедрение произойдет еще не скоро. С одной стороны, судя по скорости разработки спецификации, ее окончательная редакция в ближайшее время не выйдет. С другой стороны, выпущено уже очень много программных средств, автоматически генери- рующих WSDL-описания Web-служб и создающих клиентские приложения по этим описаниям. Все эти средства основаны на WSDL 1.1. Будет нелегко в кратчайший срок перевести их на новую версию. Текущее состояние языка WSDL непрерывно отражается на сайте http://www.w3.org/ws/desc/. Разработка Web-служб средствами Java Реестр UDDI Реестры UDDI пока создаются и развиваются, основываясь на специфика- ции UDDI 2.0, изложенной в нескольких документах. В июле 2002 года вышла версия 3.0 спецификации UDDI. Она записана в одном документе "UDDI Version 3.0 Published Specification", доступном адресу По новой спецификации можно зарегистрировать данные сразу в несколь- ких реестрах, для чего введено понятие присоединенных (affiliate) реестров и изменен формат записи ключей. Усилена безопасность хранящихся в рее- стре сведений. В частности, реестры теперь могут хранить сведения, подпи- санные цифровой подписью. Новая спецификация позволяет реестру опре- делить политику обработки хранящихся в нем сведений. Для этого введен элемент Реестр теперь обеспечивает интернационализа- цию хранящихся в нем сведений. Спецификация UDDI 3.0 вносит и другие изменения в структуру сведе- ний, хранящихся в реестре, например, введены дополнительные правила поиска и сортировки с помощью шаблонов. Обеспечена согласованность документов UDDI с описанием Web-службы, сделанном на языке WSDL. Значительно расширен интерфейс UDDI API, в внесено много новых функций. Эти изменения приведены в главе 5, описывающей версию UDDI 3.0. Полное внедрение версии UDDI 3.0 связано с большими трудностями — надо привести в соответствие с ней огромное количество информации, уже хранящейся в реестрах UDDI. Поскольку версия 3.0 только расширяет вер- сию 2.0, почти ничего в ней не меняя, владельцы реестров и поставщики программного обеспечения идут проверенным путем. Они выпускают и внедряют продукты, совместимые со старыми версиями UDDI. Текущее состояние дел по разработке спецификации UDDI всегда можно посмотреть на сайте Фирменные разработки Правила создания и функционирования Web-служб описываются не только протоколом SOAP, языком WSDL и реестром UDDI. Определение Web Services, приведенное в главе 2, вообще ничего не говорит об этих "трех ки- тах". Оно даже не упоминает протокол HTTP. По этому определению для Web-служб характерно только использование документов XML и технологии WWW. Многие фирмы создают свои протоколы и спецификации Web- служб, основанные лишь на XML и WWW. В предыдущих главах уже упо- минались протоколы и спецификации XML-RPC, DIME, WS-Routing, WS- Глава 9. Развитие Web Services 367 Inspection, WS-Security. Большинство нововведений принадлежит фирмам IBM и Microsoft и сообществу OASIS. Познакомимся подробнее с их дея- тельностью. Наибольшую активность в развитии Web Services, пожалуй, проявляет фир- ма IBM. Она разработала и активно внедряет несколько новых специфика- ций, ориентированных, главным образом, на организацию деловых связей и получения из них единого бизнес-процесса. Язык описания потоков работ WSFL Язык описания потоков работ WSFL (Web Services Flow Language) создан фирмой IBM с двумя целями: описать последовательность обработки ин- формации несколькими Web-службами, образующую бизнес-процесс (flow model), и описать взаимодействие Web-служб в этом процессе (global model). Для этого устанавливаются связи между SEI-интерфейсами взаимо- действующих Web-служб. При этом активно используется WSDL-описание этих Web-служб. Спецификация WSFL опубликована в документе http://www-4.ibm.com/ Описание WSFL выполняется в виде документа XML с корневым элемен- том в который вкладывается любое число необязательных элементов описывающих поток информации, и элементов описывающих взаимные связи Web-служб. Кроме того, в корневой элемент можно вложить необязательные элементы Бизнес-поток описывается элементами, вложенными в элемент Начало потока указывается элементом конец потока — эле- ментом Элементы вовлеченные в поток, а элементы Взаимодействие Web-служб описывается элементами, вложенными в эле- мент Сами Web-службы описываются элементами В листинге 9.1 приведена схема вложенности элементов языка WSFL. 368 Разработка Web-служб средствами Java Листинг Вложенность элементов языка WSFL namespace="" location="" /> [*] /> [*] location="" /> [*] serviceProviderType=""> [*] name=""> [?] Глава 9. Развитие Web Services 369 [?] operation="" /> [?] /> [?] /> serviceproviderType=""> serviceProviderType=""> . 748 370 Разработка Web-служб средствами Java serviceProvider="" portType="" /> Как видно даже из такого краткого описания, язык WSFL позволяет опи- сать во всех подробностях последовательную обработку SOAP-посланий не- сколькими Web-службами. Корпорация Microsoft создала свой язык описания бизнес-процессов, непохожий на язык WSFL. Он называется XLANG и разработан для сер- вера BizTalk. С языком XLANG можно ознакомиться на сайте |