Трехуровневые приложения. Принципы построения трехуровневых приложений

План занятия Понятие трёхуровневой архитектуры Принципы построения трехуровневых приложений Сервер приложений Приложение клиента

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

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

Принципы построения трехуровневых приложений В Delphi многоуровневые приложения разрабатываются на основе технологии MIDAS (Multitier distributed application services служба многоуровневых распределенных приложений).

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

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

Трехуровневая архитектура типа "клиент-сервер"

Сервер приложений Для создания различных серверов приложений предназначены следующие разновидности удаленных модулей данных: Remote Data Module для серверов DCOM, TCP/IP и OLEnterprise; MTS Data Module для сервера MTS; CORBA Data Module для сервера CORBA.

В удаленном модуле данных размещаются те же компоненты, что и в простом модуле данных, например, Query, Database, Session, предназначенные для организации доступа к данным. Добавление к проекту удаленного модуля данных выполняется выбором объекта Remote Data Module страницы Multitier Хранилища объектов.

При добавлении модуля выводится диалоговое окно мастера Remote Data Module Wizard, в котором нужно задать параметры модуля (рис.2).

В поле редактирования CoClass Name вводится имя модуля данных. В списке Instancing выбирается способ запуска модуля: – Internal экземпляр модуля данных создается на сервере в случае, когда МД является частью библиотеки DLL;

– Single Instance для каждого клиента в его адресном пространстве создается один экземпляр удаленного МД, и каждое клиентское соединение запускает этот свой экземпляр; – Multiple Instance один экземпляр приложения (процесс) представляет все удаленные МД, созданные для клиентов (по умолчанию).

В списке Threading Model (Потоковая модель) выбирается способ вызова интерфейса клиента, если МД является частью библиотеки DLL: Single библиотека получает запросы клиента по одному; Apartment одновременно обрабатывается несколько запросов клиентов, для каждого из которых создан отдельный экземпляр МД (по умолчанию);

Free отдельный экземпляр МД одновременно может отвечать на несколько запросов клиентов; Both отдельный экземпляр МД одновременно может отвечать на несколько запросов клиентов, результаты обработки также возвращаются одновременно.

Разместим в удаленном модуле набор данных Query и зададим для него значения свойств Datа ВаsеName и Sql так, чтобы включить в набор все поля всех записей таблицы Personnel. Указанным свойствам присвоим значения: – DataBaseName BDPlace; – SQL SELECT * FROM Personnel.db.

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

Созданное приложение сервера состоит из следующих частей: проекта; главной формы приложения; удаленного модуля данных; модуля библиотеки типов.

После создания сервера DCOM его нужно зарегистрировать как сервер автоматизации. Регистрация сервера выполняется Windows автоматически при запуске приложения сервера. Компонент DataSetProvider, который предоставляет большие возможности по управлению интерфейсом провайдера, включая обмен XML-данными.

Простейший сервер DCOM представляет собой удаленный брокер данных, который обеспечивает соединение с сервером БД и передачу данных клиенту и обратно. Поддержка механизма ограничений обеспечивается брокером ограничений.

Для реализации ограничений в сервере приложений можно использовать свой­ство Constraints наборов данных Table И Query. Свойства: customConstraint типа string код SQL, описывающий ограничение; ErrorMessage типа string текст, выдаваемый пользователю при нарушении данного ограничения;

FromDictionary типа Boolean признак, значение True которого указывает, что ограничение выбирается из словаря данных; по умолчанию свойство имеет значение False, и словарь данных не используется; importedConstraint типа string код SQL, описывающий ограничение, которое импортировано из словаря данных.

Определение ограничений для набора данных Queryl

Ответить на вопросы: Ответить на вопросы: Перечислите основные достоинства трёхуровневых архитектур. Назовите принципы построения трёхуровневых архитектур.

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

Выбор компонента, используемого для соединения с сервером приложений, за­висит от типа сервера: DCOMConnection для соединения с серверами DCOM и MTS; Socketconnection для соединения с сервером через сокеты TCP/IP; corbaConnection для соединения с сервером CORBA.

Создадим приложение клиента, подключаемого к рассмотренному серверу DCOM, для чего разместим на главной форме компонент DCOMConnection (DataSnap). Основными свойствами этого ком­ понента являются следующие: ComputerName типа string имя компьютера, на котором расположен сервер приложений; ServerName типа string имя сервера приложений;

serverGuiD типа string универсальный уникальный идентификатор GUID сервера приложений; Connected типа Boolean признак, управляющий активностью соединения.

Если сервер расположен на одном компьютере с приложением клиента (что удобно при отладке приложений), то свойству ComputerName значение не за­ дается.

Клиентский набор данных clientDataSet предназначен для работы с записями, поступающими с сервера приложений. Cвойства: RemoteServer типа TCustomRemoteServer соединение, используемое для свя­зи с сервером;

ProviderName типа string провайдер, обеспечивающий передачу данных; Active типа Boolean признак, указывающий, открыт или закрыт набор данных; PacketRecords типа integer размер пакета данных; FileName типа string имя файла для обмена данными с диском.

В качестве значения свойства RemoteServer можно указывать любой из компо­нентов, используемых для соединения с сервером: DCOMConnection, Socketconnection, corbaConnection, а также Webconnection.

Для работы с данными в приложении клиента размещаются визуальные компо­ ненты и источник данных DataSource, которые связываются между собой, а также с клиентским набором данных аналогично как и для приложений "толстого" кли­ента.

Форма приложения "тонкого" клиента на этапе разработки

Для просмотра состояния текущей записи клиентского набора данных исполь­зуется метод updatestatus: TUpdateStatus, возвращающий значения: usUnmodified запись не имеет изменений; usModified запись изменена (отредактирована); usinserted запись вставлена (является новой); usDeleted запись удалена.

Просмотр состояния текущей записи и изменений в записях

Получить доступ ко всем изменениям, которые сделаны в записях, но еще не отправлены на сервер, позволяют свойства Data и Delta, первое из которых представляет собой данные клиентского набора данных, а второе его измененные данные (Delta-данные). ClientDataSet2.Data:=ClientDataS etl.Delta;

Свойство ChangeCount, доступное во время выполнения, содержит число измененных записей, которое нужно проверять на равенство 0 перед тем, как делать попытку получить эти записи. Пример: if ClientDataSetl.ChangeCount >0 then ClientDataSet2.Data:= ClientDataSetl.Delta;

procedure TForml.DataSourcelDataChange(Sender: TObject; Field: TField); begin usUnModified: Label1.Caption:='Запись не изменялась'; usModified: Labell.Caption:=Зaпись изменена'; uslnserted: Labell.Caption:='Запись вставлена'; usDeleted: Labell.Caption:='Запись удалена'; end; if ClientDataSetl.ChangeCount > 0 then ClientDataSet2.Data:=ClientDataSetl.Delta; Labe12.Caption:='Изменения в записях ' +IntToStr(ClientDataSetl.ChangeCount); end;