Следующее поколение Сети будет использовать программно-ориентированные сервисы для непосредственного взаимодействия с приложениями, построенными на основе любой комбинации объектов, программ и баз данных.

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

Веб-сервисы предоставляют новые варианты взаимодействия. Представим, например, что вы живете в Сан-Франциско и желаете зарезервировать столик в любимом парижском ресторане, а затем составить план путешествия, позволяющий оказаться там в необходимое время. В настоящее время для осуществления заказа необходимо непосредственно позвонить в ресторан, учитывая 9-часовую разницу во времени и различия в языке, а затем связаться с агентом бюро путешествий и подобрать подходящий рейс и гостиницу. Однако, используя веб-сервисы, можно спланировать обед с помощью календаря карманного компьютера (Personal Digital Assistant, PDA), а для автоматического резервирования столика на определенное время просто щелкнуть на кнопке. После выполнения резервирования веб-сервис запустит другие сервисы, которые забронируют наиболее дешевые авиабилеты и закажут номер в самом ближайшем четырехзвездочном отеле.

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

Рис. 1.2. Приложения могут использовать веб-сервисы для резервирования места в ресторане
и бронирования авиабилетов и номеров в гостиницах

Веб-сервисы способны находить другие сервисы и взаимодействовать с ними. Веб-сервисы также полезны при поиске и осуществлении взаимодействия с сайтами, являющимися интерактивными системами заказов, например с системой продаж модных коньковых ботинок с выдвигающимися лезвиями - такими, которые использовали Бэтмен и Робин в фильме Batman and Robin.

Розничные продавцы спортивных товаров, заинтересованные в создании запасов таких ботинок, могут использовать веб-сервисы для размещения предварительных заказов, для проверки состояния выполнения заказа или размещения заказов сезонного возобновления запасов. Они также получат немедленный ответ при отсутствии коньков на складе. "Строительные" блоки веб-сервиса предоставляют стандартные компоненты конкретного приложения для компании Skateboots Company, которая не настолько велика, чтобы содержать свою собственную инфраструктуру приложений. Компания-владелец веб-сервиса также обеспечивает безопасность, гарантируя получение заказов компанией Skateboots Company только от уполномоченных оптовых покупателей, и предлагает сервисы проверки полномочий для крупных предварительных заказов. Другие компании помогут Skateboots Company создать электронный каталог и выполнить расчеты.

Целиком реализованная как веб-сервис система ввода заказов компании Skateboots зависит от Интернета, но необходимая функциональность обеспечивается за счет совместной работы ряда других веб-сервисов. На рис. 1.3 продемонстрировано, как веб-сервисы могут изменить способ построения и использования коммерческого приложения. Заинтересованный в закупке коньков оптовый покупатель вводит запрос с помощью собственной локальной системы управления складскими запасами, доступной компьютерам магазинов как веб-сервис. Локальная система управления складскими запасами контактирует через Интернет с веб-сервисом производителя и посылает ему заказ на определенное число коньков, основываясь на объеме имеющихся складских помещений и учитывая наиболее ходовые размеры ботинок.

Рис. 1.3. Служба ввода заказов Skateboots Company содержит
несколько других веб-сервисов

Система ввода заказов компании Skateboots Company состоит из нескольких сервисов, включая специальную часть, которая отвечает уникальным аспектам ее продукции, и несколько торговых компонентов, выполняющих стандартные функции, например проверку полномочий пользователя, проверку кредитоспособности и отслеживание счета. Все эти сервисы предоставляются другими компаниями, специализирующимися на оказании таких услуг через Интернет.

Создание использующих веб-сервисы коммерческих приложений влечет за собой необходимость установления между этими сервисами соответствующих взаимоотношений, что реализуется с помощью любой комбинации языков программирования, операционных систем, пакетов программ, размещенных "до" или "после" брандмауэра. (Это также является способом решения сложных EAI-проблем.) Установление необходимых отношений (или потока управления) связанных веб-сервисов также приводит к автоматизации соответствующих бизнес-процессов и процедур.

Использование веб-сервисов очень выгодно с коммерческой точки зрения. За счет повсеместного распространения веб-сервисов Интернет становится более эффективным, особенно при осуществлении коммерческих сделок. Сочетая прямой доступ к программным приложениям и коммерческим документам, веб-сервисы следующего поколения Сети обеспечат полностью автоматическое взаимодействие, что позволит обращаться непосредственно к данным программ, игнорируя знакомые веб-страницы. Более того, основные компоненты веб-сервисов, скорее всего, будут предоставляться и публиковаться множеством различных компаний, специализирующихся на отдельных функциональных элементах (проверка полномочий, координация сделок, ведение счетов). Это обеспечит непосредственное взаимодействие "приложение-приложение" - принцип, лежащий в основе веб-сервисов и определяющий их суть и реализацию.

ОБЩЕЕ ВЗАИМОПОНИМАНИЕ

Технология веб-сервисов существует на очень высоком уровне абстракции, позволяя поддерживать множество одновременных определений, которые иногда бывают противоречивы. На простейшем уровне веб-сервисы могут восприниматься как интернет-ориентированные текстовые брокеры интеграции. Любые данные могут преобразовываться в ASCII-текст и обратно, и этот подход в течение долгого времени был общим знаменателем для систем графического вывода и систем управления базами данных. Как говорится, "если ничего не получается - преобразуй данные в текстовую форму". Ориентированные на использование текста системы также лежат в основе успешного развития Интернета, на котором базируется дополнительная абстракция веб-сервисов. Любой компьютер или операционная система может поддерживать HTML, браузеры и веб-сервисы; и при получении по сети файлов им совершенно безразлично и даже неизвестно, с каким типом прикладной системы они взаимодействуют.

То же самое можно сказать и о веб-сервисах, которые зачастую вызывают замешательство, когда разработчики традиционного, устоявшегося компьютерного окружения пытаются воспринимать веб-сервисы как отдельный тип распределенной программной среды, такой как CORBA, J2EE или .NET. Поскольку веб-сервисы гораздо более абстрактны - как посредники (преобразователи), а не как интерфейсы - так и будет продолжаться, пока они не будут приведены в соответствие с общими описаниями и соглашениями.

Взаимодействие с веб-сервисами

Веб-сервисы поддерживают несколько парадигм обмена сообщениями. Уровень абстракции, на котором оперируют веб-сервисы, подразумевает такие стили взаимодействия, как эмуляцию удаленного вызова процедуры (Remote Procedure Call, RPC), асинхронный обмен сообщениями, однонаправленную передачу сообщений, широковещание и публикацию/подписку. Основные СУБД, такие как Oracle, SQL Server и DB2, поддерживают анализ XML и службы преобразования, обеспечивая непосредственное взаимодействие между веб-сервисами и СУБД. Производители связующего программного обеспечения обычно также предоставляют возможность привязки веб-сервисов к своим программным системам (серверам приложений и брокерам интеграции). Следовательно, для пользователя взаимодействие с веб-сервисами может проявляться в интерактивной или пакетной форме, поддерживающей синхронную и асинхронную модели связи; а также как пользовательский интерфейс, написанный с использованием Java, VB (Visual Basic), офисных приложений, браузеров или "толстых" клиентов СУБД. Такое взаимодействие может привязываться к любому типу базовой (более низкого уровня) программной системы.

Веб-сервисы выполняют RPC- и документно-ориентированное взаимодействия. Стандарты и технологии веб-сервисов обычно подразумевают два основных типа моделей взаимодействия приложений:

Эти два типа взаимодействия мы и рассмотрим в последующих разделах.

RPC-ориентированные взаимодействия

RPC-ориентированные взаимодействия удобны для краткого обмена данными. В RPC-ориентированном взаимодействии запросы веб-сервисов приобретают форму вызова метода или процедуры с соответствующими входными или выходными параметрами. В отличие от документно-ориентированного взаимодействия, RPC-ориентированное взаимодействие производит отправку документа, специально отформатированного для передачи в отдельную логическую программу или базу данных (рис. 1.4). Поскольку, например, заказ коньков в режиме реального времени зависит от их наличия на складе, программа обращается к базе данных с проверкой наличия заказываемого товара. Если получено подтверждение, то программа вернет заказчику XML-документ в формате "запрос/ответ", сообщающий о принятии заказа с его последующим исполнением.

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

Рис. 1.4. Веб-сервисы поддерживают интерактивный
заказ в форме запроса/ответа

Документно-ориентированные взаимодействия

Документно-ориентированные взаимодействия удобны для обмена большими объемами данных. При документно-ориентированном взаимодействии запросы веб-сервиса имеют форму завершенного XML-документа, предназначенного для обработки целиком. Например, веб-сервис, который представляет заказ на поставку (оптовый предварительный заказ на поставку коньков), должен сразу предъявлять производителю полную форму заказа (рис. 1.5). Это напоминает помещение сообщения в очередь для асинхронной обработки. Производитель обычно по электронной почте либо в какой-либо иной форме высылает заказчику подтверждение, свидетельствующее о том, что заказ принят и будет выполнен в соответствии с предопределенной последовательностью выполнения бизнес-процесса. Последовательность выполнения может содержать такие этапы, как проверка в базе данных предыдущих заказов данного оптового покупателя на предмет исчерпания кредитного лимита, согласованных объемов или графика поставок по данному заказу. В реальном потоке выполнения заказа и отправки счета, конечно же, существуют и другие этапы, но в данном примере рассматривается только заключительная стадия: отправка XML-счета для оплаты после доставки и получения заказа.

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

Рис. 1.5. Веб-сервис обрабатывает полный заказ на поставку

Для синхронных/асинхронных парадигм обмена сообщений удобны два стиля привязки. В нашем примере предварительный оптовый заказ выполняется в компании Skateboots Company с использованием заказов на покупку, представляемых в виде пакетов в соответствии с предварительными договоренностями, что помогает производителю спланировать объемы. В период активного спроса заказы на немедленное пополнение обрабатываются более интерактивными сервисами, которые зависят от заказов на пополнение с имеющихся складов и позволяют тотчас идентифицировать отложенные заказы. Таким образом, сайт Skateboots.com предоставляет веб-сервисы, поддерживающие оба основных типа взаимодействия.

Технология веб-сервисов

Порядок описания, поиска и взаимодействия веб-сервисов друг с другом определяют стандарты. Взаимодействующие через Интернет программы должны уметь обнаруживать друг друга, находить информацию, позволяющую им осуществить связь, понимать, какая модель контактирования должна быть применена (простая, типа "запрос/ответ", или более сложная последовательность), и договариваться об использовании таких услуг, как защита информации, подтверждение передачи сообщений и составление сделок. Некоторые из этих сервисов реализуются существующими технологиями и предлагаемыми стандартами, а другие - нет. Использующее веб-сервисы сообщество стремится удовлетворить все эти требования, но это - эволюционный процесс, как и сам Интернет. С самого начала инфраструктура и стандарты веб-сервисов подразумевали возможность расширения (так же как до них XML и HTML), что позволяет использовать их сразу же после появления новых стандартов и технологий.

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

НОВАЯ "СЕРЕБРЯНАЯ ПУЛЯ"?

С точки зрения современных проблем вычислительной техники веб-сервисы иногда представляются как решение типа "серебряная пуля", исполняя роль, которая ранее отводилась Сети, реляционным базам данных, языкам программирования 4-го поколения и искусственному интеллекту. К сожалению, сами по себе веб-сервисы не в состоянии решить многие проблемы. Они представляют новый уровень (или другой способ выполнения), а не фундаментальное изменение, которое приходит на смену существующей компьютерной инфраструктуре. Этот новый технологический уровень выполняет новую функцию, но, что более важно, обеспечивает механизм интеграции, определенный на более высоком уровне абстракции.

Важность веб-сервисов заключается в том, что они могут служить "связующим мостом", а не заменой существующих технологий. Можно сказать, что новые языки программирования, такие как Visual Basic, C#, C/C++ и Java, пришли на смену старым языкам, таким как COBOL и FORTRAN, хотя множество программ на этих языках все еще используются, как и привязки веб-сервисов для них. В качестве веб-серверов веб-сервисы являются дополнением и не конфликтуют с существующими приложениями, программами и базами данных. Разработка приложений по-прежнему требует знаний Java, VB и C#. Все, что является новым, - это способ преобразования данных для передачи в приложение и обратно на основе стандартных форматов XML-данных и протоколов, что позволяет обеспечить новый уровень интеграции и взаимодействия.

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

Пример использования

Стандарты веб-сервисов обычно используются совместно. Основные стандарты веб-сервисов используются согласованно. После обнаружения WSDL в UDDI или другом месте генерируется SOAP-сообщение для отправки на удаленный сайт.

Как видно из рис. 1.6, при предоставлении документа по адресу веб-сервиса программа использует XML-схему определенного типа (такую как WSDL), позволяющую преобразовать данные из ее входного источника (в этом примере структурированный файл) и на основе того же WSDL-файла создать экземпляр XML-документа в формате, согласованном с целевым веб-сервисом. WSDL-файл используется для определения как входного, так и выходного преобразования данных.

SOAP-процессор отправляющего компьютера преобразует данные из собственного ("родного") формата в тип данных, предопределенный в соответствии с содержащейся в WSDL-файле XML-схемой на основе таблиц преобразования для текстов, значений с плавающей точкой и других данных. Таблицы преобразования "связывают" собственные типы данных с соответствующими конкретной XML-схеме. (Стандартное преобразование типов широко используется в Java, Visual Basic, CORBA и других известных системах. Многие средства XML позволяют настраивать специальные преобразования типов.) SOAP-процессор получающего компьютера выполняет обратное преобразование данных из типов XML-схемы в собственные типы данных.

Файлы описаний веб-сервисов обычно регистрируются с помощью URL. URL, повсеместно используемый в Сети, указывает на IP-адрес, соответствующий веб-ресурсу. Схемы веб-сервисов являются одной из форм веб-ресурса, они содержатся в доступных через Интернет файлах и к ним применим тот же механизм, что используется при загрузке HTML-файлов. Главное отличие между загрузкой HTML-файла и обращением к ресурсу веб-сервиса заключается в том, что веб-сервис оперирует XML-документами, а не HTML-документами и опирается на соответствующие технологии, такие как использование схем, преобразование, проверка подлинности, что и обеспечивает поддержку удаленного соединения приложений. Но способ, согласно которому схемы веб- сервисов публикуются и загружаются, одинаков: HTTP-операция по указанному URL.

Рис. 1.6. Веб-сервисы используют XML-документы и
осуществляют преобразование данных

Для проверки достоверности сообщений веб-сервисы используют XML-схемы. После получения документа реализация веб-сервиса сначала должна проанализировать XML-сообщение и удостовериться в корректности данных, выполнить проверку качества услуг (Quality-of-Service), такую как проверку политики безопасности или соглашений торговых партнеров, а затем произвести последовательность связанных с данным документом коммерческих операций. Веб-сервис на вымышленном нами сайте skateboots.com размещен в папке skateboots.com/ order, на которую и указывает URL.

Веб-сервис, доступный по данному интернет-адресу, идентифицируется с помощью публичного WSDL-файла, который может быть загружен на отправляющий компьютер и использоваться при генерации сообщения. Компания Skateboots Company также осуществляет отправку в общедоступный каталог UDDI-листинга, позволяющего клиентам находить компанию с помощью технологии UDDI. В общем случае, любой, кто хочет взаимодействовать с веб-сервисом, размещающим или контролирующим по Сети заказы для Skateboots Company, для генерации сообщения должен найти способ получения и использования WSDL-файла.

Размещенные по адресу skateboots.com программы представляют собой прослушивающий HTTP-процесс, связанный с соответствующими веб-сервисами для распознавания XML-сообщений, определенных в данном формате. Эти программы включают в себя XML-анализаторы и преобразователи. Кроме того, они осуществляют конвертацию данных SOAP-сообщения в форматы, необходимые для системы ввода заказов компании Skateboots Company.

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

ПОВТОРНОЕ ИЗОБРЕТЕНИЕ КОЛЕСА

Некоторые утверждают, что веб-сервисы - это изобретение колеса, поскольку они повторяют характеристики других распределенных компьютерных архитектур, таких как CORBA или DCOM. Веб-сервисы вобрали в себя многое из существующих решений и реализаций, но они также являются хорошим поводом для открытия новой архитектуры. Глобальная сеть уже устоялась, и для получения максимальной выгоды от этой громадной структуры необходимо изменить концепции распределенной обработки данных. Во-первых, Сеть в основном была разъединенной, то есть соединения были случайными и временными. Службы распределенной обработки, такие как сервисы безопасности и транзакций, обычно зависели от соединения транспортного уровня и должны были быть воссозданы для обеспечения той же функциональности для разъединенной Сети. Во-вторых, Сеть предполагала, что стороны могут осуществлять соединение не зная друг друга, а лишь следуя логике URL и придерживаясь некоторых общих правил. Для веб-сервисов это означает, что любой клиент может обратиться к опубликованным кем бы то ни было веб-сервисам, а также к информации об этом сервисе (схеме), которая доступна и понятна для всех; а XML-процессоры способны генерировать сообщения в соответствии с этой схемой.

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

Со временем, когда окончательно сформируются стандарты регистрации, поиска и качества услуг и концепция специально организованной динамической деловой Сети получит всеобщее признание, тогда веб-сервисы станут использоваться так же, как мы сейчас используем Интернет. Это действительно даст компаниям возможность находить друг друга и осуществлять торговые операции между собой. Тем временем рассматриваемые в данной книге основные технологии и стандарты важны для реализации многих решений, например, для интегрирования несовместимых программных доменов (например, J2EE и .NET), подключения пакетов приложений (таких как SAP и PeopleSoft), а также предоставления документов в предопределенный поток управления бизнес-процессом.

Основы XML

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

Для чего нужен XML

XML позволяет определять любое количество элементов. Язык XML был разработан в целях преодоления ограничений языка HTML, в частности для усовершенствования возможностей создания динамического наполнения и управления им. HTML очень удобен для определения и поддержки статического содержания, но не при движении Сети в направлении программной платформы, в которой данные должны генерироваться и систематизироваться динамически. С помощью XML вы можете определить любое множество элементов, значение которых ассоциировано с данными; то есть вы описываете данные и указываете то, что хотите с ними делать, используя один и более элементов, созданных для этой цели. Например:

<Company>
	<CompanyNameregion="US"> 
	Skateboots Manufacturing 
	</CompanyName> 
	<address>
		<line>	
			200 High Street
		</line>
		<line>	
			Springfield, MA 55555
		</line>
		<Country>
			USA
		</Country>
	</address>
	<phone>
		+1 781 555 5000 
	</phone> 
</Company>

В этом примере язык XML позволяет описать не только сами элементы данных, но и структуры, которые группируют соответствующие данные. Легко представить поиск элементов, удовлетворяющих точному критерию, например, и нужной компании или по всем элементам с получением списка всех объектов, определяющих себя в Сети как компании.

Кроме того, как уже упоминалось ранее, XML позволяет связывать схемы, что дает возможность раздельно проверять достоверность данных и описывать их прочие атрибуты и качественные характеристики, что невозможно сделать с помощью HTML.

XML-схемы сдерживают гибкость. Разумеется, из-за большой эластичности XML возникают серьезные проблемы. Поскольку язык XML позволяет пользователю определять собственные структурные элементы, сложно гарантировать, что одинаковые элементы будут использоваться одинаковым способом. Для достижения "взаимопонимания" приходится вводить согласованные модели интерпретации содержания.

Две обменивающиеся XML-данными стороны могут однообразно понимать и интерпретировать элементы только в том случае, если они совместно используют одинаковые определения. Если эти же стороны, кроме того, разделяют сообща одну и ту же схему, они будут уверены в однообразном восприятии одинаковых тегов элементов. Именно так и работают веб-сервисы.

Технологии

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

Более подробно эти технологии будут рассмотрены в главе 2.

БУДУЩЕЕ СЕТИ

Изобретатель World Wide Web Тим Бернерс-Ли (Tim Berners-Lee) сказал, что следующее поколение Всемирной паутины будет связано с данными, а не с текстом; XML так же относится к данным, как HTML - к тексту. На следующем этапе развития Web будут учтены существующие в настоящее время недостатки, особенно сложность поиска в WWW путем точного совпадения с текстовой информацией, размещенной на веб-страницах. В настоящее время Сеть функционирует успешно, поэтому будущие разработки должны выполняться в виде расширения или дальнейшего развития существующих достижений. Не имеет смысла разрушать старое, чтобы на его останках построить новое. Решения для межпрограммных взаимодействий должны опираться на существующие интернет-технологии.

Если будущее Web зависит от возможности поддержки обмена данными с той же эффективностью, с которой он поддерживал обмен текстовыми сообщениями, то веб-сервисы должны иметь возможность динамически ссылаться на узлы или обращаться к ним (с помощью URL), а также явно осуществлять отображение данных в XML и из XML. Такие узлы (или адреса) предоставляют сервисы, обеспечивающие обработку XML-данных практически так же, как браузеры форматируют HTML-текст. Эти адреса также могут включаться в любые программы, способные распознавать URL и анализировать XML. Это позволит осуществить подключение электронной таблицы пользователя к удаленному источнику данных, или подключение программы ведения семейного бюджета к приложению, управляющему банковским счетом, или к расписанию встреч с коллегами и т. д.

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

WSDL: описание веб-сервисов

Язык описания веб-сервисов (Web Services Description Language, WSDL) - это формат XML-схем, определяющий расширенную структуру описания интерфейсов веб-сервисов. WSDL первоначально был разработан компаниями Microsoft и IBM. А затем его поддержали консорциум W3C и 25 компаний. WSDL - это сердце структуры веб-сервиса. Это общий способ представления передаваемых в сообщениях типов данных, указывающий действия, которые должны быть выполнены с данным сообщением и согласно которому сообщения привязываются к сетевым транспортам.

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

WSDL в соответствии с уровнем абстрагирования состоит из трех элементов. WSDL можно разделить на три основные составляющие:

Каждая составляющая может быть указана в различных XML-документах и импортирована в виде различных комбинаций, что позволяет создавать окончательное описание веб-сервиса. Кроме того, все составляющие могут быть представлены и в одном XML-документе. "Определение типов данных" задает структуру и содержание сообщений. "Абстрактные операции" определяют операции, которые должны быть выполнены с содержанием сообщения, а "связывание сервисов" подразумевает сетевой транспорт, который доставит сообщение по месту назначения.

На рис. 1.7 представлены составляющие WSDL, упорядоченные в соответствии с их уровнем абстракции, который определяется независимо от транспорта, особенно когда для одного сервиса используется множество транспортов. Например, к одному и тому же сервису можно обращаться посредством "SOAP поверх HTTP" или "SOAP поверх JMS". Аналогично, определения типов данных размещены в разных разделах, что позволяет использовать их различными сервисами. Основные WSDL-составляющие разделены на компоненты.

Рис. 1.7. WSDL состоит из трех основных составляющих
и семи компонентов

WSDL-интерфейсы подобны интерфейсам CORBA и DCOM. Части описания содержат описания типов данных, сообщения и абстрактные операции, которые схожи с интерфейсами CORBA и DCOM. Сообщения могут состоять из нескольких секций и могут быть предназначены для использования в случае процедурно-ориентированного стиля взаимодействия, документно-ориентированного стиля или при применении обоих стилей. В зависимости от уровня абстрагирования одни и те же сообщения могут определяться и использоваться для нескольких типов портов. Как и другие части WSDL, сообщения также поддерживают компоненты расширения, в частности, для включения в себя атрибутов других сообщений.

Типы данных веб-сервисов основаны на XML-схемах, но могут быть распространены на любые другие механизмы. WSDL-описания типов данных базируются на XML-схемах, но здесь годятся для использования и другие эквивалентные или аналогичные системы определения типов данных. Например, вместо типов данных XML-схемы может применяться язык описания интерфейса (Interface Definition Language, IDL) CORBA. (Если используется иная модель определения типов, ее должны "понимать" обе стороны.)

Абстрактные операции и сообщения отображаются на специальный транспорт. Связывание сервисов отображает абстрактные сообщения и операции на специальный транспорт, такой как SOAP. Для включения сведений, характерных для SOAP и других типов отображения, используется связывание расширяемых компонентов. Абстрактные определения могут привязываться к различным физическим транспортам. Спецификация WSDL v1.1 включает примеры однонаправленного SOAP-отображения для SMTP (Simple Mail Transfer Protocol), SOAP RPC-привязки к HTTP, SOAP-привязки к методам get и post протокола HTTP, а также пример отображения для MIME (Multipurpose Internet Mail Extensions) - многокомпонентного связывания SOAP.

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

Можно смело сказать, что по мере развития веб-сервисов WSDL, по всей видимости, будет включать множество расширений, изменений и добавлений. Как и SOAP, WSDL разработан в виде расширяемой XML-структуры, которая может быть легко модифицирована для привязки множества типов данных, определений типов сообщений, операций и транспортов. Например, рабочие группы IETF (Internet Engineering Task Force) предлагают новый стандарт протоколов - Blocks Extensible Exchange Protocol (BEEP), - позволяющий определять транспорт с установлением соединений. (В отличие от HTTP, ориентированного на связь без установления соединения, что усложняет решение проблем качества обслуживания на транспортном уровне.) Компании, интересующиеся использованием веб-сервисов во внутренних приложениях или для осуществления интеграции, могут расширить WSDL, обеспечив его привязку к более традиционным протоколам, таким как DCOM или IIOP (Internet Inter-Orb Protocol).

SOAP: доступ к веб-сервисам

До сего момента вы определяли данные (XML) и абстрактно представили службу, необходимую для обеспечения соединения и обработки сообщения (WSDL). Теперь же необходимо уточнить, каким способом сообщение будет пересылаться с одного узла на другой, что позволит провести его обработку на конечном компьютере.

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

SOAP - это XML-способ определения: какая информация должна пересылаться и как. SOAP - это базовая однонаправленная модель соединения, обеспечивающая согласованную передачу сообщения от отправителя к получателю, потенциально допускающая наличие посредников, которые могут обрабатывать часть сообщения или добавлять к нему дополнительные элементы. Спецификация SOAP содержит соглашения по преобразованию однонаправленного обмена сообщениями в соответствии с принципом "запрос/ответ", популярным при организации соединения типа RPC, а также определяет, как осуществлять передачу всего XML-документа.

SOAP включает дополнительные правила кодирования для различных типов данных, но конечные узлы SOAP-соединения могут определить собственные правила посредством конфиденциального соглашения сторон. В ходе связи зачастую используется буквенное или встроенное в XML кодирование.

Как видно из рис. 1.8, SOAP предназначена для поддержания независимого абстрактного протокола связи, обеспечивающего коммуникацию двух и более предприятий или двух и более удаленных корпоративных сайтов. Связанные системы можно построить на основе любой комбинации аппаратного и программного обеспечения, поддерживающей доступ через Интернет к таким средам, как .NET и J2EE. Существующие системы обычно также представлены множественными инфраструктурами и пакетами программ. SOAP и остальные структуры XML предоставляют возможность двум и более предприятиям, торговым площадкам или партнерам выработать общий подход по вопросу предоставления услуг в Сети.

SOAP-сообщения содержат конверт, заголовок и тело сообщения. SOAP-сообщения состоят из нескольких основных частей.

Envelope (конверт) - определяет начало и конец сообщения.

Header (заголовок) - содержит любые дополнительные атрибуты сообщения, используемые в ходе обработки сообщения как посредником, так и конечным получателем.

Body (тело сообщения) - содержит XML-данные, передаваемые данным сообщением.

Attachment (вложение) - состоит из одного и более документов, "прикрепленных" к основному сообщению. (Относится только к SOAP with Attachments ("SOAP с вложениями").)

RPC interaction (SOAP:RPC-взаимодействие) - определяет, как моделировать взаимодействия RPC-типа.

Encoding (кодировка) - определяет, как будут представлены простые и сложные данные, передаваемые в сообщении.

Обязательными являются только конверт и тело сообщения.

Рис. 1.8. SOAP-сообщения осуществляют соединение удаленных узлов

В ПРЕДЕЛАХ ПРЕДПРИЯТИЯ

Многие компании изучают потенциальные преимущества использования веб-сервисов как в пределах предприятия, так и за его границами. Такой подход аналогичен использованию браузеров и веб-серверов в рамках корпоративных сетей. Наличие внутренней веб-инфраструктуры благоприятно сказывается на поддержке взаимодействий веб-сервисов. Несмотря на то что веб-сервисы, по сути, заменяют существующие распределенные компьютерные среды, такие как COM и COBRA, они являются полезным дополнением существующих технологий. Иногда вы имеете только HTTP- или SMTP-подключение. Поскольку они представляют собой полностью нейтральный формат, который может использоваться для достижения нового уровня взаимодействия, веб-сервисы применимы в качестве "моста" между COM, CORBA, EJB и средами формирования очередей сообщений. И наконец, поскольку веб-сервисы опираются на существующую HTTP-инфраструктуру, то нагрузка на системных администраторов будет минимальна и сопоставима с внедрением в отдел IT других компьютерных технологий. Производительность, естественно, несколько падает, но это снижение сравнимо с использованием более распространенных двоично ориентированных транспортов и протоколов. Для большинства приложений потенциальные преимущества превосходят издержки, и вопросы производительности со временем теряют актуальность.

UDDI: публикация и поиск веб-сервисов

После того как вы определили данные в сообщении (XML), описали сервисы, которые будут принимать и обрабатывать сообщения (WSDL), и предъявили требования к средству их передачи и приема (SOAP), вам необходимы способы публикации предлагаемой вами службы, а также инструменты поиска нужных вам, но предоставляемых другими участниками услуг. Именно эти функции и выполняет реестр UDDI (universal distribution, discovery, and integration).

UDDI регистрирует и публикует определения веб-сервисов. Структура UDDI определяет модель данных в программных интерфейсах (API) XML и SOAP для регистрации и обнаружения коммерческой информации, включая веб-сервисы. Реестр UDDI был создан независимым консорциумом производителей (основанным компаниями Microsoft, IBM и Ariba), занимающимся разработкой стандарта для описания, регистрации и локализации веб-сервисов. Microsoft, IBM, Hewlett- Packard и SAP на начальном этапе предоставляют общедоступный UDDI-сервис, который концептуально копирует DNS (систему имен доменов Интернета, осуществляющую "перевод" имен Интернета в IP-адреса). На практике UDDI более похож на сервис реплицируемой базы данных, доступной через Интернет.

UDDI - это каталог веб-сервисов. UDDI идейно подобен каталогу "Желтые страницы". Предприниматели регистрируют свою контактную информацию, в том числе номер телефона, факса, почтовый адрес и адрес веб-сайта. Регистрация включает различные необходимые для поиска категории информации, такие как географическое положение, код отрасли промышленности, тип бизнеса и т. д. Другие предприниматели при поиске поставщиков комплектующих, служб доставки, а также аукционов и торгов могут найти нужные данные, сохраненные в UDDI. Можно также обнаружить информацию об определенном веб-сервисе обычным путем, пытаясь найти URL WSDL-файла, указывающего на веб-сервис поставщика.

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

На рис. 1.9 показано, как предприятие будет осуществлять регистрацию в UDDI сведений о веб-сервисе.

Сначала предприятие генерирует WSDL-файл, который описывает веб-сервисы, поддерживаемые SOAP-процессором (1), и с помощью API UDDI регистрирует информацию в хранилище (2). После отправки предприятием этих сведений (совместно с другой контактной информацией) элемент реестра будет содержать URL, указывающий на WSDL-файл сайта SOAP-сервера или на другой файл XML-схемы, описывающий данный веб-сервис.

После этого SOAP-процессор другого предприятия запрашивает реестр (3) для получения WSDL или другой схемы (4). Для отправки конкретной операции по определенному протоколу (6) клиент может сгенерировать соответствующее сообщение (5). Конечно же, клиент и сервер должны договориться о том, чтобы протокол был одинаковым (в данном примере "SOAP поверх HTTP"), и совместно использовать одинаковые понятия или семантические описания сервиса, который в данном примере представлен WSDL. При повсеместном распространении основных стандартов, скорее всего, общее понимание будет гарантироваться посредством WSDL.

Рис. 1.9. Для обнаружения веб-сервиса может
использоваться репозиторий UDDI

XML для сотрудничества предприятий: ebXML

Спецификации ebXML расширяют возможности основных технологий веб-сервисов. Для организации действительного взаимодействия типа business-to-business по Сети помимо основных технологий веб-сервисов требуется ряд дополнительных технологий. Например, консорциум электронной коммерции XML (Electronic Business XML, ebXML) определил всесторонний набор спецификаций для промышленной модели обмена XML-документами между торговыми партнерами. Спецификация обмена ebXML-сообщениями основана на "SOAP с вложениями" и не использует WSDL, но добавляет несколько сервисов качества обслуживания, такие как обеспечение безопасности, гарантированная доставка сообщений и согласованность модели процесса взаимодействия.

Спецификации еbXML определяют использование XML в коммерческих сделках. Деятельность по разработке спецификаций еbXML, первая фаза которой была завершена в мае 2001 года, финансировалась международной группой, учрежденной Центром содействия торговле и электронной коммерции при ООН (United Nations Center for Trade Facilitation and Electronic Business (UN/ CEFACT) и организацией OASIS (The Organization for the Advancement of Structured Information Standards), для исследований, разработки и продвижения глобальных стандартов использования XML в целях обмена данными в ходе электронной коммерции.

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

ebXML-архитектура расширяет базовые концепции веб-сервисов. Хотя ebXML-консорциум завершил начальный этап разработки, OASIS, UN/CEFACT и другие организации продолжают содействовать распространению этой архитектуры и спецификаций в широкой аудитории, надеясь утвердить глобальный рынок электронной коммерции, основанный на независящем от географических и политических границ стандартизированном обмене XML-документами и сообщениями и обладающий необходимым качеством обслуживания. еbXML архитектура определяет:

Аналогично тому, как UDDI способствует поиску определений веб-сервисов, ebXML-архитектура позволяет предпринимателям находить с помощью реестра компаньонов для определения соглашений торгового партнерства и для обмена XML-сообщениями в интересах выполнения коммерческих операций. Основная цель заключается в том, чтобы автоматизировать все эти действия, они должны выполняться с использованием сети Интернет без вмешательства человека. ebXML-архитектура имеет много общего с технологией SOAP/WSDL/UDDI и в некоторых вопросах полностью с ней совпадает (утверждение SOAP в транспортной спецификации ebXML). RosettaNet, как и множество других промышленных консорциумов, также объявила о принятии ebXML-транспорта.

ВЕБ-СЕРВИСЫ И EDI В СРАВНЕНИИ С EBXML

ПРИМЕЧАНИЕ. Хотя электронный обмен данными (Electronic Data Interchange, EDI) существует уже в течение двух десятков лет, он остается весьма сложным и имеет множество интерпретаций. При развертывании требуется проведение серьезной технической экспертизы, а сам обмен основан на негибкой архитектуре с прочными связями. Несмотря на то что EDI-приложения могут быть развернуты в общедоступных сетях, они часто используются в дорогостоящих специализированных сетях и требуют значительной квалификации персонала при установке и эксплуатации.

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

еbXML сфокусирована на документно-ориентированном взаимодействии. ebXML-архитектура четко нацелена на документно-ориентированное взаимодействие; по мере получения признания, еbXML, вероятно, переопределит парадигму В2В-ориентированного взаимодействия веб-сервисов. Компании, которые уже перешли к обмену информацией в электронном виде, например, с использованием стандартов EDI, отметят много сходного в конечных целях еbXML, хотя последние более широкие и рассчитаны на работу через Интернет.

ЕBXML И SOAP

Изначально казалось, что группа, разрабатывающая еbXML, конкурировала с группой компаний, развивающих SOAP, WSDL и UDDI. И в самом деле, спецификации еbXML перекрывают значительную часть "территории" SOAP, WSDL и UDDI. Можно представить SOAP-направление как подход "снизу вверх", который начинается с определения способа отображения XML-документов в HTTP-сообщения; либо посмотреть на еbXML как на подход "сверху вниз", берущий начало с определения бизнес-процесса как последовательности сообщений, отображаемых на какой-либо транспорт.

еbXML-группа изначально была сформирована для создания стандартов бизнес-процесса - области, в которой применение еbXML было многообещающим. Сферы транспорта, описания сервисов и регистрации считались более подходящими для деятельности, направленной на проблемы инфраструктуры, чем на бизнес-процесс и документооборот. Одним из главных факторов мотивации еbXML является определение стандартов, имеющих такие же (или подобные) цели, как и EDI, но включающие поддержку вновь появляющихся "словарей" XML (vocabularies), специфичных для определенных отраслей. По-видимому, уместно продумать ebXML-архитектуру в соответствии с требованиями W3C и других XML-ориентированых инициатив как способ проверки готовности веб-сервисов к реальному коммерческому использованию, а не как конкурентный шаг, направленный на определение сервисов центральной инфраструктуры.

Веб-сервисы и другие технологии

Веб-сервисы не похожи на традиционные технологии распределенной обработки данных, такие как CORBA, DCOM и EJB. Скорее всего, они близки веб-серверам (HTML и HTTP), на которых они основаны. Веб-сервисы по определению являются однонаправленными, асинхронными сообщениями, отображаемыми на исполняемые программы. Веб-сервисы определяют формат данных, не зависящий от языка программирования, операционной системы, сетевого транспорта и механизма хранения данных. Следовательно, данные могут быть переведены в нейтральный формат и обратно. Определение типов данных и структур абстрагируется от низкоуровневой реализации сервисов.

Веб-сервисы более похожи на посредников. Веб-сервисы зачастую сравниваются с вызовом удаленной процедуры или программным компонентом. Однако более правильно уподобить их брокерам (посредникам) интеграции приложений предприятия. Веб-сервисы определяют канонический формат сообщения, как это делается в программных системах EAI, таких как MQSeries, TIBCO, NEON Vitria и Orbix E2A от IONA, отвечают за способ отправки сообщения к интерфейсу сервиса, посредством которого данные преобразуются или отображаются на базовое приложение.

Другими словами, определение порядка передачи сообщения в программу не содержится в самом интерфейсе, как это имеет место в основанных на концепциях RPC технологиях CORBA, J2EE и DCOM, тесно увязывающих наименование сервиса с вызываемой программой. Вместо этого эти сведения содержатся в XML-процессоре, который следует соответствующим инструкциям, указывающим, как проанализировать обрабатываемое сообщение и направить данные в какую бы то ни было программу, реализующую веб-сервис.

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

Веб-сервисы являются однонаправленными, асинхронными системами передачи сообщений. В отличие от RPC-ориентированного связующего программного обеспечения, наподобие CORBA и DCOM, веб-сервисы используют однонаправленную, асинхронную передачу сообщений, которая более естественно соотносится с такими системами поддержания очереди сообщений, как MQSeries или JMS. Хотя, конечно же, веб-сервисы довольно часто отображаются и в продукты на основе CORBA, J2EE и DCOM. Веб-сервисы поддерживают парадигму "запрос/ответ", типичную для синхронных RPC-подобных соединений посредством эмуляции; то есть XML-процессор точнее, чем протокол, коррелирует запросы с ответами. Например, HTTP-привязка SOAP не поддерживает корреляцию "запрос/ответ" на уровне протокола. Имитация веб-сервисами RPC легко сочетается с такими традиционными RPC-системами, как CORBA, EJB и DCOM, хотя сервисы качества обслуживания (например, безопасности, транзакций и обработки прерываний), скорее всего, будут сильно отличаться от тех доступных в традиционных технологиях распределенной обработки данных сервисов, которые нередко в существенной мере привязаны к транспортному потоку и являются специфичными для каждой технологии.

Взаимодействие с веб-сервисами аналогично взаимодействию с обычными приложениями. Поскольку взаимодействие с веб-сервисами осуществляется посредством программ и баз данных, с которыми эти сервисы связаны, навыки пользователя, скорее всего, должны отличаться от обычных привычек работы с браузерами: веб-сервисы более похожи на обычные приложения, чем на браузеры, хотя, конечно же, браузеры также могут применяться. (Как уже упоминалось ранее, веб-сервисы сами по себе не являются исполняемыми программами, они лишь должны отображаться на программу, объект, систему связующего программного обеспечения или СУБД.)

Дополнительные технологии

Ядро технологий веб-сервисов (SOAP, WSDL и UDDI) полезно для "наведения мостов" с "несопоставимыми" технологиями и предоставления документов в общий поток делового процесса. Однако для того, чтобы быть нужными для большего количества типов приложений и соответствовать представлению о веб-сервисах как "строительных" блоках для работы через Интернет, технологии веб-сервисов должны обладать рядом дополнительных характеристик, функций и сервисов качества обслуживания.

На современном этапе деятельность по развитию веб-сервисов в качестве более полезного базиса очень похожа на эволюцию технологии Common Object Request Broker Architecture, COBRA. Группа Object Management Group (OMG) в 1990-х годах взяла на себя обязательства всесторонне определить архитектуру такого программного обеспечения. В результате открытых совместных усилий мы получили мощный набор спецификаций, формализующих осуществление сделок, асинхронный обмен сообщениями, требования к безопасности, отказоустойчивости и т. д. Подобные усилия в отношении веб-сервисов были инициированы W3С и также привели к разработке аналогичной архитектуры.

Дополнительные технологии могут стать частью стандарта. В мире веб-сервисов основные поставщики промышленного программного обеспечения уже достигли примирения по стержневым стандартам. Microsoft, IBM, Sun Microsystems, BEA Systems, Oracle, IONA и другие компании договорились о реализации SOAP, WSDL и UDDI, хотя сохранилась некоторая разница во мнениях о роли ebXML-регистрации. Однако нефундаментальные стандарты зачастую оспариваются. К таким спорам относятся разногласия Microsoft и IBM по вопросу определения последовательности действий, то есть продолжается противоборство XLANG и WSFL (Web Services Flow Language). Кроме того, остаются конкурирующие предложения по реализации контекста безопасности.

Дополнительные технологии в основном сконцентрированы в следующих ключевых направлениях:

Наиболее важными из дополнительных технологий веб-сервисов являются технологии безопасности.

Безопасность превыше всего. Безопасность подразумевает конфиденциальность и целостность данных веб-сервисов. Никто, кроме конечного получателя данных, не должен иметь возможность изучать или изменять содержание сообщения. Вопрос безопасности также важен в плане контроля доступа к веб-сервисам, особенно при совместном использовании нескольких веб-сервисов.

Для авторизации и аутентификации предложено несколько стандартов (например, Security Authorization Markup Language, SAML). Также имеются стандарты для шифрования открытым ключом (XML Key Management Specification, XKMS). Конечно же, основой всей безопасности Интернета является протокол защищенных сокетов (Secure Socket Layer, SSL), а для HTTP-протоколов - HTTPS (secure HTTP), обеспечивающие базовый уровень безопасности.

Помимо HTTPS, брандмауэров, SAML, XKMS, использования цифровых подписей и XML-кодирования компания Microsoft предложила системы WS-License (управления удостоверениями безопасности) и WS-Security (распространение удостоверений безопасности, относящихся к взаимодействию с веб-сервисами).

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

Происходит переопределение механизма транзакций для Сети. В области автоматизации коммерческих операций давно используется система контроля, гарантирующая, что, несмотря на программные или аппаратные сбои, платформы, на которых осуществляются транзакции, обеспечивают согласованные результаты при выполнении последовательности связанных с данными операций. Однако традиционные протоколы и технологии не могут быть непосредственно применены к Сети, поскольку они предназначены для работы в средах с тесным взаимодействием, где возможно наличие блокировок записей баз данных при ожидании уведомления о результатах транзакции и в которых для автоматического обнаружения нарушения связи доступны протоколы, ориентированные на соединение. Для разрешения этой проблемы веб-сервисов предназначен предложенный OASIS протокол BTP (Business Transaction Protocol), который посредством определения слабо связанного протокола гарантирует корректное распространение и доступность для совместного использования результатов множества взаимодействий веб-сервисов.

Требуется механизм надежной передачи сообщений. Протоколы передачи сообщений реализуют модель связи, определенную для таких взаимодействий веб-сервиса, как асинхронное однонаправленное взаимодействие, запрос/ответ, широковещание и обычное равноправное взаимодействие. Дополнительные технологии веб-сервисов также могут зависеть от уровня доставки сообщений конкретного сервиса качества обслуживания, такого, например, как надежная (гарантированная) доставка, распространение контекстов безопасности и контекстов транзакций, а также верная маршрутизация сообщений по определенному пути, на котором имеется один и более промежуточных узлов. Компания IBM в связи с этим представила надежный протокол HTTP (HTTPR).

IBM сотрудничает с Microsoft в области разработки WS-Inspection, предназначенной для поиска информации о веб-сервисах, имеющихся у конкретного адресата сообщения. Кроме того, Microsoft предложила системы WS-Referral и WS-Routing для определения пути конкретного сообщения веб-сервиса, включая любое число промежуточных узлов, позволяющие тем самым определить, как перенаправлялось сообщение при прохождении по указанному маршруту.

BEEP - ориентированный на соединение протокол. Разработанный IETF протокол Blocks Extensible Exchange Protocol (BEEP) представляет собой ориентированный на соединение протокол. Уже определена привязка SOAP для BEEP, и в данном случае SOAP-сообщения наследуют от BEEP дополнительные сервисы качества обслуживания, поддерживая контекст сеанса на узлах отправителя и получателя. Контекст может быть использован для соотнесения множества сообщений с большим модулем пересылки, а также для соотнесения множества сообщений, поступающих от одного источника или предназначенных одному получателю. Контексты безопасности и транзакций также могут быть связаны с соединением.

С веб-сервисами связано множество технологий и стандартов. Другие значимые стандарты и технологии представлены следующими организациями:

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

ВСЕ ЕЩЕ ВПЕРЕДИ

Дополнительные технологии (обеспечение безопасности, транзакции и надежный обмен сообщениями), которые можно найти в распределенных средах обработки данных, должны быть определены заново ввиду коренных изменений в инфраструктуре - XML и HTTP, - на которой они строятся. Интернет-консорциум (W3C) должен предпринять дополнительные усилия по определению архитектуры веб-сервисов, так же как OMG определила архитектуру для COBRA, хотя это, по всей видимости, будет сложным и утомительным делом. W3C не должен допускать серьезных различий во мнениях между его членами, особенно когда такие разногласия мотивируются коммерческими интересами. В действительности это приведет к отказу от многих из предлагаемых стандартов.

Производители обращаются к веб-сервисам

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

Веб-сервисы не изменяют базовые программные системы. Веб-сервисы не изменяют существующие программные системы коренным образом, хотя они могут повлиять на их взаимодействие. Разница в подходе или философии производителей обычно приводит к различиям в реализации: являются ли веб-сервисы стержневой технологией или они просто представляют собой точки входа и выхода в существующих программных системах? Другими словами, производители варьируют свою тактику в зависимости от степени влияния веб-сервисов на существующую архитектуру программных систем. Например, отменяют ли веб-сервисы технологию J2EE или они совместимы с ней? Ответы на этот и другие аналогичные вопросы можно увидеть в подходе различных производителей программных систем.

Пять основных подходов к веб-сервисам связывают их с:

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

Может ли сервер приложений или СУБД нормально функционировать без поддержки веб-сервисов? Или способны ли веб-сервисы существовать сами по себе?

Что первостепенно: базовое программное обеспечение или уровень веб-сервисов? Таким образом, возникает вопрос: в чем состоит ценность? Является ли реализация веб-сервисов для серверов приложений, СУБД, брокеров интеграции лишь средством передачи данных в существующие программные системы? Или значимы сами веб-сервисы, являющиеся основой новой категории программных систем?

Взгляды производителей различны подобно тому, как это происходит с Java/ Visual Basic. Реализации производителей имеют тенденцию следовать различным взглядам на сущность веб-сервисов. Не удивительно, что компания Microsoft имеет свою собственную точку зрения, в то время как Sun Microsystems, IBM, BEA Systems, Oracle и другие компании придерживаются других мнений. До некоторой степени подобные отклонения в суждениях отражают продолжение противостояния производителей Visual Basic/Java, но компания Microsoft имеет более активную и агрессивную позицию в отношении веб-сервисов. Она готова даже путем разрыва с существующими приложениями Visual Basic гарантировать, что будущая версия VB будет поддерживать веб-сервисы как фундаментальную технологию. Сообщество Java придерживается менее радикальных взглядов, расширяя API Java для веб-сервисов вместо полного их изменения.

Продукты строятся либо на основе RPC, либо на асинхронном стиле взаимодействия. Промышленные консорциумы, например ebXML и OASIS, а также продукты типа "посредник интеграции" таких производителей, как IBM, Microsoft, IONA и WebMethods, стремятся сконцентрироваться на приложениях для веб-сервисов типа "бизнес-процесс" (ориентация на обработку документов). Продукты других производителей, в том числе Web services toolkits, поставляемый в составе WebLogic компании BEA, и J2EE Edition компании IONA, нацелены на взаимодействие RPC-типа. Одинаковые XML-технологии и стандарты могут использоваться по-разному, но поскольку предлагаемые парадигмы слишком отличаются, тенденции при разработке предложений и продуктов сближаются на базе какого-то одного принципа. Вообще говоря, серверы приложений ориентированы на поддержку взаимодействия RPC-типа, в то время как брокеры интеграции стремятся обеспечить асинхронный тип взаимодействия, ориентированный на обработку документов.

Производители брокеров интеграции, такие как WebMethods, Vitria, SeeBeyond, Software AC и Mercator, обычно понимают веб-сервисы как расширение классических технологий интеграции предприятия или B2B и подходят к построению веб-сервисов так же, как и к любой иной технологии, с которой должны быть интегрированы их продукты. Другие производители, такие как IONA, относятся к веб-сервисам более нейтрально и воспринимают их еще и как технологию для расширения существующего сервера приложений, которая связывает программное обеспечение COBRA и СОМ, и как основу для следующего поколения стандартов интеграции бизнеса и предприятий. Линия продуктов Orbix E2A компании IONA предоставляет не только преобразователи веб-сервисов для асинхронного документно-ориентированного взаимодействия и интерфейсы веб- сервисов для CORBA- и J2EE-совместимых объектов, но и стандартные блоки для построения основ веб-сервисов. Инструментарий (engine) бизнес-процесса компании IONA, средства перекодировки и преобразования XML, посредники пакетов приложений и структуры бизнес-протоколов - все они предназначены для экспорта интерфейсов веб-сервисов. Продукты компании IONA характеризуются согласованным подходом к интеграции приложений, использующих технологии веб-сервисов "до" и "после" брандмауэра.

Некоторые производители ориентируется только на веб-сервисы. И, наконец, ряд производителей рассматривает веб-сервисы как интересное и потенциально прибыльное направление и разрабатывает продукты, базирующиеся исключительно на веб-сервисах. Эти продукты, полностью основанные на технологии веб-сервисов, как правило, требуют наличия других технологий и продуктов. Например, Cape Clear ориентирован на "установление отношений" с J2EE и .NET. Компания Shinka предлагает продукты, которые предполагают, что веб-сервисы - фундаментальный центр разработки и что программы разрабатываются "под них", а не наоборот, как считает большинство других производителей.

ДЛЯ ЧЕГО НУЖНЫ ВЕБ-СЕРВИСЫ?

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

Резюме

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

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

Инициатива ebXML предлагает альтернативный взгляд на инфраструктуру распределенной обработки информации на основе XML, в частности при организации взаимодействия между коммерческими партнерами через Интернет. ebXML представляет форму промышленных веб-сервисов, хотя в состав ebXML не входят WSDL и UDDI. Многие производители усматривают в ebXML и веб-сервисах значительные перспективы, расширяющие существующие продукты; другие представляют веб-сервисы как самодостаточную технологию, на основе которой можно создавать цельные продукты.

Начало
Cодержание
Отрывок
[Заказать книгу в магазине "Мистраль"]