SOA. СМЭВ. Электронный обмен или обман. Проблемы интеграции

АБСТРАКТ

https://ic.pics.livejournal.com/ss69100/44650003/1731472/1731472_300.jpgДо настоящего времени в мире не было эффективных подходов к решению проблем интеграции и совместного комплексного использования множества программных продуктов, разработанных на различных аппаратно-программных платформах, языках и архитектурах в разное время различными разработчиками.

Интеграция, взаимодействие и синхронизация развития программных приложений должны обеспечивать СЕМАНТИЧЕСКУЮ ИНТЕРОПЕРАБЕЛЬНОСТЬ (СИ, Semantic Interoperability) – осмысленное взаимодействие множества созданных и вновь создаваемых информационных систем.

Все говорят о необходимости создания Системы Систем (System of Systems, SoS).

Сервис-Ориентированная Архитектура (Service-Оriented Architecture, SOA), которую безуспешно пытаются использовать во всех странах мира в том числе IBM, ORACLE, SAP, Microsoft, GOOGLE, Яндекс и другие для обеспечения Системы Межведомственного Электронного Взаимодействия/СМЭВ различного программного обеспечения (ПО) не принесла и в принципе не может принести решение нарастающих проблем.

Почему? Где выход?

Реализован «заказ» на изобретение: поиск и создание новой фундаментальной научной основы и единой сетецентричной GGG-архитектуры+платформы (Глобальный Гносеологический Граф/Global Gnoseology Graph, GRAPH, G3), в которых «врожденных» недостатков и проблем интеграции в принципе нет.

Ключевые слова: программирование, программное обеспечение, интеграция приложений, единое информационно-функциональное пространство, Система Систем (System of Systems, SoS), экосистема, Сервис-Ориентированная Архитектура (SOA, Service-oriented Architecture), Система Межведомственного Электронного Взаимодействия/СМЭВ, управление изменениями требований, семантическая интероперабельность, «интернет вещей»  (Internet of Things, IoT) «интернет всего» (Internet of Everything), сетецентрическая GGG-архитектура (Глобальный Гносеологический Граф (Global Gnoseology Graph, GRAPH, G3),…

АКТУАЛЬНОСТЬ ПРОБЛЕМЫ

«Информационная эпоха», «цифровая экономика», «электронное государство», «умные города, дома, машины, вещи,…», «интернет всего» (Internet of Everything), «большие данные» (Big Data), «виртуальный мир», системы «искусственного интеллекта» сегодня захватили умы, кошельки, пространство и время человечества.

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

Например, приведем краткий перечень общеупотребимых видов модулей систем управления для предприятия:

MRP – Material Requirements Planning, ERP – Enterprise Resource Planning, AMHS – Automated Material Handling System, APC – Advanced Process Control, APS – Advanced Planning & Scheduling, BPM – Business Process Management, CMM – Collaborative Manufacturing Management, CPAS – Collaborative Process Automation System, CPM – Collaborative Production Management, VMI – Vendor Managed Inventory, CPS – Collaborative Planning & Scheduling, CRM – Customer Relationship Management, CSR – Customer Service Representative, EAM – Enterprise Asset Management, EMS – Electronic Manufacturing Services, LIMS – Laboratory Information Management System, WMS – Warehouse Management System, NPI – New Product Introduction, OpX – Operational Excellence, PAM – Plant Asset Management, PDM – Plant Data Management, PLM – Product Lifecycle Management, PSC – Plant Services Connector, PSM – Product Service Management, SBA – Service-Based Architecture, SBI – Service-Based Infrastructure, SCM – Supply Chain Management, SCPM – Supply Chain Process Management, SEM – Strategic Enterprise Management, SFA – Sales Force Automation, SRM – Supplier Relationship Management, TMS – Transportation Management System, KM – Knowledge Management,…
https://imgprx.livejournal.net/68780d717be22204e1c1c308eebc42180febd953/QQV-6hBbqyamZfnsJG8HlYj06DoUGoy5ROebqK8TGWfW9Vl3WbniezvrLe4SOJi4ISdavGPmkq6om9lSYQFuFdgjckFBZ8H8_Gt3RNeo6ig

Как эти системы и соответствующие им модули программного обеспечения семантически (по смыслу) взаимоувязаны, интегрированы?

Никак.

А комплексный объект, где они должны вместе согласованно работать, оптимально взаимодействовать и обеспечивать эффективные обоснованные решения – один и един, например, обычная транснациональная корпорация (ТНК) или исполнительные органы власти (правительство) страны.

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

Может ли различное ПО синхронизировать между собой свое развитие?

НЕТ, НИКОГДА.

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

Они требуют дорогостоящих реинжинирингов, реструктуризаций и реформирования технологических и бизнес-процессов для соответствия жесткому каркасу предлагаемого архитектурного и функционального программного решения, созданного 5-10-30-50 лет назад.

Внедряемые, продвигаемые и анонсируемые решения всех мировых лидеров IBM, ORACLE, SAP, Microsoft, GOOGLE, Яндекс и других, в полной мере служат историческими экспонатами таких традиционных архаичных подходов, но при этом они порой уже сами верят в собственные же рекламные иллюзии провозглашаемого технологического превосходства в создании единого информационного пространства.

Из-за многочисленных слияний, поглощений, финансовой монополизации ИТ-рынков, проблемы интеграции всего приобретенного ПО даже внутри компаний IBM, Microsoft, SAP, ORACLE GOOGLE, Яндекс и других только нарастают и становятся неразрешимыми.

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

Итак, острыми критичными проблемами стали ИНТЕГРАЦИЯ программного обеспечения, «бесшовное» on line ВЗАИМОДЕЙСТВИЕ и СИНХРОНИЗАЦИЯ РАЗВИТИЯкак внутри этих условно «монолитных» программных продуктов «черных ящиков», так и с внешними программами других производителей.

Интеграция, взаимодействие и синхронизация развития ПО должны обеспечивать СЕМАНТИЧЕСКУЮ ИНТЕРОПЕРАБЕЛЬНОСТЬ (СИ, Semantic Interoperability) – осмысленное взаимодействие множества созданных и вновь создаваемых информационных систем.

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

Весь мир сегодня ищет принципы и методы создания Системы Систем (System of Systems, SoS), интегрированных комплексных платформ и экосистем, единого информационно-функционального пространства и т.п.

СЕМАНТИЧЕСКАЯ ИНТЕРОПЕРАБЕЛЬНОСТЬ

В настоящее время при интеграции программного обеспечения в современном определении «Семантической Интероперабельности (СИ) информационных систем»(Wikipedia) акцент делается на видимую и меньшую (хотя и очень трудную) часть задачи: на обмен данными между информационными системами и полную автоматическую интерпретацию принимающей системой смысла передаваемой информации.

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

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

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

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

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

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

Например, для реализации осознанного взаимодействия людей — прежде всего надо было именно их (людей) системно в идентичных правилах порождать и обеспечить близость человеческих генов в ДНК (при сохранении всей индивидуальности). Так как способность обменяться сообщениями с собакой или тараканом у нас так же есть, а вот с семантическим взаимодействием – уже на порядки сложнее.

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

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

• инфраструктурное (общее) программное обеспечение,


• функциональное (предметно-ориентированное) программное обеспечение.

К инфраструктурному программному обеспечению относятся программные продукты, для которых характерна абстрактность понятия обрабатываемой информации. Классические примеры — операционные системы, текстовый процессор, табличный процессор, система управления базами данных (СУБД), геоинформационная система (ГИС), почтовая система, мессенджер и т.д.

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

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

Для функциональных программ складывается совсем другая ситуация в связи со следующими их особенностями:

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


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


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

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

Интероперабельность (взаимодействие) функциональных информационных систем может и должна быть только СЕМАНТИЧЕСКОЙ.

ТРАДИЦИОННЫЕ МЕТОДЫ ИНТЕГРАЦИИ И ОБЕСПЕЧЕНИЯ ВЗАИМОДЕЙСТВИЯ

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

НАПРАВЛЕНИЕ 1: Интеграция функциональных информационных систем с реализацией подсистем экспорта-импорта («электронных документов») для каждой пары различных объединяемых систем.

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

Данные методы экспорта-импорта используются последние семьдесят лет.

НАПРАВЛЕНИЕ 2: Интеграция функциональных систем с помощью «универсальной» среды обмена сообщениями.

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

Кроме того, была предложена некая «новая» Сервис Ориентированная Архитектура (SOA — Service-oriented Architecture), которая должна была сказочным образом обеспечивать создание единого информационного пространства и помочь в решении проблем неполноты, нецелостности, противоречивости, избыточности, несопоставимости и т.п. данных различных функциональных систем.

Эти принципы создания Системы Систем и Сервис-Ориентированной Архитектуры безуспешно пытаются использовать во всех странах мира в том числе для обеспечения Системы Межведомственного Электронного Взаимодействия/СМЭВразличного программного обеспечения (ПО).

Данные методы предлагаются последние 15-20 лет.

https://imgprx.livejournal.net/d4edd7b6566c046577be5c2619251ea00fd76e0b/QQV-6hBbqyamZfnsJG8HlYj06DoUGoy5ROebqK8TGWfW9Vl3WbniezvrLe4SOJi4ISdavGPmkq6om9lSYQFuFcjSeNhDZaDwPCZoxIt1BmI

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

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

IT-лидерами IBM, Microsoft, ORACLE, SAP и другими сделаны баснословные финансовые вложения в эти направления интеграции, выпущены и рекламируются программные продукты в архитектуре SOA.

Они стали инициаторами и заложниками многомиллиардной мировой «цифровой» SOA-аферы 21 века, обманув ожидания миллионов заказчиков.

Цели «эффективной семантической интероперабельности» множества функциональных информационных систем до сих пор никем не достигнуты.

Почему?

ПОЧЕМУ SOA, СМЭВ БУКСУЮТ В ТУПИКЕ

До настоящего времени большинство усилий в исследованиях методов интеграции направлено на создание универсальных шлюзов и технологий формирования и сопровождения «среды общения» между несопоставимыми программами.

Ожидается открытие секрета этакого универсального программного «клея» для воды, камня, огня, газа, бумаги, кислоты и т.п.

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

И все мировые ИТ-вендоры начали фантазировать на распиаренную тему SOA.

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

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

То есть, например, в случае с реализацией Единого портала государственных услуг РФ предполагается, что система межведомственного электронного взаимодействия (СМЭВ) на основе SOA будет действовать следующим образом: заявка на услугу, заполненная в электронном виде на портале, передается сервису ведомства и далее в обработку внутренними системами.

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

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

Кстати, для информации:

Государственная дума РФ принимает в год более 3000 законодательных актов.

А сколько «думы» 83 регионов?

А сколько 22 000 муниципалитетов?

А сколько в день?

А каково количество существенных изменений в каждом документе?

Что же регламентирует SOA-парадигма? Как она решает эти проблемы?

Каково содержание множества принятых в мире законодательных актов и так называемых стандартов, в том числе, например, в России по поводу реализации СМЭВ с использованием архитектуры SOA?

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

https://imgprx.livejournal.net/ec586cdf3665c062d3edf9738018ed58351bafdc/QQV-6hBbqyamZfnsJG8HlYj06DoUGoy5ROebqK8TGWfW9Vl3WbniezvrLe4SOJi4ISdavGPmkq6om9lSYQFuFTiMUjewSBoI9AKFk-cO1vE

Например, приведем далеко неполный их перечень, в том числе первые документы Организации по развитию стандартов структурированной информации — Organization for the Advancement of structured Information Standards (OASIS), Консорциума Всемирной Паутины – World Wide Web Consortium (W3C), которые надо учитывать разработчику функциональных информационных систем и новых сервисов обмена:

• Протокол передачи гипертекста, Hypertext Transfer Protocol (HTTP)


• Комментарии инженерной группы проектировщиков информационно-коммуникационной сети Интернет, RFC (Request for Comments)


• Безопасность Транспортного уровня, TLS (Transport Layer Security)


• Протокол защищенных соединений, SSL (Secure Socket Layer)


• Набор протоколов для обеспечения защиты данных, передаваемых по межсетевому протоколу, IPsec (IP Security)


• Система поддержки пространства имен, DNS (Domain Name System)


• Спецификация универсального описания, поиска и интеграции электронных сервисов версии 2.0 (Universal Description Discovery and Integration, UDDI 2.0)


• Протокол обмена структурированными сообщениями, Simple Object Access Protocol, SOAP


• Язык описания электронных сервисов версии 1.1, Web Services Description Language, WSDL 1.1.


• Базовый профиль интероперабельности версии 1.1, WS-I Basic Profile 1.1.


• Политика использования электронных сервисов версии 1.2, Web Service Policy 1.2.


• Профиль интероперабельности по передаче бинарных данных, WS-I Attachments Profile 1.0.


• Оптимизированный механизм передачи бинарных данных в структурированных сообщениях SOAP, Message Transmission Optimization Mechanism


• Профиль сопоставления данных версии 1.0, WS-I Simple SOAP Binding Profile 1.0.


• Спецификация универсального описания, поиска и интеграции электронных сервисов версии 3.0, Universal Description Discovery and Integration, UDDI 3.0.


• Расширяемый язык разметки XML, Extensible Markup Language


• Расширяемый язык описания схем данных версии не ниже 1.0, XML Schema 1.0, XML Schema 1.1.


• Расширяемый язык описания таблиц стилей версии 1.1, Extensible Stylesheet Language, XSL v. 1.1.


• Правила форматирования и преобразования данных XSL Transformation, XSLT


• Язык описания схем данных, XML Schema Definition, XSD


• и многие другие…