19 ответов

Простое определение: веб-служба - это функция, к которой могут обращаться другие программы через Интернет (Http). Чтобы немного уточнить, когда вы создаете веб-сайт на PHP, который выводит HTML, его целью является браузер и, в дополнение, человек, читающий страницу в браузере. Веб-сервис не предназначен для людей, а скорее для других программ.

Таким образом, ваш сайт PHP, который генерирует случайное целое число, может быть веб-службой, если он выводит целое число в формате, который может быть использован другой программой. Это может быть в формате XML или другом формате, если другие программы могут понять вывод.

Полное определение, очевидно, более сложное, но вы попросили простой английский.

Упрощенное, нетехническое объяснение: Веб-сервлет позволяет PROGRAM разговаривать с веб-страницей, вместо того чтобы использовать ваш браузер для открытия веб-страницы.

Пример: Я могу перейти на maps.google.com и ввести свой домашний адрес, а также посмотреть, где я живу в своем браузере.

Но что, если вы пишете компьютерную программу, где вы хотите взять адрес и показать симпатичную карту, точно так же, как карты Google?

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

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

Да, это простой веб-сервис.

Веб-сервисы - это не что иное, как механизм запроса/ответа, который позволяет клиенту удаленно получать доступ/изменять данные. Существуют официальные стандарты для веб-сервисов (SOAP, SOA и т.д.), Но ваша простая страница также является сервисом.

Основной недостаток печати на странице - это то, что ваша служба вернет HTML. Предпочтительными форматами данных являются JSON и XML, поскольку большинство клиентских фреймворков (и серверных фреймворков) разработаны с использованием JSON и XML.

Итак, если вы изменили свой сервис для возврата:

some random number

... some random number

то это было бы более полезно для большинства клиентов

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

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

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

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

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

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

Веб-сервисы являются ключевым компонентом в "mashups". Mashups - это когда информация с многих сайтов автоматически агрегируется в новый и полезный сервис. Например, есть сайты, которые объединяют Карты Google с информацией о полицейских отчетах, чтобы дать вам графическое представление о преступности в вашем районе. Другим типом mashup было бы получение реальных данных о запасах, предоставляемых другим сайтом, и объединение их с поддельным торговым приложением для создания "рыночной игры" на фондовом рынке.

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

Надеюсь, это поможет!

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

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

Введите веб-службы.

Веб-сервис - это то, что веб-сайт предлагает предложить тем, кто хочет читать, обновлять и/или удалять данные с вашего сайта. Вы можете назвать это "бэкдором" для своих данных. Вместо того, чтобы представлять данные как часть веб-страницы, она предоставляется заранее определенным образом, где некоторые из наиболее популярных - это XML и JSON. Существует несколько способов общения с веб-сервисом, некоторые используют SOAP, другие - веб-службы REST"а и т.д.

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

Лучшее объяснение на английском языке объясняется аналогией:

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

Ваш пример PHP - это веб-сервис по этому определению, потому что вывод может быть использован другой программой. Но на самом деле HTML-скребок экрана не является надежным или поддерживаемым способом создания веб-сервисов.

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

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

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

Он работает примерно так:

Webservice - это технология, посредством которой два или более удаленных веб-приложения взаимодействуют друг с другом по сети/Интернету. Он может быть реализован с использованием Java,.net, PHP и т.д.

Особенности веб-службы: -

Операционная система предоставляет интерфейс GUI (и CLI), с которым вы можете взаимодействовать. Он также предоставляет API, с которым вы можете взаимодействовать с программным обеспечением.

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

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

Simple way to explain web service is::

• Веб-сервис - это способ связи между двумя электронными устройствами по Всемирной паутине.
• Его можно назвать процессом, который программист использует для связи с сервером.
• Для вызова этого процесса программист может использовать SOAP и т.д.
• Веб-службы создаются поверх открытых стандартов, таких как TCP/IP, HTTP

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

Поскольку @Vincent Ramdhanie сказал, что веб-сервис не предназначен для просмотра/потребления конечным пользователем, а другой программы. Таким образом, техническая логика в вашей программе будет:

В случае выполнения нормальной программы

User on website -> HTML/JS/JQuery etc -> give me a random number ->ur program

ur program -> generate random number -> generate HTML and encapsulate o/p -> go back to user

Валентин Колесов
разработчик красноярского отделения санкт-петербургской компании "Астрософт", сертифицированный специалист Microsoft (MCSD, MCSE, MCDBA)
[email protected]

Демонстрация работы SOAP на примере написания Web-сервера

Что такое SOAP

Широко распространенные в настоящее время технологии удаленного вызова методов (DCOM, CORBA/IIOP и RMI) довольно сложны в настройке и организации взаимодействия. Это влечет за собой трудности в эксплуатации и функционировании распределенных систем (проблемы безопасности, неудобства транспорта через брандмауэры и т. д.). Многие проблемы удалось решить благодаря созданию SOAP (Simple Object Access Protocol, простой протокол доступа к объектам), простого протокола, основанного на XML и служащего для обмена сообщениями в распределенных средах (WWW). Протокол предназначен для создания Web-сервисов и удаленного вызова методов. SOAP можно использовать в сочетании с разными транспортными протоколами, включая HTTP, SMTP и др.

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

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

Для демонстрации возможностей SOAP в статье использована недавно вышедшая реализация SOAP Toolkit версии 2.0 производства Microsoft. Следует заметить, что текущая версия Toolkit заметно отличается от предыдущей (Microsoft SOAP Toolkit for Visual Studio 6.0) и от бета-версии SOAP Toolkit 2.0.

Объектная модель SOAP Toolkit предоставляет как низкоуровневые, так и высокоуровневые интерфейсы (SOAPClient, SOAPServer), скрывающие от программиста всю "внутреннюю кухню" - разбор и формирование пакетов, вызов методов и т. п. С помощью этих интерфейсов можно весьма элегантным образом использовать Web-сервисы в разрабатываемых приложениях. Объект SOAPClient выступает в роли посредника (proxy), предоставляющего интерфейс Web-сервиса и позволяющего работать с ним как с обычным COM-объектом (рис. 1).

1. Клиентское приложение создает экземпляр объекта SOAPClient.
2. SOAPClient читает файлы описания методов Web-сервиса (на языках WSDL и Web Services Meta Language, WSML). Эти файлы могут храниться и на стороне клиента.
3. Клиентское приложение, используя возможности позднего связывания методов объекта SOAPClient, вызывает метод сервиса. SOAPClient формирует пакет запроса (SOAP Envelope) и отправляет его на сервер. Можно применить любой транспортный протокол, но, как правило, используется HTTP.
4. Серверное приложение Listener (это может быть ISAPI-приложение или ASP-страница) принимает пакет, создает объект SOAPServer и передает ему пакет запроса. Помимо этого Listener обрабатывает HTTP-пакеты от клиента, отправляет клиенту пакеты с результатом работы сервиса, обрабатывает ошибки и использует функциональность SOAP-объектов.
5. SOAPServer читает описание Web-сервиса, загружает описание и пакет запроса в деревья XML DOM.
6. SOAPServer вызывает метод объекта или приложения, реализующего сервис.
7. Результаты выполнения метода или описание ошибки конвертируются объектом SOAPServer в пакет ответа и отправляются клиенту.
8. Объект SOAPClient проводит разбор принятого пакета и возвращает клиентскому приложению результаты работы сервиса или описание возникшей ошибки.

WSDL-файл - это документ в формате XML, описывающий методы, предоставляемые Web-сервисом, а также параметры методов, их типы, названия и местонахождение сервиса Listener. Мастер SOAP Toolkit автоматически генерирует этот документ, фрагмент которого приведен ниже:

Тег Envelope должен быть корневым элементом пакета. Элемент Header не обязателен, а Body должен присутствовать и быть прямым потомком элемента Envelope. В случае ошибки выполнения метода сервер формирует пакет, содержащий в теге Body элемент Fault, который содержит подробное описание ошибки.

Если вы пользуетесь высокоуровневыми интерфейсами SOAPClient, SOAPServer, то вам не придется вдаваться в тонкости формата пакета, но при желании можно воспользоваться низкоуровневыми интерфейсами или же вообще создать пакет "вручную", используя любой язык программирования.

Объектная модель SOAP Toolkit дает возможность работать с объектами низкоуровневого API:

• SoapConnector - обеспечивает работу с транспортным протоколом для обмена SOAP-пакетами.
• SoapConnectorFactory - обеспечивает метод создания коннектора для транспортного протокола, указанного в WSDL-файле (тег).
• SoapReader - читает SOAP-сообщения и строит деревья XML DOM.·
• SoapSerializer - содержит методы создания SOAP-сообщения.·
• IsoapTypeMapper, SoapTypeMapperFactory - интерфейсы, позволяющие работать со сложными типами данных.

С помощью объектов высокоуровневого API можно передавать данные только простых типов (int, string, float и т. п.), но спецификация SOAP 1.1 допускает работу с более сложными типами данных, например с массивами, структурами, списками и их комбинациями. Для работы с такими типами приходится использовать интерфейсы IsoapTypeMapper и SoapTypeMapperFactory.

Пример

Чтобы продемонстрировать работу SOAP, напишем несложный Web-сервис, который будет уметь складывать и вычитать числа. Для работы серверного приложения потребуется пакет IIS 5 в среде Windows 2000 или IIS4 на Windows NT 4.0 Service Pack 6, а также установленный SOAP Toolkit 2.0.

Требования клиентского приложения - ОС Microsoft Windows 98/Me или Windows NT 4.0 Service Pack 6/2000 Service Pack 1, а также установленный SOAP Toolkit 2.0.

Создание сервера

Откройте в VB новый проект ActiveX DLL. Измените название класса на SOAPClass, а имя проекта - на SOAPProj.

В классе создайте следующие методы:

В следующем окне Мастера можно выбрать методы, которые войдут в Web-сервис. В данном случае выберите все методы. Затем укажите, где будет находиться Web-приложение (например, http://wsd010/soap/), задайте тип приложения Listener (ASP или ISAPI), выберите ASP, формат схемы (по умолчанию). Укажите путь, где будут находиться файлы описания Web-сервиса, и кодировку. После окончания работы Мастера в Web-каталоге появятся файлы ASP, WSDL и WSML - это Listener для ASP и описания сервиса (см. листинги 1-3).

Осталось только настроить права доступа к Web-приложению - желательно установить NT Challenge/Response authentication. На этом работа по созданию сервера закончена.

Создание клиента

Откройте в VB новый проект Standard EXE. В меню Project/References сделайте ссылку на библиотеку Microsoft SOAP type library. Создайте на форме кнопку, в обработчике нажатия кнопки напишите следующий код:

Dim SoapClient As New SoapClient SoapClient.mssoapinit "http://wsd010/soap/SOAPService.wsdl" MsgBox SoapClient.AddNumbers(4, 3) MsgBox SoapClient.SubtractNumbers(3, 2)

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

После создания объекта SOAPClient его надо инициализировать - указать путь к документу описания Web-сервиса. После инициализации у объекта появятся методы Web-сервиса. С ними можно работать как с обычным COM-объектом.

С помощью замечательной утилиты MsSoapT.exe (Trace Utility), входящей в Toolkit, можно просматривать в режиме реального времени пакеты, идущие от клиента к серверу и обратно. Для этого надо в WSDL-файле найти тег и вместо строки типа http://wsd010/soap/SOAPService.ASP написать http://wsd010:8080/soap/SOAPService.ASP, то есть указать порт 8080. После этого нужно запустить утилиту трассирования и принять настройки по умолчанию, а затем создать новый объект Formatted Trace. Теперь все SOAP-пакеты работы с Web-сервисом доступны для оперативного просмотра. Если трассировщик не загружен, то в нужно убрать указание порта 8080. На рис. 4 приведено содержимое пакета запроса на выполнение метода SubstractNumbers.

А пакет ответа выглядит следующим образом:

1

Так выглядит пакет сервера, пришедший в ответ на запрос некорректного формата:

SOAP-ENV:Server Connector - Bad request to the server. -2146823238 800a13ba

Дополнительная информация по теме

http://msdn.microsoft.com/webservices/ и http://msdn.microsoft.com/soap/ - последние новости о SOAP и Web-сервисах от Microsoft. Там же можно найти свежие версии ПО.

http://www.vbxml.com/soap/ - много полезной информации для разработчиков. Есть презентации и учебники по SOAP.

http://www.w3.org/TR/SOAP/ - спецификация SOAP от W3C.

http://www.w3.org/TR/wsdl - сведения о стандарте Web Services Definition Language (WSDL) 1.1/

http://microsoft.public.xml.soap - в этой конференции специалисты помогут решить сложные проблемы программирования SOAP.

Листинг 1. Код Listener для ASP <%@ LANGUAGE=VBScript %> <% Option Explicit On Error Resume Next Response.ContentType = "text/xml" Dim SoapServer If Not Application("SoapServerInitialized") Then Application.Lock If Not Application("SoapServerInitialized") Then Dim WSDLFilePath Dim WSMLFilePath WSDLFilePath = Server.MapPath("SOAPService.wsdl") WSMLFilePath = Server.MapPath("SOAPService.wsml") Set SoapServer = Server.CreateObject("MSSOAP.SoapServer") If Err Then SendFault "Cannot create SoapServer object. " & Err.Description SoapServer.Init WSDLFilePath, WSMLFilePath If Err Then SendFault "SoapServer.Init failed. " & Err.Description Set Application("SOAPServiceServer") = SoapServer Application("SoapServerInitialized") = True End If Application.UnLock End If Set SoapServer = Application("SOAPServiceServer") SoapServer.SoapInvoke Request, Response, "" If Err Then SendFault "SoapServer.SoapInvoke failed. " & Err.Description Sub SendFault(ByVal LogMessage) Dim Serializer On Error Resume Next " "URI Query" logging must be enabled for AppendToLog to work Response.AppendToLog " SOAP ERROR: " & LogMessage Set Serializer = Server.CreateObject("MSSOAP.SoapSerializer") If Err Then Response.AppendToLog "Could not create SoapSerializer object. " & Err.Description Response.Status = "500 Internal Server Error" Else Serializer.Init Response If Err Then Response.AppendToLog "SoapSerializer.Init failed. " & Err.Description Response.Status = "500 Internal Server Error" Else Serializer.startEnvelope Serializer.startBody Serializer.startFault "Server", "The request could not be processed due to a problem in the server. Please contact the system administrator. " & LogMessage Serializer.endFault Serializer.endBody Serializer.endEnvelope If Err Then Response.AppendToLog "SoapSerializer failed. " & Err.Description Response.Status = "500 Internal Server Error" End If End If End If Response.End End Sub %>

Листинг 2. Код файла WSDL

Листинг 3. Код файла WSDL

Практическое использование Web-сервисов в IBM Lotus Domino 7

Что такое Web-сервисы и почему они важны?

Серия контента:

Этот контент является частью # из серии # статей: Практическое использование Web-сервисов в IBM Lotus Domino 7

https://www..jsp?series_title_by=Практическое+использование+web-сервисов+в+ibm+lotus+domino+7

Следите за выходом новых статей этой серии.

Возможно, вы встречались с упоминаниями о 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 показано как John . Ещё есть элементы, в которые вложены другие элементы, например в элемент Вложены элементы , и .

Написание 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 это будет выглядеть приблизительно так:

FOO

В базовом случае у вас есть пакет SOAP, включающий в себя тело SOAP и тело, в котором находятся передаваемые данные. Иногда ещё есть необязательный заголовок SOAP (внутри пакета перед телом), содержащий дополнительную информацию.

Инструкции SOAP

Хотя формат SOAP стандартен и имеет одинаковые инструкции, необходимо помнить что разные производители могут немного по разному воплощать эти инструкции. Например, структура именных пространств и XML в сообщении SOAP, сгенерированном Apache Axis может сильно отличаться от структуры, сгенерированной Microsoft .NET. Однако правильно написанный клиент или сервер может обработать любое правильно написанное в соответствии с инструкциями SOAP сообщение.

Кроме того, в инструкциях 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-сервисы клиентам или системам.

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

— Добрый день. Мне нужен сайт, простенький такой. Сколько стоит? (та же история с веб-приложениями).

Это прямо-таки головная боль каждого аккаунта. Но тот не нервничает и объясняет, что сайты бывают разные по сложности, функционалу и т.п. Уточняет, что нужно клиенту и что в его понимании значит «простенький». Получает, например, такой ответ:

— Ну понимаете, у меня есть бизнес по продаже окон. Вот было бы хорошо сделать web-сайт, чтобы там можно было самому сделать себе «виртуальное» окно. Выбрать цвет, материалы, размеры. Количество указать. Посмотреть, как оно будет выглядеть. Ну а потом наши спецы бы выехали на место. Договорились?

Это уже интересно. Но это еще не всё:

— И да, у меня есть еще пожелание. У нас подразделение есть в Москве, Питере и Новосибирске. Штат большой, документооборот, ну вы понимаете. Можно сделать что-то типа... маленькой социальной сети внутри сайта, что ли? Нам так удобнее будет общаться, безо всяких «асек». И документы хранить в одном «облаке» — я слышал, что так делают.

Аккаунт-менеджер всё записывает, делает примерную смету, называет стоимость. Потенциальный клиент округляет глаза (это слышно даже по телефону), говорит «ваши цены просто космос» и вежливо бросает трубку.

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

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

Разработка web-сервиса — это по большому счету та же разработка сайта. Но с одним большим «НО»: в отличие от знакомых уже каждому промо-сайтов и корпоративников, у онлайн-сервиса есть уникальный функционал. Это может быть конструктор товара (как в примере выше), фотохостинг, закрытая социальная сеть для корпоративного пользования, открытая социальная сеть (данедайбох), доска объявлений...

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

И всё это значит, что:

• Потребуется некоторое время на выяснение всех возможностей будущего проекта. Обычно много времени.
• Понадобится подробно проработанное техническое задание. А еще лучше — прототип.
• Нужно будет разработать сам web-сервис (неожиданно, да?). Сделать это с нуля или с привлечением существующих наработок. Но в любом случае — его невозможно будет «собрать» на коленке, из коробки, по шаблону и «по-быстрому».
• Необходимо будет тщательно оттестировать продукт перед выпуском.

Как следствие, цена создания веб-сервиса (вместе с его программированием) — будет колебаться. Но всегда будет выше, чем у сайта с «типичным» набором функций.

К нашему примеру: когда клиент упомянул внутреннюю социальную сеть, облачное хранилище для данных и конструктор окон — всё это вместе стало возможным назвать веб-сервисом. Поэтому и была названа «неожиданная» для заказчика стоимость.

«Космичность» цен при разработке интернет-сервисов — оправданная мера. Это объективно сложная и длительная работа.

А нужен ли такой сервис бизнесу — задачка для ваших маркетологов.

Особая и любимая всеми тема — социальные сети

Здесь случаются совсем курьезные случаи. Причем эти комедии разыгрываются с серьезным лицом. Например, некий активный процент школьников, «продвинутых» пользователей ВКонтакте, постоянно хочет собственную игру. Чтобы головокружительный успех. И чтобы при этом не заморачиваться.

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

Да уж, 5000 рублей за несколько недель работы — ок. Мы сейчас говорим только о годных экземплярах, а не о тех, что набирают аудиторию в 200 пользователей и чахнут.

Если вас всё же настигла мания сделать успешный клон — то хотя бы задумайтесь над тем, во сколько обошлось авторам оригинала продвижение и раскрутка веб-приложения или сервиса (обычно это бюджет на разработку, умноженный на десять).

Не делайте ошибок. Рассчитывайте силы. Запускайте успешные интернет-проекты. Аминь.

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

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

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

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

Сколько существует различных видов веб-служб?

В первую очередь, существуют два типа веб-служб, простой протокол доступа к объектам (SOAP) и репрезентативный перенос состояний (REST).

• Веб-служба SOAP принимает запрос в формате XML и генерирует вывод в формате XML.
• Веб-служба REST более универсальна и может принимать XML, а также JSON в качестве запроса и генерирует вывод в XML, а также в JSON или даже HTML

Подробнее данный вопрос может быть изучен на наших .