Вход
Закрыть
Вход
Войти, используя:
Зарегистрироваться Экспертная сеть по вопросам государственного управления

Редакция

Максим Кравцов

Разное31 Мая, 12:26

Виктор Гриднев

Бизнес1 Марта, 14:31
Все редакторы (2) →

Эксперты

Наталья Храмцовская

Бизнес30 Июля, 08:57

Владимир Дрожжинов

Общественные организации29 Июля, 13:50

Юрий Хохлов

Общественные организации25 Июля, 18:38

Максут Шадаев

Государство13 Мая, 23:30

Сергей Муругов

Бизнес18 Апреля, 09:09
Все эксперты (25) →

Активные участники

Николай Адащик

Бизнес30 Июля, 14:11

Олег Карнаухов

Бизнес30 Июля, 05:45

Илья Мальков

Разное30 Июля, 02:49

Андрей Михайлов

Государство29 Июля, 17:47

Сергей Добриднюк

Бизнес29 Июля, 17:40
Активные участники (91) →

Партнеры сообщества

Подтверждение удаления
Отменить
Удалить

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

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

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

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

sites/default/files/user_pictures/2012/03/26/1_1.jpg

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Почему?

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

sites/default/files/user_pictures/2012/03/26/2_2.jpg

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

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

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

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

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

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

sites/default/files/user_pictures/2012/03/26/3_3.jpg

Отсутствие каких-либо видимых успехов в применении 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.
  • и многие другие.

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

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

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

sites/default/files/user_pictures/2012/03/26/4_4.jpg

Опять сложно? А всё выше сказанное регламентирует пока только лишь процедуру обмена следующими видами сообщений между реально используемыми функциональными информационными системами:

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

sites/default/files/user_pictures/2012/03/26/5_5.jpg

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

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

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

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

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

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

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

Никогда!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

sites/default/files/user_pictures/2012/03/26/6_6.jpg

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Почему?

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

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

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

sites/default/files/user_pictures/2012/03/26/7_7.jpg

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

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

Книга в web: http://group-g3.ru/public/book/

Прикрепленные файлы:

Комментарии (16)

Андрей Михайлов, Государство 

Нет ощущения мнимости решения? Когда математики в свое время решили задачу путем выделения мнимой единицы. Тогда решение тоже выглядело простым, однако задача мнимой единицы до сих пор не решена.

Марина Хохлова, Бизнес 

Уважаемый Андрей, данная статья является одной из глав книги "Конец информационного общества. Новый ренессанс." где более детально изложены проблемы создания систем управления муниципалитетами, регионами, государством в целом, а также даны конструктивные предложения по применению новых сетецентрических подходов создания систем управления глобальными структурами. Реализован проект G3-Россия с которым в ближайшее время вы сможете ознакомиться на страницах Госбука и на наших сайтах. На сегодняшний день фрагмент проекта "G3-Бюджет России на ладони" размещен в открытом доступе и продается в сети Интернет.

Андрей Михайлов, Государство 

Ссылка скачать в PDF не работает, не могу оценить всего "слона" целиком. :(

Марина Хохлова, Бизнес 

Уважаемый Андрей, прошу Вас уточнить какой именно PDF файл не работает, т.к. мы проверили свои Интернет ресурсы там все документы открываются.

Андрей Михайлов, Государство 

Марина Хохлова писал(а):

Уважаемый Андрей, прошу Вас уточнить какой именно PDF файл не работает, т.к. мы проверили свои Интернет ресурсы там все документы открываются.

Марина Николаевна, не могу скопировать ссылку, Сайт

http://group-g3.ru/public/book/#

Вверху справа есть ссылка [скачать книгу в PDF] она у меня не открывается ни в одном из браузеров. .

Марина Хохлова, Бизнес 

Уважаемый Анадрей, приносим свои извинения, данная книга будет опубликована с "10" апреля 2012г.

Игорь Синяев, Государство 

"Это смутно мне напоминает индо-пакистанский инцедент". Озадачивался я этой проблемой. Пришел к следующему (помимо изложенного выше). Любая инфомационная система фиксирует/отражает некоторые события, происходящиен в реальности. При этом в ней самой происходят события, о котрых бы неплохо "знать" другим информационными системам. Ну и т.д. и т.п. Кратенько можно посмотреть здесь http://www.fostas.ru/library/show_article.php?id=200

Пришел к выводу, что нужно в принципе (коренным образом) пересматривать существующие подходы к разработке ПО. Т.е. все должно быть ближе к реальности, т.е. к тому как это происходит в жизни, а не виртуально/абстракно. Были кое-какие изыски на эту тему в 2004-2006 г.г., но из-за неподъемности темы одним индивидом - все заброшено в "пыльный" ящик. Вообще тема интересная, по уровню Сколково...

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

Марина Хохлова, Бизнес 

Уважаемый Игорь, благодарю Вас за подержку. Плиглашаем Вас к взаимодействию и сотрудничеству в столь интересной теме "Инновационные подходы к разработке ПО", надеюсь Вас заинтересует технологии автоматического программирования G3AP - "Робота/Станка по программированию информационных систем".

Относительно Сколково замечу, что направления развития иследований ИТ, приведенные на их сайте, представляют собой асистемную не структурированную "кашу" пересекающихся тематик. Наши предложения по систематизации и актуализации не нашли должного внимания из-за статьи "Конкурсы «Сколково»! Почём «опиум» для инноваторов?" мы внесены в "черный список".

  • Новое поколение мультимедийных поисковых систем,
  •  Распознавание и обработка видео и аудиообразов
  • Аналитическое программное обеспечение
  • Мобильные приложения
  • Встроенные системы управления
  • Web X.0
  • Сложные инженерные решения
  • Новые методы хранения, обработки и передачи информации
  • Облачные вычисления
  • Зеленые информационные технологии
  • Программное обеспечение для финансовой и банковской сфер
  • ИТ-безопасность
  • ИТ в медицине и здравоохранении
  • Беспроводные сенсорные сети
  • ИТ в образовании
Игорь Синяев, Государство 

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

Но от этого интерес к данной тематике, по крайней мере у меня, не ослабевает.

Марина Хохлова, Бизнес 

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

Игорь Орлов, Разное 

Прошу прощения, но в приведенной статье слишком много спорных и недостоверных утверждений в части критики SOA. SOA - лишь инструмент и без МАСТЕРА он бесполезен. Если Вы знаете более качественный инструмент - предложите его. Но, к сожалению, я пока не увидел внятного описания альтернативы- только лозунги. Буду признателен за более детальное описание альтернативной архитектуры. Спасибо.

Марина Хохлова, Бизнес 

Уважаемый Игорь, нам очень интересны все спорные утверждения, просим Вас перечислить их. Относительно недостоверных утверждений также просим сообщить, так как основой данного матриала были исходные данные ведущих IT компаний мира и законодательное пространство России. SOA как инструмент нам не известин, просим дать ссылку на источник, где можно взять этот инструмент. Почему тогда IBM, SAP, Oracle не воспользовались этим инструментом, а разрабатывают собственные и по-своему?! Мы понимаем, что альтернативное предложение - сетецентрическая архитектура G3A пока еще не всем понятна, с ней можно ознакомиться на наших сайтах, а также приглашаем Вас пройти обучение (в т.ч дистанционное) по инновационным G3-технологиям.

Игорь Орлов, Разное 
По поводу инструментов:
-SOA - это инструмент проектирования информационных систем
-информационные технологии - инструмент, позволяющий
достигнуть определенного уровня эффективности некоторых бизнес- процессов
-планирование - инструмент управления...
Системный подход, проектное управление - тоже инструменты, но не цели и не задачи.
Не каждый инструмент сделан из металла или написан на языке программирования...
Интеграция информационных систем- тоже не самоцель. 
Это способ построения новых информационных систем на основе набора ранее существовавших систем меньшего уровня агрегирования.
SOA позволяет решать задачи интеграции слабосвязанных информационных систем, а также увеличивать коэффициент повторного использования ранее написанного кода.
Я это знаю - видел, делал, использовал.
Если другой подход или архитектура решают эти задачи эффективнее - здорово, но это не означает немедленную утилизацию SOA,
как появление бензопилы "Дружба" не привело к утилизации топоров.
По поводу спорных и недостоверных утверждений:
1.многократное избыточное несопоставимое описание в различных функциональных информационных системах одних и тех же предметов и процессов предметной области;
SOA как раз позволяет это избежать. Поставщик сервиса описывает предмет и процесс предметной области, а его потребитель сервиса ссылается на него и использует
так, как считает нужным, выстраивая свою часть предметной области или решая свою задачу.
2.различное время внесения изменений в идентичные данные в различных системах, принципиальная невозможность запросами и обменными операциями 
синхронизировать по времени и данным всё информационное пространство, следовательно обеспечить достоверность обрабатываемой и передаваемой информации, 
единое информационное пространство;
Продолжение п.1. К SOA это не имеет отношения. Это имеет отношение к безграмотному проектированию конкретной системы.
Здесь нужно помнить область применения SOA - слабосвязанные системы- поэтому задержка в цепочке связанных изменений является нормой и изменения клиента и сервера
транзакционно не связываются.
3.при каждом изменении требований многократное переписывание, тестирование, ввод в опытную и промышленную эксплуатацию как функциональных программных систем, 
так и принимающих и передающих сервисов;
SOA как раз и позволяет сделать возможным независимость доработки сервиса и его использования. Правда, при условии сохранения интерфейса.
Если же заказчик сервиса постоянно меняет требования к его интерфейсу - тупой и должен платить, раз не знает чего хочет.
Это вопрос квалификации.
4.обеспечение взаимодействия систем между собой становится еще одним «видом деятельности», 
превышающим по времени и другим ресурсам сопровождение эксплуатации и развития самих систем;
Это процесс создания новой системы из набора ранее существовавших подсистем и ее эксплуатации.
В противном случае обеспечение взаимодействия не имеет смысла.
5.замедление и ограничение скорости модификации в ответ на увеличивающийся рост динамики изменений реальных объектов и процессов управления, 
при увеличении количества интегрируемых систем и повышении их сложности;
Это к разговору об уместности использования конкретного инструмента в конкретном случае: 
все ли изменения внутри реального объекта и процесса должны тиражироваться "наружу"?
мы не забываем про требование слабой связанности?
неужели использованы все возможности для обеспечения необходимой производительности сервиса?
6.проблемы обеспечения интероперабельности программных комплексов приводят к существенному падению работоспособности информационных систем в целом;
необходимость согласовывать свои действия с коллегами иногда приводит к потерям времени на это согласование. Но без такого согласования
невозможна эффективная деятельность компании. Компания как система требует обучения людей взаимодействовать между собой.
SOA - система нуждается в том, чтобы ее подсистемы умели между собой общаться. И это требует накладных расходов.
7.отсутствие и принципиальная невозможность реализации комплексной системы безопасности фрагментарных программных систем и 
межсистемного интеграционного информационного пространства;
Хотелось бы подробнее, какие аспекты ИБ принципиально нереализуемы в SOA?
Что касается Вашего GGG- подхода - его преимущества перед SOA для меня совсем не очевидны.
Может вы приведете конкретный пример использования каждого подхода - и на нем разберем все достоинства и недостатки обоих методов?
Или GGG - технологии идеальны?
Марина Хохлова, Бизнес 

Уважаемы Игорь, Ваш комментарий позвал в дорогу и мы постарались ответить Вам наиболее подробно. Получилась статья «ИЛЛЮЗИИ SOA».

Игорь Орлов, Разное 

Уважаемая Марина! Как в Вашей архитектуре обеспечивается работа многосерверной, многокластерной, многоцодовой модели? Или все жизнеспособно только в рамках одного физического сервера?

Марина Хохлова, Бизнес 

Уважаемый Игорь, сетецентрическая архитектура программного обеспечения прекрасно работают как в кластерном решении, так и в мультисерверном. Если же у Вас есть несколько независимых ЦОДов (не в "зеркале"), то реализована репликация изменяемых данных по согласованному регламенту. Однако наши клиенты при сегодняшнем уровне Интернет доступа со всех точек страны и мира чаще всего имеют единый ЦОД с одним или двумя "зеркалами".