Содержание


Web-сервисы Java, Часть 1

Web-сервисы Java в предстоящем году

Узнайте об измененных структурах Web-сервисов для разработок Java

Comments

Серия контента:

Этот контент является частью # из серии # статей: Web-сервисы Java, Часть 1

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Web-сервисы Java, Часть 1

Следите за выходом новых статей этой серии.

Наступающий 2006 год станет рекордным годом для Web-сервисов в общем, и Java Web-сервисов в частности. Разработчики получают доступ к новым шаблонам третьего поколения, обеспечивающим гораздо лучшую поддержку doc/lit SOAP и перспективные улучшения рабочих характеристик. В то же время, стандарты WS-* наконец начинают приобретать законченный вид обычного набора интероперабельных слоев, расширяющих SOAP и WSDL и соответствующих основным корпоративным требованиям.

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

Подготовка почвы

Прошло шесть лет после выхода спецификации SOAP 1.0. Задолго до появления спецификации SOAP разработчики обменивались XML-сообщениями посредством протоколов интернет, но введение SOAP обещало формализацию этой техники и обеспечивало лучшую интероперабильность. SOAP также предоставлял возможности для удобного расширения, чтобы можно было добавлять в инфраструктуру функциональные средства более высокого уровня для усовершенствования обмена XML-сообщениями в будущем. Спецификация WSDL, вышедшая вскоре после SOAP, привнесла стандартизированное представление метаданных Web-сервисов. Основные поставщики ПО быстро поняли, каким потенциалом обладает сочетание SOAP и WSDL, и в течение следующих нескольких лет казалось, Web-сервисы на базе SOAP будут технологией будущего.

Сложности, связанные с SOAP и WSDL

Несмотря на быстрое распространение SOAP+WSDL в отрасли, существует ряд проблем, препятствующих достижению SOAP той популярности, которой многие ожидали. Первой такой проблемой является оперативная совместимость. Хотя оперативная совместимость явилась краеугольным камнем привлекательности SOAP, ее реализация не оправдала ожиданий. Изначально это произошло по причине ориентации Web-сервисов на стиль rpc/encoded (известный также как rpc/enc), где объектная модель преобразуется в XML, а затем восстанавливается на принимающей стороне. Это автоматическое двустороннее преобразование делает rpc/enc простым в использовании (до тех пор, пока вы используете относительно простые структуры данных, поддерживаемые им), но результатом имеет XML, не пригодный для других целей. Более того, различия в поддержке языков программирования и платформ приводят к несовместимости программных реализаций.

Сейчас при разработке Web-сервисов хорошим тоном считается отказ от использования стиля rpc/enc в пользу стиля document/literal (doc/lit). В doc/lit, форматы сообщений XML определены схемой W3C XML. Теоретически этот ход должен был снять любые проблемы оперативной совместимости, поскольку схема определяет реальную структуру XML, а тип обработки этого XML оставлен на усмотрение платформ. Практически разные уровни поддержки для чрезвычайно сложной схемы W3C порождают ряд других проблем оперативной совместимости.

Проблемы совместимости как для более раннего rpc/enc, так и для разработанного гораздо позже doc/lit осложняются отсутствием подтверждения приема сообщения. Это особенно актуально для doc/lit, где интегрированная среда поддерживает разные стандарты схем разного содержания без указания отсутствующих элементов. Даже там, где разные среды поддерживают определенные функции схемы, их реализация часто неполная и порождает проблемы оперативной совместимости при их использовании. Частично переход к doc/lit был обусловлен желанием использовать стандартные корпоративные или промышленные схемы. При проектировании таких схем обычно не учитывается их использование в Web-сервисах, поэтому они часто имеют функциональные характеристики, слабо поддерживаемые средами SOAP.

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

Альтернатива SOAP

Кроме описанных в предыдущем разделе проблем с оперативной совместимостью и стандартизацией, ограничивающих практичность Web-сервисов SOAP, сами среды SOAP также зачастую сложно настроить и нелегко использовать. Такая комбинация ограничения преимуществ и значительной сложности побуждает многих разработчиков к поиску более простых альтернатив SOAP. Большая часть "движения сопротивления" SOAP связана с технологией REST. Строго говоря, REST это формализация основных правил протокола HTTP, которые применимы к Web-сервисам. На практике движение REST часто оставляет в стороне формализацию и охватывает все, что позволяет передавать документы XML через HTTP без надстройки SOAP, по существу кооптируя идею о прямом обмене документами XML, которая предшествовала SOAP.

REST гораздо менее претенциозна, чем SOAP. REST в своей основе ограничена использованием HTTP в качестве транспортного слоя (хотя сходные подходы могут использоваться и для других протоколов передачи данных), тогда как SOAP теоретически является транспортно-агностической (хотя ее широкое применение объясняется использованием протокола передачи данных HTTP). REST не имеет прямых способов добавления инфраструктурных расширений - но лишь когда SOAP действительно станет позволять добавление таких расширений, это ограничение можно будет рассматривать как недостаток.

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

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

Но, также, как и в кино, хотя ситуация выглядит действительно безнадежной для SOAP, появляется шанс на спасение, связанный с появлением инфраструктур нового поколения. Эти инфраструктуры позволяют разработку новых возможностей SOAP, делают доступным весь диапазон SOAP приложений Web-сервисов, в то же время значительно улучшая интероперабельность Web-сервисов doc/lit.

Важность Индиго

Хотя данная серия посвящена технологиям Java, первая новая инфраструктура, о которой я расскажу, разработана главным конкурентом Java технологий: Microsoft® .NET. Это новая инфраструктура Windows Communication Foundation (WCF), также известная как Индиго. Изначально Индиго являлся частью версии "Longhorn" для Windows, выпуск которого был запланирован на последние несколько лет. Но Microsoft объявила, что в виде WCF она также будет доступна и для более старых версий Windows. Ожидается, что WCF, как только станет доступна, заменит инфраструктуру .NET.

Важность WCF (Индиго) для всего мира Web-сервисов заключается в том, что Microsoft контролирует подавляющее большинство ПК (это не полный контроль - как и многие другие люди я, например, использую Linux®, да и Macs также популярны - но более 90%). Такая расстановка сил означает, что, когда Microsoft выходит на рынок с новой инфраструктурой, то оказывает подавляющее воздействие на другие компании и их продукты. Технологии, поддерживаемые Microsoft, автоматически поддерживаются другими инфраструктурами, а не поддерживаемые Microsoft могут рассчитывать лишь на второстепенное использование, при условии, что системы Microsoft будут исключены, как со стороны клиента, так и со стороны сервера.

Вместе с WCF, Microsoft добавляет новые технологии к базовой платформе .NET (в настоящее время некоторые из них доступны в виде дополнительных приложений WSE 3.0 к базовой .NET). Эти технологии включают в себя XOP/MTOM, WS-Addressing, WS-Trust, WS-SecureConversation, WS-ReliableMessaging, WS-Coordination, WS-AtomicTransaction и WS-Policy. XOP и MTOM - это новые стандарты, поддерживающие передачу двоичных данных, включенных в сообщение SOAP в качестве приложения, которые должны в конечном счете привести к интероперабельности приложений между всеми основными инфраструктурами SOAP (ранее Microsoft поддерживал только технологию приложений DIME, тогда как большинство инфраструктур поддерживали более раннюю технологию Microsoft, называющуюся SwA). WS-Addressing продоставляет стандартный формат для идентификаторов сообщений, адресов (адресата и адресанта) и действий; часть, связанная с идентификаторами, очень важна, поскольку ее наличие обусловлено требованиями нескольких других технологий, тогда как части, связанные с адресами и действиями, нужны для поддержки альтернативной доставки (отличной от транспортного протокола HTTP)и асинхронных операций. WS-Trust и WS-SecureConversation дополняют более старый (и уже широко использующийся) WS-Security с поддержкой более удобного симметричного шифрования. WS-ReliableMessaging поддерживает доставку сообщений и обеспечение последовательности. WS-Coordination управляет последовательностью операций в распределенной сети Web-сервисов. WS-AtomicTransaction поддерживает транзакции над SOAP с распределенным протоколом двухфазного подтверждения транзакции. Наконец, WS-Policy определяет расширения к WSDL, что позволит сервисам указывать свои требования к использованию всех этих технологий. Эти WCF технологии представляют большинство сервисов поддержки, необходимых для построения корпоративного приложения с Web-сервисами.

Если технологии, входящие в WCF действительно будут широко распространены и интероперабельны, у нас будет отличная причина для построения корпоративных Web-сервисов на базе SOAP. В настоящий момент вероятность того, что это вскоре произойдет, довольно велика. Большая часть основных инфраструктур SOAP были представлены на прошедшем в ноябре 2005 года фестивале WCF Interoperability Plug-fest, спонсором которого стала компания Microsoft, и среди них альтернативы Java, о которых я расскажу в оставшейся части данной статьи. Полученные на начальном этапе результаты тестирования свидетельствуют об ограниченных возможностях, и существуют действительно серьезные препятствия для достижения полной интероперабельности, (включая поддержку конкретных версий находящихся в процессе изменения стандартов WS-*), но направление в данной отрасли определено на поддержку технологии WCF как ядра для инфраструктур SOAP следующего поколения.

Sun и стандарты Java

JAX-RPC 1.0 был исходным стандартом для Web-сервисов на Java. Хотя JAX-RPC проектировался с учетом того, что могут использоваться разные реализации протоколов при фактической реализации Web-сервисов, на практике он использовался лишь для SOAP-сервисов. Было разработано несколько разных версий JAX-RPC, наиболее широко используемой из которых была, пожалуй, инфраструктура Apache Axis, за которой следовала Reference Implementation, включенная как часть Пакета программ разработчика Java Web-сервисов, распространяемого Sun Microsystems.

Ко времени разработки JAX-RPC 1.0 многие считали, что стиль SOAP rpc/enc является самым удобным и полезным для Web-сервисов. Спецификация JAX-RPC 1.0 требовала базовой поддержки, как стиля rpc/enc, так и стиля doc/lit, но не требовала поддержки многих элементов схемы. Это имело неблагоприятный побочный эффект, выразившийся в том, что SOAP doc/lit (который основан на схемах) стал фактически программным средством второго класса.

JAX-RPC 1.0 также ограничивал функциональность Web-сервисов. Как можно предположить из названия, назначением его была поддержка RPC операций (Remote Procedure Call; дистанционный вызов процедур) посредством XML. Уже существовала технология Java для обработки вызовов RPC между Java приложениями - технология RMI (Remote Method Invocation; удаленный вызов метода). Технической группой было принято решение о моделировании JAX-RPC с использованием существующего интерфейса RMI. Эта модель обеспечивает достаточно хорошую совместимость, пока вы работаете с SOAP rpc/enc, используя операции запрос-ответ через HTTP, но не справляется с асинхронными операциями или другими протоколами передачи данных. К концу 2003 года было очевидно, что необходима переработка JAX-RPC для решения этих и других задач, поэтому Sun сформировала экспертную группу для разработки спецификаций JAX-RPC 2.0.

JAX-*

Основной целью создания JAX-RPC 2.0 было обновление стандартов поддержки, реализуемых JAX-RPC 1.X, построенных на таких свойствах Java 5, как комментарии и настраиваемость; улучшение поддержки сообщений (включая асинхронные операции и другие протоколы передачи данных, помимо HTTP), и улучшение схемы поддержки посредством привязки данных JAXB 2.0 вместо простой (но очень ограниченной) встроенной привязки данных JAX-RPC 1.X. Частично для отражения изменений, имя второй версии программного продукта было изменено на JAX-WS 2.0. В настоящий момент доступна рабочая версия JAX-WS 2.0, а выход программного продукта ожидается в первом полугодии 2006 года.

Разработчики JAX-WS 2.0 выполнили все задачи, поставленные ими перед собой при переработке JAX-RPC 1.X, и даже привнесли дополнительные усовершенствования, такие как ограниченная поддержка REST. Некоторые разработчики столкнутся с определенными сложностями при работе с JAX-WS 2.0 из-за большого использования комментариев и других свойств Java 5 (что делает его несовместимыми с более старыми варсиями JVM), но большинство разработчиков оценят достоинства надежности Java 5. Более серьезным недостатком является то, что JAX-WS 2.0 не поддерживает никаких альтернатив комментариям в структуре Web-сервисов, что может снизить гибкость и привлекательность инфраструктуры в долгосрочной перспективе.

И JAX-WS 2.0 и JAXB 2.0 готовились для включения в пост-Java 5 версии спецификации J2SE. Внесение этих компонентов как части в состав стандартной инсталляции JVM вне всякого сомнения увеличит их популярность среди разработчиков, поскольку это исключит необходимость включения этих несколько громоздких инфраструктур в само приложение. Обратной стороной включения их в стандартную JVM (помимо увеличения размера загрузочного файла) могут стать трудности определения версии в случае необходимости выполнения отладочных работ, что мы уже видели на примере таких компонентов, как JAXP.

Переход к интероперабельности

JAX-WS 2.0 напрямую поддерживает XOP/MTOM, но не другие новые технологии WCF. Тем не менее, как часть соглашения Sun об интероперабельности с Microsoft было объявлено о разработке Java-версий с открытым программным кодом остальных технологий, входящих в состав WCF. Эти программные продукты будут разработаны в рамках мегапроекта "GlassFish", включающего в себя все технологии, используемые как часть сервера приложений Sun (в том числе JAX-WS 2.0 и JAXB 2.0 reference implementations).

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

Подход Apache

Проект Apache тесно связан с работой Web-сервисов уже несколько лет, в основном фокусируясь на разработке платформ Java. Выпускаемая Apache в настоящее время платформа для Java SOAP Web-сервисов - это инфраструктуры Axis третьего поколения. Axis широко используется как разработчиками, которые загружают и используют его напрямую, так и будучи встроенным в качестве движка SOAP для нескольких различных серверов приложений. Axis считается наиболее широко используемой платформой для Java SOAP Web-сервисов.

Axis, тем не менее, имеет ряд недостатков. Во-первых, он спроектирован на основе стандарта JAX-RPC 1.0, который значительно ограничил возможности архитектуры и функциональной гибкости Axis. Это ограничение гибкости стало серьезной проблемой, поскольку нужны были расширения для построения новых технологий вокруг рабочего ядра SOAP. В то же время переход SOAP-сервисов к стилю doc/lit вызвал необходимость разработки лучшей схемы поддержки, чем применяемая с Axis. К середине 2004 года команда разработчиков Axis согласилась, что необходимо осуществить переработку Axis, используя опыт, полученный при создании Axis, чтобы новый продукт был гораздо более функционально гибким.

Решение проблемы с помощью Axis2

Axis2 - потомок Axis. Он спроектирован как облегченный сервер обработки SOAP (хотя, как и JAX-WS 2.0, Axis2 также включает в себя некоторую поддержку REST), расширяемый несколькими способами. В отличие от оригинального Axis, Axis2 сознательно не ограничен реализацией какого-либо определенного API (хотя некоторые уровни поддержки JAX-WS 2.0 проектировались с оболочкой для кода ядра Axis2). Axis2 находится в стадии разработки уже более года и вскоре приобретет статус программного продукта.

Одной из наиболее удобных характеристик Axis2 является объектная модель AXIOM, используемая для SOAP сообщений. Объектные модели XML существуют так же долго, как и сам XML, беря начало от древнего стандарта DOM от W3C. Отличие AXIOM от других объектных моделей XML заключается в том, что ее гибкость обеспечивается новыми формами парсеров XML, что позволяет выполнять построение объектной модели по требованию. Это значит, что вы платите за построение объектной модели только для тех фрагментов XML документа, доступ к которым возможен лишь через объектную модель.

Другой характерной чертой Axis2 является поддержка сменной привязки данных. Это свойство позволяет вам выбирать простейший способ работы с информационным наполнением XML ваших документов SOAP, настраивая сгенерированный код для использования выбранного подхода. Возможными вариантами является использование AXIOM напрямую; использование простого способа привязки данных, сходного с оригинальным Axis; или использование специальной схемы привязки данных, такой как XMLBeans, JiBX или JAXB 2.0.

Расширение Axis2

Хотя Axis2 все еще активно разрабатывается, имеется уже ряд проектов, реализующих технологии расширения SOAP поверх Axis2. Эти проекты включают в себя все главные технологии, поддерживаемые WCF, а также немногие расширения, которые Microsoft планирует включить в добавляемые для расширения (другими словами, поставляемые за отдельную плату) приложения. Архитектура Axis2 упрощает разработку таких приложений, используя компонент, называемый модуль.

Модули адресации WS-Addressing и безопасности WS-Security в настоящий момент включены в базовый дистрибутив Axis2 (в будущем они могут стать отдельными загружаемыми файлами или даже отдельными проектами, поскольку между этими модулями и кодом ядра Axis2 нет тесной связи). В рамках проекта Sandesha разрабатывается модуль поддержки WS-ReliableMessaging, а модули WS-Trust и WS-SecureConversation - в рамках проекта WSS4J (который уже обеспечивает реализацию WS-Security). WS-AtomicTransaction и WS-Coordination разрабатываются в проекте Kandula.

Низшие лиги

Кроме разработок компаний с громкими именами, такими как Sun и Apache, в сфере технологий с открытым программным кодом также существуют различные инновационные проекты Web-сервисов. Одним из них является мой собственный JibxSoap проект, движок SOAP и REST, построенная на моей инфраструктуре привязки XML данных JiBX. Главным достоинством JibxSoap является ее скорость - в ранних тестах она практически сравнялась с Java RMI при использовании стандартных сообщений SOAP. XFire -другой движок SOAP, позволяющая выбирать инфраструктуру привязки данных; XFire также показывает превосходные рабочие характеристики. Как JibxSoap, так и XFire, возможно, приобретут статус программного продукта в следующем году.

Учитывая темпы развития технологий с открытым программный кодом, я не удивился бы, увидев какие-то новые инфраструктуры Java, разработанные к 2006. Даже если бы они не достигли популярности продукции Sun и Apache, они все-таки могли бы оказать большое влияние на решение рассмотренных проблем, предложив, быть может, более простой или эффективный выход.

Взгляд в будущее

Теперь, когда в этой статье был дан обзор состояния Java Web-сервисов в 2006 году, я планирую посвятить следующие публикации более подробному рассмотрению инфраструктур Java с открытым программным кодом. В следующем месяце мы погрузимся в Axis2, обсудим его архитектуру и лежащую в его основании объектную модель AXIOM. Я также рассмотрю приложение поддержки XOP/MTOM, входящее в состав AXIOM, а также то, как к нему осуществляется доступ инфраструктур привязки данных. В следующих статьях будут рассмотрены альтернативы и рабочие характеристики системы Axis2 привязки данных, а также других инфраструктур Web-сервисов Java. Не пропустите новый выпуск в данной серии, чтобы быть в курсе последних событий.


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=SOA и web-сервисы, Технология Java
ArticleID=209995
ArticleTitle=Web-сервисы Java, Часть 1: Web-сервисы Java в предстоящем году
publish-date=04172007