"Госбук". SOA. СМЭВ. Электронный обмен или обман

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

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

Программные комплексы компаний Microsoft, SAP, ORACLEи других производителей представляют собой наборы модулей по отдельным задачам – HR, MR, FI, CRM, SPM, MES, PLM, BI,… В них так же существуют проблемы интеграции как внутри этих условно «монолитных» систем, так и с внешними системами других производителей. Со временем, из-за многочисленных слияний, поглощений, финансовой монополизации рынков ИТ, проблемы интеграции всего приобретенного даже внутри компаний Microsoft, SAP, ORACLEи других, только нарастают и становятся неразрешимыми.

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

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

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

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

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

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

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

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

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

функциональное программное обеспечение.

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

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

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

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

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

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

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

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

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

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

Интероперабельность функциональных информационных систем может и должна быть только семантической.

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

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

· Направление 1:

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

· Направление 2:

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

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

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

Почему?

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

Все представленные решения не «живут» в динамике изменения требований к объединяемым информационным системам, не поддерживают жизненный цикл функциональных систем, требуют колоссальных затрат ресурсов на ещё один вид деятельности – поддержку интероперабельности, не учитывают фактор единого времени в поддержании целостности и сопоставимости данных различных интегрируемых систем, не эффективны при количестве систем больше 3, не надежны, не решают комплексно вопросы безопасности и многое другое.

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

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

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

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

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

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

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

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

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

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

Кстати, для информации, Государственная дума РФ принимает в год около 3000 законодательных актов. А сколько 83 региона, а сколько в день, а каково количество существенных изменений в каждом документе?

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

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

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

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

распределенная независимая параллельная разработка модулей сложных функциональных систем приводит к тому, что разработка системы 1 одной крупной части предметной области неизбежно входит в противоречие с одновременной, но отдельной разработкой системы 2 другой крупной части предметной области, что в дальнейшем усиливается субъективными аспектами различия в кодировании программ;

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

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

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

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

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

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

· и многие другие проблемы…

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

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

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

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

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

При реализации интеграции информационных систем на принципах обмена сообщениями синхронизация данных распределенных информационных хранилищ в едином времени и пространстве не достижима.

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

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

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

Однако, что же делать с унаследованным программным обеспечением?

Ведь нельзя же в одночасье всем вместе перейти на новую сетецентрическую G3Aархитектуру.

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

Создать «идеальную» технологию «бесшовного» Будущего;

Создать технологию Эволюционной Миграции в Будущее.

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

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

G3A — сетецентрическая архитектура глобальной информационной системы управления,

G3LC — «биологический» двухэтапный жизненный цикл информационных систем,

G3L— визуальный язык описания единого «генезиса» сетецентрических информационных систем;

G3EM— коллективное эволюционное создание единой адаптивной семантической модели наших совокупных знаний – «ДНК» проектируемых информационных систем;

G3AP — автоматическое программирование адаптивных информационных сетецентрических систем управления на основе модели проектирования (гиперграфа классов Хохловой), описанного в единой виртуальной среде эволюционного моделирования;

· Создание технологии Эволюционной Миграции в Будущее — система перехода к GGG-технологиям с постепенным «безболезненным» замещением настоящего, в т.ч. унаследованного, на инновационное будущее с использованием технологии G3I.

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

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

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

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

Почему?

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

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

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

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

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

Источник: "Госбук"