 | Уровень сложности: средний Джулиан Робиччо, разработчик,
консультант
20.04.2007 В первой из трёх частей мы обсудим терминологию и принципы работы Web-сервисов, а также пользу, которую они приносят профессионалу в сфере IT. В этой статье мы не будем касаться Lotus Domino, однако данного обзора достаточно для начала работы с Web-сервисами.
Возможно, вы встречались с упоминаниями о Web-сервисах в технических статьях, описаниях программных продуктов или даже в диалогах с сослуживцами. Видно, кому-то Web-сервисы нужны и важны, однако, повстречавшись с определениями вроде "Грамматика XML для определения наборов конечных точек для обмена сообщениями," вы решили, что такие сложные вещи и трогать не стоит.
К счастью, Web-сервисы можно разъяснить и так, чтобы поняли все, при этом не вникая в подробности того, как всё это работает. Вам стоит попробовать разобраться, что такое Web-сервисы, поскольку область их (а также имеющей к ним отношение сервис-ориентированной архитектуры, SOA) применения в мире IT постоянно расширяется.
Web-сервисы можно воспринимать как автомобиль: вам не надо знать на техническом уровне, как работают поршни, распредвалы и топливные инжекторы - вы и без этого можете купить автомобиль, управлять им и разговаривать о машинах с друзьями (если они, конечно, не механики). То же и с Web-сервисами, вам как специалисту IT достаточно просто разобраться, что это такое и как они работают, чтобы понять, зачем они вам нужны.
Сейчас стало намного легче работать с Web-сервисами, не затрагивая скрытых низкоуровневых технологий, поскольку производители ПО и сообщество тех, кто пишет программы с открытым кодом, за последние несколько лет немало сделали для отделения интерфейса Web-сервисов от задач низкого уровня. Это позволит вам работать, просто соединяя между собой компоненты, не углубляясь в пространную документацию о форматировании XML-сообщений.
Эта серия статей поможет разработчикам Domino понять и использовать Web-сервисы в IBM Lotus Domino V7.0. Эта вступительная статья содержит достаточно полезной информации, и пригодится любому желающему понять, что же такое Web-сервисы. Технологии в Lotus Domino V7.0 позволяют разработчикам легко создавать и использовать Web-сервисы, и позже мы детально коснёмся этого.
Вначале давайте разберёмся, что такое Web-сервис.
Что такое Web-сервис?
Говоря просто, Web-сервис позволяет компьютерным программам стандартизированно общаться между собой.
|
Связь между тремя и более машинами
Хотя в примерах мы рассматриваем транзакции в пределах одной или двух машин, Web-сервисы могут использоваться и для коммуникаций между большим количеством компьютеров. Например, перенаправление или хранение транзакций может осуществляться промежуточным устройством, или обращение к Web-сервису на одном сервере может порождать обращение к сервису на другом.
В конце этой статьи, рассматривая настоящую SOA, мы будем говорить о взаимодействии Web-сервисов через несколько машин, поскольку именно так в SOA всегда и бывает.
|
|
Web-сервис является абстрактным компонентом - равно как абстрактна концепция диалога между людьми. В диалоге участвуют двое и более людей, разговаривающих на известном им языке. В их языке определены используемые ими слова и то, как из этих слов складывать предложения. Обычно диалог имеет структуру вопрос-ответ, когда некто задаёт вопрос или высказывает утверждение, а собеседник отвечает на него. Люди могут находиться рядом, общаться по телефону, посылать друг другу сообщения по почте или в чате.
В любом случае, диалог имеет сложную структуру и может проходить по-разному, в зависимости от количества общающихся, языка общения используемых для общения технологий, конечно, если таковые используются.
В структуру коммуникаций с использованием Web-сервисов включены многие элементы, которых мы коснёмся в этой статье. Однако идея остаётся той же, что и у обычного диалога - программы общаются, используя знакомый им язык, иногда по сети. Программы могут как находиться на одном компьютере, так и размещаться на разных машинах в разных точках земного шара, соединённые через интернет маршрутизаторами и серверами. Хорошо то, что программам и компьютерам не обязательно быть одинаковыми. Благодаря Web-сервисам переговариваться могут как две программы Microsoft .NET на одном ноутбуке, так и программа Java на канадском сервере iSeries с программой C++ на компьютере с ОС Linux из Китая.
В коммуникациях посредством Web-сервисов используются следующие стандартные технологии:
-
XML. Язык (формат данных), используемый компонентами Web-сервисов.
-
Протокол SOAP. Сообщения XML, которыми обмениваются программы
-
Библиотека описаний Web-сервисов (WSDL). Файл XML, в котором определены формат сообщений SOAP и то, как их посылать
Для осуществления связи между Web-сервисами также может использоваться стандартная технология, известная как Universal Description, Discovery, and Integration (UDDI). Мы рассмотрим это далее в статье, однако поскольку использование UDDI не обязательно, многие Web-сервисы её не используют.
Немного терминологии: публикация и использование Web-сервисов
Прежде чем заняться разъяснением наших терминов, давайте рассмотрим часть связанной с Web-сервисами терминологии.
Когда мы говорим о публикации Web-сервиса, имеется в виду программа, публикующая файл WSDL и позволяющая иным программам пользоваться соответствующей службой. Программы, публикующие Web-сервисы, называются провайдерами.
Говоря об использовании Web-сервиса, мы имеем ввиду программу, отправляющую вызов к Web-сервису на другой машине. Пользователи Web-сервисов называются клиентами.
XML: родной язык
Язык XML используется для общения между компонентами Web-сервисов. Сообщения, пересылаемые между приложениями, равно как определяющие Web-сервис файлы, имеют формат XML. На рисунке 1 показана структура простого файла XML.
Рисунок 1. Базовая структура XML
Как видите, некоторая информация в файле (такая как имя, фамилия) окружена тегами, заключёнными в треугольные скобки. Имя John показано как <firstname>John</firstname>. Ещё есть элементы, в которые вложены другие элементы, например в элемент <person> вложены элементы <firstname>, <lastname> и <birthday>.
Написание Web-сервисов языком XML даёт немалые преимущества, включая:
- Структура и грамматика XML аналогична структуре остальных языков программирования, поэтому взаимодействующим с Web-сервисами программам нет надобности проводить структурный анализ файлов XML напрямую.
- Файлы XML текстовые, и их может прочитать человек (иными словами, зная язык XML, вы можете открыть файл XML в текстовом редакторе и понять его содержимое). Это может помочь при отладке.
- XML позволяет использовать в сообщениях любую стандартную кодировку, поэтому сообщения вы можете писать как на английском, так и на русском или японском языках.
- XML позволяет вам пользоваться так называемым пространством имен, в котором вы можете предопределить желаемую структуру файлового элемента с определённым именем. Например, вы можете определить элемент Price, который всегда должен быть числом с плавающей точкой, или PersonName, включающий в себя два строковых подэлемента FirstName и LastName.
Кроме того, при необходимости пространства имен позволяют нескольким элементам с одинаковыми именами иметь разные определения. Например, элемент StockPrice в одном пространстве имен может включать в себя тикерный символ и цену, а в другом пространстве имен может состоять из тикерного символа, цены, дневных минимума и максимума и 12-месячного максимума.
Единственными недостатками XML, если это и в самом деле недостатки, являются:
- Язык XML жёсткий, поэтому любое неправильное форматирование сообщения XML приводит к сбою анализа всего сообщения (даже если проблему легко интерпретировать или пропустить). Однако если вы используете стандартную библиотеку для генерации файлов XML (что и делается при создании Web-сервисов), библиотека сама проверяет правильность форматирования.
- Сообщение XML хранится в обычном текстовом файле, а потому занимает больше места, чем его эквивалент в другом формате (в таких как разделённый, двоичный или "самодельный" формат).
Но эти проблемы не имеют значения по сравнению с преимуществами формата XML.
SOAP: отправляемые сообщения
Вы знаете, что общение Web-сервисов ведётся в формате XML, однако это решает лишь половину проблемы. Приложения могут разобрать сообщение, однако откуда им знать, что делать с полученным после анализа результатом?
Инструкция, описывающая правила форматирования сообщений XML для Web-сервисов известна как SOAP. В ней определена структура сообщений, благодаря чему программы знают, как отправлять и интерпретировать данные. Базовая структура сообщения SOAP показана на рисунке 2.
Рисунок 2. Базовая структура сообщения SOAP
На языке XML это будет выглядеть приблизительно так:
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<ns1:GetStockInfo xmlns:ns1="urn:thisNamespace">
<symbol>FOO</symbol>
</ns1:GetStockInfo>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
|
В базовом случае у вас есть пакет SOAP, включающий в себя тело SOAP и тело, в котором находятся передаваемые данные. Иногда ещё есть необязательный заголовок SOAP (внутри пакета перед телом), содержащий дополнительную информацию.
|
Инструкции SOAP
Хотя формат SOAP стандартен и имеет одинаковые инструкции, необходимо помнить что разные производители могут немного по разному воплощать эти инструкции. Например, структура именных пространств и XML в сообщении SOAP, сгенерированном Apache Axis может сильно отличаться от структуры, сгенерированной Microsoft .NET. Однако правильно написанный клиент или сервер может обработать любое правильно написанное в соответствии с инструкциями SOAP сообщение.
Кроме того, инструкции SOAP 1.1
и SOAP 1.2 порой сильно различаются, поэтому клиент или сервер, понимающий SOAP 1.1 может не понять сообщения SOAP 1.2.
|
|
На случай проблем в теле SOAP содержится информация об ошибке в форме SOAP Fault. Fault - это структура XML, содержащая описание ошибки, например:
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Server</faultcode>
<faultstring>Server Error</faultstring>
<detail>Database not available</detail>
</SOAP-ENV:Fault>
|
Хотя сообщение SOAP и хранится в текстовом виде в формате XML, из-за специфичности определений пространств имен и свойств элементов его порой бывает непросто понять или интерпретировать вручную. К счастью, программ и библиотек, способных создать или интерпретировать вам сообщение SOAP, много, и они берут на себя большую часть сложностей. Инструменты могут сделать за нас сложную работу.
WSDL: определение Web-сервисов
Каждая программа, публикующая Web-сервисы, в файле WSDL описывает доступные службы и правила их вызова. Формат WSDL тоже основан на XML и имеет определённую понятную приложениям структуру. WSDL часто произносится как "Whiz-dull."
В сердце файла WSDL провайдером определены методы, которыми могут пользоваться другие программы. Например, у Web-сервиса может быть метод под названием GetTemperature, возвращающий температуру в определённом городе. В файле WSDL описан этот метод со следующей информацией:
- Имя, по которому обращаются к методу (в данном случае - GetTemperature)
- Необходимые параметры в запросе, если таковые есть (определяются имена и типы данных параметров)
- Формат возвращаемого значения или значений, на случай успешной обработки запроса (опять-таки, имена и типы данных)
- Ссылка URL и протокол, по которым следует вызывать метод
Также в файле есть информация о таких правилах форматирования сообщений SOAP, как используемые пространства имен, порядок и структура параметров, и даже о дополнительной информации, которую необходимо включить в заголовок SOAP или HTTP.
|
Инструкции WSDL
Как и в SOAP, в WSDL есть стандартные требования, которые можно воплотить по-разному. В частности, есть много регулярно используемых стилей ("styles") WSDL, таких как RPC/Encoded и Document/Literal. Замечательный ресурс, где описаны различия между типами WSDL - статья на developerWorks, "Какой стиль WSDL мне использовать?"
Кроме того, в инструкциях WSDL 1.1 и
WSDL 2.0 есть некоторые важные различия. Хотя инструкция 2.0 на момент написания статьи ещё только на этапе завершения, вскоре она начнёт занимать место версии 1.1.
|
|
если вы никогда раньше не сталкивались с файлами WSDL и пытаетесь открыть такой и прочесть, вам будет непросто добыть оттуда всю информацию, поскольку структура такого файла может быть довольно сложной. Вся информация о методе (имя, параметры, протокол, и.т.п.) раскидана по разным секциям файла, и для конструирования сообщения SOAP она должна быть собрана клиентским приложением. Описания частей файла WSDL и их совместной работы в этой статье не будет.
Здесь технологии снова приходят нам на помощь. Вам как разработчику нет нужды читать, анализировать и понимать содержимое файла WSDL. Эту информацию для вас достанут инструменты, так что вам надо лишь придумать что отправить службе, и куда девать полученные результаты. Вы не только можете использовать библиотеки и инструменты, но и наверняка будете. Во всех компонентах Web-сервисов есть немало исключений, закавык и сложностей, и вам стоит заняться использованием Web-сервиса, а не её разборкой с последующим детальным исследованием каждого компонента.
Протоколы: как отправляются сообщения
Мы ещё не касались вопроса, как же передаются все эти сообщения по SOAP?
А передаются они обычно по сети (и/или интернет) по протоколу HTTP, почти так же, как и страницы передаются с сервера на ваш браузер. HTTP используется не всегда (его главный конкурент - SMTP, однако он далеко позади). Используемый Web-сервисом протокол определён в файле WSDL.
Обычно в файле WSDL протокол, используемый для передачи сообщения SOAP, определён как HTTP. Клиент SOAP отправляет сообщения в соответствии с указанным протоколом.
Другие термины из области Web-сервисов, с которыми вы можете столкнуться
Мы уже разобрались с основными терминами, однако в разговоре о Web-сервисах вы можете услышать ещё некоторые.
Слабые связи
Использующие Web-сервисы программы обычно имеют слабые связи с сервисами, то есть необходимые для работы программы сервисы не привязаны к ней напрямую, равно как и программа не привязана к сервисам. Программа может запросто использовать любые необходимые ей сервисы, а они ждут вызова от программы - от любой программы, которой нужен их ответ.
Жизненный пример слабых связей - это обед с друзьями. Несколько друзей как-то договариваются между собой (лично, по телефону, через электронную почту и т.д.). Каждый самостоятельно добирается до ресторана, и после обеда каждый сам оплачивает свою еду. Независимо от того как прошёл обед, конечный результат неизменен - это был дружеский обед.
А вот вождение машины - это действие с более жёсткими связями. У вас есть фиксированный набор инструментов, с помощью которого необходимо достичь предопределённых целей. Выезжая из гаража, вы включаете заднюю передачу и давите на газ. Поворачивая налево, вы поворачиваете налево руль. У вас нет возможности сделать одно и то же разными путями, поскольку вся система очень точная и слаженная, и каждый её элемент связан с другими.
UDDI
UDDI - это стандарт для создания каталога Web-сервисов, поставляемых любым количеством программ. Это нечто вроде телефонной книги поставщиков Web-сервисов. Клиенты могут искать необходимую им информацию в реестре UDDI, а реестр возвращает им необходимые данные для подключения к сервису.
Хотя UDDI и довольно важный стандарт для определения Web-сервисов, его значительность сильно уменьшена за счёт того, что он является необязательным элементом Web-сервисов, а когда есть выбор, использовать или нет, многие решают не использовать.
Большинство организованных корпоративных сред с большим количеством внутренних Web-сервисов имеют реестры UDDI. Замечательно, когда есть корпоративный сайт UDDI, содержащий информацию о доступных в вашей компании Web-сервисах. Собирая вместе все сервисы, UDDI позволяет без проблем и незаметно менять их поставщиков. Если клиенты ищут сервисы через UDDI, то вызовы SOAP автоматически отправляются к новому поставщику.
Однако этот компонент не обязателен в архитектуре Web-сервисов.
Безопасность Web-сервисов
Читая про SOAP и WSDL, вы можете заметить, что не раскрыта тема безопасности. Как проводится аутентификация при вызовах сервисов, если поставщик работает с закрытой информацией? Ведь понятно, что не все Web-сервисы доступны широкой публике, не так ли?
Это важный вопрос, однозначно ответить на который непросто. Есть различные схемы, которые вы можете использовать, смотря по ситуации, например:
- Могут ли сообщения SOAP приходить в виде текста или они должны быть зашифрованы?
- Достаточно ли вам простой аутентификации по логину и паролю или же она должна быть устойчивой и маркерной?
- Если используются маркеры, необходимы ли на них подписи, и как правильно их включить в сообщение SOAP?
- А что если клиент отправляет сообщения SOAP не напрямую, а через какую-то промежуточную структуру, такую как очередь сообщений или через ещё какой-нибудь Web-сервис?
Кроме того, при обмене сообщениями не всегда может использоваться HTTP, поэтому у вас не выйдет попросту использовать системы безопасности Web-сервисов в дополнение к существующим системам безопасности HTTP.
Есть несколько инструкций, которые охватывают эти и прочие аспекты безопасности Web-сервисов: WS-Security, WS-Policy, WS-Trust и WS-Privacy. Некоторые производители ПО и комитеты работают над этими вопросами уже несколько лет. Хотя не все варианты реализации Web-сервисов поддерживают все инструкции безопасности, однако в имеющихся стандартах безопасности обычно реализовано хотя бы несколько основных путей обеспечения безопасности.
Промежуточное ПО и Enterprise Service Bus
Есть ещё один немаленький набор стандартов для Web-сервисов, собранных вместе в один довольно большой комок, которые обычно называются инструкциями WS-*. Вместе они затрагивают много проектировочных моментов, которые возникают, когда вы собираете много Web-сервисов в одну среду. Стандарты WS-* касаются таких вопросов, как:
- Безопасность
- Надёжность
- Обмен сообщениями
- Транзакции
- Качество обслуживания
Такое количество стандартов необходимо, потому что обмен сообщениями между клиентом Web-сервиса и сервером в промышленной среде может быть намного сложнее, чем просто запрос/ответ. Например, как убедиться, что сообщение дошло до поставщика и вернулось к клиенту? Что если запрос SOAP состоит из нескольких частей? Как управлять процессами, в которых участвуют Web-сервисы, обращающиеся к другим Web-сервисам? Что если программа посылает последовательность запросов с требованиями по срокам реагирования?
Для крупных производителей ПО работа с этими стандартами предоставляет как сложности, так и возможности. Некоторые производители представляют на рынке целые пакеты промежуточного ПО для работы с Web-сервисами, часто называемые Enterprise Service Bus, или ESB, которые позволяют разобраться сразу со всеми или по крайней мере некоторыми из вышеупомянутых задач. Эти ESB ценны ещё и потому, что могут связать вместе несколько Web-сервисов в рамках одной организации и обеспечить их функциональность, запись их действий и хранение сообщений в очередях.
Сервис-ориентированная архитектура
И наконец сервис-ориентированная архитектура. В большинстве случаев это просто комбинация всего вышеописанного: слабо связанные Web-сервисы от разных поставщиков, взаимодействующие в соответствии с принятыми стандартами (возможно и с участием ESB) и собранные вместе разными программами, берущими у сервисов данные и по-разному их использующими.
Поскольку SOA - программная архитектура, то с её построением связаны огромные работы по координированию и планированию. Это не просто кучка перемешанных вместе сервисов; это организация того, как сервисы собираются вместе и публикуются, какие управляющие инструменты и промежуточное ПО используются, и как ведётся наблюдение и управление сервисами и всей системой в целом.
Если смотреть глобальнее, то SOA - это ещё и тип мышления. Оно заставляет думать не о независимо работающих больших программах, а воспринимать всё в качестве возможных публикуемых и используемых на производстве компонентов. Вместо многофункциональных приложений вы думаете о специфических и чётко определённых сервисах - каковыми и являются Web-сервисы.
Почему это важно?
Теперь вы уже что-то знаете о том, как работают Web-сервисы - клиент читает файл WSDL поставщика, в соответствии с ним форматирует и отправляет сообщение SOAP и получает другое сообщение SOAP в ответ. Так почему ж это так важно? В чём дело?
Частично важность сервисов заключена в том, что они предоставляют стандартный путь для общения между программами, вне зависимости от языков, на которых они написаны и платформ, на которых они работают. Ранее нам приходилось работать с форматами данных, уникальными для разных программ, или же с функциями API-уровня, с которыми не могли работать программы на других языках. Из использования XML во всех стандартах Web-сервисов означает, что все сервисы доступны и понятно определены.
Фактически, это позволяет совсем разным программам легко общаться друг с другом на понятном им всем языке. Одной из главных сложностей при работе с разными технологиями от разных производителей всегда была необходимость заставить все эти разные программы общаться между собой и обмениваться данными. Теперь, когда все ваши приложения могут поставлять и/или использовать Web-сервисы, налаживать взаимодействие между ними невероятно упростилось.
Ещё одним преимуществом Web-сервисов является то, что клиенты и поставщики могут находиться на разных машинах, пользоваться разными аппаратными и программными средствами, и общению это не мешает. Программы могут использоваться другими программами в рамках одной машины, или с других машин, но с использованием определённого формата передачи данных. Web-сервисам нужны только подключение к сети и обработчик XML.
Если все эти факторы учитывать вместе, результат получается значительным. Раз у нас есть стандартное средство для общения между приложениями по сети, мы можем по-другому строить и свои программы. Вместо написания монолитных программ, в которых каждый раз заново изобретается колесо, мы можем писать программы, состоящие из модулей.
Например, вместо большой программы, собирающей информацию о нескольких процессах, превращающей её в графики и показывающей их пользователям мы можем создать инструментальную панель, которая будет отображать полученные от нескольких Web-сервисов данные. Скомпилированные данные получаются от одной или нескольких сервисов, а получаемые в результате графики создаются ещё одним Web-сервисовом, принимающим данные и выдающим некоторый график.
Инструментальная панель превращается из большой программы в простой интерфейс. Желая добавить новые компоненты, мы просто обращаемся к дополнительным сервисам. Если нам нужен другой график, мы обращаемся к другому строящему графики сервису. Если нам нужна более интерактивная инструментальная панель, с возможностью обучения или сортировки, то панель может передавать сообщения от пользователя соответствующим сервисом. Мы можем даже полностью поменять вызываемые сервисы так, что пользователи этого и не заметят (пока не будет меняться файл WSDL), и панель останется прежней.
Будучи профессионалом в сфере IT вы можете заниматься как разработкой интерфейса, так и сервисов, или и тем и другим. Понимание того, как всё это работает вместе (или хотя бы знание, что это такое) важно для работы в подобном проекте.
Также хорошо, что есть много инструментов, котлорые помогут вам поставлять и использовать Web-сервисы и могут сделать за вас много тяжёлой работы. В последующих частях статьи мы разберёмся, как с использованием IBM Lotus Domino V7.0 вы сможете легко поставлять Web-сервисы клиентам или системам.
Ресурсы Научиться
Получить продукты и технологии
Обсудить
Об авторе | | | Джулиан Робиччо (Julian Robichaux) работает разработчиком ПО, он профессиональный программист, специализирующийся в области IBM Lotus Notes и разработчик Java. Его можно нанять для работы как в небольших, так и в крупных проектах в области разработки, проектирования и обучения. В свободное время он пишет свой личный сайт http://www.nsftools.com. Его семья не понимает, зачем он везде таскает за собой ноутбук. Он, впрочем, тоже. |
Выскажите мнение об этой странице
| |
