Что такое веб-сервис. Что такое "веб-сервис" на простом английском языке

Мы выпустили новую книгу «Контент-маркетинг в социальных сетях: Как засесть в голову подписчиков и влюбить их в свой бренд».

Подписаться

Web-сервис (служба) – программа, которая организовывает взаимодействие между сайтами. Информация с одного портала передается на другой.

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

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

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

Архитектура и протоколы Web-сервисов

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

Механизм обмена данными формируется в описании Web Services Description. Это спецификация, охватывающая форматы пересылки, типы контента, транспортные протоколы, которые применяются в процессе обмена сведениями между заказчиком и транспортировщиком услуг.

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

1. TCP/IP – протокол, который понимается практически любым сетевым оборудованием, от мэйнфреймов до портативных устройств и PDA.
2. HTML - универсальный язык разметки, используемый для демонстрации контента устройствами потребителей.
3. XML – универсальное средство для обработки всех разновидностей данных. На его базе могут работать и прочие протоколы обмена информацией: SOAP и WSDL.
4. UDDI – универсальный источник распознавания, интеграции и описания. Работает, как правило, в частных сетях и пока не нашел достаточного распространения.

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

Преимущества

• Создание необходимых условий для взаимодействия программных компонентов вне зависимости от платформы.
• Веб-сервисы основываются на открытых стандартных протоколах. За счет внедрения XML обеспечивается простота формирования и настройки веб-сервисов.
• Применение HTTP гарантирует взаимодействие систем посредством межсетевого доступа.

Недостатки

• Невысокая производительность и большой объем трафика, в сравнении с системами RMI, CORBA, DCOM, за счет использоваться XML-сообщений в разрезе текста.
• Уровень безопасности. Все современные веб-сервисы должны внедрять кодирование, и требовать авторизации пользователя. Хватит ли здесь наличия HTTPS или необходимы более надежные протоколы, как XML Encryption, SAML и т.д., – решаются в ходе разработки.

Задачи веб-сервисов

Веб-сервисы могут использоваться во многих сферах.

B2B-транзакции

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

Интеграция сервисов предприятий

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

Создание системы клиент-сервер

Сервисы используются, чтобы настроить работу клиента и сервера. Это дает преимущества:

• можно продавать не само программное обеспечение, а делать платным доступ к веб-сервису;
• легче решать проблемы с использованием стороннего ПО;
• проще организовывать доступ к контенту и материалам сервера.

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

Аннотация: Области применения. Преимущества. Особенности разработки web-сервисов для платформы.NET. Описание и обнаружение web-сервиса

Что такое XML Web Service?

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

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

Назовем сервисом (service) ресурс , реализующий бизнес-функцию и обладающий следующими свойствами:

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

Частным случаем сервиса является XML web -сервис.

XML Web-сервис - это особый тип web -приложения, который:

• развертывается на web-сервере;
• публикует web-методы, которые могут быть вызваны внешними клиентами;
• ожидает поступления HTTP-запросов, являющихся командами вызовов web-методов;
• исполняет web-методы и возвращает результаты.

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

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

Web -сервисы - не собственность конкретной компании. Это промышленный стандарт на основе открытых протоколов ( SOAP , HTTP и т. д.). Web -сервисы развертываются на различных платформах (в том числе на серверах под управлением Windows или UNIX ). Web -сервисы можно разрабатывать с применением многих средств разработки (от текстового редактора до семейства Microsoft Visual Studio ).

Методы большинства web -сервисов вызываются HTTP -запросами, содержащими сообщения SOAP SOAP - это XML -язык ( XML vocabulary ) для вызова удаленных процедур по HTTP и другим протоколам (полное описание SOAP http://www.w3.org/TR/SOAP).

Место web-сервисов среди других технологий удаленного вызова

Существует немало протоколов и технологий удаленного вызова: Microsoft Distributed Component Object Model ( DCOM ), the Object Management Group "s Common Object Request Broker Architecture ( CORBA ), Sun "s Remote Method Invocation ( RMI ), . NET Remoting , XML Web Services.

Все эти компонентно-ориентированные технологии ( DCOM , CORBA и RMI ) долгие годы успешно применялись в Intranet-приложениях. Они обеспечивают надежную, масштабируемую архитектуру. Однако при использовании этих технологий в Internet возникают две серьезные проблемы. Во-первых, они плохо взаимодействуют между собой. Все технологии оперируют объектами, но существенно отличаются деталями: управлением жизненным циклом, поддержкой конструкторов и степенью поддержки наследования. Второй, более важный аспект состоит в том, что ориентация на RPC-взаимодействия приводит к построению сильносвязных систем на основе явных вызовов методов объектов.

В отличие от данных технологий, XML Web Services и. NET Remoting в полной мере реализуют объектно-ориентированный подход для web -программирования.

XML Web Service - компонент , предоставляющий Internet -клиентам набор функций API или web -методов. XML входит в название, поскольку web -сервисы и их клиенты используют его для обмена данными. В основе web -сервисов лежат открытые стандарты, такие как HTTP , XML ( Extensible Markup Language ), SOAP (Simple Object Access Protocol - стандарт Intenet, описывающий, как приложения могут взаимодействовать, то есть вызывать методы друг друга, с помощью HTTP и других протоколов). Основная задача web -сервисов - обеспечение межпрограммного взаимодействия. Многие работают на UNIX -серверах, при этом к ним обращаются Windows -клиенты. Данные, передаваемые web -сервисам, сериализуются в XML и передаются в SOAP -пакетах. Метаданные о содержимом таких сообщений хранятся в WSDL-контракте web -сервиса и схемах XSD . Главное преимущество такого подхода - читабельность метаданных. Разработчик может легко просмотреть все описание web -сервиса и даже создать собственный модуль , разбирающий SOAP -пакеты.

.NET Remoting предоставляет инфраструктуру для распределенных объектов. Она гораздо сложнее простой архитектуры web -сервисов, основанной на передаче сообщений. . NET Remoting включает передачу параметров по ссылке и значению, обратные вызовы, множественную активацию объектов и политики управления жизненным циклом. Чтобы использовать указанные возможности, клиентское приложение должно владеть всеми технологиями. Данные в. NET Remoting передаются в бинарном или SOAP -формате. Однако в любом случае метаданные о структуре переданной информации содержатся в общеязыковой исполняющей среде. Без общеязыковой исполняющей среды ( CLR ) клиентское приложение не сможет разобрать специфичные для. NET Remoting заголовки SOAP . То есть. NET Remoting предъявляет существенно более высокие требования по сравнению с web -сервисами.

Разработка web-сервисов на платформе.NET

Есть много способов написания web -сервисов. Их можно разрабатывать вручную или с помощью SOAP -инструментов, предоставляемых Microsoft, IBM и др. Написание web -сервисов с помощью Microsoft. NET имеет два преимущества:

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

Создание

Разработаем простой web-сервис AdditionService, осуществляющий сложение двух чисел. У него будет всего один метод Add, принимающий в качестве параметра два целых числа и возвращающий также целое число. AdditionService демонстрирует несколько важных принципов программирования web-сервисов с помощью Microsoft .NET Framework.

• Web-сервисы реализуются как ASMX-файлы. ASMX - это особое расширение имени файла, зарегистрированное за ASP .NET (точнее, за HTTP-обработчиком ASP.NET) в главном файле конфигурации ASP .NET Machine.config.
• ASMX-файлы начинаются директивой @WebService . Эта директива должна содержать хотя бы атрибут Class , задающий класс, из которого состоит web-сервис.
• Классы web-сервисов могут иметь необязательные атрибуты WebService . В данном примере такой атрибут назначает имя web-сервиса и описание, которое отображается на HTML-странице, когда пользователь вызывает в браузере AdditionService.asmx .
• Web-методы объявляются путем назначения открытым методам класса Web-сервиса атрибута WebMethod . Для вспомогательных методов, применяемых внутри него, но недоступных внешним клиентам, этот атрибут просто не указывается.
• HTTP, XML и SOAP "невидимы". Работу с XML-данными и сообщениями SOAP выполняет.NET Framework.

AdditionService.asmx <%@ WebService language="C#" Class="AddService" %> using System using System.Web.Services class AddService { public int Add (int a, int b) { return a + b } }

Несмотря на малые размеры, AdditionService.asmx - полноценный web-сервис, если его установить на web-сервер с ASP.NET. Его методы вызываются с помощью SOAP, HTTP GET и HTTP POST, и он может возвращать результаты как SOAP-отклики или как простые XML-оболочки.

Используя фоновый код, классы web-сервиса можно вынести из asmx-файлов в отдельные файлы.

Web-сервисы поддерживают использование сложных типов данных в качестве входных или выходных параметров. Сложные типы данных поддерживаются, так как XML позволяет легко сериализовать большинство типов данных. Однако при автоматическом тестировании web-сервиса ASP .NET не генерирует тестовые страницы для методов, принимающих сложные типы данных. Это происходит потому, что нельзя передать сложные типы данных web-методу с помощью HTTP GET и POST.

Web-сервисы позволяют вызывать свои методы асинхронно . Асинхронный вызов возвращает управление немедленно, независимо от того, сколько времени нужно web-сервису на обработку вызова. Асинхронные вызовы полезны в случае, если обработка вызова требует значительного времени. Приложение выполняет вызов, далее продолжает работать, не дожидаясь результата вызова, и позднее получает результаты асинхронного вызова. Получение результата происходит при повторном вызове web-метода в удобное приложению время либо с помощью подписки на уведомление об окончании обработки вызова web-сервисом (механизм делегатов).

Web-сервисы можно создавать при помощи инструментальных средств, например, Microsoft Visual Studio 2005 . Для создания web-сервисов там предусмотрен отдельный тип проекта ASP .NET Web Service. Visual Studio генерирует asmx-файл, файл с фоновым кодом для описания классов web-сервиса, файл конфигурации web-сервиса и т. д. При запуске проекта на исполнение происходит компиляция классов сервиса и открытие asmx-файла в окне браузера.

Описание web-сервисов при помощи контрактов

Для того чтобы другие разработчики могли использовать AdditionService, им нужно знать, какие методы он предоставляет, какие протоколы поддерживает, сигнатуры методов и адрес web-сервиса (URL). Вся эта и другая информация может быть описана на языке WSDL (Web Service Description language).

Обнаружение web-сервисов

Каким образом другие разработчики узнают о существовании AdditionService?

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

Также возможно использовать VSDISCO-файлы, которые аналогичны DISCO-файлам, но их содержимое есть результат динамического поиска web-сервисов в указанных каталогах и всех вложенных подкаталогах. ASP .NET отображает расширение имени файла.vsdisco на HTTP-обра-ботчик, который отыскивает в данном каталоге и его подкаталогах asmx и disco и возвращает динамически генерируемый DISCO-документ. По соображениям безопасности динамический поиск в ряде версий.NET Framework отключен, но его можно включить, изменив записи файла Machine.config.

А как же осуществляется поиск web-сервисов в глобальной сети? Для поиска web-сервисов в глобальной сети Microsoft, IBM и Ariba совместно разработали UDDI (Universal Description Discovery and Integration) - спецификацию построения распределенных баз данных, которая позволяет отыскивать web-сервисы. UDDI поддерживается сотнями компаний. UDDI-сайты сами являются web-сервисами. Каждый может опубликовать свой реестр на основе UDDI. Большинство разработчиков никогда не используют UDDI API напрямую. Вместо этого к реестрам UDDI обращаются инструментальные средства разработки. Они также генерируют классы-оболочки обнаруженных и выбранных web-сервисов.

Итоги

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

Практическое использование 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-сервисы клиентам или системам.

Мы отобрали 10 лучших веб-сервисов, обзоры которых публиковались в «Лайфхакере» в прошлом году. Эти инструменты помогают нам эффективно организовывать время и работать в команде, управлять своим бизнесом, приобретать новые знания и развивать свои способности, получать больше удовольствия от отдыха и развлечений. Попробуйте их в новом году и пусть ваша жизнь станет ярче и комфортнее!

Гениальный мэшап ifttt позволяет устанавливать причинно-следственную связь между событиями в различных веб-сервисах по принципу «Если это произошло в одном сервисе, то то произойдет в другом сервисе». Поддерживается более 20 сервисов, социальных сетей и технологий: Gmail и любая другая почта, RSS, Facebook, Twitter, Evernote, Dropbox, Google Reader, Google Talk, Foursquare, Flickr, Instapaper, ReadItLater, LinkedIn, YouTube и другие. Кроме того, событиями служат SMS, телефонные звонки, изменения котировок акций и даже изменение погоды в заданном регионе. Примеры автоматизированных процессов, созданных с помощью ifttt: «если в Google Reader пост отмечен звездочкой, то он сохраняется в Evernote», «если начался дождь в Нью-Йорке, то приходит уведомление об этом в SMS». А теперь представьте себе возможности ifttt в будущем «интернете вещей », когда разные электронные устройства смогут общаться друг с другом! ;) Впервые я узнал об этом сервисе от друга «Лайфхакера» Виктора Захарченко. Позже он также рассказывал о своем опыте использования ifttt в сольном выпуске подкаста «42» , посвященном продуктивности и управлению стартапами.

Bookmate - ваша личная электронная библиотека, книги из которой можно читать на компьютере и мобильных устройствах (iPhone, iPad, Android, Symbian). При этом происходит синхронизация данных между используемыми вами девайсами - приступив к чтению на компьютере, вы можете продолжить его на смартфоне или планшете с того места, где остановились. В фонде Bookmate хранится несколько тысяч бесплатных книг, множество книг доступны по подписке стоимостью всего 99 рублей в месяц. Если вы не найдете среди них нужной книги, вы можете загрузить ее в библиотеку самостоятельно. Сервис позволяет делиться с друзьями рекомендациями, видеть списки их чтения и брать книги с их книжных полок. Любителям чтения могу порекомендовать также замечательную социальную сеть книголюбов Goodreads ( в «Лайфхакере» c интересными дополнениями от Петра Диденко и Виктора Захарченко), которой уже почти год пользуюсь сам и о которой мы говорили в 40-ом выпуске подкаста «42» вместе с Петром Диденко и Виктором Захарченко.

Современные компании должны использовать новые технологии для повышения конкурентоспособности и стимулирования своего развития. Многие задачи учета и управления бизнесом можно отдавать на аутсорсинг, и во многих случаях удобным для ИП или ООО является использование таких облачных сервисов, как «Мое дело». Этот сервис - выгодная замена привычного аутсорсинга. С его помощью можно в полуавтоматическом режиме вести бухгалтерский учет, рассчитывать налоги, сдавать отчетность в государственные органы в электронном виде через интернет, получать экспертные консультации, за 15 минут создавать пакет документов, необходимых для регистрации ИП (а в скором времени появится возможность готовить документы и для регистрации ООО). Обратите также внимание на аналогичный сервис от компании «СКБ Контур» - электронный бухгалтер «Эльба ». Если вам интересна тема облачных технологий для бизнеса, то слушайте 54-ый выпуск подкаста «42» с участием Петра Диденко и Нины Горбуновой.

Еще одна важная категория облачных сервисов - системы управления проектами. Одной из лучших (и бесплатной) является TeamLab, достойный конкурент Basecamp и других популярных систем. TeamLab поставляется в трех решениях - в виде SaaS для использования в браузере сразу же после регистрации аккаунта; в виде открытого исходного кода, который можно самостоятельно дорабатывать под свои нужды и вкусы, чтобы затем развернуть систему на своих серверах; и в виде виртуальной машины с предустановленным порталом TeamLab на серверах Amazon. TeamLab включает в себя модули управления проектами, совместной работы, управления документами, календарь, CRM-систему (систему управления взаимоотношениями с клиентами). Менеджер по маркетингу TeamLab Нина Горбунова представляла эту систему в 54-ом выпуске подкаста «42» про облачные технологии для бизнеса.

Новый модный сервис Pinterest позволяет создавать красивые виртуальные доски с изображениями различных предметов, зданий, мест, интерьеров, блюд - всего того, что вы любите и хотите показать другим. Новые объекты добавляются на доски очень просто - с помощью букмарклета для браузеров или вручную через веб-интерфейс. В Pinterest вы можете следить за обновлениями виртуальных досок своих друзей, разглядывая интересные картинки в поисках идей, вдохновения и просто хорошего настроения. В качестве примера приведу мою доску «Гости подкаста „42“ » с фотографиями всех замечательных гостей, информацией об их деятельности и ссылками на выпуски подкаста с их участием.

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

Moredays - онлайн-органайзер, стилизованный под бумажные планировщики и чем-то напоминающий легендарные Молескины. Главное его достоинство - изумительная красота. Дизайнеры постарались на славу и сделали один из самых красивых органайзеров в мире. При этом Moredays обладает довольно богатой функциональностью: можно управлять задачами, планировать время в календаре, хранить заметки, контакты, делиться отдельными страницами органайзера с другими людьми через Twitter, Facebook и Google+, синхронизировать данные с Evernote и Google Apps, а в скором времени появятся и клиенты для мобильных устройств.

Если вы - один из основателей Facebook, то любой ваш проект мгновенно становится известным. Так и случилось с системой управления проектами Asana Дастина Московица, со-основателя крупнейшей в мире социальной сети. Однако Asana заслуживает внимания не только из-за личности Дастина - разработчики создали простой и удобный сервис с приятным, но строгим интерфейсом. Asana подойдет для индивидуального использования и для работы в небольшой команде. Функциальность системы трудно назвать богатой, но, возможно, именно в этом и заключается одно из ее главных достоинств для тех, кому не требуются перегруженные функциями инструменты управления проектами. Asana синхронизируется с Google Calendar, Apple iCal и Microsoft Outlook, интегрируется с почтой, имеет клиенты для смартфонов и планшетов.

BO.LT предоставляет простую, но при этом удивительную возможность отредактировать по своему вкусу любую веб-страницу. Достаточно указать ее адрес и вы сможете очень легко, без знания HTML и прочих технологий веб-разработки, вносить любые изменения в текст и дизайн копии этой веб-страницы, а затем отправлять другим людям сокращенную ссылку на результат. Приглашенные к просмотру друзья или коллеги также могут редактировать данную веб-страницу. Сервис незаменим, когда требуется ясно представить внешний вид сайта после различных доработок, провести мозговой штурм по поиску новых идей для дизайна или показать друзьям веб-страницу со своими пояснительными комментариями. Можно переключиться в режим редактирования HТML-кода, чтобы получить еще большую свободу действий.

Уважаемые читатели, а какие веб-сервисы понравились вам в 2011 году? Какие из них вы можете порекомендовать нам для обзоров в «Лайфхакере»?

Мы рассмотрели общие понятия использования механизма « Web -сервисов». Освежим некоторые знания.

Web-сервисы применяются для обмена данными между сервером и клиентом; формат XML используется для «упаковывания» данных в целях взаимопонимания между обоими участниками общения.

РАЗДЕЛ I

ПРИМЕР РЕАЛИЗАЦИИ WEB -СЕРВИСА В СИСТЕМЕ «1С:ПРЕДПРИЯТИЕ»

ЗАДАЧА: Необходимо создать web-сервис, обращаясь к которому клиенты могут определить всю необходимую информацию по своим заявкам.

Задача является демонстрационной и служит только примером для понимания и обучения механизму web -сервисов.

РЕШЕНИЕ:

Шаг 1. Создадим новую информационную базу без конфигурации для разработки новой конфигурации.

Шаг 2. Добавим в конфигурацию несколько новых объектов

Справочник «Клиенты»;

Документ «Заявка»;

Перечисление «СтатусыЗаявок».

Шаг 3. Создадим новый XDTO-пакет.

Почему и для чего мы создаем XDTO-пакет? Подробнее об использовании механизма XDTO можно прочитать в «Глава 16. Руководство разработчика» и .

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

В нашем случае пакет XDTO создается для описания возвращаемого значения web-сервиса.

Раскроем ветку «Общие» → «XDTO-пакеты» → Добавить…

Укажем имя XDTO-пакета «DocumentsData » и его пространство имен http://localhost/request или http://192.168.1.76/request (для облегчения понимания и процесса обучения, мы указываем локальный IP-адрес компьютера, где установлен web-сервер (поддерживаемые web-сервера: IIS или Apache)). Каждый Web-сервис может быть однозначно идентифицирован по своему имени и URI пространству имен, которому он принадлежит.

Наш пакет содержит два типа объектов XDTO:

1) Сustomer - для передачи данных элемента справочника «Клиенты».

- Name ;

2) Document - для передачи данных документа «Заявки»

Этот тип объекта XDTO будет содержать следующие свойства:

- Сustomer - тип Сustomer из пространства имен http://192.168.1.76/request ; представляет собой ссылку на объект XDTO, который мы определили выше;

- Status - тип string из пространства имен http://www.w3.org/2001/XMLSchema ;

- Numder - тип string из пространства имен http://www.w3.org/2001/XMLSchema .

Шаг 4. Добавим в конфигурацию новый Web-сервис

Раскроем ветку «Общие» → «Web-сервисы» → Добавить…

Для Web-сервиса укажем следующими значения свойств:

Имя - DocumentsData

URI Пространства имен - http://192.168.1.76/request

Пакеты XDTO - DocumentsData или http://192.168.1.76/request

Имя файла публикации - request.1cws

Шаг 5. У созданного Web-сервиса определим операцию «GetData »

Значения свойств операции:

Тип возвращаемого значения - Document (http://192.168.1.76/request)

Возможно пустое значение - Истина

Имя процедуры - GetData .

Шаг 6. У операции GetData определим параметр Сustomer со следующими значениями свойств:

Тип значения - тип string из пространства имен http://www.w3.org/2001/XMLSchema;

Направление передачи - входной .

Шаг 7. Откроем модуль созданного Web-сервиса и поместить в него функцию Получить(), которая будет выполняться при вызове данного Web-сервиса.

Функция GetData(Сustomer) // Получить типы объектов XDTO КлиентТип = ФабрикаXDTO.Тип("http://192.168.1.76/request", "Сustomer"); ЗаявкаТип = ФабрикаXDTO.Тип("http://192.168.1.76/request", "Document"); // Получаем клиента КлиентСсылка = Справочники.Клиенты.НайтиПоНаименованию(Сustomer); Если Не ЗначениеЗаполнено(КлиентСсылка) Тогда Возврат Неопределено; КонецЕсли; Запрос = Новый Запрос; Запрос.Текст = "ВЫБРАТЬ ПЕРВЫЕ 1 | Заявка.Ссылка, | ПРЕДСТАВЛЕНИЕ(Заявка.Статус) КАК Статус, | Заявка.Номер |ИЗ | Документ.Заявка КАК Заявка |ГДЕ | Заявка.Клиент = &Клиент"; Запрос.УстановитьПараметр("Клиент", КлиентСсылка); РезультатЗапроса = Запрос.Выполнить(); Если РезультатЗапроса.Пустой() Тогда Возврат Неопределено; КонецЕсли; Выборка = РезультатЗапроса.Выбрать(); Выборка.Следующий(); Документ = Выборка.Ссылка.ПолучитьОбъект(); // Создать объект XDTO заявки Заявка = ФабрикаXDTO.Создать(ЗаявкаТип); Заявка.Numder = Выборка.Номер; Клиент = ФабрикаXDTO.Создать(КлиентТип); Клиент.Name = КлиентСсылка.Наименование; Заявка.Сustomer = Клиент; Заявка.Status = Выборка.Статус; // Вернуть заявку Возврат Заявка; КонецФункции

Шаг 8. Опубликуем созданный Web-сервис на веб-сервере.

Пункт меню Конфигуратор: «Администрирование» → «Публикация на Web-сервере».

На вкладке «Web-сервисы» устанавливаем признак «Публиковать Web-сервисы» и напротив нашего нового Web-сервиса также ставим «галочку».

РАЗДЕЛ II

ПРИМЕР ОБРАЩЕНИЯ К WEB -СЕРВИСУ СИСТЕМЫ «1С:ПРЕДПРИЯТИЕ» ИЗ СТОРОННЕГО ПРИЛОЖЕНИЯ

Основное назначение механизма Web-сервисов в системе «1С:Предприятие» - это передача необходимых данных сторонним приложениям.

Рассмотрим пример разработки приложения на Delphi обращения к нашему web-сервису из первого раздела данной статьи.

Шаг 1. Создадим новый проект и на форме разместим несколько элементов управления

Текстовое поле - используется для вывода полученной от web-сервиса информации;

Две кнопки - очистка текстового поля и обращение к web-сервису;

Поле ввода - передаваемый в web-сервис параметр.

Шаг 2. Выполняем импорт WSDL-файла

В результате мы получаем новый модуль request (такое наименование мы определили непосредственно в 1С). В данном модуле имеется все необходимая информация по web-сервису.

Шаг 3. Напишем обработчик вызова web-сервиса

Переменная DocumentDataPortType уже определена в модуле request

Шаг 4. Запустить приложение и выполнить проверку.

РАЗДЕЛ III

ПРИМЕР ОБРАЩЕНИЯ К WEB -СЕРВИСУ В СИСТЕМЕ «1С:ПРЕДПРИЯТИЕ»

Шаг 1. Создадим новую внешнюю обработку с именем «WEB_Service»

Шаг 2. Для обработки определим новую форму

Шаг 3. У формы укажем несколько реквизитов

Клиент - тип «Строка»

КлиентВозврат - тип «Строка»

НомерВозврат - тип «Строка»

СтатусВозврат - тип «Строка».

Выведем реквизиты на форму.

Шаг 4. Добавим команду формы «ПолучитьДанные »

Укажем обработчик команды

&НаКлиенте Процедура ПолучитьДанные(Команда) ПолучитьДанныеНаСервере(Клиент); КонецПроцедуры Процедура ПолучитьДанныеНаСервере(Клиент) // Создать WS-прокси на основании ссылки и выполнить операцию Получить() Определение = Новый WSОпределения("http://192.168.1.76/WEB_Service/ws/request.1cws?wsdl"); Прокси = Новый WSПрокси(Определение, "http://192.168.1.76/request", "DocumentsData", "DocumentsDataSoap"); ДанныеЗаявки = Прокси.GetData(Клиент); Если ДанныеЗаявки = Неопределено Тогда КлиентВозврат = "Неопределено"; СтатусВозврат = "Неопределено"; НомерВозврат = "Неопределено"; Возврат; КонецЕсли; КлиентВозврат = ДанныеЗаявки.Сustomer.Name; СтатусВозврат = ДанныеЗаявки.Status; НомерВозврат = ДанныеЗаявки.Numder; КонецПроцедуры

Система «1С:Предприятие» может использовать веб-сервисы, предоставляемые другими поставщиками, двумя способами:

С помощью статических ссылок, создаваемых в дереве конфигурации;

«плюс»: большая скорость работы;

«минус»: повторный импорт WSDL-описания средствами конфигуратора и сохранение измененной конфигурации.

С помощью динамических ссылок, создаваемых средствами встроенного языка

(соответственно «минусы» статических для динамических - «плюсы»)

РАЗДЕЛ IV

ОТЛАДКА WEB-СЕРВИСОВ В СИСТЕМЕ «1С:ПРЕДПРИЯТИЕ»

Для локального web-сервиса необходимо:

Шаг 1. Положить на клиент, где запускается система 1С файлик webservicecfg.xml со следующим содержимом

Шаг 2. В файл default . vrd публикации конфигурации добавить строку

Шаг 3. В конфигураторе выбрать пункт меню

«Отладка» → «Подключение» → «Автоматическое подключение» → «Web-сервисы на сервере»

Шаг 4. Нажать на кнопку «OK»

Для серверного варианта надо еще сервер 1с запускать в режим отладки с ключом /debug