Напечатать документ Послать нам письмо Сохранить документ Форумы сайта Вернуться к предыдущей
АКАДЕМИЯ ТРИНИТАРИЗМА На главную страницу
Дискуссии - Технологии

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

Oб авторе

АБСТРАКТ

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

Интеграция, взаимодействие и синхронизация развития программных приложений должны обеспечивать СЕМАНТИЧЕСКУЮ ИНТЕРОПЕРАБЕЛЬНОСТЬ (СИ, 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,…


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

Никак.

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

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

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

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

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

Они требуют дорогостоящих реинжинирингов, реструктуризаций и реформирования технологических и бизнес-процессов для соответствия жесткому каркасу предлагаемого архитектурного и функционального программного решения, созданного 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 лет.



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

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

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

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

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

Почему?


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



Например, приведем далеко неполный их перечень, в том числе первые документы Организации по развитию стандартов структурированной информации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
  • и многие другие.

О чем так многочисленно, многословно и глобально пафосно?

Постараемся на человеческом языке изложить суть ну хотя бы применительно к родному СМЭВу. Все эти документы содержат описание общих подходов и принципов к реализации функции обмена данными включающие:

«формирование, ведение и актуализацию единого реестра Участников СМЭВ, обеспечивающего регламентированное предоставление доступа к ней; реализацию механизмов предоставления электронных сервисов Потребителям, включая обеспечение интеграционной логики электронного сервиса и вызовы необходимых служб Поставщиков в требуемой последовательности, задаваемой межведомственным административным регламентом исполнения государственной услуги (функции); реализацию механизмов публикации электронных служб Поставщиков, доступных для использования электронными сервисами СМЭВ; реализацию механизмов получения, обработки и гарантированной доставки электронных сообщений в рамках межведомственного информационного взаимодействия с обеспечением фиксации времени, с обеспечением целостности, подлинности, авторства и возможности предоставления необходимых свидетельств, позволяющих восстановить ход событий в процессе оказания государственных и муниципальных услуг в электронном виде и при межведомственном информационном взаимодействии; обеспечение защиты передаваемой информации от несанкционированного доступа, искажения или блокирования; ведение журнала межведомственного информационного взаимодействия Участников через СМЭВ; формирование необходимой отчетности о процессе информационного межведомственного взаимодействия» и многое другое такого же качества.

Опять сложно?

А всё выше сказанное регламентирует пока только лишь процедуру обмена служебными сообщениями.

Какими?



Например, следующими видами сообщений:

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


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

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

Да, можно стандартизовать вид почтового конверта, но получателям и отправителям нужно другое — смысл самого письма!

А что же в этих обязывающих документах по существу, предмету, смыслу, семантике, функциям, данным, бизнес-процессам, объектам и процессам управления, реальной жизни (ну как ещё спросить о главном?!) в реализации электронного межведомственного взаимодействия самих функциональных информационных систем при обеспечении электронных услуг?

Ничего! Ни Слова!

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

Министры и айтишники бодро и радостно рапортуют — у нас приходит сто тысяч запросов, миллион запросов, «квадраллион» запросов ...

Ничего не напоминает?

Хлестаковщина в мировом масштабе: «...курьеры, курьеры, курьеры... можете представить себе, тридцать пять тысяч одних курьеров!»

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

Никогда!

Повторю, стратегия развития информационных архитектур и технологий, ориентированная на SOA, является тупиком.

Нет в SOA принципиальных решений по реализации высокой динамики структурного изменения информационно-функционального пространства.

Не решен вопрос:

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

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

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

SOA — отличный глобальный бизнес-проект не ОБМЕНА, а ОБМАНА и «развития» ИТ для нового вида освоения денежных средств заказчика:

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

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

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

Катастрофа!

Модернизация и интеграция миллионов модулей фрагментарных информационных систем всех компаний мира: SAP, ORACLE, GOOGLE, EADS, THALES, LOCKHEED MARTIN, IBM, Microsoft, SAS и других – находится в концептуальном тупике, создает угрозу национальной и глобальной безопасности.

Кроме того, ИТ-специалисты одумайтесь, откройте глаза!

Надо наконец понять полную абсурдность SOA-предложений, в том числе лидеров информационных технологий: IBM, Microsoft, ORACLE, SAP и других:

Предлагается проблемы семантической интероперабельности N-интегрируемых функциональных программных систем (модулей) решить, добавив к ним ещё новых М-программных систем интеграции.

Все равно, что огонь заливать бензином!

То есть попытки справиться со сложностью привели к еще большему усложнению.

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

Но король-то голый!

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


Доказана теорема:

семантическая интероперабельность трёх и более динамических программных приложений не достижима. 

Service-Оriented Architecture/SOA - Сервис-Ориентированная Архитектура, Системы Межведомственного Электронного Взаимодействия/СМЭВ не могут обеспечить единое адаптивное информационно-функциональное управленческое пространство.


ВЫВОДЫ

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

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

ИТ-лидеры – выдохлись. «Механистическая» кибернетика отжила своё и умирает. Издержки увеличиваются, а полезность, адекватность, надёжность, безопасность и т.п. комплексных сложных систем снижается.



НОВАЯ ПАРАДИГМА

Изобретая информационные
системы будущего

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

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

ПРЕДЛАГАЕТСЯ вообще не решать задач обмена, в том числе сообщениями.


Увеличить >>>


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

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

Более детально с сетецентрической GGG-архитектурой можно ознакомиться в работах «Теория эволюционного моделирования», «Конец информационного общества», «Робот по программированию», «Модель знания. Мера знания» и других.

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

Поэтому в предложенных инновационных GGG-технологиях решались две задачи:

  1. Создать «идеальную» информационную технологию «бесшовного» Будущего.
  2. Создать технологию Эволюционной Миграции в Будущее.


При этом для решения данных задач разработаны и промышленно используются следующие технологии:

1. Создание «идеальной» информационной технологии «бесшовного» Будущего включает следующие основные GGG-технологии:

  • G3A — сетецентрическая архитектура глобальной информационной системы управления,
  • G3LC — «биологический» двухэтапный жизненный цикл информационных систем,
  • G3L— визуальный эволюционно развивающийся язык описания единого «генезиса» (семантической модели) сетецентрических информационных систем;
  • G3EM— коллективное эволюционное создание единой адаптивной семантической модели наших совокупных знаний в виде однорангового G3-гиперграфа классов – «ДНК» проектируемых информационных систем;
  • G3AP — автоматическое программирование адаптивных информационных сетецентрических систем управления на основе единой семантической модели проектирования (G3-гиперграфа классов)

2. Создание технологии Эволюционной Миграции в Будущее: система перехода к GGG-технологиям с постепенным «безболезненным» замещением унаследованного ПО на инновационное сетецентрическое с использованием технологии G3I (G3-Интегратор).

  • G3I — GGG-технология, осуществляющая эволюционное «проецирование», то есть описание внешних унаследованных информационных систем на новом языке G3L с помощью специальных классов гиперграфа Хохловой в сетецентрической среде G3EM.
  • Автоматическое программирование G3AP создаёт "свои" новые пользовательские интерфейсы к внешним системам, кроме того данные внешних систем используются "на чтение" в различных функциях обработки.


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

Осуществлен переход от примитивного обмена сообщениями — к главному: совместной взаимосвязанной коллективной работе в единой сетецентрической среде.

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

Почему?



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

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

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

Интеграция G3I является вынужденной временной компонентой эволюционного «бесшокового» перехода в единую новую глобальную сеть GGG, GRAPH коллективного управления.


ФАКТОРЫ УСПЕХА

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

G3-технологии эффективно использовались в более 800 проектах национального масштаба.



На основе реализованных проектов сформированы управленческие тренажёры – сетецентрические информационные G3-системы коллективного пользования с контрольными примерами для демонстрации и обучения навыкам работы в GGG (GRAPH) сетях нового поколения.  

Наиболее популярны тренажёры: «G3-РОССИЯ», «G3-КОРПОРАЦИЯ».

В настоящее время робот по программированию успешно работает с единым гиперграфом - G3S, включающим:

сотни тысяч вершин (классы содержание, форма, поведение), более 2 миллиардов связей, около 100 000 взаимоувязанных таблиц базы данных (например, ORACLE), около 10 миллиардов записей, которые описывают знания об объектах и процессах управления проектов «G3-РОССИЯ», «G3-КОРПОРАЦИЯ».

На основании результатов экспертиз и отзывов международных организаций, структур NATO (RTO, SPS, NAMSA,..), ведущих институтов РАН и государственных корпораций можно утверждать, что предлагаемые технологии и системы не имеют мировых аналогов и на 5-10 лет превосходят уровень мировых фундаментальных исследований в этой области.



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



М.Н. Хохлова, SOA. СМЭВ. Электронный обмен или обман. Проблемы интеграции // «Академия Тринитаризма», М., Эл № 77-6567, публ.25111, 21.01.2019

[Обсуждение на форуме «Публицистика»]

В начало документа

© Академия Тринитаризма
info@trinitas.ru