ASoft использует Java в банковских системах
Валерий Коржов
win.www.osp.ru/java/1997/03/01.html
Java - многообещающая компьютерная технология, однако пока не совсем понятно, какое место ей суждено занять в российских корпоративных системах. Компания ASoft, разрабатывающая ПО для банковской сферы, является одной из немногих российских компаний, которые используют Java при создании систем корпоративного масштаба. Поэтому ее работы в данной области представляют особый интерес.
Когда речь заходит о создании сложных корпоративных приложений, неизбежно возникает вопрос о выборе архитектуры. Вариантов существует достаточно много: архитектура хост-терминал; двухуровневая и многоуровневые архитектуры клиент-сервер; web-технология, или intranet. Но прежде чем выбирать архитектуру, стоит сформулировать требования к "российской корпоративной системе".
В большой корпоративной сети администрирование рабочих мест традиционно считается весьма трудоемкой задачей. Администратору необходимо осуществлять модернизацию ПО на всех рабочих местах, выполнять их настройку и управление конфигурациями. Это особенно сложно, когда рабочие места расположены в разных зданиях и даже городах. Понятно, что ни одному системному администратору не понравится перспектива ездить, например, по всем филиалам банка и устанавливать новые версии программ. Поэтому многие компании, которые используют крупные и распределенные корпоративные сети, стремятся к их централизованной архитектуре. Вкратце рассмотрим, каким образом данные требования могут повлиять на выбор архитектуры корпоративной системы.
Архитектура хост-терминал с очень умным центральным компьютером и очень "глупыми" (если не сказать "тонкими") рабочими местами обеспечивает централизованное управление ПО. Однако она налагает жесткие требования на пропускную способность каналов и очень сильно загружает центральный компьютер. Web-технология также хорошо централизована, меньше нагружает каналы связи, и оборудование у пользователя может быть почти любым, но центральный сервер получается перегруженным, поскольку на нем должно работать очень много различных программ: web-сервер, сервер базы данных и все остальные серверы системы. Двухуровневая технология клиент-сервер распределяет нагрузку между центральным компьютером и рабочим местом, но опять же налагает достаточно жесткие требования на каналы связи, так как по ним передаются необработанные данные.
Специалисты компании ASoft в результате длительного экспериментирования пришли к выводу, что адекватной архитектурой для реализации их проектов является многоуровневая система клиент-сервер. "Было время, когда мы писали приложения для клиент-серверных архитектур с двумя и двумя с половиной уровнями, - говорит Сергей Петрушенко, главный инженер ASoft. - В конце концов остановились на многослойной технологии клиент-сервер, потому что, на наш взгляд, она наиболее гибка. Нам приходится иметь дело не только с базами данных, но и с другими внешними источниками информации и устройствами. Даже если мы основное приложение делаем в двухслойной архитектуре, для управления этими устройствами все равно приходится что-то изобретать".
Ключевая идея многоуровневой технологии клиент-сервер состоит в том, чтобы иметь отдельный сервер, на котором функционирует специальное промежуточное ПО. Он выполняет роль сервера для рабочих мест и роль клиента для сервера базы данных и других серверов. Такую трехуровневую архитектуру можно реализовывать по-разному: например, на основе менеджера транзакций, который просто переправляет запросы базе данных, либо по более сложной объектной технологии типа CORBA. "Мы выбрали CORBA, поскольку считаем, что за ней будущее, - отмечает Петрушенко. - Это более сложная, но и более гибкая технология. Она позволяет нам строить приложения как из собственных, так и из готовых компонентов. Кроме того, она дает возможность интегрировать системы не на уровне баз данных, а на уровне программных компонентов".
В такой трехуровневой архитектуре клиент-сервер нашлось место и для Java - для создания универсального пользовательского интерфейса. Основная система работает на сервере приложений, посылая запросы различным базам данных, а доступ к ней обеспечивается с помощью Java-приложений, которые исполняются на рабочих местах пользователей.
Еще в недавнем прошлом для организации интерфейса пользователя с корпоративными системами вполне годились алфавитно-цифровые терминалы. Однако сейчас пользователям все чаще требуется графический интерфейс. X-терминалы для этого не очень подходят, так как сильно загружают сеть и сервер. Java же как раз позволяет перераспределить нагрузку между сервером и рабочим местом. "Вместе с Java появилась возможность, во-первых, иметь графический интерфейс, во-вторых, разгрузить сервер и, в-третьих, обеспечить централизованное управление системой", - отмечает Петрушенко.
Впрочем, распределенные компьютерные комплексы можно строить и на базе протокола HTTP, который позволят выполнять приложения на web-серверах и получать доступ к web-среде из браузеров. Java дает возможность сделать вычислительную систему еще более распределенной, передавая часть работы, которую осуществляет web-сервер, браузеру. В результате появляется возможность строить более гибкие и производительные системы.
Итак, web-технология, дополненная Java, почти идеально подходит на роль интерфейса с конечными пользователями. При этом главным преимуществом Java является возможность выполнения единожды написанных Java-программ практически на любой платформе, что позволяет сохранить уже вложенные в вычислительную технику средства. Если не использовать Java, то клиентское ПО для каждой платформы придется переписывать заново.
"Мы применяем технологию Java в "БашКредитБанке", где действует разработанная нами учетная система вкладов частных лиц, - говорит Петрущенко. - Сейчас устанавливаем биллинговую систему в компании VessoLink. В VessoLink на одном компьютере будут работать сервер приложений и сервер баз данных Oracle. Рабочих мест там не меньше полусотни. В "БашКредитБанке" мы поставили один сервер, а они сами переносят его с машины на машину, запускают несколько копий. Рабочих мест там тоже около пятидесяти. В качестве сервера базы данных используется двухпроцессорный Compaq 5000, а для сервера приложений - двухпроцессорный компьютер Compaq 2500, на всех рабочих местах - Windows 95".
Компоненты Java обычно устанавливают на сервер локальной сети. Там же хранятся и Java-классы, и вся загрузка Java-программ выполняется с этого сервера. В случае, если у организации есть филиалы со своими локальными сетями и медленными каналами связи с центром, в каждой такой сети устанавливается отдельный сервер, на который автоматически реплицируются все Java-программы с центрального сервера (это можно сделать и по медленным каналам). На сами же рабочие станции не устанавливается ничего, кроме браузера. Таким образом гарантируется очень быстрое и своевременное обновление ПО. Причем модернизация системы выполняется автоматически и проходит незаметно для конечного пользователя.
Однако, хотя производители ПО и уверяют, что Java-программы одинаково выполняются на различных платформах, практика показала, что это не всегда так. Например, сотрудники ASoft обнаружили, что в JDK 1.1.3 компонент-меню, который под Solaris работал правильно, под Windows открывал окно на весь экран и зависал. Причем в ранних версиях JDK такой ошибки не было. Есть проблемы и с русификацией Java-программ, поскольку русификаторы для Windows и Solaris работают по-разному. Сама же JavaSoft проблему локализации еще не может решить. Специалисты ASoft выявили и другие проблемы. Например, Java-терминалы, выпускаемые Sun, работают только с латинскими шрифтами, и установить в них русские пока невозможно. Правда, Sun обещает в скором времени выпустить Java-терминал, который позволит использовать JDK 1.1 и загружать любые внешние шрифты, в том числе и русские. Это нововведение откроет Java-терминалам путь на российских рынок. По мнению сотрудников ASoft, хорошее будущее в России ожидает и другую инициативу фирмы Sun - Java PC, которая позволяет применять в качестве Java-терминалов устаревшие компьютеры с 286 и 386 процессорами Intel и небольшим объемом ОЗУ. Такое решение вернет к жизни устаревшее оборудование, которое в больших количествах еще сохранилось в российских организациях.
Следует, однако, отметить, что использовать Java для более серьезных целей, чем интерфейс с пользователем, многие специалисты считают преждевременным. Одна из причин - неэффективность применяемого в Java механизма очистки памяти (garbage collection - буквально "сборка мусора"). Если в Си и С++ неиспользуемый ресурс освобождался сразу же после выхода из соответствующего блока программы, то в Java это происходит с некоторой задержкой - пока сборщик мусора "сообразит", что данный ресурс свободен. В небольших системах (например, в клиентских программах) такой "мусор" почти ни на что не влияет, но когда речь идет о серверных Java-программах, одновременно обслуживающих большое количество пользователей, количество "мусора" может достичь таких масштабов, что он заблокирует работу всей системы.
"Использовать "сборщик мусора" в Java неудобно, - поясняет Петрушенко. - Допустим, есть сервер и клиент. Клиент устанавливает сеанс связи с сервером, и сервер выделяет для него ресурсы. Если сервер написан на С++, то после разрыва связи он автоматически вызывает специальные методы-деструкторы, которые освобождают зарезервированные для клиента ресурсы. В Java же ресурсы на сервере остаются зарезервированными, и неизвестно, когда они будут освобождены. Для клиента процесс освобождения ресурсов незаметен, но с сервером работают сотни людей, которые могут зарезервировать (но не использовать) достаточно большой объем памяти. Поэтому приходится прибегать к явному освобождению ресурсов, что, конечно же, очень неудобно".
Есть и другие проблемы, характерные для языка Java, такие, как отсутствие шаблонов и переопределения операторов, которые ограничивают его использование там, где применяется С++ (например, на сервере приложений, поскольку для него не нужны кросс-платформенные возможности Java). "Использовать Java в серверах приложений, - констатирует Петрушенко, - совершенно неразумно, потому что Java по сравнению с С++ - довольно слабый язык".
Подготовил Александр Запольскис
win.www.osp.ru/java/1997/03/01.html
Java - многообещающая компьютерная технология, однако пока не совсем понятно, какое место ей суждено занять в российских корпоративных системах. Компания ASoft, разрабатывающая ПО для банковской сферы, является одной из немногих российских компаний, которые используют Java при создании систем корпоративного масштаба. Поэтому ее работы в данной области представляют особый интерес.
Когда речь заходит о создании сложных корпоративных приложений, неизбежно возникает вопрос о выборе архитектуры. Вариантов существует достаточно много: архитектура хост-терминал; двухуровневая и многоуровневые архитектуры клиент-сервер; web-технология, или intranet. Но прежде чем выбирать архитектуру, стоит сформулировать требования к "российской корпоративной системе".
В большой корпоративной сети администрирование рабочих мест традиционно считается весьма трудоемкой задачей. Администратору необходимо осуществлять модернизацию ПО на всех рабочих местах, выполнять их настройку и управление конфигурациями. Это особенно сложно, когда рабочие места расположены в разных зданиях и даже городах. Понятно, что ни одному системному администратору не понравится перспектива ездить, например, по всем филиалам банка и устанавливать новые версии программ. Поэтому многие компании, которые используют крупные и распределенные корпоративные сети, стремятся к их централизованной архитектуре. Вкратце рассмотрим, каким образом данные требования могут повлиять на выбор архитектуры корпоративной системы.
Архитектура хост-терминал с очень умным центральным компьютером и очень "глупыми" (если не сказать "тонкими") рабочими местами обеспечивает централизованное управление ПО. Однако она налагает жесткие требования на пропускную способность каналов и очень сильно загружает центральный компьютер. Web-технология также хорошо централизована, меньше нагружает каналы связи, и оборудование у пользователя может быть почти любым, но центральный сервер получается перегруженным, поскольку на нем должно работать очень много различных программ: web-сервер, сервер базы данных и все остальные серверы системы. Двухуровневая технология клиент-сервер распределяет нагрузку между центральным компьютером и рабочим местом, но опять же налагает достаточно жесткие требования на каналы связи, так как по ним передаются необработанные данные.
Специалисты компании ASoft в результате длительного экспериментирования пришли к выводу, что адекватной архитектурой для реализации их проектов является многоуровневая система клиент-сервер. "Было время, когда мы писали приложения для клиент-серверных архитектур с двумя и двумя с половиной уровнями, - говорит Сергей Петрушенко, главный инженер ASoft. - В конце концов остановились на многослойной технологии клиент-сервер, потому что, на наш взгляд, она наиболее гибка. Нам приходится иметь дело не только с базами данных, но и с другими внешними источниками информации и устройствами. Даже если мы основное приложение делаем в двухслойной архитектуре, для управления этими устройствами все равно приходится что-то изобретать".
Ключевая идея многоуровневой технологии клиент-сервер состоит в том, чтобы иметь отдельный сервер, на котором функционирует специальное промежуточное ПО. Он выполняет роль сервера для рабочих мест и роль клиента для сервера базы данных и других серверов. Такую трехуровневую архитектуру можно реализовывать по-разному: например, на основе менеджера транзакций, который просто переправляет запросы базе данных, либо по более сложной объектной технологии типа CORBA. "Мы выбрали CORBA, поскольку считаем, что за ней будущее, - отмечает Петрушенко. - Это более сложная, но и более гибкая технология. Она позволяет нам строить приложения как из собственных, так и из готовых компонентов. Кроме того, она дает возможность интегрировать системы не на уровне баз данных, а на уровне программных компонентов".
В такой трехуровневой архитектуре клиент-сервер нашлось место и для Java - для создания универсального пользовательского интерфейса. Основная система работает на сервере приложений, посылая запросы различным базам данных, а доступ к ней обеспечивается с помощью Java-приложений, которые исполняются на рабочих местах пользователей.
Еще в недавнем прошлом для организации интерфейса пользователя с корпоративными системами вполне годились алфавитно-цифровые терминалы. Однако сейчас пользователям все чаще требуется графический интерфейс. X-терминалы для этого не очень подходят, так как сильно загружают сеть и сервер. Java же как раз позволяет перераспределить нагрузку между сервером и рабочим местом. "Вместе с Java появилась возможность, во-первых, иметь графический интерфейс, во-вторых, разгрузить сервер и, в-третьих, обеспечить централизованное управление системой", - отмечает Петрушенко.
Впрочем, распределенные компьютерные комплексы можно строить и на базе протокола HTTP, который позволят выполнять приложения на web-серверах и получать доступ к web-среде из браузеров. Java дает возможность сделать вычислительную систему еще более распределенной, передавая часть работы, которую осуществляет web-сервер, браузеру. В результате появляется возможность строить более гибкие и производительные системы.
Итак, web-технология, дополненная Java, почти идеально подходит на роль интерфейса с конечными пользователями. При этом главным преимуществом Java является возможность выполнения единожды написанных Java-программ практически на любой платформе, что позволяет сохранить уже вложенные в вычислительную технику средства. Если не использовать Java, то клиентское ПО для каждой платформы придется переписывать заново.
"Мы применяем технологию Java в "БашКредитБанке", где действует разработанная нами учетная система вкладов частных лиц, - говорит Петрущенко. - Сейчас устанавливаем биллинговую систему в компании VessoLink. В VessoLink на одном компьютере будут работать сервер приложений и сервер баз данных Oracle. Рабочих мест там не меньше полусотни. В "БашКредитБанке" мы поставили один сервер, а они сами переносят его с машины на машину, запускают несколько копий. Рабочих мест там тоже около пятидесяти. В качестве сервера базы данных используется двухпроцессорный Compaq 5000, а для сервера приложений - двухпроцессорный компьютер Compaq 2500, на всех рабочих местах - Windows 95".
Компоненты Java обычно устанавливают на сервер локальной сети. Там же хранятся и Java-классы, и вся загрузка Java-программ выполняется с этого сервера. В случае, если у организации есть филиалы со своими локальными сетями и медленными каналами связи с центром, в каждой такой сети устанавливается отдельный сервер, на который автоматически реплицируются все Java-программы с центрального сервера (это можно сделать и по медленным каналам). На сами же рабочие станции не устанавливается ничего, кроме браузера. Таким образом гарантируется очень быстрое и своевременное обновление ПО. Причем модернизация системы выполняется автоматически и проходит незаметно для конечного пользователя.
Однако, хотя производители ПО и уверяют, что Java-программы одинаково выполняются на различных платформах, практика показала, что это не всегда так. Например, сотрудники ASoft обнаружили, что в JDK 1.1.3 компонент-меню, который под Solaris работал правильно, под Windows открывал окно на весь экран и зависал. Причем в ранних версиях JDK такой ошибки не было. Есть проблемы и с русификацией Java-программ, поскольку русификаторы для Windows и Solaris работают по-разному. Сама же JavaSoft проблему локализации еще не может решить. Специалисты ASoft выявили и другие проблемы. Например, Java-терминалы, выпускаемые Sun, работают только с латинскими шрифтами, и установить в них русские пока невозможно. Правда, Sun обещает в скором времени выпустить Java-терминал, который позволит использовать JDK 1.1 и загружать любые внешние шрифты, в том числе и русские. Это нововведение откроет Java-терминалам путь на российских рынок. По мнению сотрудников ASoft, хорошее будущее в России ожидает и другую инициативу фирмы Sun - Java PC, которая позволяет применять в качестве Java-терминалов устаревшие компьютеры с 286 и 386 процессорами Intel и небольшим объемом ОЗУ. Такое решение вернет к жизни устаревшее оборудование, которое в больших количествах еще сохранилось в российских организациях.
Следует, однако, отметить, что использовать Java для более серьезных целей, чем интерфейс с пользователем, многие специалисты считают преждевременным. Одна из причин - неэффективность применяемого в Java механизма очистки памяти (garbage collection - буквально "сборка мусора"). Если в Си и С++ неиспользуемый ресурс освобождался сразу же после выхода из соответствующего блока программы, то в Java это происходит с некоторой задержкой - пока сборщик мусора "сообразит", что данный ресурс свободен. В небольших системах (например, в клиентских программах) такой "мусор" почти ни на что не влияет, но когда речь идет о серверных Java-программах, одновременно обслуживающих большое количество пользователей, количество "мусора" может достичь таких масштабов, что он заблокирует работу всей системы.
"Использовать "сборщик мусора" в Java неудобно, - поясняет Петрушенко. - Допустим, есть сервер и клиент. Клиент устанавливает сеанс связи с сервером, и сервер выделяет для него ресурсы. Если сервер написан на С++, то после разрыва связи он автоматически вызывает специальные методы-деструкторы, которые освобождают зарезервированные для клиента ресурсы. В Java же ресурсы на сервере остаются зарезервированными, и неизвестно, когда они будут освобождены. Для клиента процесс освобождения ресурсов незаметен, но с сервером работают сотни людей, которые могут зарезервировать (но не использовать) достаточно большой объем памяти. Поэтому приходится прибегать к явному освобождению ресурсов, что, конечно же, очень неудобно".
Есть и другие проблемы, характерные для языка Java, такие, как отсутствие шаблонов и переопределения операторов, которые ограничивают его использование там, где применяется С++ (например, на сервере приложений, поскольку для него не нужны кросс-платформенные возможности Java). "Использовать Java в серверах приложений, - констатирует Петрушенко, - совершенно неразумно, потому что Java по сравнению с С++ - довольно слабый язык".
Подготовил Александр Запольскис
Компьютерная газета. Статья была опубликована в номере 50 за 1997 год в рубрике программирование :: java
