В чем заключается работа врапперов в веб интеграции

Опубликовано: 16.05.2024

Продолжая серию статей по нововведениям в DIRECTUM 4.8, следует уделить внимание вопросу интеграции DIRECTUM с другими системами. Компоненты для интеграции появились в DIRECTUM уже давно. Например, коннектор к SAP существует, начиная с версии DIRECTUM 4.5. Примерно в то же время появились коннекторы к 1С и Axapta. Они позволяют синхронизировать данные между интегрированной системой и системой DIRECTUM, связывать объекты интегрированной системы и документы DIRECTUM, стартовать задачи DIRECTUM из интегрированной системы и т.д. Но главное их ограничение состоит в том, что для интеграции необходимо, чтобы обе системы были установлены на одном компьютере.

Для большего удобства пользователей необходима связь интегрированной системы и DIRECTUM именно «на расстоянии», т.е. так, чтобы интегрированная система находилась на одном сервере, а DIRECTUM на другом. Причем довольно часто между системами отсутствует связь по локальной сети и есть возможность связи только через Интернет.

Раньше такое взаимодействие было невозможно. Но в версии DIRECTUM 4.8 оно стало возможным, благодаря разработанным веб-сервисам интеграции.

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

Веб-сервис , (или веб-служба, англ. web service) — идентифицируемая веб-адресом программная система со стандартизированными интерфейсами. Веб-службы могут взаимодействовать друг с другом и со сторонними приложениями посредством сообщений, основанных на определённых протоколах (XML, JSON и т. д.). Веб-служба является единицей модульности при использовании сервис-ориентированной архитектуры приложения.

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

Применение.

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

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

создание задачи;
загрузка документов в систему DIRECTUM, получение информации о документах, создание, обновление, получение связей документов системы DIRECTUM с объектами внешней системы, получение метаинформации карточки документа;
загрузка записей справочника в систему DIRECTUM, получение информации о записях справочника, получение метаинформации карточки записи справочника;
преобразование данных (преобразование xml-пакета в формат системы DIRECTUM);
обработка синхронного/асинхронного метода;

Различают два типа методов веб-сервиса:

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

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

выполнение прикладных сценариев после загрузки данных в систему DIRECTUM.

Архитектурно веб-сервис интеграции представляет собой WCF-сервис. (Windows Communication Foundation — программный фреймворк, используемый для обмена данными между приложениями входящими в состав .NET Framework). Обмен данными производится через SOAP-пакеты. Формат обмена данными зависит от типа объекта, который передается из одной системы в другую.

Следует отметить, что для установки требуется серверная лицензия Веб-сервисы интеграции.

Пример работы веб-сервисов интеграции.

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

В каждой отрасли бизнеса, каждой компании, как правило, используется целый зоопарк ПО, например: сайт на 1С-Битрикс, CRM 1С-Битрикс24, учетная система на базе 1С. Одни системы “из коробки” умеют взаимодействовать с «соседними» продуктами, другие же приходится дорабатывать. За десятилетия существования веба как отрасли сформировались следующие практики межсетевого взаимодействия:

Обмен файлами по FTP.
Неструктурированные HTTP-запросы, договорённости между разработчиками.
Веб-сервисы.
Экзотика: сокеты, порты, бинарные объекты.

В данной статье мы поговорим о веб-сервисах. Чем они отличаются от прочих способов и какие они бывают.

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

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

Главное отличие веб-сервиса от других способов передачи данных: стандартизированность. Приняв решение использовать веб-сервисы, можно сразу переходить к структуре данных и доступным функциям. Например, В SOAP (как более строгом протоколе), уже решён вопрос уведомления об ошибках.

Самые известные способы реализации веб-сервисов:

XML-RPC (XML Remote Procedure Call) — протокол удаленного вызова процедур с использованием XML. Прародитель SOAP. Предельно прост в реализации.
SOAP (Simple Object Access Protocol) — стандартный протокол по версии W3C. Четко структурирован и задокументирован.
JSON-RPC (JSON Remote Procedure Call) — более современный аналог XML-RPC. Основное отличие — данные передаются в формате JSON.
REST (Representational State Transfer) — архитектурный стиль взаимодействия компьютерных систем в сети основанный на методах протокола HTTP.
Специализированные протоколы для конкретного вида задач, такие как GraphQL.
Менее распространенный, но более эффективный gRPC, передающий данные в бинарном виде и использующий HTTP/2 в качестве транспорта.

Остальные протоколы не так широко распространены. Подробно рассмотрены в статье будут SOAP и REST.

SOAP

SOAP (Simple Object Access Protocol) — Данные передаются в формате XML.

отраслевой стандарт по версии W3C;
наличие строгой спецификации;
широкая поддержка в продуктах Microsoft,
однозначность.

сложность реализации;
сложность/ресурсоемкость парсинга XML-данных.

Любое сообщение в протоколе SOAP — это XML документ, состоящий из следующих элементов (тегов):

Envelope. Корневой обязательный элемент. Определяет начало и окончание сообщения.
Header. Необязательный элемент — заголовок. Содержит элементы, необходимые для обработки самого сообщения. Например, идентификатор сессии.
Body. Основной элемент, содержит основную информацию сообщения. Обязательный.
Fault. Элемент, содержащий информацию об ошибках, возникающих в процессе обработки сообщения. Необязательный.

Пример SOAP запроса:

Пример SOAP ответа:

REST

REST (Representational State Transfer) — на самом деле архитектурный стиль, а не протокол. В отличие от SOAP, REST не подкреплен официальным стандартом. Фактически, он основывается на соглашениях. Веб-сервис, построенный с учетом всех требований и ограничений архитектурного стиля, можно назвать RESTful веб-сервисом.

REST не использует конвертацию данных при передаче, данные передаются в исходном виде — это снижает нагрузку на клиент веб-сервиса, но увеличивает нагрузку на сеть. Управление данными происходит с помощью методов HTTP:

GET — получить данные;
POST — добавить данные;
PUT — изменить данные;
DELETE — удалить данные.

Использование этих методов позволяет реализовать типичный CRUD (Create/Read/Update/Delete) для любой информации. Но это лишь соглашение: часто используются только 2 метода: GET для получения и POST для всего остального. Разобраться поможет такое понятие, как REST-Patterns . Паттерны связывают HTTP методы с тем, что они делают.

простота реализации;
экономичность в плане ресурсов;
не требует программных надстроек (json_decode есть почти в каждом языке).

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

Пример REST запроса:

Пример REST ответа:

Что же использовать?

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

Если же вы разрабатываете публичное API и логика взаимодействия во многом покрывается четверкой методов CRUD — смело выбирайте REST. Он наиболее популярен в WEB. Яндекс, Google и другие используют именно его для своего API.

Веб-сервисы в Битрикс

Подробное описание реализации веб-сервисов с помощью средств Битрикс можно найти в статье Веб-сервисы в Битриксе (пример) .

Веб-сервисы в живом производстве

Разработка веб-сервисов — типичная задача интеграции. ИНТЕРВОЛГА, как веб-интегратор, регулярно сталкивается с задачами разработки веб-сервисов и успешно с ними справляется. Наши сайты были и SOAP/REST серверами, и SOAP/REST клиентами.

Успешным примером внедрения веб-сервисов является проект Enterprise-уровня — Личный кабинет клиентов компании Евраз Металл Инпром . Все функции личного кабинета основываются на взаимодействии с удаленным SOAP веб-сервисом. Сайт выступает клиентом. В процессе эволюции в угоду безопасности сайт переквалифицировался в SOAP-сервер, а учетная система в SOAP-клиента.

Еще один личный кабинет для клиентов компании Евраз — еще один пример сайта в качестве клиента удаленного SOAP веб-сервиса.

Если у вас есть потребность организовать взаимодействие с веб-сервисом, сделать из сайта REST/SOAP/RPC клиент или сервер, обращайтесь к нам.

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

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

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

Интеграция на уровне представления. Данный уровень позволяет пользователю взаимодействовать с приложением. Интеграция на уровне представления дает доступ к пользовательскому интерфейсу удаленных приложений.
Интеграция на уровне функциональности. Данная интеграция подразумевает обеспечение прямого доступа к бизнес-логике приложений. Это достигается непосредственным взаимодействием приложений с API (программному интерфейсу приложений) или же взаимодействием посредством веб-сервисов.
Интеграция на уровне данных. В данном случае предполагается доступ к одной или нескольким базам данных, используемых удаленным приложением.
Комплексная интеграция. Коммерческие решения по веб-интеграции, как правило, включают все три типа интеграции

Использование веб-интеграции выгодно по многим причинам:

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

Для веб-интеграции обычно используется коммерческое ПО или популярные технологии, такие как PHP/Python/Perl, XForms, SOAP и т.д.

Интеграция на основе XML

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

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

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

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

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

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

Интеграция на основе XML практически реализуется в рамках протоколов:

XML-RPC. Это протокол удаленного вызова процедур с передачей данных в формате XML через TCP-порт 80, т.е. HTTP -порт.
WDDX (Web Distributed Exchange). Представляет собой механизм обмена сложными структурами данных по протоколу HTTP. Протокол базируется не на структурах, а на событиях.
ebXML (electronic buisiness XML) – XML для электронного бизнеса. Основное назначение – предоставление открытой XML-инфраструктуры, обеспечивающей безопасное глобальное использование информации электронного бизнеса.
Веб-сервисы (веб-службы).

Веб-сервисы

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

Сервис-ориентированная архитектура ( SOA , service-oriented architecture ) — модульный подход к разработке программного обеспечения, основанный на использовании сервисов со стандартизированными интерфейсами.

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

Интерфейс компонентов SОА-программы осуществляет инкапсуляцию деталей реализации конкретного компонента (ОС, языка программирования и т. п).

SOA хорошо зарекомендовала себя при построении крупных корпоративных программных систем. Целый ряд разработчиков и интеграторов предлагают инструменты и решения на основе SOA (например, платформы Microsoft . NET , IBM WebSphere, SAP NetWeaver, Diasoft и др.).

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

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

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

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

При работе веб-сервисов . NET используется технология ASP . NET , являющаяся частью системы . NET Framework. Она также требует поддержки со стороны сервера Microsoft IIS .

Работа веб-сервисов построена на использовании нескольких открытых стандартов:

XML - расширяемый язык разметки, предназначенный для хранения и передачи структурированных данных;
SOAP - протокол обмена сообщениями на базе XML;
WSDL - язык описания внешних интерфейсов веб-сервисов на базе XML;
UDDI - универсальный интерфейс распознавания, описания и интеграции (Universal Discovery, Description, and Integration). Каталог веб-сервисов и сведений о компаниях, предоставляющих веб-сервисы во всеобщее пользование или конкретным компаниям.

Спецификация WSDL

Каждый веб-сервис предоставляет документ WSDL ( Web Service Description Language - язык описания веб-сервиса), в котором описывается все, что клиенту необходимо для работы с этим сервисом. WSDL -документ предоставляет простой и последовательный способ задания разработчиком синтаксиса вызова любого веб-метода. Более того, этот документ позволяет использовать инструменты автоматического генерирования прокси-классов, подобные включенным в среды Visual Studio . NET и . NET Framework. Благодаря указанным средствам использование веб-сервиса является таким же простым, как и применение локального класса.

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

Протокол SOAP

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

SOAP (Simple Object Access Protocol - простой протокол доступа к объектам) представляет собой протокол сообщений для выбора веб-сервисов.

Основная идея стандарта SOAP заключается в том, что сообщения должны быть закодированы в стандартизированном XML -формате.

Кроме сообщений SOAP , для обмена данными с сервисами . NET можно использовать методы GET и POST протокола HTTP .

Преимущества применения формата SOAP перед другими форматами для передачи данных:

Кодировать в XML структуры данных и наборы DataSet с использованием SOAP так же легко, как и данные простых скалярных типов.
При использовании SOAP-сообщений предоставляются дополнительные инструменты, позволяющие легко добавлять, например, функции обеспечения безопасности или трассировки.
Имеются наборы инструментов SOAP для различных языков программирования (и даже для предыдущих версий Microsoft C++ и Visual Basic). Иначе, для того чтобы обеспечить связь с сервисом посредством методов GET и POST протокола HTTP, придется, очевидно, самостоятельно конструировать строку запроса, а затем проводить синтаксический анализ ответа.

Стандарт DISCO

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

DISCO- файл может включать файлы различных веб-серверов и поддерживает "динамический поиск " - автоматический поиск каталога файлов веб-сервисов на сервере.

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

Спецификация UDDI

Спецификация UDDI (Universal Description , Discovery , and Integration - универсальное описание, поиск и интеграция ) позволяет избежать указанных проблем посредством использования специального хранилища (репозитория), где предприятия и организации могут размещать данные о предоставляемых ими сервисах. Инициаторами создания технологии UDDI стали более 100 компаний (полный список можно найти по адресу http ://www. uddi .org/community.html), включая Sun и Microsoft. Объединив свои усилия, эти компании разработали проект спецификации UDDI , которая по истечении 18 месяцев была стандартизирована.

Информация в этом репозитории должна обновляться вручную. С этой целью некоторые "узловые операторы " хранят идентичные копии репозитория UDDI . Эти компании обеспечивают хранение указанного репозитория и бесплатный доступ к нему для популяризации веб-серисов. Кроме того, Майкрософт включила версию UDDI в программное обеспечение сервера Windows . NET для использования в корпоративных сетях интранета.

Главными недостатками веб-сервисов являются меньшая производительность и больший размер сетевого трафика по сравнению с такими технологиями как RMI , CORBA , DCOM за счет использования текстовых XML -сообщений.

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

Интеграция на уровне представления. Данный уровень позволяет пользователю взаимодействовать с приложением. Интеграция на уровне представления даёт доступ к пользовательскому интерфейсу удаленных приложений.

Интеграция на уровне функциональности. Данная интеграция подразумевает обеспечение прямого доступа к бизнес-логике приложений. Это достигается непосредственным взаимодействием приложений с API (программному интерфейсу приложений) или же взаимодействием посредством веб-сервисов.

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

Комплексная интеграция. Коммерческие решения по веб-интеграции, как правило, включают все три типа интеграции

Использование веб-интеграции выгодно по многим причинам:

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

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

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

Веб-интеграция позволяет использовать веб-сервисы разработчиков.

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

Интеграция на основе xml

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

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

средства разработки и стандартные библиотеки для XML существуют практически на всех платформах и для большинства популярных языков программирования;

методы работы с XML достаточно стандартны для того, чтобы в разных системах можно было пользоваться одинаковыми приемами;

информация, оформленная в виде XML, может обрабатываться не только машинами, но и человеком (что намного облегчает отладку).

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

XML языки не зависят от аппаратных и программных платформ, что позволяет связывать разнородные системы;

выразительная мощность XML достаточно велика для того, чтобы описать данные практически любой сложности;

Интеграция на основе XML практически реализуется в рамках протоколов:

XML-RPC. Это протокол удаленного вызова процедур с передачей данных в формате XML через TCP-порт 80, т.е. HTTP -порт.

WDDX (Web Distributed Exchange). Представляет собой механизм обмена сложными структурами данных по протоколу HTTP. Протокол базируется не на структурах, а на событиях.

ebXML (electronic buisiness XML) – XML для электронного бизнеса. Основное назначение – предоставление открытой XML-инфраструктуры, обеспечивающей безопасное глобальное использование информации электронного бизнеса.

Веб-сервисы (веб-службы).

Веб-сервисы (веб-службы)

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

Сервис-ориентированная архитектура (SOA, service-oriented architecture) — модульный подход к разработке программного обеспечения, основанный на использовании сервисов со стандартизированными интерфейсами.

SOA хорошо зарекомендовала себя при построении крупных корпоративных программных систем. Целый ряд разработчиков и интеграторов предлагают инструменты и решения на основе SOA (например, платформы Microsoft .NET , IBM WebSphere, SAP NetWeaver, Diasoft и др.).

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

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

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

Поддержка сообщений на понятном человеку языке. Переход от двоичных стандартов, применяемых в СОМ и CORBA, к XML-тексту позволил упростить исправление ошибок и обеспечил возможность осуществлять взаимодействие с веб-сервисами по обычным каналам HTTP.

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

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

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

Потребитель находит созданный веб-сервис и может добавить соответствующую веб-ссылку в проект Visual Studio .NET.

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

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

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

Затем прокси-класс получает SOAP-ответ, преобразует его в соответствующий тип данных и возвращает его как обычный тип данных .NET.

Потребитель использует полученные данные.

При работе веб-сервисов .NET используется технология ASP .NET, являющаяся частью системы .NET Framework. Она также требует поддержки со стороны сервера Microsoft IIS.

Работа веб-сервисов построена на использовании нескольких открытых стандартов:

XML - расширяемый язык разметки, предназначенный для хранения и передачи структурированных данных;

SOAP - протокол обмена сообщениями на базе XML;

WSDL - язык описания внешних интерфейсов веб-сервисов на базе XML;

UDDI - универсальный интерфейс распознавания, описания и интеграции (Universal Discovery, Description, and Integration). Каталог веб-сервисов и сведений о компаниях, предоставляющих веб-сервисы во всеобщее пользование или конкретным компаниям.

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

Оптимальный способ интеграции — это API (application program interface) или программный интерфейс приложения. Мы привыкли, что купленный билет в кино автоматически добавляется в календарь, а моментально авторизовавшись через google-аккаунт можно оставить комментарий. Именно API соединяет сайт с внешним миром и позволяет совершить необходимое действие – регистрацию, покупку, подписку, не уходя с сайта.

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

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

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

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

Какие функциональности можно таким образом добавить на сайт

А также сервисы для быстрой отправки имейла, использования электронной подписи, карты Google Maps, стриминговые платформы или Wikipedia.

Вот как мы интегрировали внешние сервисы на своих проектах.

МегаФон

Бизнес-задача:

Подключить на сайте megafon.ru оплату банковской картой. Для этого был выбран сервис онлайн-платежей InPlat.

В документации от сервиса Inplat прописаны сценарии оплаты с подтверждением или без, единичная оплата или привязка карты. Когда абонент собирается оплатить услуги на сайте МегаФона, он получает ответ системы:

МегаФон отправляет в систему InPlat метод init (или form);
Система отвечает, что успешно приняла инициацию;
Система пытается списать введенную сумму с карты абонента, используя данные, которые он ввел в форме на сайте (init или form);
Система оповещает сайт МегаФона о результате проведения платежа методом result;
Сайт МегаФона отвечает об успешном получении метода result.

Реализация:

Интеграция – это организация обмена информацией с сервисом-поставщиком данных. Поставщик данных определяет способ взаимодействия со своим сервисом и описывает ее в документации. Это запросы к интерфейсу API по протоколу http различного предназначения — получение информации, изменение, удаление, добавление сущности. Разработчик сайта МегаФон видит API и пишет код, который обращается к API. Сайт МегаФона предоставляет форму, после того, как пользователь ее заполняет, запрос отправляется к API InPlat. Дальше запрос обрабатывается на стороне InPlat.

Nikon

Бизнес-задача:

Провести розыгрыш призов, с механикой, основанной на верификации чеков.

Мы создали несколько лендингов для акций Nikon. Их механика отличалась, например, в акции Я свобода творчества после покупки техники Nikon, покупатель может зарегистрировать чек и получить годовую подписку на пакет программ Adobe Creative для фотографов. Пользователь отправляет номер и фотографию чека, серийный номера проверяется на официальном сайте Nikon, после чего пользователь получает ключ доступа к программам. В этом случае сначала необходима интеграция с API Nikon, а потом с API Adobe.

В акции Я объективно лучший подарок пользователь регистрирует свой чек на покупку и может получить подарок в фирменном магазине Nikon. Чтобы сразу на лендинге акции узнать адреса магазинов, мы подключили интерактивную карту.

Реализация:

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

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

PepsiCo

Бизнес-задача:

Создать единую платформу для промоактивностей PepsiCo
Интегрировать платформу с имеющейся CRM

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

Реализация:

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

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

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

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

Особенности интеграции

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

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

Читайте также: