Лекция 11 Технологии взаимодействия приложений.
Дата добавления: 2014-07-28 ; просмотров: 1356 ; Нарушение авторских прав
1. Использование библиотек динамической компоновки — DLL
DLL (англ. Dynamic-link library – динамически подключаемая библиотека) понятие операционной системы Microsoft Windows; динамическая библиотека, позволяющая многократное применение различными программными приложениями. К DLL относятся также элементы управления ActiveX и драйвера. В мире UNIX аналогичные функции выполняют т. н. shared objects («разделяемые объекты»).
Формат файлов DLL придерживается тех же соглашений, что и формат исполняемых файлов, сочетая код, таблицы и ресурсы.
Цели введения DLL
Первоначально предполагалось, что введение DLL позволит эффективно организовать память и дисковое пространство, используя только одну инстанцию библиотечных модулей для многих приложений. Это было особенно важно для ранних версий Microsoft Windows с жёсткими ограничениями по памяти.
Далее, предполагалось улучшить эффективность разработок и использования системных средств за счёт модульности. Замена DLL-программ с одной версии на другую должна была позволить независимо наращивать систему, не затрагивая приложений. Кроме того, библиотеки DLL могли использоваться разнотипными приложениями — например, Microsoft Office, Microsoft Visual Studio и т. п.
В дальнейшем идея модульности выросла в концепцию СОМ.
Фактически, полных преимуществ от внедрения DLL получить не удалось по причине явления, называемого DLL hell («ад DLL»). DLL Hell возникает, когда несколько приложений требуют одновременно различные, не полностью совместимые, версий DLL-библиотек, что приводит к сбоям в этих приложениях. Когда система выросла до определённых размеров, количество DLL стало превышать многие тысячи, не все из них обладали полной надёжностью и совместимостью, и конфликты типа DLL Hell стали возникать очень часто, резко понижая общую надёжность системы. Поздние версии Microsoft Windows стали разрешать параллельное использование разных версий DLL, что свело на нет преимущества изначального принципа модульности.
Статическая компоновка представлена на рис. 9.1
Во всех ОС имеются участки кодов, которые могут пользоваться библиотекой кодов
Существуют следующие типы переходников:
1. активный переходник — фрагмент кода, который устанавливает первоначальную связь между базой данных и библиотечного модуля.
2. переходник для данных — в DLL библиотеке могут храниться и данные, например шрифты.
3. переходник динамической компоновки — (см. рис. 9.2). Переходник выполняет подсчет обращений и определяет адрес функции.
Если много программ работает с одними и теми же функциями то получается существенная экономия памяти. В случае если одно приложение запрашивает код функции то динамическая компоновка усложняет структуру, увеличивая время обработки. Если два и боле приложений запрашивают код функции то целесообразно использовать DLL.
Использование таких DLL библиотек дает следующие преимущества:
1. Возможность расширения функций приложений за счет DLL других производителей. Для этого необходимо лишь знать перечень функций и способы обращения.
2. Возможность написания программ на различных языках программирования.
3. Простота организации управления проектом по разработке сложного программного комплекса.
4. Экономия оперативной памяти
2 Технология DDE (Dynamic Data Exchange-динамический обмен данных).
Механизм DDE основан на пересылке данных через буфер обмена Windows. Буфер обмена — специальная область память, предоставляемая операционной системой для обмена данных между приложениями.
В Windows существуют средства для работы с буфером обмена. К ним относятся:
функции для помещения данных в буфер и извлечения из буфера;
функции проверки наличия данных в буфере;
предусмотрены 25 встроенных типов данных (изображение, фрагмент текста, звук, и т.д.);
возможность создания собственных типов данных;
возможность обмениваться командами;
Основным преимуществом DDE является его стандартность и наличие во всех версиях Windows. Недостатки DDE:
низкая скорость обмена данных;
низкая надежность, в частности за счет того, что буфер обмена доступен
всем выполняющимся приложениям;
DDE непригоден для обмена технологическими данными, в частности из-за низкой производительности и надежности;
Для преодоления недостатков DDE разработчики предложили свои собственные протоколы Advanced DDE, Fast DDE . В основе лежит пакетирование информации, что позволяет увеличить скорость обмена. Такие частные решения приводят к ряду проблем:
Для каждой SCADА системы, поддерживающей один из этих протоколов необходимы драйверы оборудования, которые поддерживают тот же протокол;
В общем случае две SCADА системы не могут иметь доступ одновременно к одному и тому же драйверу.
Тем не менее, этот механизм используется для получения данных от технологических процессов и для передачи управляющих воздействий (в этом случае SCADA системы выполняют функции клиента по отношению к поставляющему данные драйверу или серверу ввода/вывода), а также для взаимодействия с другими приложениями, например с MS Excel. SCADA системы могут быть как клиентами так и серверами.
В основу DDE положен принцип, в котором осуществляется передача адресов блоков памяти, а сами данные располагаются в таблице атомов.
Таблица атомов — область памяти, доступная всем программам для чтения и записи. Адресация в ней ведется при помощи 4-х составляющих: сервис — имя приложения, которое обеспечивает этот сервис; тема; элементы данных; данные.
DDE канал может работать в трех режимах: обычный режим, «теплый» канал, «горячий» канал.
I. Работа DDE канала в обычном режиме (см. рис. 9.3).
II. Организация «теплого» канала (см. рис. 9.4). Создается тогда, когда клиент заранее должен извещаться сервером об изменении данных.
III. Организация «горячего» канала (см. рис. 9.5).
Приложения могут устанавливать одновременно несколько связей с несколькими приложениями. При этом это приложение может быть как клиентом, так и сервером.
Не нашли то, что искали? Google вам в помощь!
Источник
Интеграция корпоративного приложения с внешними системами
Ни одна информационная система не способна решать все задачи компании. Между различными приложениями возникает необходимость обмена данными, делать это вручную сложно и занимает много времени. Необходима автоматическая интеграция с помощью таких технологий, как SOAP, REST, или готовых коннекторов. О технологиях интеграции и их применении в SimpleOne расскажем в нашей статье.
Интеграции в корпоративных приложениях
Корпоративные приложения получают, обрабатывают и передают данные. Зачастую для выполнения одного бизнес-процесса компания использует несколько информационных систем, и между ними происходит обмен данными. Одна система получает информацию от пользователя и передаёт в другие через каналы интеграции. Например, для авторизации на сервисном портале пользователь не создаёт новую учетную запись: система получает данные из Active Directory, а приложение контроля доступа загружает справочник сотрудников из базы данных ERP SAP.
Интеграция ускоряет решение задач, повышает качество, исключая человеческий фактор, снижает стоимость владения информационных систем без посредников и уменьшает издержки.
Простейшие способы интеграции — это обмен файлами и сообщениями или обращение к общей базе данных. Эти способы имеют множество недостатков, особенно в эпоху распространения веб-приложений. Форматы файлов могут отличаться, а выгрузка, загрузка и конвертация — это дополнительное влияние человеческого фактора и труда. Давать всем подряд доступ к одной базе данных и контролировать правильность её использования различными приложениями — серьёзный риск для целостности и безопасности хранения данных.
На смену этим архаичным и неудобным способам интеграции пришли современные технологии, использующие API (интерфейсы прикладного программирования) для связи веб-приложений. Разработчики создают свои информационные системы с API-интерфейсами, чтобы приложения могли взаимодействовать и передавать данные друг другу. Существуют два основных стиля API — SOAP и REST, они имеют различные архитектуры, но в большинстве случаев используют общий транспорт — HTTP-протокол.
Технологии интеграции
SOAP и REST решают одинаковую задачу: позволяют разработчикам с помощью API настраивать обмен данными между приложениями. Но если SOAP является протоколом обмена информацией, то REST — это стиль или набор рекомендаций, которым должен следовать разработчик для предоставления веб-службы — RESTful, то есть разработанной с учётом требований REST и не нарушающей тех ограничений, которые он накладывает.
SOAP — протокол, REST — архитектурный стиль
SOAP (Simple Object Access Protocol) — отлично стандартизированный и давно используемый протокол. Это одна из причин, по которой его выбирают как API корпоративных приложений. Он работает поверх протоколов HTTP, SMTP, TCP или UDP, но передаёт данные только в формате XML. Для устаревших систем и тех, которые производят сложные транзакции, а также предъявляют высокие требования к безопасности, SOAP всё ещё хороший вариант. Он широко применяется в банковских и других финансовых приложениях, CRM, коммунальными службами и при оказании телекоммуникационных услуг. Там, где важна стабильность и целостность данных, используют SOAP, например, работа светофоров, канализации и электроснабжения города должна всегда выполняться безотказно и предсказуемо. Возможность асинхронной передачи данных по SMTP делает этот протокол незаменимым для интеграции в системах с нестабильным каналом связи.
REST (REpresentational State Transfer) — довольно молодой, но очень популярный архитектурный стиль для создания интеграционных API. Он приобрёл популярность у разработчиков в 2018 году, и на текущий момент большинство интернет-сервисов его используют как общедоступный API-интерфейс. Twitter, WordPress, Google Maps и другие известные приложения имеют REST API для взаимодействия с другими веб-сервисами и пользовательскими сайтами.
Для обмена данными REST использует только HTTP в качестве транспортного протокола, но форматы сообщений могут быть любыми — HTML, JSON, XML, YAML или простой текст. Универсальным является формат JSON (JavaScript Object Notatio): его легко анализировать, у него простой синтаксис и он не зависит от языка программирования. В JSON используется меньше слов, его проще писать и читать, такие сообщения имеют меньший вес, поэтому скорость их передачи выше, чем с XML.
REST — простой, удобный и универсальный способ интеграции корпоративных приложений, в большинстве случаев веб-сервисы RESTful могут взаимодействовать с любыми другими сервисами.
SOAP vs REST. REST работает быстрее, а разработка RESTful-сервисов проще. SOAP взаимодействует с операциями, поэтому лучше подходит для реализации транзакций и сложной логики. Кроме того, SOAP может работать с любым протоколом транспортного уровня вместо HTTP и используется в большинстве устаревших информационных систем, с которыми может потребоваться интеграция.
Для чего нужны коннекторы
Для того чтобы упростить настройку взаимодействия между информационными системами, администратор может использовать коннекторы. Коннектор — это готовое решение для взаимодействия с определённым приложением, например системой мониторинга, SAP, SharePoint, 1С и другими. Достаточно указать адрес внешней системы и задать параметры обмена данными, и коннектор сам будет отвечать за взаимодействие, конвертацию и проверку передаваемых сообщений.
Настройку коннекторов администратор выполняет с использованием графического интерфейса приложения (GUI) без необходимости программирования, такой подход отлично вписывается в концепцию No Code.
Пример реализации коннектора — взаимодействие ITSM-системы и системы мониторинга. Для настройки их интеграции администратор ITSM вводит адрес внешней системы, настраивает набор событий, которые должен принимать коннектор, и правила их обработки. Таким образом, ITSM-система оперативно получает информацию от системы мониторинга — коннектор обрабатывает поступающие данные и в соответствии с заданными правилами производит действия с данными ITSM-системы.
Способы интеграции в SimpleOne
Интеграция SimpleOne с другими корпоративными приложениями настраивается через REST API, интерфейс позволяет создавать, читать и обновлять данные в таблицах платформы.
REST-клиент
Чтобы связать стороннее приложение с SimpleOne, администратор должен в редакторе REST-запросов (REST Client) создать запрос к внешнему сервису (REST Request), а также запланировать его регулярное исполнение. В панели администрирования создаётся REST-запрос, для него указывается заголовок, дополнительные методы запроса и их параметры при необходимости, а также профили аутентификации.
Настройку REST-запросов и REST Bot Engine может выполнить администратор платформы с помощью GUI без глубоких знаний API и навыков программирования.
Настройка REST API в SimpleOne: пример настройки запроса для интеграции co Slack 
Настройка REST API в SimpleOne: пример настройки заголовка запроса 
Настройка REST API в SimpleOne: пример настройки дополнительных методов
Коннекторы
Отдельно в SimpleOne реализован коннектор для интеграции с мессенджерами и системами искусственного интеллекта — REST Bot Engine. Он позволяет настроить взаимодействие с чат-ботами и передавать информацию о происходящих в системе событиях в мессенджеры ответственных сотрудников. Например, при создании пользователем инцидента члены группы технической поддержки получат сообщение об этом прямо в свой мессенджер.
REST API
ESM-платформа SimpleOne предлагает задокументированный набор готовых операций с данными для взаимодействия сторонних систем с нашей платформой посредством REST API.
Scripted REST API
Когда готовых методов для работы сторонней системы с данными SimpleOne недостаточно, можно создать свои собственные сценарии обработки запросов с помощью инструмента Scripted REST API. Для этого достаточно создать новый модуль API, с помощью low-code-инструментария настроить действия и параметры, после чего связать параметры запросов к API с созданными модулями и действиями.
Это позволит настроить сложную логику обработки REST-запросов от внешних систем.
Заключение
Наличие API для веб-приложения — это общепринятый стандарт корпоративной интеграции. Он позволяет бизнес-платформам, решающим различные задачи, взаимодействовать без дополнительной разработки. В SimpleOne реализованы no-code-инструменты для настройки запросов к внешним системам, REST API с возможностью его расширения через интерфейс системы, а также универсальные и специализированные коннекторы к популярным информационным системам. Всё это позволяет быстро настраивать взаимодействие со сторонними сервисами, мессенджерами и другими приложениями. Основные настройки производятся с помощью графического интерфейса, не требующего глубоких знаний языков программирования от администратора.
Источник
