КРИТИЧНО ДЛЯ  БИЗНЕСА

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

От нашего клиент-серверного инструментария мы хотим легкости мини-гольфа в сочетании с мощью настоящего гольфа.

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

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

Есть четыре типа разделения: базовое разделение клиент-сервер, разделение данных, логики и объектов. Чтобы успешно провести эти процедуры, нужно выбрать подходящую архитектуру, нужные средства и людей с соответствующими профессиональными навыками. Давайте посмотрим, что требуется в каждом из этих случаев. Простое разделение клиент-сервер, или подход "мини-гольф". Здесь интерфейс пользователя, логика сохранения целостности полей и перекрестных ссылок (cross-field), бизнес-логика, а также компоненты настольного ПО и совместно используемые компоненты выполняются на клиентском ПК, Логика сохранности целостности транзакций и управление данными реализованы на единственном сервере. Роли и профессиональные навыки обычные.

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

Логическое разделение, или серия ударов. Вот здесь вам придется закопаться в однослойную, многоуровневую равноправную (узел к узлу) архитектуру. Интерфейс пользователя, бизнес-логика и логика целостности полей и перекрестных ссылок исполняются на платформе-клиенте. Бизнес-логика, а также компоненты настольного ПО и совместно используемых компонент исполняются на стороне клиента или на сервере приложений. Логика сохранения целостности транзакций реализуется на сервере приложений. Управление данными происходит на большом центральном сервере данных.

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

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

Кристина Комафорд

Кристина Комафорд, президент фирмы Corporate Computing, с ней можно связаться по адресам: MCI Mail (371-9004), CompuServe (74603,3664), Internet (74603.3664@compuserve.com) или no факсу (708-374-1124).