CC BY
12
DOI 10.36622/VSTU.2022.18.6.002 УДК 004.056
ПРИМЕНЕНИЕ КОМПОНЕНТНО-ОРИЕНТИРОВАННОГО ПОДХОДА ПРИ РАЗРАБОТКЕ ИНФОРМАЦИОННЫХ СИСТЕМ С МИКРОСЕРВИСНОЙ АРХИТЕКТУРОЙ
А.А. Рындин, Д.В. Шитиков Воронежский государственный технический университет, г. Воронеж, Россия
Аннотация: рассматриваются программные компоненты и их использование для системного анализа, разработки, ввода в эксплуатацию, управления и обработки информации в информационных системах, основанных на микросервисной архитектуре, а также их последующей поддержки и развитии. Описываемая технология программных компонентов поддерживает создание определенного стиля, включающего компоненты, модели компонентов, интерфейсы, контракты, наборы типов компонентов и каркасы компонентов. Компонентный подход к архитектуре информационных систем рассматривается с точки зрения паттерна разработки, который можно описать с помощью моделирования взаимодействия компонентов разных типов. Представленная компонентная модель накладывает ограничения на разработчиков компонентов, а структура компонентов обеспечивает соблюдение этих ограничений в дополнение к реализации и предоставлению необходимых услуг. Показаны преимущества перехода на микросервисную архитектуру с использованием абстрактных контрактов для реализации общих для различных систем компонентов. Приводится реализация корпоративного портала, построенного на микросервисной архитектуре и разделенного на отдельные сервисы, включающие систему авторизации, организационную структуру, систему учета времени, систему отпусков, имеющие собственные базы данных и взаимодействующие между собой через API. Приведен листинг кода реализации модели компонента на языке java. Для данных сервисов выделены общие интерфейсы, позволяющие разделять одни зависимости
Ключевые слова: компонентно-ориентированный подход, интерфейс, контракт, модель компонентов, диаграмма компонентов
Введение
Длительное время в качестве основополагающей Н концепции управления архитектурой приложений служил монолитный подход, не разделяющий уровни интерфейсов и их целевое использование, но за развитием и глобализацией облачных технологий последовало разочарование в традиционном стиле организации сервиса [1].
Сложность информационных систем стремительно нарастала, что повлекло за собой увеличение временных издержек при разработке и тестировании функциональности при внесении изменений в приложение, а также необходимость концентрации дополнительного внимания на сохранении совместимости ее частей.
Первоначально приведенные проблемы попытались решить путем обособления уровней интерфейса в рамках монолитной архитектуры:
1) пользовательские интерфейсы;
2) базы данных;
3) бизнес-логика.
© Рындин А.А., Шитиков Д.В., 2022
Таким образом произошла
дифференциация программного кода на фронт-энд и бэк-энд, но существенных методов решения вышеназванных проблем данная концепция предложить не могла, поскольку все еще имела ряд недостатков [2]:
1. Повышенный риск недоступности и ошибок функционирования всей информационной системы из-за потребности в более кропотливом тестировании крупного монолита с широким набором взаимозависимых сервисов.
2. Высокие трудозатраты при масштабировании информационной системы.
3. Существенные временные издержки при реализации и, соответственно, более редкий выпуск обновлений.
4. Необходимость пересборки всего приложения при внесении изменений.
5. Последовательное усложнение кода при развитии системы ведет к потере обособленности сервисов, из-за чего систему труднее поддерживать.
В качестве одного из решений был предложен переход на микросервисную архитектуру [3].
Описание компонентно-ориентированного шаблона разработки информационных систем
Одной из сложностей работы с несколькими сервисами является дублирование кода, оперирующего одними сущностями приложения. Эффективным решением стало применение компонентно-ориентированного подхода.
Компонентно-ориентированные системы считаются следствием выбора стратегии системного анализа и управления информационными системами, основанной на компонентах и содержащей в себе концепции и продукты, поддерживающие данную идеологию.
Компонентный подход к архитектуре информационных систем является отражением паттерна разработки, который можно описать с помощью моделирования взаимодействия компонентов разных типов [4] (рис. 1). Данное отражение сопряжено с тем, что технология компонентов программного обеспечения выступает как часть развернутой информационной системы или приложения, а не ограничивается сущностью инструмента разработки. Данный шаблон применяется и описывается в коммерческом программном обеспечении, таком как JavaBeans от Oracle [5] и COM+ от Microsoft [6].
Рис. 1. Компонентно-ориентированный шаблон разработки информационных систем
В качестве основных элементов компонентно-ориентированного стандарта для системного анализа и управления обычно используют [7]:
1. Компонент.
Компонент является сущностью программной реализации, которая может выполняться на физическом или логическом устройстве, объединяющей две позиции на компонент - как на реализацию, где компоненты могут быть развернуты и помещены в состав более крупных систем, и как на архитектурную абстракцию, накладывающую ограничения в виде набора стандартов и соглашений на все компоненты.
2. Интерфейс.
Интерфейсы определяют характеристики, приводящие к взаимозависимостям
компонентов, при этом абстрактные интерфейсы не зависят от реализации, а связанные — неотделимы от нее, проявляя, таким образом, свойства, которых не было в абстрактном интерфейсе.
3. Контракт.
Контракты являются обязательствами, выполняемыми в интерфейсе,
акцентирующими внимание на спецификации моделей взаимодействия и взаимозависимостей соучастников данных взаимодействий. Контракты компонентов представляют паттерны взаимосвязей, базирующиеся на компоненте, а контракты взаимодействия отражают абстрактные шаблоны
взаимодействия внутри назначений
компонентов.
4. Независимое развертывание.
Независимое развертывание компонентов
гарантируется условленными обязательствами в контрактах.
5. Набор типов компонентов.
Любой компонент осуществляет самостоятельную функцию системы.
6. Компонентная модель.
Компонентная модель отображает набор
типов компонентов, а также их интерфейсы и спецификацию паттернов, описывающих взаимодействие между данными типами, определяющих требования к разработке компонентов, которые сопровождаются декларацией общесистемных атрибутов качества, что приводит к исключению источников несоответствия интерфейсов и быстроте развертывания компонентов.
7. Платформа компонентов.
Платформа компонентов является набором сервисов, сопровождающих реализацию компонентной модели и ее поддержку.
При этом основными достоинствами компонентного подхода, по мнению авторов, являются:
1. Самостоятельность компонентов.
Недостаток гибкости в монолитах
усложняет внесение изменений в ИС, в то время как компонентная модель диктует правила создания и расширения компонентов, что влечет за собой независимую разработку и развертывание дополнений.
2. Реестр компонентов.
Компонентные модели указывают на
эталоны, гарантирующие, что для независимо сформированных компонентов будет обеспечено развертывание в единой среде.
3. Сокращение времени разработки.
Трудозатраты на системный анализ,
управление и обработку информации уменьшаются за счет ранее принятых и реализованных архитектурных решений в инфраструктуре и модели компонентов.
4. Увеличение надежности.
Поскольку компонентные модели предписывают стандарты для системного анализа и управления, все развернутые компоненты системы поддерживают
глобальные свойства для обеспечивания безопасности, масштабируемости и других свойств, наличие которых определяет предсказуемость функционирования ПО при внесении любых изменений.
Реализация компонентно-ориентированной
разработки информационных систем
Примером практической реализации компонентных платформ являются
компонентные фреймворки, как Laravel, Symfony, Spring, .NET [8].
Рассмотрим компонентный подход на примере разработки на языке Java микросервисной архитектуры корпоративного портала, включающего в себя следующие сервисы (рис. 2):
- система авторизации;
- система учета времени сотрудников;
- организационная структура;
- система отпусков.
Рис. 2. Структура микросервисного приложения
На рис. 3 показаны диаграммы компонентов каждого сервиса.
Анализируя диаграммы компонентов, можно выделить общие интерфейсы, которые могут быть реализованы в разных сервисах.
Общие интерфейсы для реализации в сервисах
Сервис Интерфейс
Сотрудник Проект База данных API клиент Календарь
main + + +
система авторизации + + +
система учета времени + + + + +
организационная структура + + + +
система отпусков + + + +
Как пример, все микросервисы используют сущность «Сотрудник», имеющую отношения с другими сущностями. Сложность поддержки подобной системы заключается в обновлении всех микросервисов при изменении структуры «Сотрудник».
Рис. 3. Диаграммы компонентов сервисов
Имея общие интерфейсы, можно выделить соответствующие им компоненты в отдельную реализацию и переиспользовать их в виде зависимостей в нескольких микросервисах. Вынесем модель «Сотрудник» («Employee») для взаимодействия с базой данных в отдельный компонент. Создадим отдельный репозитарий, в котором опишем все модели и отношения между ними.
Пример описания модели «Employee» для компонента: @Entity @Getter @Setter
@NoArgsConstructor @AllArgsConstructor @Builder
@Table(name = "employee")
@SequenceGenerator(name = "app_sequence_generator",
sequenceName = "employee_id_seq", allocationSize = 1) public class EmployeeEntity extends BaseEntity implements EmployeeContract {
@NotEmpty(message = "Last name should not be empty") @Size(min = 2, max = 30, message = "Last name between 2 and 20")
@Column(name = "last_name") private String lastName;
@Column(name = "first_name") private String firstName;
@Column(name = "second_name") private String secondName;
@Column(name = "birthday_date") private LocalDate birthdayDate;
@NotEmpty(message = "Login should not be empty") @Size(min = 2, max = 30, message = "Login between 2 and 20") @Column(name = "login", unique = true) private String login;
@NotEmpty(message = "Email should not be empty") @Email
@Column(name = "corp_email", unique = true) private String corpEmail;
@NotEmpty(message = "Position should not be empty") @Column(name = "position") private String position;
@NotEmpty(message = "Guid should not be empty") @Column(name = "guid", unique = true) private UUID guid;
@Column(name = "gender_code", updatable = false, insertable = false) private String genderCode;
@OneToMany(cascade = CascadeType.ALL,
mappedBy = "employee") private Set<EmployeeExtemalSystemId> employeeExternalSystemIdSet;
@ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "gender_code", nullable = false, referencedColumnName = "code") private GenderType genderType; @OneToMany(cascade = CascadeType.ALL, mappedBy = "employee") private Set<EmployeeWorkStatus> employeeWorkStatusSet;
}
Теперь можно создать jar архив данного компонента и использовать его во всех микросервисах в качестве зависимости (рис.
4).
<groupld>ru. service. backend</groupld> <artifactId>java-model</artifactId>
Рис. 4. Зависимость в разных микросервисах на один компонент
Заключение
Показана модель микросервисной архитектуры приложения, использующая между сервисами общие компоненты. При последующих изменениях в компонентах будет достаточно изменить зависимость в микросервисах на другую версию компонента, что позволяет при создании и сопровождении приложений:
1) избежать дублирования кода;
2) повторно переиспользовать компоненты в различных приложениях, не повышая их связности;
3) автоматизировать процесс развертывания приложений.
Системы, основанные на компонентном подходе, опираются на шаблон проектирования, включающий в себя такие технические концепции, как компонент, интерфейсы и контракты компонентов.
Независимость компонентов друг от друга позволяет гибко обновлять систему в целом, повысить скорость разработки и развертывания системы, а также облегчить поддержку нескольких сервисов, оперирующих одними объектами.
Литература
1. Plummer D.C., Cearley D.C., Smith D.W. Cloud Computing Confusion Leads to Opportunity //Report № G00159034. Gartner Group, 2017. [Электронный ресурс]. Режим доступа: https://www.researchgate.net/publication/337085937_Insights _of_Trends_and_Developments_in_Cloud_Computing (дата обращения 07.09.2022).
2. Mazlami G., Cito J., Leitner P. Extraction of microservices from monolithic software architectures // IEEE International Conference on Web Services (ICWS). 2017. P. 524-531.
3. Balalaie A., Heydarnoori A., Jamshidi P. Microservices Architecture Enables DevOps: Migration to a Cloud-Native Architecture // IEEE Software. 2016. Vol. 33. No. 3. P. 42—52.
4. Кулямин В.В. Технологии программирования. Компонентный подход. М.: Просвещение/Бином, 2014. 463 с.
5. JavaBeans [Электронный ресурс] / Режим доступа https://docs. oracle. com/j avase/tutorial/j avabeans/ (дата обращения 28.08.2022)
6. COM+ (Component Services) [Электронный ресурс] / Режим доступа https://docs.microsoft.com/en-us/windows/win32/cossdk/component-services-portal (дата обращения 28.08.2022)
7. Technical Concepts of Component-Based Software Engineering / Felix Bachmann, Len Bass, Charles Buhman and others. SEI Joint Program Office, 2000. 65 p.
8. Budden Ph., Murray F. MIT's Stakeholder Framework for Building & Accelerating Innovation Ecosystems // Working Paper, MIT's Laboratory for Innovation Science & Policy. 2019. 28 p.
Поступила 16.09.2022; принята к публикации 15.12.2022
Информация об авторах
Рындин Александр Алексеевич - д-р техн. наук, профессор, Воронежский государственный технический университет (394006, Россия, г. Воронеж, ул. 20-летия Октября, 84), e-mail: alexandr.a.ryndin@me.com, тел. +7(473) 243-77-04 Шитиков Дмитрий Викторович - канд. экон. наук, магистрант, Воронежский государственный технический университет (394006, Россия, г Воронеж, ул. 20-летия Октября, 84), e-mail: vrnvgasu@yandex.ru, тел. +7(473) 243-77-04
APPLICATION OF A COMPONENT-BASED SOFTWARE ENGINEERING IN THE DEVELOPMENT OF INFORMATION SYSTEMS WITH MICROSERVICE
ARCHITECTURE
A.A. Ryndin, D.V. Shitikov
Voronezh State Technical University, Voronezh, Russia
Abstract: the article discusses software components and their use for system analysis, development, commissioning, management and information processing in information systems based on microservice architecture, as well as their subsequent support and development. The described technology of software components supports the creation of a specific style, including components, component models, interfaces, contracts, sets of component types, and component frameworks. The component approach to the architecture of information systems is considered from the point of view of a design pattern, which can be described by modeling the interaction of components of different types. The component model presented imposes constraints on component developers, and the component design enforces these constraints in addition to implementing and providing the necessary services. The advantages of switching to a microservice architecture using abstract contracts for the implementation of components common to various systems are shown. The implementation of a corporate portal built on microservice architecture and divided into separate services, including an authorization system, an organizational structure, a time tracking system, a vacation system, which have their own databases and interact with each other via API, is presented. The code listing of the implementation of the component model in the java language is given. For these services, common interfaces are allocated that allow sharing the same dependencies.
Key words: component-based software engineering, interface, contract, component model, component diagram
References
1. Plummer D.C., Cearley D.W., Smith D.M. "Cloud computing confusion leads to opportunity", report no. G00159034, Gartner Group, 2017, available at:
https://www.researchgate.net/publication/337085937_Insights_of_Trends_and_Developments_in_Cloud_Computing (date of access: 07.09.2022).
2. Mazlami G., Cito J., Leitner P. "Extraction of microservices from monolithic software architectures", IEEE International Conference on Web Services (ICWS), 2017, pp. 524-531.
3. Balalaie A., Heydarnoori A., Jamshidi P. "microservices architecture enables devops: migration to a cloud-native architecture", IEEE Software: journal, 2016, 1 May, vol. 33, no. 3, pp. 42—52.
4. Kulyamin V.V. "Programming technologies. Component approach" ("Tekhnologii programmirovaniya. Komponentnyy podkhod"), Moscow: Prosveshchenie / Binom, 2014, 463 p.
5. JavaBeans, available at: https://docs.oracle.com/javase/tutorial/javabeans/ (date of access: 28.08.2022)
6. COM+ (Component Services), available at:https://docs.microsoft.com/en-us/windows/win32/cossdk/component-services-portal (date of access: 28.08.2022)
7. Bachmann F., Bass L., Buhman Ch. et al. "Technical concepts of component-based software engineering", SEI Joint Program Office, 2000, 65 p.
8. Budden Ph., Murray F. "MIT's stakeholder framework for building & accelerating innovation ecosystems", Working Paper, MIT's Laboratory for Innovation Science & Policy, 2019, 28 p.
Submitted 16.09.2022; revised 15.12.2022 Information about the authors
Aleksandr A. Ryndin, Dr. Sc. (Technical), Professor, Voronezh State Technical University (84 20-letiya Oktyabrya, Voronezh 394006, Russia), e-mail: alexandr.a.ryndin@me.com, tel. +7(473) 243-77-04
Dmitriy V. Shitikov, Cand. Sc. (Economics), MA, Voronezh State Technical University (84 20-letiya Oktyabrya, Voronezh 394006, Russia), e-mail: vrnvgasu@yandex.ru, tel. +7(473) 243-77-04
