Веб-службы - Краткое руководство

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

Веб-служба - это любое программное обеспечение, которое становится доступным через Интернет и использует стандартизированную систему обмена сообщениями XML. XML используется для кодирования всех сообщений веб-службы. Например, клиент вызывает веб-службу, отправляя сообщение XML, а затем ожидает соответствующего ответа XML. Поскольку все коммуникации происходят в XML, веб-сервисы не привязаны к какой-либо одной операционной системе или языку программирования - Java может взаимодействовать с Perl; Приложения Windows могут взаимодействовать с приложениями Unix.
Веб-сервисы - это автономные, модульные, распределенные, динамические приложения, которые можно описывать, публиковать, размещать или вызывать по сети для создания продуктов, процессов и цепочек поставок. Эти приложения могут быть локальными, распределенными или веб-приложениями. Веб-службы построены на основе открытых стандартов, таких как TCP / IP, HTTP, Java, HTML и XML.
Веб-сервисы - это системы обмена информацией на основе XML, которые используют Интернет для прямого взаимодействия между приложениями. Эти системы могут включать программы, объекты, сообщения или документы.
Веб-сервис - это набор открытых протоколов и стандартов, используемых для обмена данными между приложениями или системами. Программные приложения, написанные на разных языках программирования и работающие на различных платформах, могут использовать веб-службы для обмена данными по компьютерным сетям, таким как Интернет, аналогично межпроцессному обмену данными на одном компьютере. Эта функциональная совместимость (например, между приложениями Java и Python или Windows и Linux) обусловлена использованием открытых стандартов.

Таким образом, полный веб-сервис - это любой сервис, который:

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

Компоненты веб-служб

Базовая платформа веб-сервисов - это XML + HTTP. Все стандартные веб-службы работают с использованием следующих компонентов -

SOAP (простой протокол доступа к объектам)
UDDI (универсальное описание, открытие и интеграция)
WSDL (язык описания веб-служб)

Все эти компоненты обсуждались в главе « Архитектура веб-служб» .

Как работает веб-служба?

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

XML для маркировки данных
SOAP для передачи сообщения
WSDL для описания доступности службы.

Вы можете создать веб-службу на основе Java в Solaris, доступную из вашей программы Visual Basic, работающей в Windows.

Вы также можете использовать C # для создания новых веб-служб в Windows, которые можно вызывать из вашего веб-приложения, основанного на JavaServer Pages (JSP) и работающего в Linux.

пример

Рассмотрим простую систему управления аккаунтом и обработки заказов. Бухгалтерский персонал использует клиентское приложение, созданное на Visual Basic или JSP, для создания новых учетных записей и ввода новых заказов клиентов.

Логика обработки для этой системы написана на Java и находится на машине Solaris, которая также взаимодействует с базой данных для хранения информации.

Шаги для выполнения этой операции следующие:

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

Вот преимущества использования веб-служб -

Отображение существующей функции в сети

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

Совместимость

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

Стандартизированный протокол

Веб-службы используют для связи стандартизированный промышленный протокол. Все четыре уровня (уровни Service Transport, XML Messaging, Service Description и Service Discovery) используют четко определенные протоколы в стеке протоколов веб-служб. Эта стандартизация стека протоколов дает бизнесу множество преимуществ, таких как широкий выбор вариантов, снижение стоимости из-за конкуренции и повышение качества.

Низкая стоимость коммуникации

Веб-службы используют протокол SOAP через HTTP, поэтому вы можете использовать существующий недорогой Интернет для реализации веб-служб. Это решение намного дешевле по сравнению с проприетарными решениями, такими как EDI / B2B. Помимо SOAP через HTTP, веб-службы также могут быть реализованы на других надежных транспортных механизмах, таких как FTP.

Веб-сервисы обладают следующими особенностями поведения:

На основе XML

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

Слабо связанный

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

Крупнозернистый

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

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

Возможность быть синхронным или асинхронным

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

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

Поддерживает удаленные вызовы процедур (RPC)

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

Разработка компонентов с помощью Enterprise JavaBeans (EJB) и компонентов .NET все чаще становится частью архитектур и корпоративных развертываний за последние пару лет. Обе технологии распространяются и доступны через различные механизмы RPC.

Веб-служба поддерживает RPC, предоставляя собственные службы, эквивалентные службам традиционного компонента, или путем преобразования входящих вызовов в вызов EJB или компонента .NET.

Поддерживает обмен документами

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

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

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

Роли веб-сервисов

В архитектуре веб-сервисов есть три основные роли:

Поставщик услуг

Это поставщик веб-службы. Поставщик услуг реализует услугу и делает ее доступной в Интернете.

Запрос на обслуживание

Это любой потребитель веб-службы. Запрашивающая сторона использует существующую веб-службу, открывая сетевое соединение и отправляя XML-запрос.

Реестр услуг

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

Стек протоколов веб-служб

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

Сервисный транспорт

Этот уровень отвечает за транспортировку сообщений между приложениями. В настоящее время этот уровень включает в себя протокол передачи гипертекста (HTTP), простой протокол передачи почты (SMTP), протокол передачи файлов (FTP) и новые протоколы, такие как протокол расширяемого обмена блоками (BEEP).

Обмен сообщениями XML

Этот уровень отвечает за кодирование сообщений в общем формате XML, чтобы сообщения можно было понять с любой стороны. В настоящее время этот уровень включает XML-RPC и SOAP.

Описание услуг

Этот уровень отвечает за описание открытого интерфейса конкретной веб-службы. В настоящее время описание службы обрабатывается с помощью языка описания веб-служб (WSDL).

Обнаружение услуг

Этот уровень отвечает за централизацию служб в общем реестре и обеспечивает простую функцию публикации / поиска. В настоящее время обнаружение сервисов осуществляется через универсальное описание, обнаружение и интеграцию (UDDI).

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

В следующей главе объясняются компоненты веб-сервисов.

Несколько слов о служебном транспорте

Нижняя часть стека протоколов веб-служб - это транспортная служба. Этот уровень отвечает за фактическую передачу сообщений XML между двумя компьютерами.

Протокол передачи гипертекста (HTTP)

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

Блокирует расширяемый протокол обмена (BEEP)

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

SOAP не привязан к какому-либо конкретному транспортному протоколу. Фактически, вы можете использовать SOAP через HTTP, SMTP или FTP. Поэтому одна многообещающая идея - использовать SOAP вместо BEEP.

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

XML-RPC

Это простейший протокол на основе XML для обмена информацией между компьютерами.

XML-RPC - это простой протокол, который использует сообщения XML для выполнения RPC.
Запросы кодируются в XML и отправляются через HTTP POST.
Ответы XML встроены в тело ответа HTTP.
XML-RPC не зависит от платформы.
XML-RPC позволяет взаимодействовать различным приложениям.
Клиент Java может передавать XML-RPC серверу Perl.
XML-RPC - это самый простой способ начать работу с веб-службами.

Чтобы узнать больше о XML-RPC, посетите наш учебник XML-RPC .

МЫЛО

SOAP - это протокол на основе XML для обмена информацией между компьютерами.

SOAP - это протокол связи.
SOAP предназначен для связи между приложениями.
SOAP - это формат для отправки сообщений.
SOAP предназначен для связи через Интернет.
SOAP не зависит от платформы.
SOAP не зависит от языка.
SOAP прост и расширяем.
SOAP позволяет обойти брандмауэры.
SOAP будет разработан как стандарт W3C.

Чтобы узнать больше о SOAP, посетите наш учебник по SOAP .

WSDL

WSDL - это язык на основе XML для описания веб-сервисов и способов доступа к ним.

WSDL означает язык описания веб-служб.
WSDL был разработан совместно Microsoft и IBM.
WSDL - это протокол на основе XML для обмена информацией в децентрализованных и распределенных средах.
WSDL - это стандартный формат для описания веб-службы.
Определение WSDL описывает, как получить доступ к веб-сервису и какие операции он будет выполнять.
WSDL - это язык для описания взаимодействия со службами на основе XML.
WSDL является неотъемлемой частью UDDI, всемирного бизнес-реестра на основе XML.
WSDL - это язык, который использует UDDI.
WSDL произносится как «глупый» и пишется как «WSD-L».

Чтобы узнать больше о WSDL, посетите наш учебник по WSDL .

UDDI

UDDI - это стандарт на основе XML для описания, публикации и поиска веб-сервисов.

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

Чтобы узнать больше о UDDI, посетите наш учебник по UDDI .

На основе архитектуры веб-сервисов мы создаем следующие два компонента как часть реализации веб-сервисов:

Поставщик услуг или издатель

Это поставщик веб-службы. Поставщик услуг реализует услугу и делает ее доступной в Интернете или интранете.

Мы напишем и опубликуем простой веб-сервис с использованием .NET SDK.

Запрашивающая услуга или потребитель

Мы также напишем два запросчика веб-службы: один потребитель на базе веб (приложение ASP.NET) и другой потребитель на основе приложения Windows.

Ниже приведен наш первый пример веб-службы, которая работает как поставщик услуг и предоставляет два метода (add и SayHello) в качестве веб-служб, которые будут использоваться приложениями. Это стандартный шаблон для веб-сервиса. Веб-службы .NET используют расширение .asmx. Обратите внимание, что метод, представленный как веб-служба, имеет атрибут WebMethod. Сохраните этот файл как FirstService.asmx в виртуальном каталоге IIS (как описано в разделе настройки IIS; например, c: \ MyWebSerces).

FirstService.asmx
<%@ WebService language = "C#" class = "FirstService" %>

using System;
using System.Web.Services;
using System.Xml.Serialization;

[WebService(Namespace = "http://localhost/MyWebServices/")]
public class FirstService : WebService{
   [WebMethod]
   public int Add(int a, int b) {
      return a + b;
   }

   [WebMethod]
   public String SayHello() {
      return "Hello World";
   }
}

Чтобы протестировать веб-службу, ее необходимо опубликовать. Веб-сервис может быть опубликован либо в интрасети, либо в Интернете. Мы опубликуем эту веб-службу в IIS, работающем на локальном компьютере. Начнем с настройки IIS.

Откройте Пуск → Настройка → Панель управления → Администрирование → Диспетчер служб Интернета.
Разверните и щелкните правой кнопкой мыши веб-сайт по умолчанию; выберите Новый & # rarr; Виртуальный каталог. Откроется мастер создания виртуального каталога. Нажмите "Далее.
Откроется экран «Псевдоним виртуального каталога». Введите имя виртуального каталога. Например, MyWebServices. Нажмите "Далее.
Откроется экран «Каталог содержимого веб-сайта».
Введите путь к виртуальному каталогу. Например, c: \ MyWebServices. Нажмите "Далее.
Откроется экран «Разрешение доступа». Измените настройки в соответствии с вашими требованиями. Для этого упражнения оставим настройки по умолчанию.
Щелкните кнопку Далее. На этом настройка IIS завершена.
Нажмите Готово, чтобы завершить настройку.

Чтобы проверить, правильно ли настроен IIS, скопируйте файл HTML (например, x.html) в виртуальный каталог (C: \ MyWebServices), созданный выше. Теперь откройте Internet Explorer и введитеhttp://localhost/MyWebServices/x.html. Он должен открыть файл x.html.

Note- Если это не сработает, попробуйте заменить localhost на IP-адрес вашего компьютера. Если по-прежнему не работает, проверьте, работает ли IIS; вам может потребоваться перенастроить IIS и виртуальный каталог.

Чтобы протестировать эту веб-службу, скопируйте FirstService.asmx в виртуальный каталог IIS, созданный выше (C: \ MyWebServices). Откройте веб-службу в Internet Explorer (http: //localhost/MyWebServices/FirstService.asmx). Он должен открыть страницу вашего веб-сервиса. На странице должны быть ссылки на два метода, представленных нашим приложением как веб-службы. Поздравляю! Вы написали свой первый веб-сервис!

Тестирование веб-службы

Как мы только что убедились, писать веб-службы в .NET Framework легко. В .NET framework также легко писать потребителей веб-сервисов; однако это немного сложнее. Как было сказано ранее, мы напишем два типа потребителей услуг: один на основе веб-интерфейса, а другой - на основе приложения Windows. Давайте напишем нашего первого потребителя веб-сервиса.

Потребитель веб-сервисов

Напишите интернет-потребителя, как указано ниже. Назовите его WebApp.aspx. Обратите внимание, что это приложение ASP.NET. Сохраните это в виртуальном каталоге веб-службы (c: \ MyWebServices \ WebApp.axpx).

Это приложение имеет два текстовых поля, которые используются для получения чисел от добавляемого пользователя. У него есть одна кнопка «Выполнить», при нажатии на которую появляются веб-службы «Добавить» и «Привет».

WebApp.aspx
<%@ Page Language = "C#" %>
<script runat = "server">
   void runSrvice_Click(Object sender, EventArgs e) {
      FirstService mySvc = new FirstService();
      Label1.Text = mySvc.SayHello();
      Label2.Text = mySvc.Add(Int32.Parse(txtNum1.Text),  Int32.Parse(txtNum2.Text)).ToString();
   }
</script>

<html>
   <head> </head>
   
   <body>
      <form runat = "server">
         <p>
            <em>First Number to Add </em>:
            <asp:TextBox id = "txtNum1" runat = "server" Width = "43px">4<  /asp:TextBox>
         </p>
			
         <p>
            <em>Second Number To Add </em>:
            <asp:TextBox id = "txtNum2" runat = "server" Width = "44px">5</asp:TextBox>
         </p>
			
         <p>
            <strong><u>Web Service Result -</u></strong>
         </p>
			
         <p>
            <em>Hello world Service</em> :
            <asp:Label id = "Label1" runat = "server" Font-Underline = "True">Label< /asp:Label>
         </p>

         <p>
            <em>Add Service</em> :
            & <asp:Label id = "Label2" runat = "server" Font-Underline = "True">Label</asp:Label>
         </p>
			
         <p align = "left">
            <asp:Button id = "runSrvice" onclick = "runSrvice_Click" runat = "server" Text = "Execute"></asp:Button>
         </p>
      </form>
   </body>
</html>

После создания потребителя нам нужно создать прокси для использования веб-службы. Эта работа выполняется автоматически Visual Studio .NET для нас при обращении к добавленной веб-службе. Вот шаги, которым нужно следовать -

Создайте прокси для использования веб-службы. Прокси-сервер создается с помощью утилиты WSDL, поставляемой с .NET SDK. Эта утилита извлекает информацию из веб-службы и создает прокси. Прокси-сервер действителен только для определенной веб-службы. Если вам нужно использовать другие веб-службы, вам также необходимо создать прокси для этой службы. Visual Studio .NET автоматически создает прокси-сервер при добавлении ссылки на веб-службу. Создайте прокси для веб-службы с помощью утилиты WSDL, поставляемой с .NET SDK. Он создаст файл FirstSevice.cs в текущем каталоге. Нам нужно скомпилировать его, чтобы создать FirstService.dll (прокси) для веб-службы.

c:> WSDL http://localhost/MyWebServices/FirstService.asmx?WSDL
c:> csc /t:library FirstService.cs

Поместите скомпилированный прокси в каталог bin виртуального каталога веб-службы (c: \ MyWebServices \ bin). Информационные службы Интернета (IIS) ищут прокси в этом каталоге.
Создайте потребителя сервиса так же, как мы это уже сделали. Обратите внимание, что объект прокси-сервера веб-службы создается в потребителе. Этот прокси отвечает за взаимодействие с сервисом.
Введите URL-адрес потребителя в IE, чтобы проверить его (например, http: //localhost/MyWebServices/WebApp.aspx).

Потребитель веб-служб на основе приложений Windows

Написание потребителя веб-службы на основе приложения Windows аналогично написанию любого другого приложения Windows. Вам нужно только создать прокси (что мы уже сделали) и ссылаться на этот прокси при компиляции приложения. Ниже представлено наше приложение для Windows, использующее веб-службу. Это приложение создает объект веб-службы (конечно, прокси) и вызывает для него методы SayHello и Add.

WinApp.cs

using System;
using System.IO;

namespace SvcConsumer {
   class SvcEater {
      public static void Main(String[] args) {
         FirstService mySvc = new FirstService();
         Console.WriteLine("Calling Hello World Service: " + mySvc.SayHello());
         Console.WriteLine("Calling Add(2, 3) Service: " + mySvc.Add(2, 3).ToString());
      }
   }
}

Скомпилируйте его, используя c:\>csc /r:FirstService.dll WinApp.cs. Будет создан WinApp.exe. Запустите его, чтобы протестировать приложение и веб-службу.

Теперь возникает вопрос: как вы можете быть уверены, что это приложение действительно вызывает веб-службу?

Проверить несложно. Остановите свой веб-сервер, чтобы с ним нельзя было связаться. Теперь запустите приложение WinApp. Это вызовет исключение времени выполнения. Теперь снова запустите веб-сервер. Он должен работать.

Безопасность критически важна для веб-сервисов. Однако ни спецификации XML-RPC, ни SOAP не содержат явных требований к безопасности или аутентификации.

Существует три конкретных проблемы безопасности с веб-службами:

Confidentiality
Authentication
Сетевая безопасность

Конфиденциальность

Если клиент отправляет XML-запрос на сервер, можем ли мы гарантировать конфиденциальность связи?

Ответ лежит здесь -

XML-RPC и SOAP в основном работают поверх HTTP.
HTTP имеет поддержку Secure Sockets Layer (SSL).
Связь может быть зашифрована через SSL.
SSL - проверенная и широко распространенная технология.

Один веб-сервис может состоять из цепочки приложений. Например, одна большая служба может связывать вместе службы трех других приложений. В этом случае SSL не подходит; сообщения должны быть зашифрованы на каждом узле на пути обслуживания, и каждый узел представляет собой потенциально слабое звено в цепочке. В настоящее время не существует согласованного решения этой проблемы, но одним из многообещающих решений является стандарт шифрования XML W3C. Этот стандарт обеспечивает основу для шифрования и дешифрования целых XML-документов или только частей XML-документа. Вы можете проверить это на сайте www.w3.org/Encryption.

Аутентификация

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

Могут быть рассмотрены следующие варианты, но нет четкого консенсуса в отношении строгой схемы аутентификации.

HTTP включает встроенную поддержку базовой и дайджест-аутентификации, поэтому службы могут быть защищены во многом так же, как в настоящее время защищаются документы HTML.
Цифровая подпись SOAP (SOAP-DSIG) использует криптографию с открытым ключом для цифровой подписи сообщений SOAP. Это позволяет клиенту или серверу проверять личность другой стороны. Проверьте это на www.w3.org/TR/SOAP-dsig .
Организация по развитию стандартов структурированной информации (OASIS) работает над языком разметки утверждений безопасности (SAML).

Сетевая безопасность

В настоящее время нет простого ответа на эту проблему, и она является предметом многочисленных споров. На данный момент, если вы действительно намерены отфильтровать сообщения SOAP или XML-RPC, одна из возможностей - отфильтровать все запросы HTTP POST, которые устанавливают их тип содержимого как text / xml.

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

Эта глава дает вам представление обо всех последних стандартах, относящихся к веб-службам.

Транспорт

BEEP, расширяемый протокол обмена блоками (ранее называвшийся BXXP), представляет собой основу для создания протоколов приложений. Он был стандартизирован IETF и делает для интернет-протоколов то же, что XML для данных.

Блокирует расширяемый протокол обмена (BEEP)

Обмен сообщениями

Эти стандарты и спецификации обмена сообщениями предназначены для создания основы для обмена информацией в децентрализованной распределенной среде.

SOAP 1.1 (Примечание)
SOAP 1.2 (Спецификация)
Профиль вложений веб-служб 1.0
Механизм оптимизации передачи сообщений SOAP

Описание и открытие

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

UDDI 3.0
WSDL 1.1 (Примечание)
WSDL 1.2 (рабочий проект)
WSDL 2.0 (рабочая группа)

Безопасность

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

Безопасность веб-служб 1.0
Язык разметки утверждения безопасности (SAML)

Управление

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

Распределенное управление веб-службами

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

WSDL

WSDL - это язык на основе XML для описания веб-сервисов и способов доступа к ним.

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

Чтобы узнать больше о WSDL, посетите наш учебник по WSDL .

UDDI

UDDI - это стандарт на основе XML для описания, публикации и поиска веб-сервисов.

Чтобы узнать больше о UDDI, посетите наш учебник по UDDI .

МЫЛО

SOAP - это простой протокол на основе XML, который позволяет приложениям обмениваться информацией через HTTP.

Чтобы узнать больше о SOAP, посетите наш учебник по SOAP .