Лучшие статьи журнала ╚Компьютеры+Программы╩

Здравствуйте, уважаемые читатели!

В этом выпуске рассылки публикуется статья, занявшая по результатам голосования второе место.

Михаил Продан,
1099511627776@mail.ru
www.g299792458.boom.ru

Разработка многоуровневых приложений

В сетях часто нужен доступ к серверу БД большого количества клиентских приложений на Delphi. Одно из решений — копирование BDE на все клиентские машины и настройка соединений. Но существует и более «культурный» способ — доступ через протокол MIDAS

MIDAS — что это такое?

MIDAS — multi-tired distributed application service suite. Это технология Borland для создания трехуровневых приложений баз данных. Применение данной технологии позволяет быстро разрабатывать надежные и простые в сопровождении распределенные БД, которые практически не зависят от формата хранения данных на сервере. Эти трехуровневые приложения состоят из следующих компонентов, или слоев.

1. Первый (самый нижний) слой — слой СУБД. Это может быть любая из имеющихся на рынке систем управления базами данных (Oracle, Interbase, MS SQL, MySQL, Sybase, Paradox и пр.). Назовем его уровнем БД (он же — сервер БД).
2. Средний слой — слой бизнес-логики и транспортный слой. Посредством этого компонента осуществляется доступ клиентов к данным, хранимым в слое БД: передача запросов, результатов, проверка на правильность вносимых данных, обновление данных. Транспортный уровень (он же — сервер приложений).
3. Самый верхний слой — клиентское приложение. Используя механизмы транспортного уровня? отображает данные в необходимой для клиента форме. Клиент.

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

Доступ

MIDAS предоставляет несколько протоколов для связи транспортного и клиентского уровня. Это:

• DCOM;
• Socket;
• Web;
• Corba;

DCOM

Этот режим связи основан на использовании встроенных возможностей Windows. Из числа достоинств данного метода выделим следующие:

• наличие встроенной поддержки в Windows98/2000/XP/NT. DCOM может быть установлен и на Win95 как отдельное приложение;
• отсутствие необходимости в запуске дополнительных приложений на стороне сервера для управления подключением клиентов;
• реализация возможности автоматического запуска сервера при обращении к нему клиента и его выгрузки при отсутствии обращений.

Недостатки метода:

• наличие проблем с работой DCOM в сетях с контролером домена не NT. Это значит, что полноценное функционирование DCOM-приложений возможно только на базе серверных версий Windows NT/2000?;
• отсутствие возможности создания прозрачности положения сервера. То есть клиент должен явно указать, на какой машине в сети установлен сервер;
• использовать DCOM можно только на Windows-платформах.

Socket

Один из простейших случаев реализации связи. В его основе лежит использование сокетов и протокола TCP/IP.

Достоинства:

• может функционировать на любой платформе, использующей TCP/IP;
• требует минимум установленных компонентов в системе.

Недостатки:

• требует дополнительного приложения, установленного на сервере для постоянного отслеживания запросов клиентов;
• отсутствие механизма обеспечения безопасности. Другими словами, все серверы приложений на этой машине могут быть использованы любым клиентом, имеющим доступ к TCP/IP.

Web

Основан на протоколе HTTP. Незаменимая вещь при необходимости обеспечения доступа к данным извне.

Достоинства:

• позволяет организовать возов объекта с машины находящейся за пределами сегмента сети.

Недостатки:

• требует установки на стороне клиента wininet.dll;
• требует веб-сервера IIS 4.0 (или выше) — или других серверов, поддерживающих эту технологию.

CORBA

Полностью независимый от ОС стандарт функционирования приложений в распределенной сети.

Достоинства:

• независимость от ОС;
• позволяет полностью реализовать механизм прозрачности положения сервера;
• возможность выбора между автоматическим и ручным запуском сервера приложений.

Недостатки:

• требуется установка дополнительного программного обеспечения (брокера объектных запросов);
• более сложная установка и настройка сервера приложений для автоматического запуска;
• использование в Delphi COM для реализации CORBA.

Практика

Для демонстрации функционирования технологии MIDAS мы воспользуемся любым средством разработки Borland (Delphi 5, 6, 7, C++Builder 5, 6?), которое поддерживает разработку данного типа приложений. Кроме того, нам понадобятся базы данных, к которым мы будем предоставлять доступ нашим клиентам (для нашего первого приложения воспользуемся набором данных, входящим в состав продуктов Borland).

Постановка задачи

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

Сервер

Создание простенького MIDAS-сервера средствами разработки Borland не предоставляет никакой сложности (как раз тут в полной пере реализована методика разработки приложений без ручного написания кода).

Для начала откроем одно из средств разработки Borland, к примеру Delphi. Далее выберем пункт создания нового приложения и создадим для нашего сервера библиотеку ActiveX. Для этих целей можно также создать приложение (New =>Application).

После этого нам нужно будет еще раз заглянуть в пункт меню New — теперь уже для того, чтоб создать удаленный модуль данных (Remote Data Module).

После того как в нашем проекте появился модуль, перетаскиваем на него главный связующий объект DataSetProvider из палитры Data Access, а также компонент TTable — кроме него могут использоваться любые другие компоненты для работы с БД, TQuery, TStoredProc и т.п. В нашем же случае достаточно будет и одного Ttable.

Теперь настроим наш TTable на работу с некоторой базой данных — посредством задания (или выбора из списка) значений свойств DatabaseName и TableName.

Далее свойство Table1.Active назначаем равным «true" — и переходим к настройке провайдера. Здесь, также прилагая минимум усилий, заполняем свойство DataSet компонента DataSetProvider1 — и регистрируем наш сервер (Run =>Register ActiveX Server).

Всё — на этом разработка сервера приложений закончена. И, как видим, мы вполне обошлись без ввода единой строки кода — все было сделано средой разработки автоматически.

Клиент

В этот раз для создания клиента выберем при создании приложения пункт Application — и после появления на экране формы примемся перетаскивать на нее необходимые компоненты. Итак, для непосредственной связи с сервером приложений на стороне клиента могут быть использованы следующие компоненты:

• DCOMConnection;
• SocketConnection;
• WebConnection;
• CorbaConnection.

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

Так как мы пока тренируемся и клиент и сервер у нас находятся на одном компьютере, то для связи воспользуемся первым из перечисленных компонентов. Здесь при настройке DCOMConnection нам понадобится написать от руки только одно свойство — ComputerName (в нашем случае — localhost).

Далее опять беремся за мышь и переходим к заполнению свойств ServerName и ServerGUID.

Сначала из ниспадающего меню при ServerName выбираем наш вариант (если вы еще не занимались разработкой подобных приложений, то в списке будет один только наш проект с названием, которое назначается объекту по шаблону <имя библиотеки ActiveX. имя сервера>). После этого выбора среда разработки сама вставит в поле ServerGUID необходимый идентификатор. Последнее приготовление компонента DCOMConnection к работе осуществляется его активизацией (DCOMConnection1.Active = true). Теперь, если никаких ошибок не возникло, мы с уверенностью можем сказать, что сервер настроен нормально.

Для дальнейшей работы перетащим с палитры компонентов DataAccess компонент TClientDataSet, который и будет представлением удаленного набора данных на стороне клиента. Для задействования компонента ClientDataSet мы должны установить его свойства RemoteServer и ProviderName (порядок установки значений этих свойств оказывает существенное влияние на дальнейшее поведение ClientDataSet). Так, из ниспадающего меню при свойстве RemoteServer выбираем значение того связующего компонента (если их несколько), который настроен на необходимый сервер. В нашем случае в этом списке будет только один компонент DCOMConnection1, который мы и выбираем.

После этого принимаемся за установку значения свойства ProviderName. Как вы помните, при разработке сервера приложений в RemoteDataModule мы поместили компонент TDataSetProvider. Теперь же — при разработке клиента — выбираем его из ниспадающего списка и заносим в свойство ProviderName.

Теперь нам остается перетащить на форму компонент, который будет отображать полученные данные (например, TDBGrid), и компонент TDataSource. После настройки всех необходимых параметров (DataSource.DataSet, DBGrid.DataSource) мы готовы вывести наши данные на форму. Для этого установим значение свойства Active компонента ClientDataSet в True. При этом заметьте: мы еще даже не запустили наше приложение-клиент — но уже удостоверились в его работоспособности.

Работа с данными
Модель «портфеля"

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

Модель портфеля основывается на двух методах компонента ClientDataSet:

• procedure SaveToFile (const FileName: string = ''; Format TDataPacketFormat=dfBinary);
• procedure LoadFromFile (const FileName: string = '');

Первый из представленных методов сохраняет полученные данные в локальном файле — в соответствующем формате. Второй, соответственно, загружает сохраненные данные. Если надо работать с двумя таблицами, их необходимо сохранять в двух отдельных файлах (или, чтоб не засорять диск большим количеством файлов, воспользоваться COM-хранилищами и методами ClientDataSet.SaveToStream и ClientDataSet.LoadFromStream).

Сам процесс записи и считывания данных с локального диска чрезвычайно прост, однако для правильной работы с «портфелем" необходимо принять во внимание некоторые моменты

Свойство PacketRecords

Свойство PacketRecords — одно из важнейших свойств компонента ClientDataSet. Основное его предназначение — установка количества записей, которые могут быть переданы сервером в одном пакете. При создании экземпляра класса TClientDataSet это свойство автоматически принимает значение —1, что означает передачу сразу всех данных в одном пакете. Установка значения свойства PackerRecords в ноль информирует сервер о том, что клиенту необходимы только метаданные базы данных (информация о самой БД, описания таблиц, названия, типы используемых полей и т.п.).

Если же значение свойства больше нуля, то информация передается сервером по запросу несколькими пакетами, в каждом из которых размещается не больше <PacketRecords> записей. Это удобно во многих случаях — особенно при низкой пропускной способности сети (или в случае связи через модем).

Но установка значения 1 и больше не подходит для работы по «портфельному" методу. Вместо этого при использовании модели «портфеля» мы оставим значение свойства PacketRecords по умолчанию (-1). При этом все останется по-прежнему — кроме того, полный набор данных на сервере будет доступен все время.

С другой стороны, этот подход не очень практичен при использовании больших объемов данных

Обновление данных

Для сохранения одной или более отредактированных записей при использовании удаленного набора данных надо вызвать метод ApplyUpdates:

function ApplyUpdates (MaxErrors: Integer): Integer; virtual;

Присвоение параметру MaxErrors значения проинформирует компонент о том, что сервер не должен останавливать процесс обновления данных при количестве ошибок, меньшем чем MaxErrors. Установка значения —1 говорит о том, что вы не хотите останавливать процесс обновления при возникновении ошибок. Но в случае возникновения ошибок метод ApplyUpdates возвращает значение, равное их количеству.

После того как вы внесли свои изменения в удаленную БД, вы, возможно, захотите обновить свой набор данных — с тем чтобы посмотреть изменения, внесенные в базу другими пользователями. Для этого используется метод Refresh, входящий в TDataSet. Типичный пример обновления:

if ClientDataSet1.ApplyUpdates (-1) = 0 then ClientDataSet1.Refresh;

Последние замечания

Итак, теперь вы уже знаете, как организовать в своей сети (или даже на одном компьютере) полнофункциональное трехуровневое приложение Клиент-Сервер — и облегчить тем самым последующую настройку и сопровождение своего приложения, а также задействование новых клиентских машин с минимумом затрат рабочего времени и ресурсов аппаратуры. Под конец хотелось бы, с вашего позволения, дать несколько советов для тех, кто сразу же бросился писать код. Не спешите — определитесь сначала с тем, что вы хотите видеть в вашем приложении, и, в зависимости от поставленных задач, выберите приемлемый способ связи и представления данных. Вот несколько советов по выбору протокола передачи данных:

ЕСЛИ:

• ?вы в первый раз занимаетесь разработкой приложения такого уровня, ТО можно посоветовать использовать DCOM, установив сервер приложений на и клиента на одной машине;
• ?ваша БД будет использоваться только с ОС Windows с контроллером домена NT — ТО смело используйте DCOM;
• ?вы не уверены в платформе или в том, что в сети есть NT-домен, ТО можете воспользоваться протоколом CORBA или сокетами;
• ?необходимо обеспечить распределение нагрузки на несколько компьютеров и их имена и адреса не известны заранее (или могут изменятся), ТО воспользуйтесь технологией CORBA;
• ?вы желаете предоставить доступ к данным извне, ТО вам не обойтись без WebConnection. Но здесь следует также позаботится и о веб-сервере, поддерживающем данную технологию;
• ?вам необходимо в кратчайшие строки организовать многослойную БД и вы не хотите забивать голову внушительными перечнями настроек и правами доступа Corba и DCOM, ТО SocketConnection — как раз то, что вам нужно.

Михаил Продан,
1099511627776@mail.ru
www.g299792458.boom.ru

До следующего выпуска!
Елена Полонская, редактор "К+П"
www.comizdat.com

Перепечатка материалов этой рассылки разрешается только по согласованию с редакцией журнала "Компьютеры+Программы"