Технология Клиент-Сервер 1998'1
	Home Поиск Издания Контакты k-press.ru

Продолжается подписка на наши издания! Вы не забыли подписаться?

От редакции

Темой этого номера стала многоуровневая архитектура клиент-сервер. Как она появилась? Какие преимущества дает ее применение на практике? Как создать приложения работающие в этой архитектуре? В этом номере мы начинаем обстоятельный разговор на эти темы.

Поначалу для того, чтобы несколько человек могли (с помощью компьютера) работать с общей информацией, всю информацию и необходимое для ее обработки программное обеспечение располагали на “большом компьютере”. Программы обработки этой информации запускались непосредственно на этом “большом компьютере”, а люди имели доступ к ним через терминалы.¹

У этого подхода есть всего два (но очень существенных) недостатка.

1. Очень высокая цена “больших компьютеров”.

2. Перегрузка, а вследствие этого недостаточная производительность работы системы.

Если с первым пунктом все понятно, то со вторым невольно возникает вопрос: на что же тратится мощь такого дорогого “большого компьютера”? Как не банально это звучит – на интерфейс с пользователем и на выполнение задач, напрямую не связанных в обработкой совместно используемых данных.

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

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

Цена такой машины была на порядки меньше цены “большого компьютера”, а главное, для увеличения числа рабочих мест достаточно было докупить необходимое количество персоналок. Проблема обработки совместно используемых данных решалась при этом соединением нескольких таких компьютеров в сеть. Развитием этой идеи явился вынос общих данных на специально выделенную для их хранения машину. Такую машину стали называть сервером (вернее, файл-сервером, так как основной единицей разделения информации в те времена являлся файл). Разделение на уровне файла не могло удовлетворить всех потребностей пользователя, поэтому вскоре появились так называемые файл-серверные базы данных (БД). Система управления базой данных (СУБД) работала на каждой клиентской машине и позволяла осуществлять разделяемый (на уровне записи) доступ.

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

Однако при таком подходе появились другие проблемы, а именно:

• Из-за того, что СУБД находилась на клиентской машине, для осуществления любой выборки или модификации БД необходимо было прокачивать по сети большие объемы данных, вследствие чего производительность не поднялась, а упала.

• Сетевые соединения оказались менее надежными, чем внутренние шины и оперативная память “больших компьютеров”, что привело к общему снижению надежности системы.

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

• Из-за того, что данные хранились на сервере в общедоступной форме, появились проблемы с защитой информации от несанкционированного доступа. Они оказались настолько существенными, что многие владельцы “больших компьютеров” вообще отказались от перехода на файл-серверную технологию.

В это момент на сцене появилась “технология клиент-сервер”.

Главной идее этой технологии был перенос на сервер функций СУБД и контроля бизнес-логики. Преимущества этой технологии очевидны:

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

За счет транзакционного² механизма общая надежность системы стала выше, чем при использование “больших компьютеров”.

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

Размещение бизнес-логики на сервере позволило облегчить разработку более надежных и гибких программ.

“Что же еще надо!” – воскликнете вы и … будете не правы.

У этой технологии тоже есть свои недостатки:

Хотя цена клиент-серверных систем значительно ниже, чем систем на базе “больших компьютеров”, но все же выше файл-серверных за счет того, что серверное приложение стоит денег (и порой немалых).

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

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

Многоуровневая архитектура клиент-сервер (МАКС) совместно с компонентным подходом к разработке программного обеспечения должны помочь современным программистам перейти на новый виток в разработке систем масштаба предприятия.

Постулаты МАКС довольно просты:

1. В системе выделяется три слоя:

   1) слой пользовательского интерфейса;

   2) слой бизнес-логики;

   3) слой логики работы с данными.

2. Каждый из слоев (кроме слоя пользовательского интерфейса) разбиваются на части.

3. Каждая часть системы описывается как компонент.

4. Определяются связи между компонентами.

В сущности, МАКС можно было бы назвать трехуровневой архитектурой, но в виду того, что компоненты бизнес-логики могут быть распределены между отдельными серверами, и, так как между бизнес компонентами может быть построена своя иерархия, (их можно дополнительно поделить на уровни), эта архитектура называется многоуровневой.

Сейчас преобладают две технологии. Одна из них - COM/DCOM фирмы Microsoft, другая - CORBA консорциума OMG. В этом и последующих номерах нашего журнала мы будем публиковать статьи посвященные по теоретическим и, главное, практическим аспектам этой МАКС. Но мы не хотим зацикливаться только на продуктах и решениях больших американских корпораций, поэтому наши материалы будут включать статьи о разработках не столь больших гигантов.

Стоит заметить, что подавляющее большинство разработок ведется в расчете на вполне конкретные платформы или, более того в расчете на использование одного определенного продукта. Не столь важно, планирует разработчик использование своего приложения с MS SQL Server, Oracle 8 или DB/2. Важно то, что он зависит от этой платформы и вынужден постоянно отслеживать как ее текущее состояние, так и ближайшие перспективы ее развития. Перенос с одной платформы на другую отнимает немало средств и времени, а кроссплатформная разработка с использованием новомодных средств оказывается, как правило, очень похожей на настоящую, но не работающей. Поэтому мы в ближайших номерах планируем опубликовать ряд материалов, посвященных современному положению дел на этом динамичном рынке.

Copyright © 1994-2016 ООО "К-Пресс"