Файл: Средства разработки клиентских программ (Архитектура клиент-сервер).pdf

Таблица 1.

Достоинства и недостатки архитектуры клиент-сервер

1.2 Эволюция архитектуры клиент-сервер

Идея организовать вычислительные ресурсы в соответствии с архитектурой клиент-сервер возникла на уровне рабочих групп и подразделений компаний. Менеджеры отделов обнаружили, что использование централизованных приложений, работающих на мэйнфрейме, не дает им достаточно быстро реагировать на требования бизнеса. Развертывание приложений центральным отделом информационного обслуживания требовало очень много времени, а результаты не всегда соответствовали нуждам подразделений. С развитием персональных компьютеров работники получили возможность хранить и обрабатывать данные прямо на своих рабочих местах, а менеджеры отделов — быстро находить нужные приложения.

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

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

1.3 Классы приложений клиент-сервер

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

Выделяют четыре класса приложений с разными вариантами распределения задач между сервером и клиентом.

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

Модель «толстого» клиента стала популярной благодаря появлению таких инструментальных средств как PowerBuilder корпорации Powersoft и SQL Windows корпорации Gupta. Данные инструментальные средства рассчитаны на создание приложений уровня подразделения с поддержкой от 25 до 150 пользователей. Главное достоинство модели «толстого» клиента заключается в том, что она максимально опирается на вычислительные возможности настольного компьютера, освобождая сервер от излишней нагрузки по обработке данных и, таким образом, повышая их эффективность и снижая вероятность того, что сервер станет узким местом системы.

Однако у стратегии «толстого» клиента имеются и недостатки. Оснащение настольных компьютеров новыми функциями быстро истощает их вычислительные мощности, заставляя компании проводить модернизацию. Если в работу приложения вовлекаются множество пользователей из разных подразделений, компании приходится устанавливать локальную сеть с высокой пропускной способностью для поддержки огромных объемов данных, передаваемых между «тонкими» серверами и «толстыми» клиентами. Наконец, приложения, распределенные по нескольким десяткам и сотням настольных машин, трудно поддерживать, обновлять и заменять.

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

Вывод по главе

Клиентские приложения являются составной частью приложения архитектуры клиент-сервер, поэтому в первой главе были рассмотрены основные принципы архитектуры клиент-сервер.

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

Вычислительная модель клиент-сервер действительно представляет собой новый технический метод распределенных вычислений. Но помимо этого, архитектура клиент-сервер создает условия для новых методов организации бизнеса.

Глава 2. Обзор API для создания клиентских приложений

2.1 Настольные приложения

2.1.1 Создание клиентских приложений в Windows.

Для разработки клиентских приложений для Windows используется совокупность функций для написания ПО, работающих под управлением Microsoft Windows 98, Windows NT или Windows 2000 — Win32 API .

Реализация как МFС, так и Windows Forms основана на вызовах функций Windows API. Эти интерфейсы являются надстройкой над Win32 АPI и разработаны для того чтобы облегчить программирование Windows приложений. МFC и Windоws Fоrms способны повысить производительность работы программистов, но также гораздо менее гибки по сравнению с Win32 API. [10]

После запуска windows-программа находится в состоянии ожидания, она ожидает, когда ей операционная система пошлёт сообщение. Операционная система посылает специально оформленные группы данных, называемых сообщениями. Сообщения бывают разных типов, они взаимодействуют с ОС хаотично, поэтому приложение не может знать, какое сообщение оно получит. Отсюда следует, что логике построения Windows-приложения необходимо обеспечивать корректную и предсказуемую работу при поступлении сообщений любого типа. Здесь можно провести некоторую ана­логию между механизмом сообщений Windows и механизмом прерываний в архитектуре IBM PC. Для обеспечения правильной работы программы программисту необходимо знать правила использования функций интерфейса (API) ОС. Windows поддерживает два типа приложений.

1. Оконное приложение создаётся с помощью функций API, которые составляют графический интерфейс пользователя (Graphic User Interface, GUI). Оконное приложение - это программа, в которой вывод на терминал производится в графическом виде. В результате работы оконных приложений на экране отображаются специальные объекты — окна. Затем, приложения должны поддерживать эти окна их в актуальных состояниях.
2. Консольное приложение - это программа, которая работает в текстовом режиме. Консольное приложение в процессе выполнения похоже на программу MS-DOS. Но это только внешние впечатления. Работа консольного приложения осуществляется с помощью специальных функций Windows.

Разница между этими типами Windows-приложений только в том, с какими типами информации они работают.

Основная задача главной функции оконного Windows-приложения состоит в правильной инициализации программы и корректном ее заверше­нии.

Правильная инициализация приложения предполагает выполнение ряда предопределенных шагов.

Под классом окна понимается совокупность присущих ему характеристик, таких как стиль его границ, формы указателя мыши, значков, цвет фона, наличие меню, адрес оконной процедуры, обрабатывающей сообщения этого окна. Класс окна можно впоследствии использовать для создания окон приложения функцией CreateWindow. Характеристики окна описываются с помощью специальной структуры WNDCLASS (или ее рас­ширенного варианта WNDCLASSEX в Win32).

В WinMain определен экземпляр структуры WNDCLASSEX — wc. Первое поле структуры WNDCLASSEX cbSize должно содержать длину структуры. В поле style можно определять стиль границ окна и его поведение при пере­рисовке. Значение стиля является целочисленным и формируется из констант. Каждая константа означает некоторую предопределенную характеристику.

В поле lpfnWndProc записывается адрес оконной функции. С помощью этой функции все окна, созданные позднее функцией CreateWindow на основе класса, для которого выполняется регистрация, будут обрабатывать посланные им сообщения.

Поля cbClsExtra и cbWndExtra служат для указания количества байтов, дополнительно резервируемых в структуре класса окна WNDPROC и структуре параметров окна, которая поддерживается внутри самой системы Windows. Обычно эти поля инициализированы нулевыми значениями.

Дескриптор приложения формируется в поле hlnstance.

В поля Iсоn и hCursor загружаются дескрипторы значка и ука­зателя мыши. После запуска приложения значок будет отображаться на панели задач Windows и в левом верхнем углу окна приложения, а указатель мыши по­явится в области окна. Значки и указатели мыши представляют собой ресурсы и находятся в отдельных файлах. Windows предоставляет в распоряжение программиста ряд стандартных изображений указателей мыши и значков. B фaйлe winuser.h содержатся символические имена констант, обозначающих стандартные указатели мыши и значки.

Последнее действие при описании класса окна — присвоение данному классу уникального имени. Это имя описано в виде ASCIIZ-строки в поле szClassName lpszClassName.

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

Необходимо заметить, что после того как класс окна зарегистрирован, структура WNDCLASSEX больше не нужна. Поэтому появляется возможность сэкономить, немного памяти. Это можно сделать, используя предоставляемый ассемблером тип данных объединения либо инициализируя поля структуры в стеке с последующим их выталкиванием. Здесь есть широкое поле для экспериментов.