ВКР: Интеграционные решения для сервисов Платформы Поддержки и Развития Бизнеса ПАО «Сбербанк»

СОДЕРЖАНИЕ

Введение
1 Анализ предметной области
1.1 Технико-экономическая характеристика АО «СберТех»
1.1.1 Показатели деятельности компании
1.1.2 Организационная структура предприятия
1.2 Обоснование выбора задачи
1.3 Экономико-информационная сущность задачи
1.3.1 Характеристика единой сервисной шины
1.3.2 Характеристика среды обмена данными
1.3.3 Характеристика подходов к интеграции сервисов
1.3.4 Характеристика реализуемой интеграционной системы
1.3.4.1 Характеристика технологий среды обмена данными
1.3.4.2 Характеристика технологий единой сервисной шины
1.3.5 Организация процесса интеграции внешних и внутренних сервисов
1.4 Основные требования к разрабатываемой интеграционной системе
1.5 Основные выводы по главе
2 Проектное решение интеграции сервисов платформы поддержки и развития бизнеса
2.1 Информационное обеспечение интеграции сервисов
2.1.1 Обоснование проектных решений по техническому обеспечению
2.1.2 Организация информационного обеспечения
2.2 Программное обеспечение интеграции сервисов
2.2.1 Обоснование проектных решений по программному обеспечению
2.2.1.1 Обоснование выбора целевой технологии реализации интеграционного модуля
2.2.1.2 Технология композиции объектов с использованием Spring Framework
2.2.1.3 Обоснование выбора целевой технологии для работы с реляционными базами данных
2.2.1.4 Обоснование выбора брокера сообщений для единой сервисной шины
2.2.1.5 Обоснование выбора брокера сообщений для среды обмена данными
2.2.1.6 Характеристика брокера сообщений Apache Kafka
2.3 Архитектура интеграционного решения
2.4 Описание программных модулей системы интеграции сервисов.
2.4.1 Программный модуль модели данных
2.4.2 Программный модуль транспорта IBM WebSphere MQ
2.4.3 Программный модуль транспорта Apache Kafka
2.4.4 Программный модуль журналирования
2.4.5 Программный интеграционный модуль
2.5 Руководство администратора
2.5.2 Возможности системы
2.5.3 Требования к уровню подготовки пользователя
2.5.4 Обязанности и задачи администатора
2.5.5 Обслуживание системы
2.5.5.1 Установка брокера сообщений IBM WebSphere MQ
2.5.5.2 Установка брокера сообщений Apache Kafka
2.5.5.3 Установка и запуск сервера приложений Wildfly
2.5.5.4 Установка СУБД MySQL
2.5.5.5 Управление учетными записями пользователей MySQL
2.5.5.6 Загрузка данных в технологическую базу данных
2.5.5.7 Развертывание интеграционного модуля в сервере приложений
2.6 Основные выводы по главе
3 Оценка экономической эффективности
3.1 Экономические показатели разрабатываемой системы
3.2 Экономическая оценка разработки программного проекта
3.3 Расчет эксплуатационных затрат
3.4 Расчет показателя экономического эффекта
Заключение
Список использованных источников
Приложение А - Организационная структура АО «СберТех»
Приложение Б – Листинги форматов собщений интеграционного модуля
Приложение В – Конфигурация модуля client-dto
Приложение Г – Конфигурация spring контекста интеграционного модуля

ВВЕДЕНИЕ

Современный бизнес невозможен без применения автоматизированных информационных систем. Известно, что все крупные предприятия и корпорации используют корпоративные информационные системы (далее - КИС) для оптимизации и автоматизации своих производственных процессов. С особой тщательностью к разработке таких систем подходят финансовые и кредитные организации, где вопросу надежности, безопасности и производительности систем уделяется особое внимание.
Сегодня, при разработке КИС, наблюдается устойчивый рост к интереса к концепции сервис-ориентированной архитектуры. Современные КИС все дальше уходят от монолитных и трехзвенных архитектур к сервис-ориентированной. Данная концепция была сформулирована еще в 1980-х годах, но получила признание только в последние пять лет.
Основная её идея состоит в том, что любой бизнес-процесс необходимо декомпозировать на атомарные модули-сервисы, которые организованны вокруг конкретных функций (пользовательский интерфейс, регистрация клиента, логистика, и т.п.). Тем самым модули получаются слабо связанными и легко заменяемыми, что позволяет достаточно быстро изменять и подстраивать функциональность под изменения бизнеса, а также вести разработку модулей без привязки к языку программирования и программному обеспечению. Также такую архитектуру часто называют «микросервисной». В своем знаменитом труде «Microservices» Мартин Фаулер и его коллега Деймс Льюис[46] подробно описывают концепцию архитектуры «микросервисов».
Тем не менее, концепция микросервисов с момента создания подвергалась критике. Основные проблемы, обозначенные критиками, относятся к согласованию форматов сообщений