Веб-службы XML — это основные строительные блоки для распределенных вычислений в Интернете. Открытые стандарты и ориентация на общение и сотрудничество между пользователями и приложениями создали среду, в которой веб-службы XML становятся платформой для интеграции приложений. Приложения создаются с использованием веб-служб XML из нескольких разных источников, которые работают вместе независимо от того, где они расположены и как они реализованы.
Существует столько же определений веб-служб XML, сколько компаний, создающих веб-службы XML. Но почти все определения имеют следующее общее:
Веб-службы XML предоставляют полезные функции веб-пользователям через стандартные веб-протоколы. В большинстве случаев используется протокол SOAP.
Веб-службы XML могут детально определять свои интерфейсы, что позволяет пользователям создавать клиентские приложения для взаимодействия с ними. Это описание обычно содержится в XML-документе, называемом документом языка описания веб-служб (WSDL).
Веб-службы XML регистрируются, чтобы потенциальные пользователи могли легко их найти, что достигается посредством универсального обнаружения, описания и интеграции (UDDI).
В этой статье будут представлены эти три технологии, но сначала нам нужно объяснить, почему вам следует обратить внимание на веб-службы XML.
Одним из основных преимуществ архитектуры XML Web Services является то, что она позволяет множеству программ, написанных на разных языках и на разных платформах, взаимодействовать друг с другом на основе стандартов. Пользователи, которые что-то знают об этой отрасли, могут сразу же сказать: «Подождите, разве CORBA и предыдущая версия DCE не взяли на себя одинаковые обязательства? В чем разница между ней и ними? Самое важное отличие: SOAP лучше, чем раньше?» Этот подход намного проще, поэтому существует гораздо меньше препятствий для внедрения протокола SOAP, соответствующего стандартам. Пол Кульченко предоставляет список реализаций SOAP по адресу http://www.soapware.org/directory/4/implementations (на английском языке). По последним подсчетам, в списке было 79 пунктов. Как и следовало ожидать, большинство крупных компаний-разработчиков программного обеспечения предоставляют реализации SOAP, но существует также множество реализаций, созданных и поддерживаемых отдельными разработчиками. Еще одним важным преимуществом веб-служб XML по сравнению с предыдущими решениями является использование стандартных веб-протоколов — XML, HTTP и TCP/IP. Многие компании уже создали веб-инфраструктуру, а их сотрудники обладают знаниями и опытом для ее обслуживания. Таким образом, стоимость внедрения веб-служб XML намного ниже, чем стоимость внедрения предыдущих технологий.
Мы определяем веб-службу XML как программную службу, предоставляемую в Интернете через SOAP, описываемую с помощью файла WSDL и зарегистрированную через UDDI. Итак, вы можете спросить: «Что можно делать с помощью веб-служб XML?» Исходные веб-службы XML часто были источниками информации, которую можно было легко включить в приложения, например курсы акций, прогнозы погоды, спортивные результаты и т. д. Легко представить себе целый класс приложений, которые можно было бы создать для анализа и обобщения интересующей вас информации и сделать эту информацию доступной различными способами. Например, вы можете использовать электронную таблицу Microsoft® Excel для обобщения всех ваших финансовых данных; информация — акции, 401К, банковские депозиты, кредиты и т. д. Если эта информация доступна через веб-службы XML, Excel может постоянно ее обновлять. Часть этой информации бесплатна, а на часть может потребоваться подписка для получения соответствующей услуги. Большая часть этой информации уже доступна в Интернете, но веб-службы XML могут сделать программный доступ более простым и надежным.
Существующие приложения доступны в виде веб-служб XML, а новые, более мощные приложения могут быть созданы с использованием веб-служб XML в качестве строительных блоков. Например, пользователь может разработать приложение для закупок, чтобы автоматически получать информацию о ценах от разных поставщиков, позволяя пользователю выбирать поставщика, отправлять заказ, а затем отслеживать отгрузку товаров до тех пор, пока товары не будут получены. Помимо предоставления услуг через Интернет, приложение поставщика также может использовать веб-службу XML для проверки кредитоспособности клиента, сбора платежей и управления процедурами перевозки грузов в транспортных компаниях.
В будущем некоторые из наиболее интересных приложений на основе веб-служб XML смогут использовать Интернет для выполнения задач, которые в настоящее время невозможны. Например, служба календаря — это одна из служб, которая будет поддерживаться проектом Microsoft .NET My Services (английская версия). Если ваши стоматологи и механики предоставляют свои расписания через эту веб-службу XML, вы можете, если хотите, назначать им встречи через Интернет; они также могут планировать даты чисток и планового технического обслуживания непосредственно в вашем календаре; Легко представить, что если бы вы умели программировать Интернет, вы могли бы создавать сотни приложений.
Дополнительные сведения о веб-службах XML и приложениях, которые вы можете создавать, см. на домашней странице веб-служб MSDN (английская версия).
SOAP
SOAP — это протокол связи веб-службы XML. Описывая SOAP как протокол связи, большинство людей думают о DCOM или CORBA и задают такие вопросы, как «Как SOAP активирует объекты» или «Какую службу именования использует SOAP?» Хотя реализации SOAP могут включать эти элементы, они не определены стандартом SOAP. SOAP Спецификация, определяющая формат сообщений XML. Это обязательная часть спецификации. Правильно сформированный сегмент XML, содержащийся в паре элементов SOAP, представляет собой сообщение SOAP. Разве это не просто?
Другие части спецификации SOAP описывают, как представлять данные программы в формате XML и как использовать SOAP для удаленных вызовов процедур (RPC). Эти необязательные части спецификации используются для реализации приложений в стиле RPC, где клиент выдает сообщение SOAP (содержащее вызываемую функцию и параметры, которые должны быть переданы в функцию), а сервер возвращает сообщение, содержащее результаты. выполнения функции. В настоящее время большинство реализаций SOAP поддерживают приложения RPC, поскольку программисты, привыкшие к разработке приложений COM или CORBA, знакомы с форматом RPC. SOAP также поддерживает приложения в стиле документа, в которых сообщение SOAP является просто оболочкой XML-документа. Приложения SOAP на основе документов очень гибки, и многие новые веб-службы XML используют эту функцию для создания служб, которые сложно реализовать с помощью RPC.
Последняя необязательная часть спецификации SOAP определяет стиль HTTP-сообщений, содержащих сообщения SOAP. Эта привязка HTTP важна, поскольку почти все текущие ОС (и многие предыдущие ОС) поддерживают HTTP. Хотя привязка HTTP не является обязательной, она поддерживается почти всеми реализациями SOAP, поскольку это единственный стандартный протокол для SOAP. По этой причине люди часто ошибочно полагают, что SOAP должен использовать HTTP. Фактически, некоторые реализации также поддерживают транспорт MSMQ, MQ Series, SMTP или TCP/IP, но поскольку HTTP настолько распространен, почти все текущие веб-службы XML используют его. Поскольку HTTP является основным протоколом Интернета, сетевая инфраструктура большинства организаций поддерживает HTTP, и сотрудники уже знают, как им управлять. Сегодня создана инфраструктура для HTTP-безопасности, мониторинга и балансировки нагрузки.
Когда вы начинаете использовать SOAP, больше всего сбивает с толку разница между спецификацией SOAP и многочисленными ее реализациями. Большинство пользователей SOAP не пишут сообщения SOAP напрямую, а используют наборы инструментов SOAP для создания и анализа сообщений SOAP. Эти наборы инструментов обычно преобразуют вызовы функций с языка в сообщения SOAP. Например, Microsoft SOAP Toolkit 2.0 преобразует вызовы функций COM в SOAP, а Apache Toolkit преобразует вызовы функций JAVA в SOAP. Типы вызовов функций и поддерживаемые типы данных параметров различаются в зависимости от реализации SOAP, поэтому функция, которая работает для одного набора инструментов, может не работать для другого. Это ограничение не SOAP, а конкретной используемой реализации.
Безусловно, наиболее привлекательной особенностью SOAP является то, что его можно реализовать на множестве различных программных и аппаратных платформ. Это означает, что SOAP можно использовать для связи разрозненных систем внутри и за пределами предприятия. В прошлом были опробованы различные подходы для создания общего протокола связи, который можно было бы использовать для системной интеграции, но ни один из них не получил такого широкого признания, как SOAP. Почему? Потому что SOAP меньше и его проще реализовать, чем многие более ранние протоколы. Например, на внедрение DCE и CORBA ушли годы, поэтому было выпущено лишь несколько реализаций. SOAP может использовать существующие анализаторы XML и библиотеки HTTP для выполнения большей части сложной работы, поэтому внедрение SOAP может быть завершено в течение нескольких месяцев. Вот почему сейчас существует более 70 реализаций SOAP. Конечно, SOAP не обладает всеми функциями DCE или CORBA. Хотя функции и сокращены, SOAP легче применять, поскольку его сложность значительно снижается.
Популярность HTTP и простота SOAP позволяют вызывать их практически из любой среды, что делает их идеальной основой для веб-служб XML. Дополнительные сведения о SOAP см. на домашней странице MSDN SOAP (на английском языке).
Насколько это безопасно?
Часто первый вопрос, который задают пользователи, впервые знакомые с SOAP, заключается в том, как SOAP решает проблемы безопасности. На ранних стадиях разработки SOAP рассматривался как протокол, основанный на HTTP, поэтому безопасность HTTP считалась достаточной для SOAP. В конце концов, в настоящее время существуют тысячи веб-приложений, использующих HTTP-безопасность, так что для SOAP этого действительно достаточно. Таким образом, текущий стандарт SOAP предполагает, что безопасность является проблемой транспорта и не рассматривается как проблема безопасности.
По мере того как SOAP расширяется до более общего протокола и работает на многочисленных транспортах, проблемы безопасности становятся более заметными. Например, HTTP предоставляет несколько способов аутентификации пользователей, совершающих вызовы SOAP, но как эта идентичность распространяется, когда сообщения перенаправляются с HTTP на транспорт SMTP? SOAP был разработан как стандартный протокол протокола, поэтому, к счастью, существуют спецификации, обеспечивающие дополнительные функции безопасности для веб-сервисов, основанных на SOAP. Спецификация WS-Security (английская версия) определяет полную систему шифрования, а спецификация WS-License (английская версия) определяет соответствующую технологию, обеспечивающую идентификацию вызывающего абонента и гарантирующую, что только авторизованные пользователи могут использовать веб-службы.
WSDL
WSDL (язык описания веб-служб) означает язык описания веб-служб. Для целей этой статьи мы можем рассматривать файл WSDL как XML-документ, описывающий набор сообщений SOAP и способы обмена ими. Другими словами, WSDL для SOAP является тем же, чем IDL для CORBA или COM. Поскольку WSDL является документом XML, его легко читать и редактировать, но в большинстве случаев он создается и используется программным обеспечением.
Чтобы просмотреть значения WSDL, представьте, что вы хотите вызвать метод SOAP, предоставленный одним из ваших деловых партнеров. Вы можете запросить несколько примеров сообщений SOAP, а затем написать приложение для генерации и использования сообщений, подобных образцам, но при этом легко допустить ошибку. Например, вы можете увидеть идентификатор клиента 2837 и предположить, что это целое число, хотя на самом деле это строка. WSDL явно указывает, что должно содержать сообщение запроса и как должно выглядеть ответное сообщение.
Нотация, используемая файлами WSDL для описания форматов сообщений, основана на стандарте XML Schema, что означает, что она не зависит от языка программирования и основана на стандартах, что делает ее подходящей для описания веб-служб XML, к которым можно получить доступ с разных платформ и в разных программах. языки. Помимо описания содержимого сообщения, WSDL также определяет местоположение службы и протокол связи, используемый для связи со службой. То есть файл WSDL определяет все необходимое для написания программы, использующей веб-службы XML. Существует несколько инструментов, которые могут читать файлы WSDL и генерировать код, необходимый для взаимодействия с веб-службами XML. Некоторые из наиболее мощных инструментов можно найти в Microsoft Visual Studio® .NET.
В настоящее время многие наборы инструментов SOAP включают инструменты для создания файлов WSDL из существующих программных интерфейсов, но инструментов для написания WSDL напрямую мало, а поддержка инструментов для WSDL является неполной. Но вскоре появятся инструменты для написания файлов WSDL, а затем инструменты для создания прокси и заглушек (во многом похожие на инструменты COM IDL), и эти инструменты станут частью большинства реализаций SOAP. До тех пор WSDL станет предпочтительным методом создания интерфейсов SOAP для веб-служб XML.
Здесь есть очень хорошее описание WSDL (на английском языке), а спецификацию WSDL можно найти по адресу http://www.w3.org/TR/wsdl (на английском языке).
Универсальное обнаружение, описание и интеграция
UDDI
(UDDI) — это «Желтые страницы веб-сервисов».Как и на традиционных «Желтых страницах», вы можете искать компании, предлагающие необходимые вам услуги, читать, чтобы узнать о предлагаемых услугах, а затем связаться с кем-нибудь для получения дополнительной информации. Конечно, вы можете предоставлять веб-сервисы, не регистрируя их в UDDI, это все равно, что вести бизнес в своем подвале и полагаться на молву, но если вы хотите расширить свой рынок, вам нужен UDDI, чтобы вас могли обнаружить; клиенты.
Записи каталога UDDI представляют собой XML-файлы, описывающие предоставляемые услуги и сервисы. Запись каталога UDDI состоит из трех частей. «Белые страницы» представляют компании, предоставляющие услуги: название, адрес, контактную информацию и т. д.; «Желтые страницы» включают отраслевые категории, основанные на стандартных классификациях (таких как Североамериканская система отраслевой классификации и Стандартная отраслевая классификация); «Зеленые страницы» содержат подробную информацию; Информация Получите доступ к интерфейсу службы, чтобы пользователи могли писать приложения для использования веб-службы. Определение службы осуществляется с помощью документа UDDI, называемого моделью типа (или tModel). В большинстве случаев tModel содержит файл WSDL, описывающий интерфейс SOAP для доступа к веб-службе XML, но tModel очень гибок и может описывать практически любой тип службы.
Каталог UDDI также содержит несколько методов для поиска сервисов, необходимых для создания вашего приложения. Например, вы можете искать поставщиков услуг в определенном географическом месте или искать определенный тип бизнеса. Каталог UDDI предоставит информацию, контактные данные, ссылки и технические данные, чтобы вы могли определить услуги, соответствующие вашим потребностям.
UDDI позволяет вам находить компании, предоставляющие необходимые вам веб-сервисы. Что делать, если вы уже знаете, с кем хотите вести бизнес, но еще не знаете, что еще он может предложить? Спецификация WS-Inspection (на английском языке) позволяет просматривать коллекцию веб-служб XML, доступных на определенном сервере, в поисках нужной службы.
Для получения дополнительной информации о UDDI посетите http://www.uddi.org/about.html (на английском языке).
Другое содержимое
До сих пор мы обсуждали, как взаимодействовать с веб-службами XML (SOAP), как описываются веб-службы XML (WSDL) и как находить веб-службы XML (UDDI). Они образуют базовый набор спецификаций, которые обеспечивают основу для интеграции и агрегирования приложений. Основываясь на этих базовых спецификациях, компании могут создавать практические решения и извлекать из них выгоду.
Мы проделали большую работу по реализации веб-служб XML, но еще многое предстоит сделать. Сегодня люди добились успеха, используя веб-службы XML, но разработчикам еще предстоит многое улучшить. Например, безопасность, управление операциями, обработка транзакций и надежный обмен сообщениями. Глобальная архитектура веб-служб XML поможет веб-службам XML выйти на следующий этап эволюции, предоставляя согласованную, общую модель для добавления новых расширенных возможностей в веб-службы XML на модульной и расширяемой основе.
Упомянутые выше модули безопасности (WS-Security [английский] и WS-License [английский]) являются частью спецификации глобальной архитектуры веб-служб. Потребности в оперативном управлении (например, маршрутизация сообщений между несколькими серверами и динамическая настройка этих серверов для обработки) также являются частью глобальной архитектуры веб-служб посредством спецификации WS-Routing (на английском языке) и спецификации WS-Referral (на английском языке). По мере развития глобальной архитектуры веб-сервисов будут вводиться спецификации, отвечающие этим и другим потребностям.