Что такое интеграция автоматизированных систем (АС) на основе XML

Интегрированию автоматизированных систем (АС), как и интеграции на основе XML в целом, посвящено великое множество наукообразных и (или) околонаучных статей, всевозможных intuitru'шных курсов обучения и т.п. Но зачем же выносить публике остатки мозга и без того облегченного американского полевого образца? Жизнь хороша, когда пьешь не спеша, и все очень просто, когда знаешь ГОСТы 😉 Просто и ясно об интеграции автоматизированных систем на основе XML как автономные системы видеонаблюдения. Редакция от 18.12.2024.

Создан 10.08.2015 11:09:47

Совершенно очевидно, что интеграция — вещь важная и востребованная. Не хочет Родина выпускать за пределы сынов своих — злостных алиментщиков и прочих должников, — у судебных приставов имеется база данных, содержащих сведения о подобной публике, а у погранцов, разумеется, такого в их собственной БД нет. Никакой интеграции! Все у каждого свое. Судебным приставам приходит команда сверху — делиться информацией с Погранслужбой ФСБ России, вот они хоть и с неохотой, но делятся. Хорошо еще, что не грызутся, как волки с овцами.

Внимательно изучаем текст на рисунке ниже.

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

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

Что и требовалось доказать 😊 Не прошло и стольких–то лет с даты написания данной статьи (10.08.2015 11:09:47), как до сенаторов дошло, что к людям надо относиться гуманнее, см. «Сенатор предлагает разрешить выпускать должников за рубеж сразу по факту оплаты долгов», а если более точно, то дату публикации этой новости ТАСС. Мы же в очередной раз подтвердили свою способность предсказывать будущее 😃

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

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

💥 Что и требовалось доказать – окончательно и бесповоротно! 💥

Не прошло и семи лет с момента первой публикации (10.08.2015 11:09:47) настоящей статьи, как произошло чудо: закон приняли, погранцы с судейскими и мытарями договорились, илюхи теперь выездные!

Автор довольно лыбится — сбылось очередное его предсказание 💥

Интеграция на уровне баз данных

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

Согласно этой матрице погранцы Петя и Вася должны иметь возможность отбора из БД только той информации об Илюхе, которую им положено видеть — а именно не выпущать по причине задолженности по алиментам до момента ее погашения. А вот Боре или Яше из кредитной организации совершенно не нужно знать, что у Илюхи свинский грипп и он скоро помрет, так и не погасив кредит: это их совершенно не касается 😃 В общем, Федеральный закон от 27 июля 2006 г. № 152–ФЗ «О персональных данных» в действии.

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

Интеграция автоматизированных систем

Он давно улетел...

© Космос (Архип Архипыч)

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

Вот, что такое интегрированная АС: «Совокупность двух или более взаимоувязанных АС, в которой функционирование одной из них зависит от результатов функционирования другой (других) так, что эту совокупность можно рассматривать как единую АС [из 1.2 ГОСТ 34.003–90]». Из определения четко вытекает, что две или более АС должны взаимодействовать на уровне данных, ведь результаты — это ведь тоже данные! А данные — это информация.

Но есть нюанс. Если вы не владеете китайским языком, то набор иероглифов для вас — всего лишь некие абстрактные данные. А для китайца — полноценная информация.

Информация в АС бывает входная и выходная. Входная информация — это «Информация, поступающая в АС в виде документов, сообщений, данных, сигналов, необходимая для выполнения функций АС [из 6.4 ГОСТ 34.003–90]», выходная — «Информация, получаемая в результате выполнения функций АС и выдаваемая на объект ее деятельности, пользователю или в другие системы [из 6.5 ГОСТ 34.003–90]».

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

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

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

Рассмотрим алгоритм взаимодействия АС 1 и АС 2 (судебных приставов и погранцов) с алиментщиком Илюхой (с его персональной записью).

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

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

Обиженный отец–героин Илюха пулей несется к платежному терминалу и по–быстрому оплачивает долги. Информация с терминала — с некой АС 3 — немедленно поступает в БД и в соответствующем поле (Долги по алиментам) записи об Илюхе появляется информация о том, что тот чист аки агнец божий и единственное, что препятствует ему к вылету — только то, что механизм принятия решений в АС 1 несовершенен и требует как минимум вмешательства пристава или даже судьи. А им оно надо — отслеживать ежедневно тысячи таких илюх в международных аэропортах? Вот где преступление против человечества.

Так вот, если механизм принятия решения избавить от человеческого фактора — приставов да судей, — то все тут же стало бы на свои места: и тёлкам упали бы мгновенные платежи, и Илюха через пару минут прошел бы паспортный контроль. И улетел... Вот суть интеграции — все для человека, все во имя человека!

Совместимость как основа интеграции автоматизированных систем

Как интегрировать ключ с замком, если ключ не подходит к замку? Да никак, поскольку имеет место их несовместимость, в данном случае размерная, т.е. геометрическая. Один из тех случаев, когда размер имеет значение 😃

Несовместимость — обратная сторона совместимости. Отсюда вывод: чтобы интегрироваться, потребуется обеспечить совместимость ключа с замком, в нашем случае — совместимость автоматизированных систем.

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

Играет какую–либо роль совместимость техническая? В настоящее время практически нет, поскольку все интерфейсы обмена стандартные и совместимые, интерфейсные преобразователи тоже. Неважно, что в квартиру заведено оптоволокно, оно все равно прикручено к маршрутизатору, а он уж раздает Интернет по протоколам IEEE 802.xxx терминальным устройствам.

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

С лингвистикой все просто: по–русски или не по–русски. Но хотя бы в кодировке UTF. С метрологией тоже: во всех «цивилизованных» странах футы–дюймы, у нас же нормальная метрическая система мер. А вот совместимость информационная — те самые три кита и с десяток слонов, благодаря которым интегрирование автоматизированных систем возможно вообще.

Мораль (промежуточные итоги)

Подведем промежуточные итоги:

1. Интеграция предпочтительна на уровне баз данных федерального значения.
2. Обработку информации БД разумно препоручить взаимоувязанным автоматизированным системам.
3. Основой интеграции АС в настоящее время является информационная совместимость.

Почему XML–интеграция?

А потому что вот: «XML (англ. eXtensible Markup Language — расширяемый язык разметки; произносится [икc–эм–эль]) — рекомендованный Консорциумом Всемирной паутины (W3C) язык разметки. Спецификация XML описывает XML–документы и частично описывает поведение XML–процессоров (программ, читающих XML–документы и обеспечивающих доступ к их содержимому). XML разрабатывался как язык с простым формальным синтаксисом, удобный для создания и обработки документов программами и одновременно удобный для чтения и создания документов человеком, с подчеркиванием нацеленности на использование в Интернете. Язык называется расширяемым, поскольку он не фиксирует разметку, используемую в документах: разработчик волен создать разметку в соответствии с потребностями к конкретной области, будучи ограниченным лишь синтаксическими правилами языка. Сочетание простого формального синтаксиса, удобства для человека, расширяемости, а также базирование на кодировках Юникод для представления содержания документов привело к широкому использованию как собственно XML, так и множества производных специализированных языков на базе XML в самых разнообразных программных средствах».

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

Обмен XML–документами (сообщениями) в рамках интеграции

Обмен XML–документами или сообщениями в рамках интеграции может проводиться как угодно, обратимся к ГОСТ 34.602–89: «2.6.1.1 В требованиях к структуре и функционированию системы приводят (требования):

1. к переченю подсистем, их назначению и основным характеристикам, к числу уровней иерархии и степени централизации;
2. к способам и средствам связи для информационного обмена между компонентами;
3. к характеристикам взаимосвязей со смежными системами, к ее совместимости, в том числе указания о способах обмена информацией (автоматически, пересылкой документов, по телефону и т. п.);
4. к режимам функционирования;
5. по диагностированию;
6. к перспективам развития, модернизации.

[из 2.6.1.1 ГОСТ 34.602–89]»

Интересно перечисление 3, из которого вытекает, что обмен XML–документами или сообщениями может производиться даже по телефону 😃 Такой способ, конечно, несколько устарел, но в тех же АИИС КУЭ до сих пор существует практика передачи информации коммерческого учета электроэнергии по электронной почте, которая затем разгребается вручную и дополняет соответствующие БД, хотя никто не запрещает выполнять эту работу автоматически.

Связка XML–документов с полями базы данных

Вернемся к ГОСТ 34.602–89: «2.6.1.13 В требования к стандартизации и унификации включают: показатели, устанавливающие требуемую степень использования стандартных, унифицированных методов реализации функций (задач) системы, поставляемые программные средства, типовые математические методы и модели, типовые проектные решения, унифицированные формы управленческих документов, установленных ГОСТ 6.10.1, общероссийские классификаторы технико–экономической информации и классификаторы других категорий в соответствии с областью их применения, требования к использованию типовых автоматизированных рабочих мест, компонентов и комплексов [из 2.6.1.13 ГОСТ 34.602–89]»

В пункте стандарта не зря упомянуты всевозможные общероссийские классификаторы: именно по этим классификаторам и должны создаваться поля баз данных для каждого илюхи со всеми его пИчальками и радостями. И структура XML–документов, описывающих илюх, тоже. Именно так и никак иначе любой субъект может быть формализован от макушки до самых пяточек (или кончиков).

Мораль (выводы)

Итак:

1. Интеграция возможна и необходима на уровне единой федеральной базы данных, обработкой информации которой занимаются автоматизированные системы, интегрированные между собой на основе информационной совместимости.
2. Наиболее гибкий и поэтому наиболее подходящий для интеграции формат данных (язык разметки) — XML.
3. Как сообщения XML, так и структура полей БД федерального уровня должна строиться на основе общероссийских классификаторов, а если замахнуться на глобальные задачи, то на основе межгосударственных и межгалактических классификаторов.
4. ГОСТы надо если не знать, то хотя бы в них ориентироваться. Иначе придется действовать intuitru'шно и разбираться во всевозможных «звездах Давида», чтобы просечь, что к чему 😃

А оно вам надо?