Архитектура системы предоставления дистанционного доступа к банковским операциям на примере «iBank 2»

Система «iBank 2» построена в соответствии с современной многоуровневой архитектурой. Данная система реализована на языке Java. Сервер Приложения и СУБД находится непосредственно в банке, а представительская компонента расположена у клиента (рис 2.5).

Рисунок 2.5 - Схема информационного обмена Клиент-Банк

В системе Internet - Банкинг, функции представительской компоненты выполняет Java - апплет, который является браузером XML-документов и загружается через Web-браузер клиента. Ядро апплета содержит: LISP- интерпретатор, XML - парсер, визуальные компоненты, построитель экранных и печатных форм, механизм сжатия данных, протокол защищенного взаимодействия с банковским Сервером Приложения, криптографический модуль и другие.

В модифицируемую составляющую клиентской компоненты входят: интерфейс пользователя, экранные и печатные формы документов, клиентская бизнес-логика, механизмы и форматы взаимодействия с бухіичтерскими программами и прочее. Клиентская компонента реализована с использованием XML-описаний и LISP - скриптов. В процессе пользовательской работы с банковского сервера в сжатом виде загружаются в Java - апплет клиента. Архитекту ра системы дистанционного обслуживания клиентов схематично изображена на рисунке 2.6.

Рисунок 2.6 - Архитекту ра системы дистанционного обслуживания клиентов

В PC - Банкинге функции представительской компоненты выполняет клиентский модуль «РС - Банкинг», устанавливаемый на компьютере пользователя. Модуль реализован в виде Java-приложения размером менее 1 Мб, имеет единое ядро с Java - апплетом Internet - Банкинга, содержит локальную СУБД «Jeeves», механизм синхронизации данных и механизм управления DialupIP-соединением.

Синхронизация с банком включает в себя: передачу в банк финансовых документов, загрузку выписок, синхронизацию справочников, загрузку обновлений «прошивки» и клиентской компоненты РС - Банкинга, которая происходит через защищенное соединение по TCP/IP.

В Mobile - Банкинге функции представительской компоненты выполняет клиентский модуль «Mobile - Банкинг», устанавливаемый на КПК или смартфон пользователя. Модуль основан на ядре клиентского модуля «Internet- Банкинг», переработанном для платформ Java 2 Micro Edition и Microsoft .NET Compact Framework.

Взаимодействие с банковским Сервером Приложения осуществляется через защищенное соединение по TCP/IP.

В WAP - Банкинге, функции представительской компоненты выполняет встроенный в мобильный телефон WAP-браузер, а так­же загружаемые через защищенное соединение WML-страницы. [122]

В банке расположены Сервер Приложения «iBank 2», написанный на языке Java 2, с необходимыми серверными модулями для Java 2 и Сервер БД системы «iBank 2». В рамках Сервера Приложения исполняются серверные модули для обслуживания клиентов по различным каналам, включающим в себя: Internet, WAP, SMS, телефон. Вся прикладная бизнес-логика реализована в серверных модулях (рис.2.7).

Сервер приложения iBank 2

V —, ^А ~ — - У

Рисунок 2.7 - Схема работы серверов приложения iBank 2

В Сервере Приложения реализованы функции управления серверными модулями, механизм балансировки и распределения нагрузки, функции взаимодействия с Сервером БД системы «iBank 2», механизмы защиты информации.

Допустимо использование любого современного промышленного Сервера БД с поддержкой JDBC. Система «iBank 2» успешно функционирует с СУБД Oracle, Sybase, Microsoft SQL Server, PostgreSQL и IBM DB2.

Функции интеграции системы «iBank 2» с АБС, карточным процессингом и другими офисными системами банка реализованы в Шлюзе «iBank 2».

Для управления всеми ресурсами системы, банком и филиалами, администраторами банка и филиалов в системе «iBank 2» реализован банковский АРМ »Администратор системы».

Для управления сотрудниками банка, клиентами, ресурсами клиентов, правами клиентов на ресурсы (счета, карты и пр.) предназначен банковский АРМ »Администратор банка/филиала».

Встроенный в систему банковский АРМ »Операционист» является вспомогательным и может использоваться для контроля статусов документов. При необходимости в АРМе можно менять статусы документов.

Также в системе есть новые дополнительные сервисы, дополнительные клиентские и банковские АРМы, вспомогательный защищенный Web-сервер, утилиты для импорта справочников, генерации ключей, управления сертификатами и другие компоненты.

Все банковские АРМы, за исключением АРМа »Администратор системы», реализованы на базе технологий Internet - Банкинга, не требуют установки специализированного ПО, работают на любых современных компьютерах с любыми ОС и любыми Web-браузерами и содержат встроенные механизмы ЭЦП, шифрования и обеспечения целостности информации. [122]

Фактически на прикладном уровне реализована концепция кластеризации. Встраивание в клиентские модули и в Сервер Приложения «iBank 2» механизма балансировки и распределения нагрузки обеспечивает ключевые достоинства системы «iBank 2», к которым можно отнести:

- высокую масштабируемость;

- надёжность;

- непрерывность работы.

При клиентской работе основной нагрузке подвергается банковский Сервер Приложения «iBank 2».

В рамках Сервера Приложения «iBank 2» основная нагрузка приходится на процессоры, к объёму оперативной памяти предъявляются невысокие требования. Реализация Сервера Приложения «iBank 2» на Java позволяет использовать в банке практически все серверные платформы, включая «тяжелые» серверы от Sun, IBM и ПР.

Основным показателем производительности банковской компоненты системы «iBank 2» является количество трансакций, обрабатываемых в секунду. Анализ журналов работы в банках Серверов Приложений «iBank 2» показывает, что основная нагрузка на систему создастся корпоративными клиентами и приходится на временной интервал с 10 до 15 часов по рабочим дням. По статистике в среднем на один исходящий от клиента платёжный документ приходит около 12 трансакции.

Информация о производительности Сервера Приложения «iBank 2» при работе на типовых платформах:

- Pentium-4 2,8GHz/ RAM 1Gb/ Windows 2000 Server/ Sun JRE 1.4.2 обеспечивает обработку 39 трансакций в секунду, или около 12 тыс. платёжных документов в день;

- 2 х Xeon 3,2GHz/ RAM 2Gb/ RedHat Linux 9/ Sun JRE 1.4.2 обеспечивает обработку 82 трансакций в секунду, пли около 25 тыс. платёжных документов в день.

Цифры по объёму обрабатываемых исходящих от клиентов платёжных документов приведены из расчёта рабочего дня с 10 до 15 часов (5 часов), и работе Сервера Приложения «iBank 2» на отдельном компьютере при средней загруженности 20%. Простым увеличением количества Серверов Приложений «iBank 2» банк может увеличить общую производительность, повысить надёжность и обеспечить непрерывность работы системы. [122]

В зависимости от производительности каждого из серверов, запросы от клиентских Java - апплетов Internet - Банкинга и клиентских модулей PC - Банкинга будут в необходимой пропорции распределяться между всеми Серверами Приложений «iBank 2».

При работе в банке нескольких Серверов Приложений «iBank 2» и выходе из строя одного из них, система в целом останется доступной для клиентов, так как клиентские модули и Java - апплеты будут направлять запросы к работающим серверам, что лишь увеличит удельную нагрузку на каждый из оставшихся серверов (рис. 2.8).

Рисунок 2.8 - Схема работы серверов системы ibank2

Увеличение производительности СУБД iBank 2, повышение надежности и обеспечение непрерывности работы осуществляется встроенными средствами ПО Серверов БД и общесистемными средствами, такими как использование высокопроизводительных серверов, внешних RAID-массивов, SAN-сетей.

Для интеграции iBank 2 с Автоматизированной Банковской Системой (АБС) используется проіраммньїй модуль «Шлюз». Основная схема обработки — решения об исполнении приходящих от клиентов документов принимаются в АБС средствами АБС (рис. 2.9).

Именно эта схема обработки документов реализована практически во всех Шлюзах «iBank 2» для промышленных АБС.

Способы обработки доку мен гов:

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

Рисунок 2.9 - Схема интеграции «iBank 2» с АБС коммерческого банка

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

- Ручная обработка, решение об исполнении документов принимается исключительно операционистами. Проверки документов присутствуют в АБС, результаты проверок доступны операционистам.

При интеграции iBank 2 с АБС необходимо учи тыкать следующие особенности:

- Суммарное количество приходящих от клиентов документов вдень определяет требования к производительности Шлюза.

- Политика ІР-безопасности банка может ограничивать схемы и способы взаимодействия Шлюза с АБС.

- Способы взаимодействия Шлюза с АБС рекомендуется использовать стандартные механизмы, форматы и программные интерфейсы АБС.

Основная цель интеграции iBank 2 с АБС — минимизация человеческого участия и снижение себестоимости обработки документов.

Функционально Шлюз выполняет три основные задачи:

- Выгрузка всех пришедших от клиентов документов из iBank 2 в АБС.

- Синхронизация из АБС в iBank 2 текущих статусов документов, ранее пришедших от клиентов н выгруженных в АБС.

Синхронизация из АБС в iBank 2 проводок (выписок) по счетам, заведенным в iBank 2.

/Дополнительные задачи:

- Загрузка из АБС в iBank 2 справочника БИКов.

- Загрузка из АБС в iBank 2 справочника SWIFT.

- Загрузка из АБС в iBank 2 справочника валют, включая курсы и кросс­курсы валют.

- Загрузка из АБС в iBank 2 других служебных справочников.

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

На Шлюз также возложены задачи для обеспечения сложных схем обслуживания клиентов (холдинги, финансовые компании, доверительное управление). Шлюзы поставляются в двух конфигурациях:

- однокомпонентные;

- многокомпонентные.

Однокомпонентный Шлюз— это Java-приложение, с одной стороны взаимодействующее с Сервером БД iBank 2, ас другой с АБС. Однокомпонентный Шлюз используется для интеграции с одним или несколькими экземплярами АБС, установленными на одной площадке, когда не предъявляются жестких требований к объёму трафика между однокомпонентным Шлюзом и экземплярами АБС. Однокомпонентные Шлюзы используются в подавляющем большинстве внедрений iBank 2. Многокомпонентные Шлюзы также реализовываются на Java, состоят из одного экземпляра серверной компоненты Шлюза — «Шлюз-сервер», и одного или нескольких экземпляров клиентских компонент Шлюза — «Шлюз-клиент». Многокомпонентные Шлюзы используются для интеграции iBank 2 с несколькими АБС, расположенными на территориально удалённых площадках, соединенных корпоративной сегыо с невысокой пропускной способностью. [122]

Для обеспечения защищенного взаимодействия между модулями «Шлюз-клиент» и »Шлюз-сервер» используются взаимная

криптографическая аутентификация сторон. ЭЦП сторон под прикладными запросами и ответами, шифрование трафика (рис. 2.10).

Рисунок 2.10- Взаимодействие участников при работе с АБС

Список промышленных АБС в РФ, для которых разработаны и поставляются готовые Шлюзы:

- CSBI Банкир:

- R-Style RS-Bank;

- БИС Бисквит

- Диасофт 4x4 DOS;

- Диасофт WorkFlow;

- Диасофт 5NT;

- Инверсия XXI век;

- Кворум;

- Програмбанк Центавр;

- Програмбанк Гефест;

- ФОРС Ва-Банк;

-ЦФТІВБО;

- Юнисаб.

Также разработан и поставляется универсальный Шлюз, взаимодействующий с АБС через текстовые файлы.

2.3