Открытая архитектура информационных систем

В любом более или менее серьезном проекте по созданию программного обеспечения на одном из первых этапов производится выбор архитектуры будущего решения. Трудно переоценить важность этого этапа, особенно если речь идет о большой системе, рассчитанной на длительную эксплуатацию: на разработку подобной системы будут затрачены значительные ресурсы, и вложения окажутся эффективными лишь в случае, если система не станет «унаследованной» уже с момента ввода в эксплуатацию, а будет допускать модернизацию не только с минимально возможными затратами, но и без потери архитектурной целостности и, соответственно, надежности. К сожалению, часто разработчики программных систем делаются заложниками изначально неверно выбранной архитектуры, а развитие функционала системы становится невозможным или приводит к потере производительности и надежности. С другой стороны, верно выбранная архитектура решения позволяет системе эволюционировать, продолжительное время обеспечивая требуемый функционал. Опыт компании «Стек Софт» в создании программной платформы Onyma xRM согласно с предложенными ею принципами «Открытой архитектуры информационных систем» показал, что такая архитектура может служить хорошей основой для разработки масштабных информационных систем с длительным жизненным циклом, эксплуатируемых как в традиционных областях (в том числе CRM, BPM, ERP, АСУ), так и в только формирующихся, таких, например, как Интернет вещей или киберфизические системы [1].

Само понятие архитектуры программного обеспечения довольно размыто; часто под ним скрываются разные области программной инженерии. Стандарт ISO/IEC/IEEE 42010 не дает единого определения, а для описания архитектуры предлагает использовать так называемые виды (view) — то есть смотреть на архитектуру решения с нескольких разных точек зрения, раскрывающих принципы построения системы. В одних случаях наиболее полное представление о системе может дать структурный вид, в других — процессный. Строгий набор видов стандартом не регламентируется — предлагается выделить наиболее заинтересованные в создании системы стороны, определить их интересы и взглянуть на систему с их позиций. Практика показывает, что именно такой путь позволяет всесторонне оценить архитектуру будущего решения, не перегружая заинтересованных лиц несущественной информацией. Для формального представления видов стандарт предлагает использовать языки описания архитектуры (Architecture Definition Language, ADL), однако фактическим стандартом здесь стал язык UML, который языком ADL не является.

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

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

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

Рис. 1. Общая архитектура современной информационной системы

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

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

Рис. 2. Переход к «Открытой архитектуре»

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

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

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

***

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

Литература

1. Леонид Черняк. Киберфизические системы на старте // Открытые системы.СУБД. — 2014. — № 2. — С. 10–13. URL: http://www.osp.ru/os/2014/02/13040038 (дата обращения 20.3.2015).
2. Даниил Фейгин. Архитектуры и средства интеграции приложений // Открытые системы.СУБД. — 2005. — № 2. — С. 38–45. URL: http://www.osp.ru/os/2005/02/185300 (дата обращения 20.3.2015).
3. Леонид Черняк. Общая шина предприятия // Открытые системы.СУБД. — 2003. — № 4. — С.18–19. URL: http://www.osp.ru/os/2003/04/182897 (дата обращения 20.3.2015).
4. Леонид Черняк. Сервисы и сложные системы // Открытые системы.СУБД. — 2007. — № 10. — С. 30–33. URL: http://www.osp.ru/os/2007/10/4705804 (дата обращения 20.3.2015).

Дмитрий Волков (vdv@stacksoft.ru) — директор по развитию компании «Стек Софт» (Москва).