Многозвенная архитектура приложений баз данных

Размещено на http://allbest.ru

Оглавление

ВВЕДЕНИЕ

ЗАЧЕМ НУЖНЫ МНОГОЗВЕННЫЕ ИНФОРМАЦИОННЫЕ СИСТЕМЫ

РАСПРЕДЕЛЕННЫЕ МНОГОЗВЕННЫЕ ПРИЛОЖЕНИЯ

СТРУКТУРА МНОГОЗВЕННОГО ПРИЛОЖЕНИЯ В DELPHI

ТРЕХЗВЕННОЕ ПРИЛОЖЕНИЕ В DELPHI

ЗАКЛЮЧЕНИЕ

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

ВВЕДЕНИЕ

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

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

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

Зачем нужны многозвенные информационные системы

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

Если говорить о клиентских приложениях, созданных с помощью Delphi, для доступа к источникам данных они используют вызовы функций прикладных программных интерфейсов клиентских частей соответствующих серверных СУБД. Эти вызовы осуществляются обычно посредством использования библиотеки Borland Database Engine (BDE), хотя в целом это не является обязательным (например, некоторые пользователи Oracle непосредственно вызывают функции Oracle Call Interface из Delphi-приложений).

Соответственно подобное клиентское приложение требует наличия на компьютере конечного пользователя клиентской части используемой серверной СУБД (и наличия лицензии на ее использование) и присутствия в оперативной памяти набора динамически загружаемых библиотек как из клиентской части, так и из BDE (либо иной заменяющей ее библиотеки), таких, как драйверы баз данных, библиотеки, содержащие функции API клиентских частей, и др. Это усложняет технические требования, предъявляемые к аппаратной части клиентской рабочей станции, и в конечном итоге приводит к удорожанию всей системы в целом.

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

Выходом из этой ситуации является создание систем с так называемым «тонким» клиентом, в частности, с клиентом, не содержащим в своем составе BDE и клиентскую часть серверной СУБД.

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

В свою очередь, клиентские приложения обращаются не непосредственно к серверной СУБД посредством вызова функций клиентских API, а к серверу приложений, являющемуся для них источником данных, при этом собственно клиентская часть серверной СУБД и библиотеки типа BDE на рабочей станции, где используется такое клиентское приложение, присутствовать не обязаны. Вместо них используется одна-единственная динамически загружаемая библиотека dbclient.dll размером 154 Кб.

Таким образом, созданная информационная система становится трехзвенной, а сервер приложений является средним звеном в цепи «тонкий клиент сервер приложений - сервер баз данных» и, соответственно, относится к классу продуктов middleware.

Как может быть практически реализована данная технология? С одной стороны, с помощью набора компонентов и классов Delphi 3, обеспечивающих создание серверов приложений и клиентских частей, а, с другой стороны, с помощью MIDAS, позволяющего осуществлять запуск удаленных серверов приложений, осуществлять межреестровый обмен сведениями об OLE-серверах и оптимизировать нагрузку в случае использования нескольких серверов приложений. В данной статье будет рассмотрен простейший практический пример реализации подобной трехзвенной системы.

Распределенные многозвенные приложения

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

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

Выходом из такого положения явилась концепция многозвенных распределенных приложений. Чаще всего используется трехзвенная архитектура. На верхнем уровне расположен удаленный сервер баз данных. Он обеспечивает хранение и управление данными. На среднем уровне (middleware) располагается сервер приложений. Он обеспечивает соединение клиентов с сервером БД и реализует бизнес-логику. На нижнем уровне находятся клиентские приложения. В ряде случаев это могут быть «тонкие клиенты», обеспечивающие только пользовательский интерфейс, поскольку вся бизнес-логика может располагаться на сервере приложений.

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

Если пользователь изменил данные, то цепочка их передачи на сервер БД выглядит следующим образом. Клиент упаковывает измененные данные и отправляет пакет на сервер приложений. Тот распаковывает их и отправляет на сервер БД. Если все исправления могут быть без осложнений занесены в БД, то на этом все завершается. Но могут возникнуть осложнения: сделанные изменения могут противоречить бизнес-правилам или изменения одних и тех же данных разными пользователями могут противоречить друг другу. Тогда те записи, которые не могут быть занесены в БД, возвращаются клиенту. Пользователь может исправить их или отказаться от сделанных изменений.

Для обмена информацией сервера приложений с клиентами и серверами БД разработаны различные протоколы и средства: DCOM, CORBA, MIDAS, MTS, OLEnterprise, J2EE, TCP/IP, HTTP, XML. Большинство этих средств обмена будут далее рассмотрены.

CORBA является одним из самых мощных инструментов создания распределенных приложений. Для использования CORBA на каждом компьютере, содержащем приложения клиентов, должен быть установлен брокер VisiBroker, обеспечивающий связь приложения со средой CORBA. А на одном из компьютеров в сети должны быть установлены элементы этой среды. Если все это сделано, открываются очень широкие возможности для создания сложных распределенных информационных систем.

Система MIDAS позволяет создавать распределенные приложения, использующие самые разные протоколы и технологии: DCOM, CORBA, OLEnterprise, HTTP, сокеты TCP/IP, MTS и другие.

Система Microsoft Transaction Server (MTS) - это еще одна система создания многозвенных приложений. Правда, она работает в полную силу далеко не во всех версиях Windows.

О TCP/IP и HTTP, применяемых в Интернет и корпоративных сетях, основанных на тех же протоколах, что Интернет, будет немало сказано. Вы найдете сведения о языке HTML, используемом для описания документов Web. Дальнейшим развитием языка HTML стал XML.

Язык программирования Java - это объектно-ориентированный язык, используемый, прежде всего, для приложений Интернет. Он характеризуется простотой, надежностью, способностью создавать простыми средствами интерактивные сетевые программы. Отличительной особенностью Java является возможность исполнять созданный код на любой из поддерживаемых платформ. Достигается это тем, что программы транслируются в некоторое промежуточное представление, называемое байт-кодом. Этот байт-код может затем интерпретироваться в любой системе, в которой есть среда выполнения Java. Обычно программы на языках, использующих интерпретацию, работают медленно. Но к Java это не относится. Байт-код легко переводится непосредственно в машинные коды, что позволяет достичь очень высокой производительности.

Дальнейшим развитием возможностей, заложенных в Java, явилась платформа J2EE (Java 2 Enterprise Edition). Она вобрала в себя все технологии, наработанные к этому времени, и стала основой для большинства серверов приложений. Эта платформа обеспечивает выполнение приложений, написанных в рамках определенных стандартов, и снимает с разработчика заботу об управлении очередями, транзакциями, сообщениями и многом другом.

Перечисленные технологии могут использоваться в различных видах распределенных приложений, работающих с базами данных. Но, конечно, в настоящий момент основной упор при разработке распределенных приложений делается на использование Интернет, корпоративных сетей, основанных на тех же протоколах, что и Интернет, а также технологии Web. Глобальность Интернет делает эту сеть незаменимой при создании многопользовательских распределенных приложений.

Структура многозвенного приложения в Delphi

Многозвенная архитектура приложений баз данных вызвана к жизни необходимостью обрабатывать на стороне сервера запросы от большого числа удаленных клиентов. Казалось бы, с этой задачей вполне могут справиться и приложения клиент/сервер, однако в этом случае при большом числе клиентов вся вычислительная нагрузка ложится на сервер БД, который обладает довольно скудным набором средств для реализации сложной бизнес-логики (хранимые процедуры, триггеры, просмотры и т. д.). И разработчики вынуждены существенно усложнять программный код клиентского ПО, а это крайне нежелательно при наличии большого Числа удаленных клиентских компьютеров. Ведь с усложнением клиентского ПО возрастает вероятность ошибок и усложняется его обслуживание.

Многозвенная архитектура приложений БД призвана исправить перечисленные недостатки.

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

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

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

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

Рис. 1 Многозвенная архитектура приложений БД

Таким образом, многозвенное приложение БД состоит из (рис. 1):

§ «тонких» клиентских приложений, обеспечивающих лишь передачу, представление, редактирование и простейшую обработку данных;

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

§ сервера БД (Oralce, Sybase, MS SQL, InterBase и т. д.), поддерживающего функционирование базы данных и обрабатывающего запросы.

Более простая трехзвенная модель содержит следующие элементы:

§ «тонкие» клиенты;

§ сервер приложений;

§ сервер БД.

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

Сервер приложений взаимодействует с сервером БД, используя одну из технологий доступа к данным, реализованным в Delphi (см. часть IV). Это технологии ADO, BDE, InterBase Express и dbExpress. Разработчик может выбрать наиболее подходящую, исходя из поставленной задачи и параметров сервера БД. сервер многозвенный управление

Удаленные клиентские приложения создаются с использованием специального набора компонентов, объединенных общим названием DataSnap. Эти компоненты инкапсулируют стандартные транспорты (DCOM, HTTP, сокеты) и обеспечивают соединение удаленного клиентского приложения с сервером приложения. Также компоненты DataSnap обеспечивают доступ клиента к функциям сервера приложений за счет использования интерфейса AppServer.

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

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

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

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

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

Кроме того, вы легко сможете использовать защищенные каналы передачи данных, например HTTPS.

Трехзвенное приложение в Delphi

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

Во-первых, подобно обычному модулю данных он является платформой для размещения не визуальных компонентов доступа к данным и компонентов-провайдеров. Размещенные на нем компоненты соединений, транзакций и компоненты, инкапсулирующие наборы данных, обеспечивают трехзвенное приложение связью с сервером БД. Это могут быть наборы компонентов для технологий ADO, BDE, InterBase Express, dbExpress.

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

Рис. 3 Выбор удаленных модулей данных в Репозитории Delphi

В состав Delphi входят удаленные модули данных. Для их создания используйте страницы Multitier, WebSnap и WebServices Репозитория Delphi (рис. 3).

§ Remote Data Module - удаленный модуль данных, инкапсулирующий сервер Автоматизации. Используется для организации соединений через DCOM, HTTP, сокеты.

§ Transactioiial Data Module - удаленный модуль данных, инкапсулирующий сервер MTS (Microsoft Transaction Server).

§ SOAP Server Data Module - удаленный модуль данных, инкапсулирующий сервер SOAP (Simple Object Access Protocol).

§ WebSnap Data Module - удаленный модуль данных, использующий Web-службы и Web-браузер в качестве сервера.

Помимо удаленного модуля данных неотъемлемой частью сервера приложений являются компоненты-провайдеры TDataSetProvider. С каждым компонентом, инкапсулирующим набор данных, предназначенным для передачи клиенту, в модуле данных должен быть связан компонент-провайдер.

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