Материал: Автоматизация обработки заявок Пенсионным Фондом РФ
Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
26
Сервера отделений не имеют доступа в интернет на прямую. Все действия по
внешнему взаимодействию происходят в защищенной сети VPN и через
специальные шлюзы. Весь трафик блокируется, кроме трафика JMS-сообщений.
Сервера в целях безопасности работают не прямыми запросами, а через
технологию JAVA EE – JMS. Так как аппаратным обеспечением занимается
компания IBM, то JMS реализован через IBM MQ.
BM MQ – Является частью промежуточного программного обеспечения,
обеспечивающее обмен сообщениями между клиентами. Сообщения – бинарные
данные, текстовые данные, содержащих некоторый смысл для приложений. При
передаче через MQ служебная информация удаляется.
ПТК «Клиентская служба» защищена с использованием защиты сервера
приложений и использованием нестандартного реестра пользователей. Защита
реализована как enterprise-приложение «Безопасность и управление доступом» и
состоит из двух частей. Первая часть является менеджером пользователей и
позволяет создавать и редактировать пользователей, их роли. Вторая часть
является непосредственно надстройкой защиты сервера приложений IBM
WebSphere AS 7. Сервер приложений при доступе к любому ресурсу проверяет
идентификатор пользователя, если он отсутствует перенаправляет на страницу
входа, где после ввода пользователем логин / пароля, передает управление
надстройке. Надстройка проверяет логин/пароль по своей базе данных, в таблицах
которой хранятся данные о пользователе, извлекает его роль. После того как
пользователь прошел аутентификацию, проверяется авторизация пользователя к
данному ресурсу. Политика доступа хранится в файле web.xml, где указывается
доступ на уровне ролей пользователя.
1.3 Анализ существующих разработок и выбор стратегии автоматизации
«КАК ДОЛЖНО БЫТЬ»
1.3.1. Анализ существующих разработок для автоматизации задачи
Как было указано выше за помощь в приеме заявлений отвечает подсистема
«Учет обращений». В данной подсистеме происходит регистрация обращений
граждан. Данные записываются в региональную базу данных. Регионы не имеют
27
доступа к базам данных других регионов, и даже если бы имели, то на поиск
обращения гражданина, было бы потрачено слишком много времени.
Следует рассмотреть на аналитическо-техническом уровне структуру
подсистемы «Учет Обращений»:
База Данных. База данных состоит из огромного числа таблиц. При
сохранении используется по меньшей мере шесть таблиц, связанных между
собой. Для создания новой регистрационной экранной формы используется
девять таблиц, не считая запросов к справочникам, количество которых может
достигать двадцати. Таблицы баз данных не способны к секционированию [16],
поэтому выборка из таких баз данных затруднена. Ошибка! Источник ссылки
не найден.
Минусы такой структуры очевидны:
При сохранении используется много таблиц запись в которые происходит в
рамках одной транзакции. При неудачном стечении обстоятельств такой подход
может вызвать (и вызывает) блокировки таблиц/строк для других процессов.
При построении новой формы регистрации используется чтение множества
таблиц. При создании формы регистрации используется сложный механизм,
построенный на конкатенации строк html-разметки и js-кода. Так как форма
регистрации насчитывает минимум 100 компонентов на форме регистрации
запрос в БД происходит для каждого компонента.
28
Рисунок 4 Структура базы данных подсистемы «Учет Обращений»
Получение данных по регистрации аналогично сохранению регистрации
затрагивает большое число таблиц на чтение. Дополнительные таблицы читаются
все сразу в попытке определить в каких содержаться данные по регистрации. При
редактировании обращения к дополнительной нагрузке относится построение
формы регистрации, описанной выше.
При большом количестве регистраций разрастается таблица
R_COMPONENTS_VALUE, что приводит к торможению выборки. Как было
сказано ранее СУБД регионов не поддерживают секционирование, из-за чего
приходится применять самодельную систему архивирования - перенос
регистрационных данных со всеми зависимостями в другую таблицу, другого
табличного пространства. Перенос очень ресурсоемкий и вызывает
взаимоблокировки, если момент архивации сопровождается параллельным
процессом регистрации.
Следует отметить метрики, снятые со стенда регистраций в процессе
тестирования. Максимальное время выполнения 8356мс. при облегченной
регистрации является недопустимым.
Так же следует отметить рассмотреть программную архитектуру приложения
изображенную на Ошибка! Источник ссылки не найден..
29
Рисунок 5 Архитектура подсистемы «Учет Обращений»
Как несложно заметить запрос каждого ресурса, статического или
динамического направляется серверу приложений. Многочисленные нити веб-
контейнера генерируют нагрузку на сервер приложений и вызывают блокировки.
Множество не систематизированных скриптов JS хранящихся в отдельных
файлах, действия которых сложно предугадать и еще сложнее отлаживать.
Сервер приложений работает на устаревшей JAVA 6. На текущий момент
Oracle представила миру JAVA 10. Обновление JAVA является критическим, так
как в обновленных версиях улучшается не только быстродействие, так и
уязвимости, и баги. Покупка обновленного сервера приложений невозможна по
экономическим соображениям.
В качестве ОРМ используется устаревшая библиотека DataNucleus.
Поддержка данной версии прекращена, переход на новую невозможен из-за
аппаратных и программных ограничений.
Запросы к БД не кэшируются. Частые обращения к БД генерируют нагрузку
на БД, вызывают взаимные блокировки и как следствие повисание всего
комплекса.
Не экономичный расход аппаратных ресурсов. HTML и JS генерируются
путем конкатенации строк. Много статических классов и переменных, которые
расходуют память, наблюдаются множественные утечки памяти, источник
которых сложно детерминировать. Непрактичный код, который сложно
поддерживать.
Сложные алгоритмы построения веб-форм использующие многочисленные
запросы к БД.
30
1.3.2. Выбор и обоснование стратегии автоматизации задачи
Главной задачей разрабатываемого приложения должно являться
централизованная регистрация обращений граждан в ПФРФ. Следует выделить
основные требования к разрабатываемой системе:
1. Скорость обработки информации. Под скоростью обработки информации
следует понимать время работы с информацией, подлежащей сохранению в базу
данных, выборка из базы данных конкретного обращения гражданина, поиск в
базе данных граждан и их обращений.
2. Надежность. Под надежностью информации подразумевается безотказная
работа приложения. Способность сохранять информацию, хранить,
восстанавливать в случае сбоя аппаратных средств, безотказность работы с
информацией.
3. Юзабилити(Эргономичность). Способность программы быть понимаемой,
изучаемой, используемой и привлекательной для пользователя в части
регистрации заявлений.
4. Кроссплатформенность. Возможность работать с программой на любом
устройстве, любой операционной среде. Благодаря кроссплатформенности, прием
заявлений можно не ограничивать приемом лично специалистом.
Проведя исследование существующих бизнес-процессов внутри подсистемы
«Учет обращений», можно достичь увеличение скорости. Скорость обработки
информации будет достигаться за счет: избавлении системы от «паразитной»
нагрузки, оптимизируя технологические процессы внутри, подбором
архитектуры и максимально совместимого программного обеспечения.
Надежность будет достигаться правильной архитектурой и правильной
работой с базой, присущей высоконагруженным системам. Предполагается
развертывание программного комплекса на федеральном уровне. И организация
его в отказоустойчивый кластер.
Юзабилити – простота и однотипность управления призваны сделать новый
продукт более отзывчивым для пользователя. В текущей реализации «Учета
Обращений» нет понимания об интерфейсе, нет единого и ожидаемого поведения
системы, нет общей дизайн-концепции.
Источник: https://baza.diplomsite.ru/previewfile/1902