Файл: Модель клиент-сервер (История возникновения модели).pdf

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

4.1 Использование программного обеспечения одного производителя

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

С другой стороны у данного подхода очень много минусов. Во-первых, доступные Вам СУБД могут не поддерживать все операционные платформы или сетевые протоколы, используемые в Вашей организации. Между разными системами и компонентами систем одного и того же поставщика тоже есть требования к совместимости. Если же подобный СУБД все-таки найдется, то Вам может оказаться недостаточно ее функциональных возможностей, или покажется слишком высокой цена, или в данном пакете будут отсутствовать необходимые Вам высокоуровневые средства разработки. Пожалуй, только СУБД Oracle, работающая более чем на 100 вычислительных платформах и со всеми коммерческими сетевыми протоколами, обладающая полным набором графических средств разработки, средств конечного пользователя, реализующая все основные функции коммерческой реляционной распределенной СУБД позволяет во многом избежать этих проблем. Большинство других СУБД работает всего на нескольких платформах, поддерживает 2-3 сетевых протокола и т.д.

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

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

4.2 Работа приложений с сервером БД

На персональных компьютерах, обычно используемых в качестве компьютеров-клиентов существует большое количество популярных, легких в использовании СУБД. Наиболее известными из них являются СУБД dBase, FoxPro, Clarion, Clipper, Paradoх. С помощью этих СУБД разработано большое количество приложений.

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

К сожалению эти сетевые версии во многом сохранили архитектуру своих предшественников, а для реализации действительно многопользовательского промышленного приложения необходимо реализовывать специальную архитектуру СУБД. Эта архитектура реализована в таких серверах БД, как Sybase, Oracle, Informix, Ingres и т.д. Кроме того, СУБД для PC не реализуют многих функций обеспечения целостности и непротиворечивости данных, защиты данных, работы с большими БД и т.д. Поэтому многие организации, успешно создавшие и использовавшие приложения для сетевых версий персональных СУБД, при увеличении количества пользователей или объемов данных вынуждены переходить к архитектуре клиент-сервер. В противном случае время реакции системы, например, увеличивается выше допустимого уровня, что делает работу невозможной.

Производители СУБД для PC хорошо осознают эту проблему и потому разрабатывают программное обеспечение, позволяющее их СУБД работать с сервером БД конкретной компании. Обычно в качестве сервера используется одна из самых популярных и распространенных СУБД (Oracle, Informix, Inqres). Больше всего таких пакетов известно для СУБД Oracle, которая занимает около половины всего рынка серверов БД. Например, СУБД Paradox имеет компоненты SQL Link for Oracle и SQL Link for InterBase. С помощью этих пакетов приложения для Paradox будут работать с БД Oracle или InterBase.

4.3 Средства разработки приложений

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

Обычно в документации, поставляемой с этими пакетами, перечислены реляционные СУБД, использующие язык SQL, с которыми могут работать приложения. Список этих СУБД достаточно постоянен. Это "большая четвертка" Oracle, Informix, Inqres, Sybase. Иногда к ним добавляются InterBase, DB2, Rdb, MS SQL Server. В качестве примеров таких пакетов можно указать JAM компании Convergent Solutions Inc., Power House компании Cognos Inc., Contessa компании Contexture Systems., SC/ADS компании Convergent Solutions Inc., Pro*IV компании McDonall Daugsas., Accel компании Unify и т.д.

Недостатки у этого подхода те же, что и при использовании Paradox, Clipper и т.д. Приложения должны либо использовать стандартный SQL (Ansi Level 1 или 2) и, следовательно, они могут работать с разными СУБД, но не используют их в полной мере, либо в приложениях явно записываются специфические операторы конкретной СУБД. При этом переход к другой СУБД требует модификации приложений. Кроме того, обычно языки и технологии СУБД и средства разработки приложений сильно различаются. Не всегда "стыковка" с конкретными СУБД выполняется качественно. Еще одним недостатком является то, что этот и предыдущий подходы не позволяют связываться между собой двум серверам БД различных компаний. Они подходят только для связи клиентов с серверами одной компании.

4.4 Клиентские приложения, поддерживающие протокол DDE

Очень часто в качестве компьютеров-клиентов используются персональные компьютеры с MS Windows. Эта дружественная графическая среда очень удобна для создания клиентских приложений. Появление операционной системы Windows NT очевидно еще больше повысит популярность приложений, работающих в этой среде. Наиболее известными среди них являются электронные таблицы Lotus 1-2-3, Excel, Quattro Pro, редактор текстов MS Word, СУБД MS Access.

Для того, чтобы приложения MS Windows могли обмениваться между собой данными, компания Microsoft разработала протокол динамического обмена данными DDE (Dynamic Data Exchange). Согласно этому протоколу одно из приложений MS Windows, называемое DDE клиентом, может посылать сообщения, запросы на выполнение действий, запросы на данные другому приложению для MS Windows, называемому DDE сервером (не следует путать DDE клиентов и серверов с клиентами и серверами в архитектуре клиент-сервер СУБД). Архитектура работы с DDE сервером приведена на рисунке 1.

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

Если в качестве DDE сервера используется приложение MS Windows, умеющее обмениваться данными с некоторой СУБД и пересылать на выполнение SQL-команды в эту СУБД, то любые приложения для MS Windows, поддерживающие протокол DDE, смогут работать с данной СУБД. Правда для каждой СУБД нужно иметь свой DDE сервер и язык SQL приложения должен быть понятен тем СУБД, с которыми оно будет работать. Однако, если приложение использует базовый набор команд SQL (например, SQL ANSI Level 1), то оно сможет работать без изменения с различными серверами реляционных БД.

Если приложение умеет работать c макрокомандами и поддерживает протокол DDE (а это справедливо для всех выше перечисленных пакетов для MS Windows), то очень просто настроить такое приложение на работу с одной СУБД или группой однородных реляционных СУБД. Вопросы передачи данных по сети либо должен решать сам DDE сервер, либо он может использовать транспортные средства СУБД, например SQL*NET .Примером DDE сервера для работы с СУБД Oracle является пакет Oracle for Windows компании Oracle.

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

4.5 Стандарт ODBC

Все рассмотренные выше подходы не позволяли создавать клиентские приложения, не зависимые от используемого сервера БД. Каждый сервер реализовывал свое множество функций, имел свой диалект SQL и т.д. Для того, чтобы можно было создавать приложения и серверы, которые будут обмениваться командами и данными, ничего не зная друг про друга, было решено выработать стандарт интерфейса клиент-сервер. Этим занималась группа SQL-Access Group (SAG), в состав которой входили ведущие компании: - разработчики СУБД, операционных систем, компьютеров, такие как DEC, Hewlett-Packard, Bull, Inqres, Oracle, Informix, Sybase, Microsoft, Novell, Information Builders, NCR/Teradata, Tandem.

Группе удалось создать стандарт, который определяет:

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

Первую программную реализацию этого стандарта выполнила компания Microsoft, назвав ее Open Data Base Connectivity (ODBC). Эта реализация позволяет различным приложениям для MS Windows работать с различными серверами БД (удаленными и локальными) и с БД для PC.

Основная идея ODBC заключается в следующем: компания Microsoft создала динамическую библиотеку связи (DLL) для Windows, называемую Driver Manager. Кроме нее для каждого сервера разрабатывается свой драйвер (он выполнен тоже в виде DLL). Пользовательское приложение загружает и инициализирует Driver Manager и затем общается только с ним. Оно передает ему команды стандарта ODBC для связи с БД, исполнения запросов, извлечения данных и т.д. В свою очередь Driver Manager подключает необходимый для работы с данной БД драйвер. Все это программное обеспечение работает на той же машине, что и приложение в среде MS Windows.

Драйвер преобразует команды ODBC в операторы SQL конкретной СУБД. Он также преобразует данные и коды ошибок. Драйвер может работать с локальной СУБД, использовать для связи с удаленной СУБД ее транспортные средства (например, SQL*Net) или сам реализовывать связь по сети. На рисунке 2 приведена схема архитектуры ODBC.

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