6. Модели архитектуры клиент-сервер: rda-модель, dbs-модель, as-модель. Преимущества и недостатки.

Выделяют три основных модели архитектуры клиент-сервер:

• модель доступа к удаленным данным или модель удаленного доступа к данным (Remote Data Access – RDA-модель);

• модель сервера баз данных или модель удаленного представления (Database Server – DBS-модель);

• модель сервера приложений или модель распределенной функции (Application Server – AS-модель).

RDA-модель

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

Основное достоинство данной модели состоит в том что, во-первых, взаимодействие пользователя с сервером осуществляется с помощью стандартного языка запросов SQL. Во-вторых, это наличие большого числа готовых СУБД и других инструментальных средств, обеспечивающих быстрое создание программ клиентской части.

Недостатки RDA-модели:

• высокая загрузка системы передачи данных;

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

DBS-модель

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

Хранимые процедуры – это специальные программные модули, которые используются для извлечения или изменения данных.

Существует два вида хранимых процедур: системные и пользовательские.

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

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

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

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

AS-модель

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

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

К достоинствам AS-модели относят разгрузку сервера базы данных, к недостаткам – увеличение нагрузки на сеть.

7. Технологии COM\DCOM, CORBA, MIDAS, EJB.

COM\DCOM

Технология COM (Component Object Model) и ее вариант для распределенных систем DCOM(Distributed Component Object Model) была разработана компанией Microsoft. DCOM является расширением COM и включает в себя среду распределенных вычислений и механизм удаленного вызова процедур.

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

Технология СОМ применяется при описании API и двоичного стандарта для связи объектов различных языков и сред программирования.

Технология СОМ работает с так называемыми СОМ-объектами.

СОМ-объект представляет собой двоичный код, который выполняет какую-либо функцию и имеет один или более интерфейс.

Все СОМ-объекты обычно содержатся в файлах с расширением DLL или OCX. Один такой файл может содержать как одиночный СОМ-объект, так и несколько СОМ-объектов.

СОМ-объекты похожи на обычные объекты визуальной библиотеки компонентов Delphi. В отличие от объектов VCL Delphi, СОМ-объекты содержат свойства, методы и интерфейсы.

Суть COM

Программа-клиент использует при своей работе объект (объекты) некоторой другой программы (сервера) так, словно эти объекты являются частью самого клиента. Основную роль при этом играет интерфейс объектов.

Клиенты СОМ связываются с объектами при помощи СОМ-интерфейсов. Обычный СОМ-объект включает в себя один или несколько интерфейсов. Каждый из этих интерфейсов имеет собственный указатель.

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

Клиент получает именно интерфейс затребованного объекта. Интерфейсы не являются самостоятельными объектами, они лишь обеспечивают доступ к объектам. Таким образом, клиенты не могут напрямую обращаться к данным, доступ осуществляется при помощи указателей интерфейсов.

Каждый интерфейс имеет свой уникальный идентификатор, который называется глобальный уникальный идентификатор (Globally Unique Identifier, GUID).

Уникальные идентификаторы интерфейсов называют идентификаторами интерфейсов (Interface Identifiers, IIDs). Данные идентификаторы обеспечивают устранение конфликтов имен различных версий приложения или разных приложений.

Технология СОМ имеет два явных преимущества:

1. создание СОМ-объектов не зависит от языка программирования. Таким образом, СОМ-объекты могут быть написаны на различных языках;

2. СОМ-объекты могут быть использованы в любой среде программирования под Windows. В число этих сред входят Delphi, Visual C++, C++Builder, Visual Basic, и многие другие.

Хотя технология СОМ обладает явными плюсами, она имеет также и минусы, среди которых зависимость от платформы. Данная технология применима только в операционной системе Windows и на платформе Intel.

CORBA

CORBA (Common Request Broker Architecture) – архитектура для построения распределенных объектных приложений.

Была предложена некоммерческой организацией – консорциумом OMG (Object Management Group).

Технология основана на использовании брокера объектных запросов (Object Request Broker, ORB) для прозрачной отправки и получения объектами запросов в распределенном окружении. Технология позволяет строить приложения из распределенных объектов, реализованных на различных языках программирования.

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

На машине клиента создаются два объекта-посредника: Stab и ORB (Object Request Broker – брокер вызываемого объекта). ORB отвечает за все механизмы, необходимые для поиска подходящей для запроса реализации объекта, подготовки реализации к получению запроса и передачи данных в процессе выполнения запроса. Stub передает вызов брокеру, который посылает сообщение в сеть.

Smart agent, получив сообщение, отыскивает сетевой адрес сервиса и передает запрос брокеру, размещенному на машине сервера. Вызов требуемого объекта производится через специальный адаптер (BOA).

MIDAS

MIDAS (Multi-tier Application Server Suite) представляет собой технологию создания распределенных систем, состоящих из сервера баз данных, сервера доступа к данным (который, в свою очередь, является клиентом сервера баз данных) и так называемого тонкого клиентского приложения, являющегося, соответственно, клиентом сервера доступа к данным (рис.).

Фактически два последних звена делят между собой функциональность, характерную для клиентского приложения, используемого в «классических» двухзвенных клиент-серверных системах. «Тонкий» клиент обычно является приложением, с которым работает конечный пользователь, и поэтому предназначен главным образом для предоставления пользовательского интерфейса (то есть тех форм и интерфейсных элементов, с помощью которых пользователь редактирует данные). Естественно, подобное приложение должно «знать», на каком компьютере локальной или глобальной сети находится сервер доступа к данным, каково имя (или иной идентификатор) предоставляемого им сервиса и с помощью каких средств (имеются в виду сервисы операционной системы, сетевые протоколы и т.д.) с ним можно этими данными обмениваться. Это и есть те немногочисленные параметры, которые требуют настройки.

Что касается сервера доступа к данным, то обычно он недоступен конечным пользователям, и поэтому хотя у него может быть пользовательский интерфейс в традиционном понимании (формы, кнопки, поля для ввода данных), но не обязательно. Иными словами, сервер доступа к данным может представлять собой как обычное Windows-приложение с формами, так и приложение без форм, а также консольное приложение либо сервис операционной системы, пишущий сообщения для администратора системы в log-файл. Его задача — обмениваться данными с «тонким» клиентом и обращаться к серверу баз данных с собственными запросами (обычно инициированными этим обменом). Поэтому сервер доступа к данным должен, с одной стороны, предоставлять клиентам интерфейсы, позволяющие получать от него данные, а с другой стороны, быть полноценным клиентом сервера баз данных, то есть содержащий его компьютер должен иметь как минимум установленную клиентскую часть серверной СУБД. Нередко такой компьютер имеет и другие библиотеки доступа к данным, например, в прежних двух версиях MIDAS обязательной составляющей его частью была библиотека Borland Database Engine. В текущей версии MIDAS могут быть использованы и другие библиотеки, например библиотеки ADO (или исключительно те библиотеки, что содержат клиентский API и поставляются с сервером баз данных).

EJB

Основная идея, лежавшая в разработке технологии EJB (Enterprise JavaBeans) – создать такую инфраструктуру для компонент, чтобы они могли бы легко ``вставляться'' (``plug in'') и удаляться из серверов, тем самым увеличивая или снижая функциональность сервера.

Существует подход построения информационной системы EJB (Enterprise JavaBeans) – разделение ее на три уровня. Каждый уровень имеет свои обязанности и функциональные возможности.

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

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

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

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

Минусом таких систем является их направленность на крупные корпоративные решения.