"ДБО BS-Client. Частный Клиент" v.2.5
Архитектура системы
Версия 2.5.0.0
2. Аннотация
Настоящий документ содержит информацию, актуальную на момент его составления. не гарантирует отсутствия ошибок в данном документе. оставляет за собой право вносить изменения в документ без предварительного уведомления.
Система «Частный Клиент» это полнофункциональное тиражируемое решение, обеспечивающее удобное и надежное обслуживание розничных клиентов через Интернет и по телефону. Система включает в себя практически полный пакет электронных услуг для обслуживания счетов Клиентов, операций с кредитами, депозитами и картами Клиента, осуществления переводов и платежей.
Система «Частный Клиент» включает в себя следующие подсистемы:
· Интернет-клиент
· Телефон-клиент
· Информационный клиент
· Мобильный клиент
· Киоск Самообслуживания
· Легкий фронт.
Система предназначена для решения задач доставки, контроля и обработки различных типов платежных и информационных документов Клиентов, обмена сообщениями в произвольном формате, получения выписок по картам и счетам.
Данный документ предназначен для администраторов системы и содержит описание основных программных модулей системы, архитектурных решений, которые использовались при их создании, а также варианты развертывания системы.
СОДЕРЖАНИЕ:
1. Аннотация. 2
2. Общая структура системы.. 4
3. Логическая схема системы.. 5
3.1. Базовая архитектура системы. 5
3.2. Архитектура программных модулей. 7
3.2.1. Архитектура модуля "Сервер приложений" 7
3.2.1.1. Общее описание. 7
3.2.1.2. Архитектурные уровни. 9
3.2.2. Архитектура модуля "Сервер автопроцедур" 10
3.2.2.1. Общее описание. 10
3.2.2.2. Архитектурные уровни. 12
3.2.3. Архитектура модуля "Web АРМ операциониста" 13
3.2.3.1. Общее описание. 13
3.2.4. Архитектура модуля "АРМ операциониста или администратора" 13
3.2.4.1. Общее описание. 13
3.2.5. Архитектура модуля "ISAPI-библиотека BSI. DLL" 13
3.2.5.1. Общее описание. 13
3.2.6. Архитектура модуля "Сервлет BSI. JAR" 14
3.2.6.1. Общее описание. 14
3.2.7. Архитектура модуля "Сервер лицензирования". 14
3.2.7.1. Общее описание. 14
4. Вид развертывания и безопасности. 15
3. Общая структура системы
Система дистанционного банковского обслуживания физических лиц ДБО "BS-Client. Частный клиент" (далее по тексту - Система, Система ДБО) предназначена для предоставления услуг банка физическим лицам – клиентам банка.
В качестве пользователей системы выступают клиенты компании, а также сотрудники банка: администраторы системы и операционисты.
Для выполнения своих функция система ДБО взаимодействует с различными внешними системами, в качестве которых могут выступать как АБС различных видов, так и платежные системы.
Основные взаимодействия системы представлены на Рис. 1:
Рис. 1 Пользователи системы
Доступ клиентов к системе осуществляется по тонкой технологии с использованием интернет браузера. Операционисты и администраторы системы взаимодействуют с ней при помощи отдельного GUI приложения – АРМ оператора. Также есть возможность работы операционистов через web АРМ оператора посредством интернет браузера.
Система состоит из нескольких программных модулей, обеспечивающих его функционирование.
Программный модуль - отдельный исполняемый файл или системный сервис, реализующий определенную часть функционала Системы. В Системе ДБО “BS-Client. Частный клиент” программные модули, как правило, представляют собой либо сервера, выполняющие какой-либо набор задач в автономном режиме, либо приложения, предоставляющие визуальный интерфейс пользователю Системы. Программные модули могут располагаться как на одном и том же компьютере, так и на разных серверах и рабочих станциях.
4. Логическая схема системы
4.1. Базовая архитектура системы
Логическая схема системы представлена на (связи между программными модулями отражены с помощью стрелок, в фигурных скобках указано возможное количество программных модулей):
Рис. 2 Логическая схема системы
Как видно из схемы система состоит из нескольких серверов и АРМ-ов пользователей.
Система хранит все обрабатываемые и справочные данные в СУБД (в Системе ДБО поддерживаются следующие типы СУБД: MS SQL, Oracle, Sybase ASA).
Кроме СУБД система содержит еще один сервер, необходимый для работы практически всех модулей - сервер лицензирования, который представляет собой DCOM-сервер, связанный с электронным ключом защиты Guardant и файлом лицензий. Задача сервера лицензий - отслеживание соблюдения ограничений, которые накладываются на работу системы приобретенной лицензией. Он отвечает на запросы всех модулей Системы, связанных с проверкой наличия лицензии или ее параметров.
Система содержит в своем составе АРМы администратора или операциониста. Перечисленные АРМ выполнены по одинаковой технологии и отличаются только разным набором функционала, доступным из главной формы приложения. Каждый из этих АРМ может присутствовать в Системе ДБО в неограниченном количестве. Каждый из АРМ напрямую подключается к БД Системы для доступа к данным Системы.
Помимо отдельностоящих АРМ операционистов в системе также присутствует Web АРМ операциониста, которое выполнено по тонкой технологии и использует web доступ к системе. Этот АРМ не использует прямого подключения к СУБД, а вместо этого общается через Web сервер и сервер приложений.
Для обеспечения работы клиентов, подключающихся к системе через браузер, используется цепочка серверов. Запросы от браузера клиента поступают на WEB-сервер системы. Защита канала передачи запросов обеспечивается использованием протокола HTTPS.
Web-сервер, принимающий запросы клиентов, содержит в себе библиотеку, обрабатывающую запросы на генерацию динамических страниц. Если в качестве WWW-сервера выступает Microsoft Internet Information Server, то этой библиотекой является IS API-библиотека BSI. dll. Если же используется WWW-сервер Apache Tomcat, то такой библиотекой выступает сервлет bsi. jar, работающий под управлением WEB-контейнера Tomcat.
Запросы, поступающие на BSI, обрабатываются сервером приложений, который отвечает за выполнение запросов и генерацию страниц. Он постоянно запрашивает по протоколу TCP/IP у BSI запросы, ожидающие обработки, выбирает и выполняет их. Сгенерированная по этому запросу страница передается BSI.
Помимо подключений клиентов Web сервер системы предоставляет Web доступ к системе операционистам через Web АРМ операциониста. С точки зрения логики взаимодейсвтия компонент системы технология работы для операциониста системы через Web доступ такая же, как и для внешних клиентов. Разница только в доступном функционале и системе авторизации пользователей.
Для выполнения сервисных задач, а также различных автоматических заданий в состав системы входит сервер автопроцедур. Сервер автопроцедур в том числе выполняет задачи по связи с различными внешними системами.
4.2. Архитектура программных модулей
4.2.1. Архитектура модуля "Сервер приложений"
4.2.1.1. Общее описание
Сервер приложений представляет собой сервер, обрабатывающий запросы, приходящие от клиентов на WWW-сервер.
Для выполнения своих задач сервер приложений поддерживает пул потоков обработки. Каждый поток обработки присоединяется через TCP/IP-соединение к модулю BSI, работающему в составе WWW-сервера, и получает от него задачи на обработку. Каждая задача представляет собой запрос на исполнение функции прикладного кода на BS-Script и параметры http-запроса. Сервер выполняет запрошенную прикладную функцию, которая формирует страницу ответа. После выполнения страница ответа передается BSI. В случае отсутствия задач на выполнение поток обработки ожидает их.
Выполнение всякой задачи обычно привязано к конкретному пользователю системы (точнее, к сессии работы конкретного пользователя). В случае отсутствия такой привязки сервер приложений выполняет только задачи, связанные с авторизацией пользователя. При авторизации открывается сессия работы пользователя с системой. Все последующие запросы от определенного пользователя будут исполняться в рамках данной открытой сессии. С этой целью идентификатор сессии передается в каждом запросе от клиента. Сессия всегда привязана к конкретному пользователю. Сервер поддерживает список открытых на данный момент сессий и закрывает их по таймауту. В каждой сессии поддерживается хранение так называемых сессионных данных - произвольного списка именованных переменных разных типов. Эти данные могут использоваться для сохранения какой-либо информации между запросами (пример - текущий язык локализации для сессии).
Задачи, выполняемые на сервере приложений, получают данные запроса от сервера и на их основе формируют страницу ответа. Как правило, страница формируется не «с нуля», а на основе шаблона страницы. Шаблон представляет собой HTML - или XML-файл, содержащий места подстановок. Места подстановок бывают двух типов - локализованный ресурс и параметр.
Места подстановок локализованных ресурсов автоматически заполняются сервером приложений при формировании страницы значением соответствующего локализованного ресурса в текущем языке сессии. Все остальные места подстановок заполняются кодом задачи. Сервер приложений предоставляет удобный интерфейс для работы с шаблоном страницы и заполнением его параметров.
Помимо выполнения задач сервер приложений с помощью подсистемы автопроцедур поддерживает выполнение автоматических заданий по расписанию либо по другим событиям. Как правило, в штатных инсталляциях этот механизм не используется, и все автопроцедуры выполняются на сервере автопроцедур.
Вся архитектура сервера приложений делится на два больших архитектурных слоя - системный уровень и прикладной уровень.
Системный уровень сервера ДБО выполнен на Delphi и состоит из пакетов и динамических библиотек. Системный уровень предоставляет сервисы и механизмы, не зависящие от бизнес-логики ДБО, и, как правило, не меняется для специальных версий Системы, выполненных на основе стандартной версии Системы ДБО.
Условно системный уровень можно разделить на три архитектурных слоя:
· Уровень доступа к системным ресурсам и СУБД;
· Уровень системных сервисов;
· Интерфейс к системным сервисам.
Прикладной уровень Системы отвечает за реализацию бизнес-логики приложения и взаимодействие с пользователями системы. Он делится на уровень GUI-интерфейса и уровень прикладного кода. В сервере приложений GUI-интерфейс состоит из шаблонов HTML-форм, используемых прикладным кодом для формирования web-страниц, и скриптов, работающих на этих страницах. Модули генерации этих страниц входят в состав уровня реализации бизнес-логики.
4.2.1.2. Архитектурные уровни
Схематично уровни иерархии и их взаимосвязи представлены на Рис. 3:
Рис. 3 Архитектурные уровни «Сервера приложений»
Уровень доступа к системным ресурсам и СУБД ‑ Предоставляет классы, обеспечивающие базовое взаимодействие с основными внешними ресурсами (в том числе, с СУБД). Также в этот уровень входят утилиты общего пользования, использующиеся всеми системными сервисами. Как правило, библиотеки этого слоя используются всеми программными модулями ДБО.
Уровень системных сервисов ‑ Реализует основные системные механизмы, использующиеся в ДБО. В разных программных модулях используется разный набор подсистем уровня системных сервисов.
Интерфейс к системным сервисам ‑ Предоставляет прикладному уровню функции и интерфейсы для доступа к системному уровню. Он выполнен в виде так называемых библиотек расширения макроязыка. Это обычные динамические библиотеки (.dll), написанные по определенным соглашениям, которые доступны для вызовов из макроязыка прикладной части Системы.
Уровень прикладного кода (реализация бизнес-логики) ‑ Отвечает за реализацию бизнес-логики Cистемы.
Скрипты, работающие на WEB-страницах ‑ Представляет собой скрипты, работающие на WEB-страницах пользовательского интерфейса.
Шаблоны HTML-форм ‑ Представляет собой набор файлов - шаблонов HTML-форм. Каждый файл помимо HTML-кода может содержать места подстановок, заполняемые сервером приложений.
4.2.2. Архитектура модуля "Сервер автопроцедур"
4.2.2.1. Общее описание
Сервер автопроцедур представляет собой приложение, работающее в автономном режиме и выполняющее в автоматическом режиме основные задачи Системы. На сервере автопроцедур запускаются задачи, обеспечивающие взаимодействие с внешними системами, а также другие задачи, требующие работы в автоматическом режиме.
Архитектура сервера автопроцедур идентична архитектуре АРМ-ов операционистов и администраторов системы.
Вся архитектура основного сервера ДБО делится на две большие части: "Прикладной уровень" и "Системный уровень".
Архитектура системного уровня ничем не отличается от сервера приложений. Есть только небольшие различия в наборе подсистем, использующихся на сервере приложений и сервере автопроцедур, связанные со специфическими подсистемами обработки запросов.
Прикладной уровень Системы отвечает за реализацию бизнес-логики приложения и взаимодействие с пользователем. Он часто меняется для максимального соответствия приложения нуждам заказчика. Для обеспечения максимальной гибкости Системы на прикладном уровне максимально используется декларативный способ построения Системы. Большая часть аспектов функционирования бизнес-логики Системы и взаимодействия с пользователем прописывается не в коде, а задается в настройках Системы.
Для задания таких настроек в основном используются так называемые DSP-структуры – сохраняемые в СУБД древовидные структуры, позволяющие хранить структурированную информацию.
Помимо декларативных описаний для реализации функций Системы прикладной уровень использует скриптовый язык BS-Script. Этот макроязык - внутренний язык системы ДБО, его компилятор может поставляться вместе с Системой ДБО. Он содержит возможности для простого доступа ко всем системным механизмам ДБО.
Прикладной уровень ДБО можно разбить на два архитектурных слоя: уровень GUI-интерфейса и уровень прикладного кода. Деление прикладного уровня на GUI-часть и бизнес-логику во многом условно. Во многих частях Системы эти понятия тесно взаимосвязаны и неотделимы одно от другого. Как правило, отдельные функциональные части Системы ДБО (так называемые подсистемы), затрагивают оба этих архитектурных слоя.
4.2.2.2. Архитектурные уровни
Схематично уровни иерархии системы и их взаимосвязи представлены на Рис. 4:
Рис. 4 Архитектурные уровни «Сервера автопроцедур»
Уровень GUI-интерфейса ‑ Состоит из визуальных и печатных форм Системы, обеспечивающих взаимодействие с пользователем.
4.2.3. Архитектура модуля "Web АРМ операциониста"
4.2.3.1. Общее описание
Web АРМ операциониста представляет собой Web браузер, подключающийся к WWW серверу для предоставления интерфейса работы с системой через Web доступ.
4.2.4. Архитектура модуля "АРМ операциониста или администратора"
4.2.4.1. Общее описание
АРМ операциониста построено по той же технологии, что и сервер автопроцедур. Разница между ними заключается лишь в том, что на сервере автопоцедур запускаются автопроцедуры. На АРМ операторов по умолчанию автопорцедуры не запущены. Теоретически автопоцедуры могут использоваться на АРМ операционистов для выполнения вспомогательных задач, но, как правило, этого не делается. С архитектурной точки зрения строение АРМ оператора не отличается от строения основного сервера ДБО. Фактически с помощью настроек можно включить запуск автопроцедур на АРМ, «превратив» его тем самым в сервер автопроцедур. Разные АРМ могут отличаться друг от друга только набором функционала, доступного из главного меню Системы.
4.2.5. Архитектура модуля "ISAPI-библиотека BSI. DLL"
4.2.5.1. Общее описание
Модуль BSI. dll предназначен для получения от WEB-сервера запросов клиента и передачи их на выполнение серверу приложений. BSI. dll встраивается в Internat Information Server как IS API-библиотека. Он реализует стандартный интерфейс IS API-библиотеки, необходимый для обработки запросов.
При получении запроса от WEB-сервера BSI помещает его во внутреннюю очередь запросов. Запрос может уже иметь привязку к определенному серверу приложений (указывается через параметр запроса, указывающего идентификатор сервера приложений) или не иметь такой привязки. В первом случае запрос будет передан на обработку указанному серверу приложений, во втором случае запрос может быть обработан произвольным сервером приложений. Идентификатор сервера приложений передается во всех запросах клиента, кроме первого. Это сделано для того, чтобы все запросы одной сессии работы пользователя обрабатывались одним и тем же сервером приложений.
BSI постоянно «прослушивает» определенный TCP-порт на предмет входящих соединений от сервера приложений. При поступлении соединения открывается поток обмена, в котором сервер приложений получает задачи на обработку, обрабатывает их и возвращает ответы. BSI выдает ему последовательно задачи из очереди запросов, предназначенных этому серверу.
4.2.6. Архитектура модуля "Сервлет BSI. JAR"
4.2.6.1. Общее описание
Архитектура модуля BSI. JAR полностью повторяет архитектуру модуля BSI. DLL за исключением способа взаимодействия с WEB-сервером. BSI. JAR исполняется в WEB-контейнере Tomcat на правах сервлета. Способ его взаимодействия с сервером приложений такой же, как и у BSI. DLL.
4.2.7. Архитектура модуля "Сервер лицензирования".
4.2.7.1. Общее описание
Сервер лицензирования представляет собой COM-сервер, обрабатывающий запросы от модулей Системы на проверку наличия той или иной лицензии и ее параметры. Вызовы производятся по технологии DCOM.
Для работы серверу лицензирования требуется наличие в каталоге запуска файла лицензий. Кроме этого, на машине, где работает сервер лицензирования, должен быть установлен ключ электронной защиты Guardant. Файл лицензии и ключ защиты связаны друг с другом. Файл лицензий от одного ключа защиты не подходит к другому. При работе сервер лицензирования периодически проверяет согласованность файла лицензий и ключа защиты.
Файл лицензий хранит информацию о наличии лицензий на те или иные подсистемы, а также определенные параметры (например, максимальное количество клиентов и т. п.). Модули, запрашивающие у сервера лицензирования эту информацию, отправляют зашифрованный и специальным образом защищенный запрос через DCOM-вызов на сервер лицензирования, который проверяет корректность запроса и выдает соответствующую информацию из файла лицензий. Результат запроса также возвращается в в защищённом виде.
5. Вид развертывания и безопасности
Основной вариант развертывания системы представлен на Рис. 5:
Рис. 5 Базовая диаграмма развертывания и безопасности
Как правило, среда работы банка делится на две части - демилитаризованную зону (ДМЗ), имеющую прямой выход в сеть Интернет, и внутреннюю сеть банка, связанную с демилитаризованной зоной через отдельные порты и адреса и защищенную межсетевыми экранами. При развертывании Системы ДБО в демилитаризованную зону помещаются компоненты, требующие прямого выхода в Интернет – WWW-сервер.
Часть Системы рекомендуется размещать на четырёх серверах - сервере приложений, сервере лицензирования, сервере автопроцедур и сервере СУБД. Допускается разворачивать сервера автопроцедур, лицензирования и приложений на одном сервере для реализации тестовой среды с небольшим количеством клиентов (до 1000).
Сервер СУБД содержит один компонент – собственно, сервер СУБД. Конфигурация этого сервера должна подбираться, исходя из требований производителя конкретной СУБД. Операторы и администраторы могут управлять работой Системы со своих рабочих мест, на которые должны быть установлены соответствующие АРМ.
