Важность Индиго
Хотя данная серия посвящена технологиям 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.