WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     || 2 | 3 |
ФЕДЕРАЛЬНОЕ АГЕНСТВО ПО ОБРАЗОВАНИЮ РФ ВОРОНЕЖСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ Распределенные системы:

технология Borland MIDAS Учебноепособие по специальности 230201 (071900) «Информационные системы и технологии» ДС.09 Часть 3 ВОРОНЕЖ 2005 2 Утверждено Научно-методическим советом Воронежского университета Протокол № 12 от 18.02.2005 г.

Составитель Фертиков В.В.

Пособиеподготовлено на кафедре информационных систем факультета компьютерных наук Воронежского государственного университета.

Рекомендуетсядля использования студентами 4 курса дневного отделения в качестве учебных материалов на практических занятиях по курсу «Распределенные системы вычислений».

3 Трехзвенная архитектура распределенного приложения Многозвенные приложенияпредставляют собой распределенные системы удаленного доступа к данным, которые состоят как минимум из трех логических уровней. Этилогические уровнимогут находиться как на одной, так ина нескольких машинах. В такой минимальной простой форме, трехзвенной ("three-tiered model"), используютсяследующие уровни.

• Клиентскоеприложениеобеспечивает интерфейс пользователя на пользовательской машине.

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

• Удаленный сервер базы данных обеспечивает систему управления базой данных (СУБД).

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

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

• Формированиепакета бизнес-логики в общедоступном среднем уровнесервера приложений. Несколько клиентов имеют доступ на этотсредний уровень. Это позволяет избежать дублированиябизнес-логики для каждого отдельного клиентского приложения.

• "Тонкий клиент отличаетсявысокой надежностью ипростотой установки.

" Не надо заботитьсяо поддержании программных компонентов для обеспечения связи с базой данных.

• Распределенная обработка информации. При распределении работы приложения на несколько машин можно улучшить эффективность благодаря балансировке нагрузки.

• Увеличение устойчивости Можно изолировать чувствительные функцио.

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

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

Рис. 1. Трехзвенная архитектура клиентсервер Рассматриваемые ниже инструментальные средства позволяют реализовывать серверы приложений как приложения для Windows. Программируемость такого сервера приложений обеспечивается технологией COMпрограммирования. Сервер приложений реализуетсякак OLE-сервер, инкапсулирующий наборы данных в COM-объектах идопускающий управление ими через опубликованные COM-интерфейсы. Разработка собственных специализированных программных компонентов позволяет в ряде случаев отказаться от использования дорогостоящего фирменного программного обеспечения и добитьсякомпактности и эффективности работы комплекса в целом.

Что касается своевременного обновления версий «тонкого» клиента крупной информационной системы, эта проблема решается путем поставки приложений с помощью технологий, применяемых в Internet (intranet). Наиболее распространенными на сегодняшний день способами поставки «тонких» клиентов с помощью таких технологий являются копирование или установка приложений с Web-сервера, и как один из вариантов –копированиекомпонента ActiveX, полностью реализующего функциональность «тонкого» клиента, с целью отображения его в браузере. Такой способ поставки проиллюстрирован на рисунке 2.

Рис. 2. Поставка «тонких» клиентов корпоративной системы Рассматриваемый далее инструментарий позволяет разрабатывать рабочие места конечных пользователей в нескольких вариантах реализации.

Во-первых – как «тонкий» клиент в виде обычных 32-разрядных Windowsприложений, предусматривающих процедуру установки на рабочую станцию при помощи дистрибутива. Во-вторых – реализация «тонкого» клиента в виде отображаемого в браузере ActiveX, что позволяет осуществлять его поставку через Internet (intranet), используя Web-сервер в качестве источника очередной версии приложения и Web-браузер в качестве средства его установки. При этом существует возможность выполнения такого приложения непосредственно в браузере, с использованием тега , поддерживаемый MS Internet Explorer, начиная с версии 3.0. Наконец, можно вообще отказаться отпоставки клиента, создав систему для обработки запросов Internet-приложений (с так называемым приложением для Web на сервере). В этом случае роль клиента выполняет собственно Web-браузер и дополнительных механизмов поставки не требуется.



Введение в Borland MIDAS Multi-tier Distributed Application Services Suite (MIDAS, набор сервисов для многозвенных распределенных приложений) – технология компании Inprise Corporation (Borland International), предназначенная для разработки многозвенных распределенных приложений и их эксплуатации в корпоративных системах. Этот продукт позволяет использовать при построении информационных систем трехзвенную архитектуру с "тонким" клиентом, обеспечивая высокую производительность, надежность изащиту отсбоев при эксплуатации подобных систем. Технология MIDAS позволяет получать доступ к данным, физически расположенным на разных машинах, распределять нагрузку ресурсов по сети автоматически получать ограниченияна данные, что, позволяет уменьшить сетевой трафик, а также разделить бизнес-логику приложенияна менее уязвимые части, распределив их по звеньям серверов. С помощью MIDAS можно создавать системы для обработки запросов Internetприложений. MIDAS работает с технологиями CORBA, СОМ, MTS и OLEnterprise (основанный на протоколе RPC продукт корпорации Open Environment, ставшей впоследствии подразделением Borland), а также упрощает интеграцию существующих систем.

Перечислим основные компоненты, реализующие технологию.

• Модули удаленных данных.

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

• Компонент–провайдер (TDataSetProvider).

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

• Компонентнабора данных клиента (TClientDataSet).

Специализированный набор данных клиента, который использует MIDAS.DLL для управления данными, записанными в пакеты данных.

• Компоненты связи (TDCOMConnection, TSocketConnection, TWebConnection, TCorbaConnection).

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

• Брокер SimpleObjectBroker.

Брокер бизнес–объектов для распределениявычислительной нагрузки по нескольким серверам.

Основными инструментами разработки в технологии MIDAS являются интегрированные среды Delphi и C++Builder. В простейшей трехзвенной архитектуре средствами Delphi или C++Builder можно создать первый и второй уровень, а для третьего воспользоваться уже существующими СУБД. Перейдем к рассмотрению особенностей разработки с точки зрения программиста, знакомого с Visual Control Library (VCL) и основами реализации приложений для управления данными.

Схема распределенного приложения в терминах VCL Информационные системы, созданные на основе классической архитектуры клиентсервер, называются двухзвенными системами или системами с «толстым» клиентом. Онисостоят из сервера баз данных, содержащего сгенерированные тем или иным способом таблицы, индексы, триггеры и другие объекты, реализующие бизнес-правила данной информационной системы, и одного или нескольких клиентских приложений, предоставляющих интерфейс пользователя и производящих проверку допустимостииобработку данных согласно содержащимся в них алгоритмам. Если говорить о клиентских приложениях, созданных с помощью Delphi или C++Builder, для доступа к источникам данных ониприменяют вызовы функций прикладных программных интерфейсов клиентских частей соответствующих серверных СУБД. Этивызовы осуществляются обычно посредством использования библиотеки Borland Database Engine (BDE), хотя последнее неявляетсяобязательным. Схема такого классического клиентского приложения по представлению Delphi–программиста, вы, глядит следующим образом.

Рис. 3. Классический «толстый» клиент На форме помещаются требующиеся визуальные компоненты Data Controls, в то время как невизуальные компоненты доступа к данным (Data Access и другие), как правило, сохраняет специальный контейнер, называемый модулем данных (Data Module).

Схема трехзвенной системы, глазами того же программиста VCL, показана на следующем рисунке 4. Поскольку в данном случае речьидет о разработке лишь двух звеньев, «тонкого» клиента исервера приложений, последний уровень серверов СУБД на схеме непоказан. В известном смысле сервер приложений и «тонкий» клиентпредставляют собой разделенноена две частиклассическое клиентское приложение Первая часть (сервер приложений) содержит.

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





Рис. 4. «Тонкий» клиентисервер приложений «Тонкий» клиент Как видно, клиентское приложение по-прежнему содержит модуль данных (назовем его локальным), в котором помещаются невизуальные компоненты доступа к данным. Наиболее существенноеотличиеотклассического клиента заключается в использовании вместо любого из компонентов, инкапсулирующих наборы данных (TDataSet), специальных компонентов клиентских наборов данныхTClientDataSet, обеспечивающих кэшируемоесоединение с удаленными наборами данных, расположенными на сервере приложений. Кроме этого является обязательным использование одного из так называемых компонентов связи: TDCOMConnection, TSocketConnection, TWebConnection, TOLEnterpriseConnection, TCorbaConnection. Задача компонентов связи – поиск исоединениес сервером приложений, а затем – управлениеэтим соединением. Можно также использовать компоненты связи для вызова методов интерфейса сервера приложений. Каждый из компонентов связи использует определенный коммуникационный протокол: DCOM, Windows sockets (TCP/IP), HTTP, RPC и CORBA, соответственно.

КомпонентTClientDataSet предназначен для хранения данных, полученных отсервера приложений, в кэше клиента, и, будучипотомком компонента TDataSet, обладает, подобно компонентам TTable и TQuery, как навигационными методами, так иметодами, осуществляющими редактированиеданных. Кроме того, этот компонент обладает методами SaveToFile и LoadFromFile, позволяющими сохранять данные из кэша в файле и восстанавливать их оттуда, реализуя так называемую «briefcase model». Такая модель обработки данных, основана на том, что «тонкий» клиентосуществляет редактирование данных по большей частипри отсутствии соединения с сервером, используя лишь кэш или локальные внешниеустройства, и лишь иногда соединяется с сервером приложений для передачиему измененных данных с целью дальнейшей обработки.

КомпонентTClientDataSet делает возможным, подобно TQuery, посылать динамический SQL-запрос серверу. Для этого имеется специальное свойство CommandText, с помощью которого можно посылать команду на SQL от клиента серверу. Для выполнения команды на сервере необходимо установить значение свойства Provider.Options.poAllowCommandText равным True и далее вызвать либо метод Open, либо метод Execute.

При использовании компонента TClientDataSet необходимо помнить о том, что он содержитвсесвои данные в памяти, поэтому клиентнеможет работать с оченьбольшими наборами данных (размер данных зависитотразмера памяти у машины клиента).

Для конечного пользователя клиентская часть многозвенного приложения выглядити работает точно так же, как ив традиционном двухзвенном приложении, которое использует кэшированные изменения. По структуре клиентская часть представляет собой приложение котороеработает без BDE и позволяет, использовать набор данных клиента в режиме работы с файлами. Для работы такому клиенту необходима только библиотека MIDAS.DLL. Используя лишь эту библиотеку, приложения легче распространять; не надо инсталлировать, конфигурировать и поддерживать программное обеспечение для управления соединениями с базой данных.

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

Сервер приложений Важнейшей частью серверного приложения является так называемый удаленный модуль данных (Remote Data Module), см. рис.4. Существует три типа удаленных модулей данных.

• TRemoteDataModule. Этот тип используется в том случае, когда клиент имеет дело с компонентами сервера приложений, использующими протоколы DCOM, HTTP, Sockets, или OLEnterprise, за исключением случаев с использованием MTS.

• TMTSDataModule. Этоттип используетсяв том случае, если создаетсясервер приложений как библиотека, которая устанавливается в MTS. Можно также использовать этоттип с DCOM, HTTP, Sockets или OLEnterprise компонентами.

• TCorbaDataModule. Это сервер CORBA. Этот тип используетсядля обеспечения данными CORBA-клиентов.

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

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

В свою очередь, провайдер данных:

• получает запрос на данные отклиента, получает запрошенные данные отбазы данных, упаковывает данные для передачиипосылает их клиенту;

Pages:     || 2 | 3 |










© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.