Везет разработчикам! Им редко приходится иметь дело с теми программными продуктами, которые они создают. Даже если, принимая очередное решение, разработчик исполнен благих намерений, это отнюдь не гарантирует продуктивной работы пользователей и администраторов с его приложением. В последнее время среди наиболее важных вопросов создания сетевых приложений появился еще один: какую выбрать архитектуру - клиент-серверную или основанную на службе Web?
Существование этих двух типов архитектуры характеризует современное состояние дел в технологии построения информационных систем, причем архитектура клиент-сервер является более распространенной. Главное различие данных подходов заключается в том, как каждый из них "представляет" себе свое дальнейшее развитие и реагирует на основные тенденции рынка вычислительных технологий.
Например, системы клиент-сервер не могут полноценно реализовать те преимущества, которые предоставляют сетевые компьютеры, интрасети и язык Java. Web-приложения на основе Java и ActiveX являют собой новую централизованную архитектуру, в отличие от распределенного подхода к вычислениям, реализованного благодаря появлению настольных компьютеров. Однако отложим на время дискуссию о перспективах и на примере конкретной компании или сети рассмотрим, как оба этих подхода работают уже сегодня.
Клиент-сервер и Web: рассмотрим поближе
Производительность, надежность, интенсивность сетевого трафика, степень загрузки администратора, обеспечение безопасности и балансировка нагрузки - все это критерии оценки сетевой информационной системы. Мало того, все они тесно взаимосвязаны.
Дело осложняется еще и тем, что довольно трудно дать точное определение двум рассматриваемым архитектурным подходам. В классической архитектуре клиент-сервер клиентская часть представлена так называемым "толстым" клиентом, т. е. приложением, разработанным с помощью пакета типа Visual Basic или Delphi. Свое "прозвище" он получил в связи с тем, что помимо уровня представления информации содержит еще и бизнес-логику прикладной задачи. Такой клиент работает не только с реляционной базой данных, но и с файл-сервером. Стандартное Web-приложение, как правило, используется лишь для представления данных. Вся бизнес-логика в этом случае выполняется на сервере приложений, который и обращается к СУБД.
Однако существуют реализации архитектуры клиент-сервер, где часть бизнес-логики перенесена на выделенные компьютеры. Такие системы уже ближе к классической Web-архитектуре. Или, наоборот, могут быть созданы Web-приложения, в которых часть бизнес-логики выполняется на основе кода на JavaScript или мини-приложения Java.
Исследование производительности
Для сравнительной оценки производительности этих двух подходов мы засекали время реакции пользовательского интерфейса, отражающего работу бизнес-логики сначала на клиентской стороне (при тестировании "толстого" клиента), а потом и на серверной, причем во втором случае приложения запускались на нескольких машинах.
Заложенная в программу бизнес-логика состояла в основном из SQL-запросов, и ее главной целью было просто загрузить процессор машины. Программы на "толстых" клиентах содержали как прикладную часть, так и функции управления пользовательским интерфейсом, например ввод и редактирование данных. Бизнес-логика, работавшая на серверах приложений, была создана преимущественно с помощью программного интерфейса ISAPI (Internet Server Application Programming Interface) фирмы Microsoft и содержала вызовы функций динамических библиотек, в частности отвечающих за формирования страниц HTML. Для доступа к таблицам базы данных обе версии приложений - и клиент-серверная и Web - использовали интерфейс ODBC (Open Database Connectivity).
В процессе запуска наших "доморощенных" приложений мы отметили, что динамические библиотеки, написанные на Delphi, работают быстрее DLL, созданных с помощью Visual Basic. И вообще, производительность Delphi нас приятно удивила. Дело в том, что мы использовали специальную библиотеку WebBridge фирмы Borland International, позволяющую абстрагироваться от конкретного способа взаимодействия с Web-сервером, будь то интерфейс ISAPI или NSAPI (Netscape Application Programming Interface) фирмы Netscape Communications.
У нас не было времени оценить технологию реализации бизнес-логики в виде хранимых процедур, т. е. кода, который запускается непосредственно на компьютере сервера базы данных. Однако перенос бизнес-логики в сетевой среде на процессор компьютера СУБД способен вызвать дополнительные проблемы при увеличении интенсивности транзакций. Возможно, в этом случае вам придется увеличить число серверов баз данных и установить дополнительное связующее ПО в виде монитора транзакций, чтобы информационная система справилась с нагрузкой.
Серверы баз данных различных поставщиков имеют собственный синтаксис хранимых процедур. Так, в сервере Oracle реализован язык PL/SQL, а в MS SQL Server - язык Transact-SQL. Это несколько ограничивает возможность применения хранимых процедур, ведь вам вряд ли захочется выбрасывать массу наработанного кода, если вы вдруг поменяете поставщика СУБД. Тем не менее мы считаем, что разумное использование хранимых процедур способно в равной степени повысить производительность приложений и в клиент-серверной среде и в среде Web.
В нашей экспериментальной конфигурации для загрузки приложений мы использовали файл-сервер, поскольку в типовой архитектуре корпоративной информационной системы приложения обычно хранятся не на локальных дисках, а на дисках файл-серверов. Таким образом, наши приложения порождали повышенный сетевой трафик в момент загрузки, при доступе к данным на файл-сервере, а также при обращении к базам данных.
Трафик Web-приложений имеет несколько иную структуру, поскольку сеть задействуется каждый раз при обращении пользователя к HTML-странице или к соответствующему фрагменту приложения на JavaScript или Java, хранящемуся на Web-сервере. Кроме того, повышенная сетевая активность наблюдалась при передаче данных с Web-клиента на Web-сервер, а также при обращении сервера приложений к СУБД. (В нашей конфигурации модули бизнес-логики и ПО Web-сервера работали на одном и том же компьютере.)
Интересно, что трафик в гораздо большей степени зависел от используемого сервера баз данных (Oracle, MS SQL Server или DB2), чем от архитектурного подхода. В частности, для Oracle мы наблюдали наименьший сетевой трафик, а для SQL Server - наибольший.
Большое значение имеют и используемые сетевые протоколы. Так, наиболее "разговорчивым" оказался протокол NetBEUI, IPX/SPX был более умеренным, и самым "лаконичным" был TCP/IP. Мы также смогли снизить трафик службы DNS (Domain Name Service), используя непосредственные адреса серверов баз данных вместо их доменных имен. Но для сетевых администраторов применение этого метода означает дополнительную работу при установке новых машин.
Загрузка администратора
На сетевых администраторов обычно возлагается целый ряд обязанностей, таких, как обеспечение работы клиентских и серверных приложений, справочной службы, управление безопасностью, распространение ПО и т. п.
Администратор системы клиент-сервер должен контролировать использование файлового сервера, настраивать логические диски и конфигурировать параметры доступа к серверу баз данных. Время от времени ему приходится устанавливать файл-серверы и серверы базы данных, инсталлировать новые версии ПО, а часто и отвечать за неожиданно возникающие отказы приложений. На него также ложится ответственность за обеспечение безопасности, что подразумевает назначение пользовательских имен и паролей, постоянный контроль журнальных файлов и использование тех средств безопасности, которые приняты в данной организации.
В Web-среде у администратора примерно те же задачи. Однако на поддержку пользователей, связанную, например, с перезапуском "зависших" приложений, у него уходит гораздо меньше времени, поскольку Web-браузеры, такие, как Microsoft Internet Explorer или Netscape Navigator, "зависают" гораздо реже программ, выполненных с помощью средств разработки наподобие Visual Basic или Delphi. Кроме того, браузер автоматически получает классы мини-приложений Java с Web-сервера, поэтому администраторам не приходится заботиться о распространении пользовательских приложений на локальные диски.
Задача выравнивания нагрузки также обычно ложится на плечи сетевых администраторов. Она подразумевает добавление файл-серверов, Web-серверов, серверов баз данных и приложений по мере увеличения числа пользователей и последующую настройку приложений, с тем чтобы они могли распознавать добавленные ресурсы. Но если вы используете такое связующее ПО, как, например, монитор транзакций TUXEDO фирмы BEA Systems, то работы у вас будет намного меньше: этот продукт позволяет автоматически распознавать новые ресурсы, а также регулировать вычислительную мощность при изменении интенсивности транзакций.
Сравнение по надежности
Web-подход в общем оказался более надежным, чем клиент-серверный. Поддержка программы, т. е. необходимость внесения новых полей редактирования или изменение старых, делают ПО клиент-сервер менее стабильным. Эпитет "толстый" стал синонимом определения "сложный". Отладка и тестирование приложений клиент-сервер - довольно сложный процесс, поскольку они содержат большое число тесно взаимодействующих модулей. С другой стороны, когда во время тестирования неожиданно начинали "сыпаться" ошибки, обнаружить их в "толстом" клиенте было значительно легче: ОС Windows выводила на экран соответствующее сообщение.
Характерно, что в Web-среде "зависшая" DLL, написанная с помощью ISAPI, выводила сообщение на консоль сервера приложений, но пользователь при этом продолжал смотреть на неменяющийся экран браузера. В случае серьезной ошибки исполнения модуля DLL операционная система Windows NT будет вынуждена завершить работу Web-сервера IIS (Internet Information Server) вместе с приложением. С точки зрения надежности поставщикам следовало бы разрабатывать более совершенные методы отражения проблем сервера приложений для тех, кто использует Web-браузер.
Если выделить бизнес-логику в отдельный серверный процесс, то поддержка программ станет намного легче. И наоборот, архитектура клиент-сервер требует более значительных усилий для внесения каких-либо изменений в бизнес-логику.
После добавления новых полей редактирования в электронную форму нам приходилось внимательно отслеживать, как это изменение может повлиять на другие части программы клиент-сервер. Необходимо было убедиться, что бизнес-логика, обслуживающая новое поле, будет работать корректно, не влияя на обработку других полей ввода или логических модулей.
Один раз мы случайно внесли в клиент-серверную программу ошибку, которая при введении определенной комбинации символов в поле ввода приводила к серьезному сбою. В приложении, написанном на JavaScript или Java, подобной ошибки избежать гораздо легче благодаря простоте кода на стороне клиента. Хотя, конечно, ни один из подходов не гарантирует полной надежности. Но ясно, что сложность программы влечет за собой ошибки так же неизбежно, как болото - комаров. Клиент-серверный подход требует лучших навыков программирования и большей аккуратности.
Победителем становится...
Соревнование между архитектурой клиент-сервер и средой Web завершилось в пользу последней. С точки зрения преимуществ работы в сетевой среде Web-приложение уменьшает сложность ПО, увеличивает производительность и дает возможность использовать в вашей компании передовые технологии, такие, как сетевые компьютеры. Однако приложение клиент-сервер предоставляет всю мощь настольного компьютера для выполнения бизнес-логики и дает пользователю более ясное представление результатов обработки данных.
Если у вас еще нет корпоративной стратегии, которая отдавала бы предпочтение какому-либо из двух подходов, то мы думаем, что вашей компании будет нелишним по крайней мере поэкспериментировать с Web-архитектурой. Может быть именно она станет для вас основой построения информационной системы.