Web Services – новая технология для развертывания распределенных вычислительных систем. Основная причина ее появления – неспособность существующих технологий, таких как объектные системы типа COM семейства Microsoft и стандарты OMG CORBA, в полной мере обеспечить совместимость (интероперабельность) различных программных продуктов для неоднородных распределенных систем. Требование совместимости – один из главных рычагов давления все стремительно развивающегося рынка электронного бизнеса, основу которого составляют многочисленные разнотипные как поставщики вычислительных услуг, так и их потребители. Технология Web Services предложена и развивается под эгидой WWW-консорциума W3C [1] ведущих компаний-производителей программного обеспечения.

• простейшие коммуникационные Интернет-протоколы HTTP и/или SMTP;
• протоколы SOAP (Simple Object Access Protocol) для управления сообщениями в универсальном XML-формате;
• язык WSDL (Web Services Definition Language) описания интерфейса взаимодействия компонент распределенной системы.

Технологии услуг сети SOAP и WSDL применялись и ранее (Userland, Microsoft, Developmentor) вне W3C; их спецификации были использованы для Web Services как основание для создания расширяемой структуры управления сообщениями (messaging) SOAP 1.2 и языка определений интерфейсов WSDL 1.2.

Можно дать определение Web Services (или Web-служб) как набора услуг в виде программных приложений, идентифицированного сетевым адресом URI (Uniform Ressourse Identifier), интерфейсы и связывания (binding) которого определяются XML-средствами. Web-службы обеспечивают прямые взаимодействия через Интернет с другими агентами программного обеспечения, используя сообщения, основанные также на XML-формате. Данное определение Web-служб не предполагает использование SOAP в качестве формата или модели обработки сообщений. И при этом оно не предполагает также использование WSDL как языка описаний обслуживания. В настоящее время существуют (и будет появляться) множество услуг сети, которые используют уровень HTTP в качестве протокола передачи данных и некоторые взаимосогласованные XML-форматы содержания сообщения (контента). Однако, в W3C предполагают, что более высокие уровни стека протокола Web-служб должны строиться на основе SOAP и WSDL.

Консорциум W3C вырабатывает рекомендации, являющиеся стандартом для спецификаций и протоколов Web-служб; согласно этим рекомендациям различные компании-производители программного обеспечения разрабатывают собственные реализации этих технологий. Вот некоторые из них: SOAP Toolkit (Microsoft), WebSphere Application Server (IBM), JWSDP (Sun). Одним из замечательных достижений технологии Web-служб является совместимость всех их реализаций, независящая от поставщиков (провайдеров) вычислительных услуг и производящих их технологий. Основу этой совместимости является последовательное применение на всех уровнях предоставления услуг Web-служб стандартов XML-технологии. Так например, формат SOAP-сообщений – основной единицы передачи данных - представлен в виде XML-документа; описание интерфейса вычислительного сервиса в WSDL также представляется в XML-формате.

В архитектуре Web-служб рассматириваются две ее составные части: базовая (Basic Architecture) и расширенная (Extended Web Services Architecture) архитектура. Базовая архитектура включает в себя стандартный (обязательный) набор средств этой технологии, уже нашедший применение в различных реализациях Web-служб; расширенная архитектура в большей части ориентирована на дополнительные или перспективные спецификации, расширяющие возможности технологии, такие как:

• асинхронные сообщения,
• передача данных в режиме приложений (attachment) SOAP-сообщений,
• идентификация и конфиденциальность сообщений и др.

Базовая архитектура включает следующие технологии Web-служб:

• обмен сообщениями,
• обеспечение удаленного вызова процедур,
• описание услуг Web-служб,
• регистрация (публикация) и поиск (обнаружение) описаний услуг.

Базовая архитектура Web-служб определяет взаимодействие между агентами программного обеспечения как обмена сообщениями между запрашивающими сервис (requesters) и поставщиками услуг (provider - провайдерами). Requesters - агенты программного обеспечения, которые запрашивают выполнение сервиса, провайдеры - агенты программного обеспечения, которые обеспечивают выполнение сервиса. Каждый из агентов может быть одновременно и запрашивающим и провайдером. Провайдеры ответствены за реализацию сервиса и публикацию его описания, запрашивающие - должны иметь способ поиска описания услуг. Итак, базовая архитектура Web-служб проявляется в выполнении трех ролей: провайдера сервиса, агенства регистрации и поиска сервиса и клиента, запрашивающего сервис. Взаимодействие включает операции декларации (публикации), поиска и связывания (bind) сервиса. Эти роли и операции являются для Web-служб артифактами (artifacts): модулями программного обеспечения и их описаниями. В типичном сценарии Web-служб провайдер сервиса содержит программные модули с сетевым доступом, реализующие сервис, он же формирует описание сервиса и его декларацию (публикацию), доступную клиенту-потребителю или агенству регистрации (service discovery agency).

Как выше уже отмечалось, основной единицей обмена в технологии Web-служб являются сообщения, имеющие структуру XML-документа. Описания сервиса используют также XML-нотацию, содержащую все необходимые детали для взаимодействия в сети, включая описание форматов сообщения, транспортных протоколов и его локализацию. Иначе говоря, формирование и транспортировка XML-сообщений подчиняются правилам и спецификациям SOAP-протокола; провайдер публикует WSDL-файл, содержащий описание семантики и синтаксиса сообщения, конечного адреса сервиса (endpoint), дающего возможность клиенту-потребителю правильно сгенерировать SOAP-сообщение и отправить его в правильном направлении. Сервис-провайдер получает это сообщение, обрабатывет содержащий в нем запрос и отсылает результат клиенту также в виде SOAP-сообщения. Технология, типичная для такого типа взаимодействия Web-служб, включает SOAP, WSDL и HTTP.

SOAP - достаточно простой, основанный на XML-механизме, способ создания структурированных пакетов данных для обменов между сетевыми приложениями. SOAP содержит четыре основные компоненты:

• конверт (envelope), определяющий рамочную структуру сообщения в формате XML,
• набор правил для представления типов данных,
• соглашение о представлении вызова удаленных процедур (в режиме RPC),
• правила совместного выполнения протоколов SOAP и HTTP. SOAP может использовать также комбинацию различных сетевых протоколов, таких как HTTP, SMTP, FTP, RMI/IIOP.

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

Определения Web-сервиса в WSDL могут транслироваться (отображаться) на многие языки, применяемые для реализаций Web-служб: Java, C++, Cobol и др.

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

Выше уже упоминалось об использовании не являющейся необходимой компоненты Web-служб, так называемого регистрационного агенства или репозитария сервиса. В репозитарий направляется (публикуется) провайдером сервиса в том или ином формате (свободном или формализованном виде) информация об этих услугах. Клиент-потребитель услуг по различным критериям может обнаруживать и исследовать их качество и количество и, после выполнения процедуры связывания (binding), непосредственно обращаться к поставщику для выполнения декларированного сервиса. Для поиска и анализа сервиса необязательно иметь вышеописанную службу. Вся необходимая информация для подключения к сервису может передаваться провайдером потребителю конфиденциальным путем в виде записок, на дискетах, либо используя сетевые средства обмена данными типа FTP или WWW [5,6] и т. д. Консорциум W3C не занимается выработкой рекомендаций (стандартов) для информационного обслуживани поставщиков (провайдеров) сервисов. Для этого существуют уже зарекомендовавшие себя в электронном бизнесе системы типа ebXML или UDDI.

1. UDDI (Universal Description, Discovery and Integration) [7] представляет собой средство регистрации вычислительных или коммерческих услуг в формализованном XML-формате. UDDI можно рассматривать как логическую структуру, имеющую общепринятую стандартную классификацию:

• Желтые Страницы, в которых регистрируются под различными категориями деловые предложения и услуги.
• Белые Страницы, которые содержат контактную информацию.
• Зеленые Страницы, содержащие в основном технические детали для обращения к сервису.

UDDI предоставляет свои услуги также в формате Web-служб, и к нему можно обращаться за полученим сервиса стандартными средствами, напрмер SOAP-сообщениями. Ниже приводится фрагмент программы pingUDDI.java, с подготовкой SOAP-запроса с задаваемым ключевым словом в переменной keyWord:

. . . . . . . . . . . . . . . . . . . . . . . . . .

String keyWord = “Microsoft”;

SOAPConnectionFactory scf = SOAPConnectionFactory.newInstance();

SOAPConnection connection = scf.createConnection();

MessageFactory msgFactory = MessageFactory.newInstance();

// Create a message

SOAPMessage msg = msgFactory.createMessage();

SOAPEnvelope envelope = msg.getSOAPPart().getEnvelope();

SOAPBody body = envelope.getBody();

SOAPBodyElement findBusiness = body.addBodyElement(envelope.

createName("find_business", "", "urn:uddi-org:api"));

findBusiness.addAttribute(envelope.createName("generic"), "1.0");

findBusiness.addAttribute(envelope.createName("maxRows"), "100");

SOAPElement businessName = findBusiness.addChildElement(

envelope.createName("name"));

URLEndpoint endpoint

= new URLEndpoint(System.getProperties().getProperty("URL"));

msg.saveChanges();

SOAPMessage reply = connection.call(msg, endpoint);

System.out.println("Received reply from: " + endpoint);

reply.writeTo(System.out);

. . . . . . . . . . . . . . . . . . . . . .

Существует ряд открытых для пользователей UDDI-серверов, как промышленного использования (UBR, UDDI Business Registry), так и для исследовательских целей (тестирования):

• SAP UDDI Test Business Registry (http://udditest.sap.com/);
• IBM UBR Node (http://uddi.ibm.com/);
• Microsoft UBR Node (http://uddi.microsoft.com/);
• Microsoft Test Node (http://test.uddi.microsoft.com/);
• и другие (http://www.uddi.org/solutions.html).

2. ebXML [8], в основном предназначеный для электронного бизнеса, также предоставляет средства регистрации, поиска и анализа сервисных услуг в форматах CPP (Collaboration-Protocol Profile) и CPA (Collaboration-Protocol Agreement) в XML-представлениях. В отличие от UDDI, где информация строго структурирована и формализована, т.е. содержит только метаданные о сервисе, ebXML допускает включение в регистрацию кроме метаданных и дополнительную информацию произвольной структуры. Простой пример: файл WSDL, столь необходимый для клиента-потребителя сервиса, не может включаться непосредственно в UDDI-описания (здесь возможна лишь ссылка на этот файл на стороне провайдера услуг), ebXML допускает включение в регистрацию любых технических деталей, касающихся декларируемого сервиса.

3. JAXR (Java API for XML Registries) [9] – является составной частью свободно распространяемого пакета JWSDP компании Sun, в котором реализована поддержка Web-служб. Надо подчеркнуть особенности этой службы регистрации:

• пользователь может самостоятельно устанавливать сервер регистрации JAXR и соответствующую базу данных;
• информационная модель JAXR основана на RIM-модели регистрирующей системы ebXML (RIM, Registry Information Model) с расширенной поддержкой UDDI. Таким образом, JAXR является совместимым с обеими моделями UDDI и ebXML. Надо отметить, что в редакции 1.0 пакета JWSDP реализована только UDDI-поддержка.

Рис. 3. Архитектура верхнего уровня JAXR.

Обмен данными между клиентом-потребителем и провайдером – поставщиком услуг –это передача SOAP-сообщений. Протокол SOAP предлагает способ формирования сообщений в XML-формате, основанный на объектной модели XML-документа DOM (Document Object Model). SOAP-сообщения – это иерархическая структура вложенных XML-элементов (или узлов): SOAPMessage, SOAPPart, SOAPEnvelope, SOAPHeader, SOAPBody и содержимое передаваемого сообщения, также в формате XML (XML content). На рисунке. 4 представлена иерархическая структура SOAP-сообщения.

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

• передача данных (запрос и ответ) в формате SOAP-сообщений. Причем, формирование XML-структуры сообщения, его кодирование и обработка результата выполняются “вручную” прикладными программистами с использованием объектной модели DOM и SOAP-протокола.
• использование механизма вызова удаленных процедур RPC (Remote Procedure Call) для передачи данных и получения результатов в обращениях к подпрограммам серверного объекта. Здесь важную роль играет умение пользоваться опиcаниями интерфейсов удаленного объекта в WSDL.

Рис. 4. Иерархическая структура SOAP-сообщения.

Сообщения могут передаваться в синхронном или асинхронном режиме. В синхронном режиме (request-response messaging) передающий процесс блокируется на время ожидания ответа, который также должен соответствовать SOAP-стандарту. В асинхронном режиме (one-way messaging) для передач сообщений используются посредники (провайдеры). На время обменов передающий процесс не блокируется, но время возврата результата – непредсказуемо. Управление типами сообщений выполняется выбором соединения клиента и провайдера (объектов SOAPConnection или ProviderConnection). Для передачи синхронных сообщений используется метод call() объекта SOAPConnection, параметром которого является структура, представляющая объектную модель SOAP-сообщения, а результатом выполнения запроса – также SOAP-сообщение в формате DOM. Для передачи асинхронных запросов используется объект ProviderConnection и его метод send().

В приведенном выше фрагменте программы для обращения к UDDI-серверу показана типичная последовательность выполнения SOAP-запроса, вот некоторые из операций:

SOAPConnectionFactory scf = SOAPConnectionFactory.newInstance();

SOAPConnection connection = scf.createConnection();

SOAPMessage msg = msgFactory.createMessage();

SOAPEnvelope envelope = msg.getSOAPPart().getEnvelope();

SOAPBody body = envelope.getBody();

Затем выполняется последовательность операторов для создания запроса в виде XML-объекта, который включается в элемент типа SOAPBody.

SOAPMessage reply = connection.call(msg, endpoint);

reply.writeTo(System.out);

Режим RPC во многом напоминает технологии обмена данными, используемые в объектных распределенных системах типа RMI и OMG CORBA. Основные моменты развертывания RPC:

• разработка интерфейса удаленного сервисного объекта (формальное описание методов объекта, типа параметров и результата), реализующего вычислительный сервис (Web Service);
• кодирование методов сервисного объекта (implemention);
• создание описания методов объекта в WSDL-документе;
• декларация WSDL-документа;
• обработка (поиск и анализ) клиентской программой WSDL-документа;
• связывание (binding) - подключение к серверу (провайдеру сервиса);
• формирование объектной ссылки для методов сервисного объекта;
• обращение к методам сервиса и получение результатов вычислений.

Надо отметить два существенных момента использования RPC:

• поскольку единственным форматом передач данных в технологии Web-служб являются SOAP-сообщения, поэтому серьезной проблемой является конвертирование всех вызовов процедур и их данных в стандартный формат, принятый в SOAP, т.е. в XML-структуру. Это же обстоятельство и позволяет обеспечить реальную совместимость всех участвующих во взаимодействиях компонент распределенной системы, независимо от применяемых поставщиками услуг и/или клиентами-потребителями языков программирования, операционных систем и т.д.
• взаимное конвертирование SOAP-сообщений и RPC-запросов выполняют специальные программы – представители противоположной стороны или суррогаты. На стороне клиента они называются стабами (stubs), а в серверной программе для Web-служб они называются tie. Эти программы-посредники генерируются автоматически при подготовке и развертывании клиентских и серверных компонент Web-служб. Уровень знания их и применения прикладным программистом зависит от конкретной программной реализации Web-службы компанией-производителем.

На рисунке 5 представлена диаграмма прохождения и конвертирования RPC-запросов.

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

применение на всех уровнях предложенной технологии XML-представления структур данных, форматов передаваемых сообщений, интерфейсов взаимодействия распределенных компонент. С другой стороны, основные компоненты и протоколы Web Services – это уже зарекоменовавшие себя в других областях применения технологии: SOAP, WSDL, UDDI, ebXML и HTTP/SMTP. В немалой степени это сближение позиций фирм-производителей является следствием давления рынка электронного бизнеса.

Надо отметить также и то обстоятельство, что существует стремление использовать предложенную Web Services совместимость и для решения так называемых “решеточных” задач или GRID-технологий [11], получивших, в частности, широкое применение в задачах физики высоких энергий [12].

Рис. 5. Диаграмма преобразований RPC-вызовов в SOAP-сообщения.

1. W3C Consortium. http://www.w3c.org/.
2. SOAP Version 1.2 Part 1: Messaging Framework. http://www.w3c.org/TR/soap12-part1/.
3. SOAP Version 1.2 Part 2: Adjuncts. http://www.w3c.org/TR/soap12-part2/.
4. Web Services Description Language (WSDL) Version 1.2. W3C Working Draft 3 March 2003. http://www.w3.org/TR/wsdl12.
5. XMethods Utility Services. http://www.xmethods.net/.
6. DS Data Systems and Web Services. http://www.dsdata.co.uk/WS/.
7. http://www.uddi.org/.
8. http://www.ebxml.org.
9. Introduction to Web Services. http://java.sun.com/webservices/docs/1.1/tutorial/doc/IntroWS.html#wp70565.
10. Document Object Model. http://www.w3.org/DOM/.
11. Доменико Т.. OGSA: где GRID встречается с Web, “Открытые системы”, № 1, изд-во “Открытые системы”, Москва, 2003, с. 47.
12. Ильин В., Кореньков В., Солдатов А. Российский сегмент глобальной инфраструктуры LCG, “Открытые системы”, № 1, изд-во “Открытые системы “, Москва, 2003, с. 56.