WebClub - Всероссийский Клуб Веб-разработчиков
WebClub.RU » Советы » Опыт проектирования и разработки банковской системы для трехуровневой архитектуры клиент-сервер. Архитектура системы

Опыт проектирования и разработки банковской системы для трехуровневой архитектуры клиент-сервер. Архитектура системы


Дата публикации: 28-09-2010

1. Общее описание

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

Сейчас на рынке средств быстрой разработки проектов (RAD) имеется множество языков четвертого поколения (4GL). Мы пришли к выводу о нецелесообразности использования такого средства в данном проекте по следующим причинам.

а. Ориентация большинства языков 4GL на совмещение в коде программы средств внешнего представления данных и их обработки. Этот подход хорош для создания двухуровневых приложений. В трехуровневой схеме визуальное представление данных и их обработка принципиально разделены, поэтому такое свойство языка просто не работает. Кроме того, мы считаем, что такое совмещение усложняет разделение труда между разработчиками, сопровождение и модификацию крупного проекта.

б. Известные автору средства разработки на языках четвертого поколения (Delphi, Power Builder, SQL Windows, OpenRoad, JAM, Oracle Forms, Informix 4GL) не могут сравниться с "ручным" программированием на языках третьего поколения в области эффективности конечного продукта разработки - откомпилированного кода программы. Под эффективностью автор понимает совокупность таких показателей, как скорость работы программы и объем используемой оперативной памяти. К серверу приложения обычно предъявляются очень строгие требования в области эффективности, поэтому для его разработки идеально подходит язык типа С или С++.

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

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

в. По мнению автора, ускорение кодирования не вносит существенного вклада в скорость создания большого приложения. Собственно кодирование занимает максимум 10% времени работы над проектом, и сокращение этого времени пусть даже в 10 раз (что нереально) не становится решающим фактором. Остальные 90% времени у команды разработчиков занимает постановка задачи, создание проекта, обсуждение общей архитектуры, моделирование, отладка, написание спецификаций и документации. По нашему мнению, использование быстрого средства разработки не ускоряет темпа этих остальных 90% работы.

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

Причины, по которым разработчикам систем трехзвенной архитектуры часто приходится отказываться от систем RAD, хорошо описаны в [3].

Далее разработчики проекта все же использовали Delphi для некоторых вспомогательных модулей системы.

 

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

1. Программа-СУБД на компьютере-сервере.

2. Серверный программный комплекс, размещенный на компьютере-сервере. Причем в общем случае этот сервер может не совпадать с сервером, на котором работает СУБД. Серверный комплекс принимает и обрабатывает запросы клиентской программы. В такой схеме серверная программа берет на себя сложную обработку данных, а клиентская - управляет пользовательским интерфейсом. Серверы приложений работают на Unix-компьютере и связаны сетевым протоколом TCP/IP с клиентскими компьютерами, работающими под MS Windows 3.1 (имеется версия клиентской программы для Windows 95 и NT). Такая схема позволяет совместить высокую надежность и эффективность обработки данных, так как отвечающая за работу с данными серверная часть расположена на Unix-платформе, с простым и привычным клиентским местом под управлением Windows.

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

В последнюю версию системы вошли отдельные модули, созданные с помощью Java-технологии, для реализации, например, системы клиент-банк. Мы считаем, что Java является очень перспективным направлением в банковских технологиях.

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

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

"Машина проводок", объединенная с системой документооборота.

Система жесткой (встроенной в программный код) основной финансовой отчетности.

Система создания и выполнения произвольных отчетов и запросов.

Система поддержки справочников.

Система встроенной электронной почты.

Контрольно-статистическая система.

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

2. Используемая СУБД

Для реализации конкретного проекта, по совокупности качеств (общие возможности, соответствие промышленным стандартам, поддержка, ценовая политика, простота инсталляции и эксплуатации) разработчиками была выбрана новейшая реализация СУБД Ingres в версии OpenIngres 1.1. В целом такое решение себя оправдало. Но при создании системы было принято решение не использовать без особой необходимости специализированные функции OpenIngres для сохранения возможности переноса системы на другие СУБД (например Informix или Oracle).

3. Аппаратно-программная платформа

Приложение-клиент создавалось для среды MS Windows 3.1 с использованием всех возможностей этой графической оболочки по организации недорогого пользовательского интерфейса. Самая же ответственная часть, сервер приложения, реализовывалась с использованием мощных средств разработки операционной системы Unix. В качестве конкретного ее воплощения была выбрана платформа Sun, операционная система Solaris 2.x. Надежность и возможности ОС Unix нами были оценены очень высоко.

4. Монитор транзакций

Среди мониторов транзакций для Unix лидерство по числу установок и объему продаж удерживает TUXEDO, принадлежащий сейчас фирме BEA Systems. Кроме того, он обладает достаточно простым API-интерфейсом. Поэтому был выбран именно этот продукт.

TUXEDO поддерживает распределенные транзакции, прозрачное взаимодействие программ в разнородной сети, обмен сообщениями с гарантированной доставкой, программный интерфейс DCE RPC и множество других средств для облегчения жизни разработчику сложного программного продукта. В принципе, программист избавляется от необходимости обязательного знания и использования многочисленных сетевых и системных программных интерфейсов ОС Unix, так как TUXEDO содержит все средства для организации распределенной обработки данных.

5. Обработка данных

Хорошее банковское приложение должно включать в себя как подсистему оперативной обработки транзакций (OLTP), так и подсистему поддержки принятия решения (DSS). Например, движение платежных документов в организации - это сравнительно простые и быстрые транзакции, а расчет показателей деятельности банка за определенный период - это элемент системы поддержки принятия решения. Различные типы систем, как правило, требуют совершенно разных подходов к способам организации хранения данных. Производители современных "больших" СУБД утверждают, что их продукты одинаково хорошо поддерживают оба типа систем, но, по мнению автора, это пока не так. Вполне может быть, что реляционный подход является не лучшим для аналитической обработки. Единого мнения и метода пока нет. Фирмы-производители таких СУБД, как Informix, OpenIngres, Oracle, Sybase и др., создают или уже создали объектно-ориентированные расширения своих реляционных продуктов. Распространенные реляционные неспециализированные СУБД создавались в расчете на оперативную обработку и сейчас только начинают приспосабливаться к требованиям сложной аналитической обработки данных. Что касается специализированных СУБД (таких как Red Brick), они приспособлены (по крайней мере, пока) именно к аналитической обработке данных и слабо подходят к работе в режиме быстрых транзакций.

Весьма интересна модная сейчас технология разделения базы данных на сравнительно небольшое оперативное подмножество изменяемых данных (им управляет система типа OLTP) и большое квазинеизменное подмножество (над этими данными работает система типа DSS). Между подмножествами осуществляется однонаправленная репликация для поддержки актуальности данных. В таком случае можно в каждой подсистеме использовать наиболее подходящую для данной задачи СУБД и схему хранения данных. Например, в первой подсистеме можно использовать Informix, во второй - Red Brick (из реляционных СУБД) или какую-нибудь объектную СУБД. Разработчики данного проекта считают, что это вполне перспективное направление. Поэтому при разработке учитывалась возможность для приложения работать в такой архитектуре. Однако для конкретного описываемого в статье варианта этот подход не использовался.

Домен продается

Популярное

Не так давно в сети появился новый сервис, под названием Dead Man Zero. Этот сервис сделал...
Рынок социальных площадок уже давно стал стабильным. Несмотря на то, что время от времени...
Artisteer 4 – единственный в своем роде продукт, позволяющий автоматизировать работу над созданием...
Октябрь 2018 (14)
Февраль 2017 (3)
Январь 2017 (1)
Август 2016 (1)
Май 2016 (2)
Ноябрь 2015 (1)

Карта сайта: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41

Друзья сайта



Случайная цитата

Неизвестный автор:

"Интернет – пункт приёма, обмена и сбыта краденого остроумия."

Опрос

Как Вам новый дизайн сайта?

Отлично
Неплохо
Нормальный
Ужасно