Что такое веб-сервисы?

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

• Веб-сервис — это любое программное обеспечение, которое доступно через Интернет и использует стандартизированную систему обмена сообщениями XML. XML используется для кодирования всех сообщений в веб-сервис. Например, клиент вызывает веб-службу, отправляя сообщение XML, а затем ожидает соответствующего ответа XML. Поскольку вся связь осуществляется в XML, веб-сервисы не привязаны к какой-либо одной операционной системе или языку программирования — Java может общаться с Perl; Приложения Windows могут общаться с приложениями Unix.

• Веб-службы — это автономные, модульные, распределенные, динамические приложения, которые можно описывать, публиковать, размещать или вызывать по сети для создания продуктов, процессов и цепочек поставок. Эти приложения могут быть локальными, распределенными или сетевыми. Веб-сервисы построены на основе открытых стандартов, таких как TCP / IP, HTTP, Java, HTML и XML.

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

• Веб-сервис — это набор открытых протоколов и стандартов, используемых для обмена данными между приложениями или системами. Программные приложения, написанные на разных языках программирования и работающие на разных платформах, могут использовать веб-сервисы для обмена данными по компьютерным сетям, таким как Интернет, аналогично межпроцессному взаимодействию на одном компьютере. Эта совместимость (например, между приложениями Java и Python или Windows и Linux) обусловлена ​​использованием открытых стандартов.

Веб-сервис — это любое программное обеспечение, которое доступно через Интернет и использует стандартизированную систему обмена сообщениями XML. XML используется для кодирования всех сообщений в веб-сервис. Например, клиент вызывает веб-службу, отправляя сообщение XML, а затем ожидает соответствующего ответа XML. Поскольку вся связь осуществляется в XML, веб-сервисы не привязаны к какой-либо одной операционной системе или языку программирования — Java может общаться с Perl; Приложения Windows могут общаться с приложениями Unix.

Веб-службы — это автономные, модульные, распределенные, динамические приложения, которые можно описывать, публиковать, размещать или вызывать по сети для создания продуктов, процессов и цепочек поставок. Эти приложения могут быть локальными, распределенными или сетевыми. Веб-сервисы построены на основе открытых стандартов, таких как TCP / IP, HTTP, Java, HTML и XML.

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

Веб-сервис — это набор открытых протоколов и стандартов, используемых для обмена данными между приложениями или системами. Программные приложения, написанные на разных языках программирования и работающие на разных платформах, могут использовать веб-сервисы для обмена данными по компьютерным сетям, таким как Интернет, аналогично межпроцессному взаимодействию на одном компьютере. Эта совместимость (например, между приложениями Java и Python или Windows и Linux) обусловлена ​​использованием открытых стандартов.

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

• Доступен через Интернет или частные (интранет) сети

• Использует стандартизированную систему обмена сообщениями XML

• Не привязан ни к одной операционной системе или языку программирования

• Это самоописание через общую грамматику XML

• Обнаруживается с помощью простого механизма поиска

Доступен через Интернет или частные (интранет) сети

Использует стандартизированную систему обмена сообщениями XML

Не привязан ни к одной операционной системе или языку программирования

Это самоописание через общую грамматику XML

Обнаруживается с помощью простого механизма поиска

Компоненты веб-сервисов

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

• SOAP (простой протокол доступа к объектам)

• UDDI (универсальное описание, обнаружение и интеграция)

• WSDL (язык описания веб-сервисов)

SOAP (простой протокол доступа к объектам)

UDDI (универсальное описание, обнаружение и интеграция)

WSDL (язык описания веб-сервисов)

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

Как работает веб-сервис?

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

• XML для пометки данных

• SOAP для передачи сообщения

• WSDL для описания доступности сервиса.

XML для пометки данных

SOAP для передачи сообщения

WSDL для описания доступности сервиса.

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

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

пример

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

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

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

• Клиентская программа связывает информацию о регистрации учетной записи в сообщение SOAP.

• Это SOAP-сообщение отправляется веб-службе как тело HTTP-запроса POST.

• Веб-служба распаковывает запрос SOAP и преобразует его в команду, понятную приложению.

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

• Затем веб-служба упаковывает ответ в другое сообщение SOAP, которое отправляет обратно клиентской программе в ответ на свой HTTP-запрос.

• Клиентская программа распаковывает сообщение SOAP, чтобы получить результаты процесса регистрации учетной записи.

Клиентская программа связывает информацию о регистрации учетной записи в сообщение SOAP.

Это SOAP-сообщение отправляется веб-службе как тело HTTP-запроса POST.

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

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

Затем веб-служба упаковывает ответ в другое сообщение SOAP, которое отправляет обратно клиентской программе в ответ на свой HTTP-запрос.

Клиентская программа распаковывает сообщение SOAP, чтобы получить результаты процесса регистрации учетной записи.

Почему веб-сервисы?

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

Разоблачение существующей функции в сети

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

Interoperability

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

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

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

Низкая стоимость связи

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

Веб-сервисы — Характеристики

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

XML-Based

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

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

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

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

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

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

Способность быть синхронной или асинхронной

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

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

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

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

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

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

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

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

Веб-сервисы — Архитектура

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

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

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

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

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

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

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

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

Сервисный реестр

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

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

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

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

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

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

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

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

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

Сервис Discovery

Этот уровень отвечает за централизацию сервисов в общем реестре и обеспечивает простую функциональность публикации / поиска. В настоящее время обнаружение служб обрабатывается с помощью универсального описания, обнаружения и интеграции (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.

Запросы кодируются в 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 для связи между приложениями.

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 произносится как «wiz-тупой» и произносится как «WSD-L».

WSDL расшифровывается как язык описания веб-сервисов.

WSDL был разработан совместно Microsoft и IBM.

WSDL — это основанный на XML протокол для обмена информацией в децентрализованных и распределенных средах.

WSDL — это стандартный формат описания веб-службы.

Определение WSDL описывает, как получить доступ к веб-службе и какие операции она будет выполнять.

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

WSDL является неотъемлемой частью UDDI, всемирного бизнес-реестра на основе XML.

WSDL — это язык, который использует UDDI.

WSDL произносится как «wiz-тупой» и произносится как «WSD-L».

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

UDDI

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

• UDDI расшифровывается как универсальное описание, обнаружение и интеграция.

• UDDI — это спецификация для распределенного реестра веб-сервисов.

• UDDI является независимой от платформы, открытой структурой.

• UDDI может взаимодействовать через SOAP, CORBA и протокол Java RMI.

• UDDI использует WSDL для описания интерфейсов к веб-сервисам.

• UDDI рассматривается в SOAP и WSDL как один из трех основных стандартов веб-сервисов.

• UDDI — это открытая отраслевая инициатива, позволяющая компаниям узнавать друг друга и определять, как они взаимодействуют через Интернет.

UDDI расшифровывается как универсальное описание, обнаружение и интеграция.

UDDI — это спецификация для распределенного реестра веб-сервисов.

UDDI является независимой от платформы, открытой структурой.

UDDI может взаимодействовать через SOAP, CORBA и протокол Java RMI.

UDDI использует WSDL для описания интерфейсов к веб-сервисам.

UDDI рассматривается в SOAP и WSDL как один из трех основных стандартов веб-сервисов.

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

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

Веб-сервисы — Примеры

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

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

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

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

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

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

Мы также напишем два запросчика веб-службы: один веб-пользователь (приложение 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.

• Нажмите Готово, чтобы завершить настройку.

Откройте Пуск → Настройки → Панель управления → Администрирование → Диспетчер служб Интернета.

Разверните и щелкните правой кнопкой мыши веб-сайт по умолчанию; выберите Новый & # rarr; Виртуальный каталог. Откроется мастер создания виртуального каталога. Нажмите кнопку «Далее.

Откроется экран «Псевдоним виртуального каталога». Введите имя виртуального каталога. Например, MyWebServices. Нажмите кнопку «Далее.

Откроется экран «Каталог содержимого веб-сайта».

Введите путь к каталогу для виртуального каталога. Например, c: \ MyWebServices. Нажмите кнопку «Далее.

Откроется экран «Разрешение на доступ». Измените настройки в соответствии с вашими требованиями. Давайте оставим настройки по умолчанию для этого упражнения.

Нажмите кнопку Далее. Завершает настройку IIS.

Нажмите Готово, чтобы завершить настройку.

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

Примечание. Если это не помогает, попробуйте заменить 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).

Это приложение имеет два текстовых поля, которые используются для получения чисел от пользователя, который будет добавлен. Он имеет одну кнопку «Выполнить», которая при нажатии получает веб-сервисы Add и SayHello.

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 (прокси) для веб-службы.

Создайте прокси для использования веб-службы. Прокси создается с помощью утилиты 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).

Поместите скомпилированный прокси в каталог 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 не предъявляют никаких явных требований к безопасности или аутентификации.

Есть три конкретных проблемы безопасности с веб-сервисами —

• конфиденциальность
• Аутентификация
• Сетевая безопасность

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

Если клиент отправляет запрос 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).

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

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

Организация по продвижению стандартов структурированной информации (OASIS) работает над языком разметки утверждений безопасности (SAML).

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

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

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

Веб-сервисы — Стандарты

Эта глава дает вам представление обо всех последних стандартах, связанных с веб-сервисами.

Транспорты

BEEP, Blocks Extensible Exchange Protocol (ранее назывался BXXP), является основой для построения прикладных протоколов. Он был стандартизирован IETF и делает для интернет-протоколов то, что XML сделал для данных.

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

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

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

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

• SOAP 1.1 (Примечание)

• SOAP 1.2 (спецификация)

• Профиль веб-служб вложения 1.0

• Механизм оптимизации передачи сообщений SOAP

SOAP 1.1 (Примечание)

SOAP 1.2 (спецификация)

Профиль веб-служб вложения 1.0

Механизм оптимизации передачи сообщений SOAP

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

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

• UDDI 3.0

• WSDL 1.1 (Примечание)

• WSDL 1.2 (рабочий проект)

• WSDL 2.0 (рабочая группа)

UDDI 3.0

WSDL 1.1 (Примечание)

WSDL 1.2 (рабочий проект)

WSDL 2.0 (рабочая группа)

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

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

• Безопасность веб-сервисов 1.0

• Язык разметки утверждений безопасности (SAML)

Безопасность веб-сервисов 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 .