В разные периоды времени практиковались разные подходы к созданию корпоративных приложений. Каждый из этих подходов имеет свои достоинства и недостатки. Рассмотрим их более подробно.
Реакция на недостатки однозвенной архитектуры привела к тому, что наиболее прогрессивной была признана тенденция переноса основной "тяжести" приложения на компьютер, за которым работает пользователь, – клиентское рабочее место. В короткие сроки было выпущено значительное число средств разработки, позволяющих быстро и надежно создавать программы, способные взаимодействовать с серверами баз данных. Сейчас такие инструментальные среды обычно называют RAD-системами – средствами быстрой разработки приложений.
За счет четкого разделения функций между клиентом и сервером подобный подход обеспечивал гибкость, безопасность и конфиденциальность.
Казалось, дело шло превосходно. Но только до тех пор, пока количество пользователей было невелико, и они находились не слишком далеко друг от друга и от компьютера-сервера (желательно – не далее, чем в
соседней комнате). Задача обновления программного обеспечения, установленного на сотнях и тысячах удаленных друг от друга компьютеров, с организационной точки зрения оказалась чрезвычайно сложной .
Кроме того, наметился очевидный разрыв между "клиентом" и "сервером". Так, производители СУБД при разработке своих программных продуктов хорошо видели свои проблемы, но были плохо осведомлены о проблемах взаимодействия их ПО с клиентскими частями приложений. Надежность системы в целом определялась тем, как с этой задачей справятся разработчики клиентских частей приложений, что неизбежно увеличило сроки создания последних.
На практике все это привело к тому, что приложения, выполненные в классической архитектуре "клиент/сервер", ориентированы скорее на небольшую, относительно компактную группу пользователей, чем на крупную организацию (фирму, корпорацию) в целом.
Основная идея, заложенная в основу многозвенной архитектуры, – перенос реализации бизнес-правил (формализованных и воплощенных в программном коде правил работы организации) как с серверной, так и с клиентской части приложения в некоторое промежуточное звено. Это промежуточное звено можно рассматривать как библиотеку объектов, реализующих требуемые бизнес-правила. Преимущества этого подхода очень существенны.
Во-первых, клиентская часть приложения сильно упрощается и удешевляется. Например, при использовании BDE процесс, запускаемый на компьютере-клиенте и взаимодействующий с каким-нибудь сервером баз данных, не требует наличия на этом компьютере ни динамических библиотек BDE, ни настройки самого BDE. Более того, исполняемый модуль практически не использует функции API BDE. При использовании традиционной схемы это не было бы возможно. Очевидно, доставка и установка таких клиентских частей не является сложной организационной проблемой – это приблизительно то же самое, что установить Web-браузер.
Во-вторых, функциональность системы оказывается не связана ни с конкретным языком программирования, используемым для создания клиентских частей приложений, ни с особенностями используемой СУБД.
Однако и у многозвенной архитектуры имеются свои недостатки. Обеспечение безопасности и управляемости распределенного приложения, работающего в гетерогенной среде и включающего в себя десятки серверов баз данных, серверов приложений и сотни (или тысячи) взаимодействующих с ними упрощенных ("тонких") клиентов, является непростой задачей. Нужны некоторые дополнительные инструменты и сервисы. Кстати, их реализуют такие программные продукты Borland, как MIDAS и Entera.
Учебно-консалтинговый центр Interface Ltd. проводит курсы по программным продуктам фирмы Borland.