Внутренняя организация БИС

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

Опоздав с введением услуг в Интернете, банки, как, впрочем, и другие организации, рискуют проиграть конкурентам в борьбе за клиента. Однако разработка современных Веб-приложений – процесс сложный и занимает много времени. Есть ли выход? Эксперты компании Digital Design считают, что выход – в использовании таких принципов разработки web-приложений, как модульность, отделение уровня бизнес-логики от уровней хранения и представления данных, обеспечение максимальной интероперабельности (возможности перестройки системы в зависимости от информационных и технологических потребностей), выделения метауровня представления данных и создания корпоративных библиотек модулей (компонентов, направленных на ускоренную разработку бизнес-приложений в области Интернет-банкинга, электронной коммерции и т. д.).

При этом на уровне бизнес-логики (будь то платежная система, бухгалтерская или автоматизированная банковская система, магазин и т.д.) целесообразно вычленять некие бизнес-компоненты и помещать их в библиотеку модулей (типовыми для этого уровня являются модули, решающие задачи аутентификации, шифрования и ЭЦП электронной цифровой подписи), поддержания БД пользователя, посылки и приема сообщений по электронной почте, представления таких типичных объектов, как счет, платежное поручение, счет-фактура и т.д.), которые, будучи упакованы в определенные ХМL-структуры, могут быть использованы в онлайновом режиме.

Метауровень описывает семантику интерфейса. Каждый из компонентов метапредставления с точки зрения пользовательского интерфейса может иметь свое описание: цена представляется в виде поля, счет – в виде электронной формы, журнал счетов – в виде таблицы, номенклатура товаров – в виде дерева и т.д. Не «прорисовывая» пользовательский интерфейс, этот уровень должен реализовывать предварительную обработку данных (введение ограничений, установка значений по умолчанию и т.д.) и представлять их на уровне метаописания, выдавая наружу соответствующие ХМL-структуры.

В свою очередь, генератор клиентского интерфейса (собственно web-специфичная часть во всей данной системе), основываясь на метаописании пользовательского интерфейса, должен сформировать DHTML-страницы, которые пользователь увидит в своем браузере. Использование на этом уровне соответствующих стилей представления информации, выбираемых из ряда возможных, позволяет сделать эту информацию легко идентифицируемой клиентом как принадлежащую именно данной организации (банку).

Поскольку при описанном подходе web-система собирается из «кубиков», и сделать это может человек, которого условно можно назвать аналитиком, срок ее разработки значительно сокращается (понятно, что основное время уходит на разработку содержимого этих «кубиков»).

Таким образом, реализовав описанные подходы, банк может в относительно короткие сроки создать целостную информационную систему.

Выбор СУБД для использования в БИС

В начале 90-х годов представитель компании Progress Software, выступая в Санкт-Петербурге на семинаре, посвященном использованию СУБД этой фирмы, чтобы проиллюстрировать свой тезис о том, что СУБД разных классов имеют разные сферы применения, задал аудитории следующий вопрос: "Вы ведь не станете разрабатывать средствами Clipper или FoxPro, ну, скажем... банковскую систему ?!". Ответом послужил дружный смех – именно на этих средствах в то время базировались почти все отечественные АБС.

Как ни странно, и сегодня, когда практически все ведущие отечественные разработчики уже анонсировали или выпустили АБС нового поколения на основе профессиональных (промышленных) СУБД (Oracle, Progress, Sybase, DB2 и др.), для части банковских автоматизаторов подобный вопрос не стал риторическим, поэтому стоит перечислить преимущества, которые дает использование СУБД профессионального класса:

· оптимизированный многопользовательский режим работы с развитой системой блокировок, позволяющий сотням и тысячам пользователей одновременно работать с базой данных, не мешая друг другу;

· гарантированная защита информации от потери либо искажения в случае любых сбоев, в том числе и физического отказа диска;

· надежные средства защиты информации от несанкционированного доступа на разных уровнях;

· поддержка широкого диапазона программных и аппаратных платформ, позволяющая выбрать оптимальную платформу, а также менять ее при необходимости;

· возможность построения распределенных информационных систем, в которых базы данных и пользователи могут быть географически удалены друг от друга;

· развитые средства мониторинга и настроек сервера базы данных, позволяющие оптимальным образом использовать ресурсы системы при любых изменениях нагрузок;

· поддержка "словарей данных", триггеров и других средств, позволяющих снизить трудозатраты на разработку прикладных систем и повысить их надежность.

Очевидные преимущества АБС на основе профессиональных СУБД привели к тому, что количество их установок в коммерческих банках сегодня уже исчисляется сотнями (наибольшие тиражи успешных внедрений имеют, по всей видимости, Oracle и Progress).

В то же время у многих руководителей служб автоматизации в банках сложилось устойчивое мнение, что такого рода системы предназначены только для крупных банков с большими штатами и бюджетами служб автоматизации и применение таких систем в малых и средних банках неоправданно дорого и трудоемко. Это мнение базируется на ряде стереотипов (зачастую целенаправленно культивируемых некоторыми фирмами-производителями АБС) и руководство многих малых и средних банков при выборе АБС порой даже не рассматривает возможность приобретения современной АБС на профессиональной платформе, ограничивая свой выбор системами на базе персональных СУБД.

Рассмотрим наиболее распространенные стереотипы и попробуем привести контраргументы, основанные на практическом опыте.

Стереотип первый: профессиональные СУБД очень дорого обходятся

Большинство производителей промышленных СУБД сегодня предлагает как минимум две конфигурации своих продуктов. Как правило, одна из них ориентирована на крупные системы с большим числом пользователей (Enterprise Database), другая – на небольшие конфигурации (WorkGroup Database), причем последние распространяются по относительно невысокой цене. Учитывая возможности, которые получает при этом пользователь, это совсем недорого.

Стереотип второй: профессиональные СУБД предъявляют слишком высокие требования к вычислительной платформе

Вопреки распространенному заблуждению, промышленные СУБД совсем не обязательно функционируют только на многопроцессорных RISC-серверах. Выбор аппаратной платформы определяется различными параметрами (количество пользователей, сложность и качество реализации приложений и пр.). Опыт показывает, что однопроцессорный PC-совместимый сервер на платформе Intel вполне может поддерживать работу сервера БД Progress с 30--40 пользователями.

Что же касается рабочих станций, использование UNIX-сервера и терминальной архитектуры (наиболее подходящей для большинства рабочих мест в типичном банке) позволяет успешно использовать в качестве эмуляторов терминалов любые персональные компьютеры вплоть до морально устаревших.

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

Не нашли, что искали? Воспользуйтесь поиском по сайту: