XIII Международная студенческая научная конференция Студенческий научный форум - 2021

ВВЕДЕНИЕ

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

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

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

1 ОТКРЫТАЯ АРХИТЕКТУРА ИНФОРМАЦИОННЫХ СИСТЕМ

Основные понятия

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

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

Архитектуру функциональной среды открытых систем представляет совокупность спецификаций интерфейсов прикладного программирования (API).

Архитектуру прикладной платформы представляет спецификация интерфейсов операционной системы.

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

Открытая система – система, которая реализует открытые спецификации на интерфейсы, сервисы (услуги среды) и поддерживаемые форматы данных, достаточные для того, чтобы дать возможность должным образом разработанному прикладному программному обеспечению быть переносимым в широком диапазоне систем с минимальными изменениями, взаимодействовать с другими приложениями на локальных и удаленных системах, и взаимодействовать с пользователями в стиле, который облегчает переход пользователей от системы к системе [2].

В данном случае понятие открытости трактует открытую систему как среду, в которой функционируют приложения (application environment), основанную на стандартах интерфейсов протоколов и форматов данных, обеспечивающих переносимость приложений (application portability), «переносимость» пользователей (user portability) и взаимодействие (interoperability).

Функциональная среда открытых систем

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

СВОЙСТВА ОТКРЫТЫХ ИНФОРМАЦИОННЫХ СИСТЕМ

В данной главе будут рассмотрены более подробно свойства открытых систем. К свойствам открытых ИС относятся:

Расширяемость (extensibility) – возможность добавления новых прикладных функций ИС или изменения некоторых функций из уже реализованных, не изменяя при этом остальные функциональные части (подсистемы) ИС. Эта возможность обеспечивается декомпозицией заданного состава прикладных функций ИС на подсистемы и модульным построением приложений, выполняющих функции подсистем. При внесении изменений в какую-либо программу требуется сохранить ее интерфейс API с тем, чтобы не изменять другие программы, с которыми она взаимодействует;

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

переносимость приложений, данных и персонала (portability) – возможность перевода ИС на более совершенные аппаратно-программные платформы при их модернизации или замене с минимальными затратами, сохраняя инвестиции, вложенные в разработку приложений, формирование массивов данных и обучение пользователей. Применительно к переносимости приложений (application portability) и данных (data portability) такая возможность обеспечивается соблюдением принятых стандартизованных API между приложениями и функциональной средой открытых систем. Применительно к «переносимости» пользователей (user portability) эта возможность обеспечивается дружественным пользовательским интерфейсом. Стабильность этого интерфейса поддерживается стандартизованными API среды по функциям пользовательского интерфейса, и сохранением средств взаимодействия с пользователем, реализуемых приложениями (экранные формы, способы работы с каталогами файлов, способы задания запросов к базам данных, командные языки и т.д.). Это необходимо для того, чтобы не переучивать пользователей при внесении изменений в приложения и прикладные платформы;

интероперабельность приложений и систем (interoperability) – возможность взаимодействия данной ИС с другими системами при необходимости обращения к информационным ресурсам (базам данных, базам знаний) этих систем или решения определенных задач с использованием их вычислительных ресурсов, если собственные ресурсы недостаточны. Интероперабельность систем обеспечивается, прежде всего, форматами данных, принятыми в качестве стандартов электронного обмена данными (electronic data interchange - EDI) для разных прикладных областей. Интероперабельность систем при запуске на исполнение программ, располагающихся в других системах, обеспечивается стандартами удаленного вызова процедур (remote procedure call – RPC). В пределах каждой системы свойство интероперабельности рассматривается на трех уровнях:

взаимодействие программ (program interaction), определяемое процессами взаимопередачи управления и обмена данными между программами;

межзадачное взаимодействие (intertask communication), определяемое средствами языка программирования и операционной системы, которые обеспечивают запуск и синхронизацию задач, и обмен данными между ними;

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

способность к интеграции (system integration) – возможность объединения нескольких ИС различного назначения в единую интегрированную многофункциональную ИС. На уровне баз данных (database integration) под интеграцией понимается представление для прикладной программы или пользователя нескольких баз данных как одной логически единой базы данных. Интеграция обеспечивает обращение пользователей к любой из этих баз данных независимо от места ее размещения, коллективный доступ к данным, одновременную обработку нескольких баз данных каждой из прикладных программ ИС. На уровне интеграции данных (data integration) предполагается возможность одновременного и совместного использования программой или запросом пользователя нескольких файлов данных как единого целого (один из способов интеграции данных – базы данных). Логическая интеграция предполагает объединение данных на логическом уровне, не затрагивая их физической организации. Физическая интеграция связана со слиянием данных в единый информационный массив. Наконец, на уровне интеграции приложений (application integration) рассматриваются методы и средства объединения прикладных программ в многозвенных архитектурах «клиент-сервер» с выделением серверов приложений, ориентированных на определенные классы задач, объектные среды и оболочки, позволяющие объединять приложения на основе механизмов обмена сообщениями;

высокая готовность (high availability) – требование отказоустойчивости системы (fault tolerance), в которой в случае отказа какого-либо компонента гарантируется автоматическое восстановление работоспособности и сохранение целостности баз данных. Характеристика готовности, как меры способности системы принимать и успешно выполнять задания за доступный интервал времени, относится не только к открытым ИС. В данном случае это свойство указано в связи с тем, что его реализация при проектировании системы находится во взаимосвязи с обеспечением других, указанных выше свойств.

ПРЕИМУЩЕСТВА ОТКРЫТЫХ СИСТЕМ

Применение идеологии и стандартов открытых систем выгодно для всех участников процесса создания и развития современных ИС.

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

Таблица 1 – преимущества открытых ИС

Преимущества открытых ИС	Свойства открытых ИС, за счет которых достигаются преимущества
Для пользователей (заказчиков) ИС
1.1 Сохранение уже сделанных инвестиций при изменении требований и развитии ИС	Расширяемость, возможность замены отдельных приложений без изменения остальных, масштабируемость
1.2 Использование информационных ресурсов, существующих в других системах	интероперабельность
1.3 Дружественность человек-машинного интерфейса, сокращение затрат на обучение персонала при переходе на новые версии ИС	«переносимость» пользователей
Для проектировщиков ИС и системных интеграторов
2.1 Возможность использования разных прикладных платформ	переносимость приложений
2.2 Повторное использование готовых приложений	переносимость приложений

Продолжение таблицы 1

2.3 Возможность использования существующих информационных ресурсов	интероперабельность
2.4 Облегчение решения проблемы «унаследованных» систем	интероперабельность, способность к интеграции
2.5 Возможность применения современных технологий и инструментальных средств анализа и проектирования ИС	переносимость приложения между инструментальными и целевыми прикладными платформами
Для прикладных программистов
3.1 Модульная организация прикладных программных комплексов
3.2 Применение стандартизированных программных интерфейсов
3.3 Возможности применения компонентных технологий разработки
3.4 Новые возможности разделения труда с использованием средств коллективной разработки
Для поставщиков технических и программных средств
4.1 Сокращение затрат на портирование прикладных и системных программных средств на новые аппаратные платформы	переносимость программ
4.2 Возможности интеграции выпускаемых программных продуктов с продуктами других поставщиков	способность к интеграции
4.3 Возможности расширения областей применения и рынков сбыта выпускаемых и разрабатываемых программных платформ

АНАЛИЗ ОТКРЫТОЙ АРХИТЕКТУРЫ ИС

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

Рисунок 1 – Общая архитектура современной ИС

Компонент Business Logic реализует основной функционал системы. Компонент UI — интерфейс к основному функционалу для пользователей системы, а компонент API предназначен для интеграции с другими системами, возможно с использованием ESB. Именно компонент API обеспечивает сервисность, предоставляя внешним потребителям интерфейсы к готовым бизнес-сервисам, реализованным на базе основного функционала системы из компонента Business Logic. Причем реализация сервисов может быть инкапсулирована как в компоненте API (c использованием функций основного функционала), так и в компоненте Business Logic. Компонент UI предоставляет пользователям удобный для них интерфейс и редко оперирует готовыми бизнес-сервисами — современные требования к эргономике этого не позволяют, и всегда требуется специфический функционал, находящийся за пределами основного функционала по обработке данных и предназначенный исключительно для решения интерфейсных задач. Исходя из различных решаемых компонентами задач, чаще всего в SOA компонент Business Logic реализуется в виде своеобразного ядра системы, предоставляющего низкоуровневый интерфейс к функционалу. Дальше на основе этого интерфейса реализуются пользовательский интерфейс и сервисы для предоставления внешним системам. Процессы разработки пользовательского интерфейса и сервисов зачастую не синхронизированы, кроме того, разработчики часто с большим вниманием относятся к требованиям своих непосредственных пользователей, чем к требованиям партнеров по интеграции. В результате функционал, предоставляемый непосредственным пользователям системы, может сильно отличаться от того, что доступно внешним системам в виде сервисов, а это, в свою очередь, не позволяет использовать хорошо зарекомендовавшую себя при работе в автономном режиме систему столь же эффективно и в едином информационном пространстве предприятия.

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

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

Рисунок 2 – переход к открытой архитектуре ИС

Основные достоинства данного подхода:

Синхронность функционала, предоставляемого непосредственным пользователям и внешним системам;

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

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

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

Однако уравнивание возможностей пользовательского интерфейса и интерфейсов внешних систем может привести, к примеру, к деградации производительности пользовательского интерфейса вследствие необходимости применения более защищенных и крупно скомпонованных сервисов, предназначенных для медленных интеграционных протоколов RPC. Лишение «родного» интерфейса привилегии использования низкоуровневых методов функционального ядра системы приведет к деградации производительности, однако негативный эффект можно минимизировать, правильно организовав взаимодействие компонентов API и Business Logic и грамотно выбрав уровень гранулированности сервисов.

Возможность организации взаимодействия компонентов системы в «Открытой архитектуре» представлено на рисунке 3.

Рисунок 3 – Открытая архитектура

Выделяют четыре основных уровня:

DBMS / Data Provider — управление данными;

Core — функциональное ядро системы, реализующее основную бизнес-логику;

API — готовые к использованию сервисы;

UI / Protocol Logic — RPC-протоколы вызовов готовых сервисов API-слоя и компонентов, реализующих на основе API-сервисов логику работы пользовательского интерфейса.

В ядре системы реализуются служебные компоненты, отвечающие за разделение полномочий, аудит и организацию работы непосредственно с поставщиком данных (Tools). Для эффективной работы с большими объемами данных как в пользовательском интерфейсе, так и при интеграции недостаточно просто предоставить методы работы с данными системы — необходимо дать возможность непосредственной работы со структурами базы. Поэтому в ядре предусматривается специальный компонент, предоставляющий на уровне СУБД или иного источника данных безопасный доступ к структурам (Safe Data Provider). В реляционной СУБД это может быть, например, отдельная схема с полномочиями на чтение данных из специальных представлений, созданных таким образом, что они будут содержать только ту информацию, которая доступна текущему авторизованному пользователю. Современные СУБД предоставляют несколько различных технологий для реализации подобного механизма; важно, что такой подход позволяет обеспечить эффективную интеграцию различных систем на уровне взаимодействия баз данных, при этом ничего не потеряв с точки зрения информационной защиты.

Основная бизнес-логика системы реализуется условным компонентом ядра Logic, опирающегося на компонент Tools в части работы с данными и информационной защиты. Для компонента Logic автоматически генерируется безопасный интерфейс Safe Logic, разрешающий исполнение метода только в том случае, если это разрешено текущему авторизованному пользователю системой разделения полномочий. Фактически проверяется возможность обращения к каждому конкретному методу, что позволяет построить гибкую систему разделения полномочий. Принципиально то, что этот интерфейс, как и Safe Data Provider, должен создаваться системой поверх незащищенных методов автоматически. В результате интерфейс Safe Logic сам по себе является набором готовых к использованию бизнес-сервисов, а также основой для создания расширенных комплексных сервисов (Extention), при построении которых можно использовать еще и безопасный доступ к структурам данных (Safe Data Provider).

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

Разработчики внешних систем, также как и разработчики пользовательского интерфейса, могут использовать различные способы обращения к данным и вызова сервисов: это может осуществляться посредством медленных, но универсальных RPC-протоколов, а может — прямо на уровне сервера приложений (Safe Logic) или СУБД (Safe Data Provider). Для увеличения производительности RPC, особенно в протоколах, не поддерживающих сессии внешние разработчики могут скомпоновать на основе предоставленных Safe Logic сервисов требуемый композитный сервис в компоненте Extention и обращаться к нему, вместо того чтобы последовательно вызывать атомарные сервисы, каждый раз получая накладной расход на обработку протокола.

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

ЗАКЛЮЧЕНИЕ

На сегодняшний день внимание в концепции открытых систем обращено не только на стандарты операционных систем (ОС) и баз данных (БД), но и на стандартизованные интерфейсы объединения существующих систем, приложений и пользователей. Этот подход требует концентрации на выработке и применении признанных в мире промышленных стандартов на интерфейсы, протоколы, форматы обмена данными. В гетерогенной среде современных открытых ИС могут объединяться мэйнфреймы (универсальные ЭВМ) и суперкомпьютеры, серверы на платформах Unix и Windows NT, персональные компьютеры и рабочие станции, связанные через локальные и глобальные сети. Все это требует систематической методологической основы для выбора и реализации стандартов открытых систем в каждой системе, подключаемой к сети, и в самой сети.

На основе «Открытой архитектуры» реализована платформа Onyma xRM, которая, в свою очередь, стала базой для создания комплекса продуктов Onyma Billing, Onyma OSS и Onyma CRM, работающих в телекоммуникационных компаниях «Ростелеком», «Транстелеком», МТТ и позволивших обеспечить необходимую гибкость разработки и внедрения новых бизнес-сервисов, а также их интеграцию в информационный ландшафт предприятий. Кроме того, ряд компаний используют данные продукты в режиме SaaS.

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

Архитектура предприятия и ИТ-архитектура: [Электронный ресурс] URL: https://zen.yandex.ru/media/id/5cc9e44c9680af00b2c7a2a1/arhitektura-predpriiatiia-i-itarhitektura-5cd8162c901a5900b23c8586

Основы открытых информационных систем: [Электронный ресурс] URL: http://shpora1.do.am/_ld/2/245_LNa.pdf;

Открытая архитектура информационных систем: [Электронный ресурс] URL: https://www.osp.ru/os/2015/01/1304532;

Код для цитирования: Скопировать