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

ODBC позволяет использовать в своих операторах динамически формируемые операторы SQL. Поэтому предусмотрены команды определения формы результата оператора Select (количество переменных, их тип и т.д.) Простое ODBC приложение должно работать следующим образом:

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

В свою очередь выполнение SQL оператора состоит из следующих шагов:

1. формирование в буфере строки оператора SQL, установка значений параметров;
2. для операций выборки установление имени курсора данных оператора SQL;
3. выполнение оператора;
4. для операций выборки запрос формы результата, назначение переменных для хранения результата, выборка данных;
5. проверка и обработка кода завершения оператора.

Microsoft ODBC успешно работает в Windows и Windows NT, сейчас разрабатываются драйверы для платформы Mac, планируется переход и на другие платформы. Однако, поскольку ODBC был первой реализацией стандарта группы SAG, он имеет и ряд недостатков. К сожалению многие пакеты под Windows не поддерживают стандарт ODBC, более того компания Borland (владелец таких пакетов, как dBASE, Paradox, QuatroPro, InterBase) создала свой собственный стандарт IDAPI, альтернативный ODBC. ODBC не обеспечивает прозрачность работы в сети. Забота об этом переложена либо на драйверы, либо на транспортные пакеты СУБД. При работе с несколькими СУБД одновременно используется несколько драйверов, функции которых частично дублируются. Драйверы при этом занимают оперативную память. ODBC не поддерживает работу с распределенной БД, не позволяет выполнять в запросе операции соединения таблиц из разных БД. ODBC пока работает только под MS Windows и не позволяет переносить ODBC совместимые приложения на другие платформы.

4.6 Стандарт IDAPI

Компания Borland разработала свой альтернативный стандарт интерфейса клиент-сервер, учитывая недостатки стандарта ODBC и свой опыт связывания Paradox и QuatroPro с Interbase. Стандарт называется IDAPI (Integrated Database Application Programming Interface) [6]. В его разработке также участвовали компании IBM, Novell, WordPerfect. Архитектура IDAPI более сложна, чем ODBC, и позволяет хорошо работать как с SQL серверами, так и с навигационными записе-ориентированными базами (см. рисунок 3). Для этого язык программного интерфейса (API) был расширен за счет добавления команд для работы с навигационными СУБД (NAV/CLI - навигационный CALL-интерфейс), а в программной реализации IDAPI кроме средств обработки SQL (Relational Engine) имеется средство обработки NAV/CLI.

Планируется реализовать IDAPI среду на нескольких платформах: DOS, OS/2, NetWare, MS Windows. Это позволит переносить приложения. IDAPI предусматривает работу с ODBC - совместными серверами, но не позволяет использовать ODBC - совместимые приложения. IDAPI также планирует поддерживать свой транспортный уровень связи клиента с сервером в сети с различными протоколами. Еще одним достоинством IDAPI является возможность работы с распределенной БД и исполнения в запросе операций соединения таблиц из разных СУБД. Пользователи IDAPI смогут работать с большими двоичными объектами (BLOB), в которых может хранится изображение и звук.

Стандарты IDAPI и ODBC во многом пересекаются и очевидно некоторые время будут конкурировать не рынке. Очевидно Microsoft вскоре учтет недостатки ODBC и реализует его версию на новых вычислительных платформах.

4.7 Поддержка группы стандартов интерфейса

Поскольку сегодня не существует единого стандарта интерфейса клиент-сервер и различные компании успешно реализуют на разных вычислительных платформах ODBC, IDAPI, DAL, PIA, DDE и другие стандарты в своих приложениях, стали появляться пакеты, позволяющие одновременно работать с одной СУБД пакетам, реализующим различные стандарты на разных вычислительных платформах.

Развитие этого подхода привело к появлению пакетов, позволяющих связать множество клиентских приложений, поддерживающих разные стандарты интерфейса, с множеством СУБД, почтовых серверов, файл-серверов, palmtop компьютеров и Personal Digital Assistants (PDA) компьютеров. Эти пакеты должны работать на разных вычислительных платформах и иметь средства для быстрого наращивания числа клиентских приложений переднего плана (front end) и числа серверов (back end). Хорошим примером такого продукта является пакет Oracle Glue компании Oracle.

Oracle Glue - это адаптируемый, переносимый, интегрированный пакет, позволяющий склеить в единую прикладную систему клиентские приложения, выполненные с помощью Visual Basic, MS Access, Excel, Amipro, Lotus 1-2-3, Authorware, MS Word, QuattroPro, Asymmetrix ToolBook и любых DDE совместимых пакетов в среде MS WINDOWS; приложения, выполненные с помощью HyperCard на MAС; приложения, выполненные с помощью WINGZ на Unix; приложения, выполненные с помощью Oracle Card или Pen Apps на перьевых компьютерах, с множеством серверов БД, файловых и почтовых серверов, среди которых: Oracle6, Oracle7, Oracle*Mail, DB2, SQL/DS, Tandem, Sybase, MS SQL Server, dBASE, Paradox, Sharp Wizard & PDA, серверы БД, к которым имеются шлюзы Oracle, серверы БД, поддерживающие стандарты ODBC, DAL, PIA, IDAPI, почтовые серверы, поддерживающие стандарты MHS, VIM, MAPI и т.д. (см. рисунок 4).

4.8 Шлюзы

Шлюз - это программное обеспечение, заставляющее сервер БД одной компании выглядеть для работающих с ним клиентов как сервер БД другой компании. Например, если на компьютер mainframe с OC MVS, где работает СУБД DB2, поставить шлюз Oracle Transparent Gateway to DB2, то все программы-клиенты, работающие с СУБД Oracle, смогут работать с СУБД DB2. Шлюз обычно ставится на том же компьютере, где работает СУБД, работу которой надо "закамуфлировать".

Большинство компаний-производителей популярных коммерческих серверов БД имеют шлюзы к серверам БД других компаний ("чужим" серверам). Шлюз позволяет работать с "чужой" СУБД не только клиентским приложениям, но и серверам БД (в приведенном примере приложения Oracle и сервер БД Oracle могут работать с СУБД DB2). Это позволяет перекачивать данные между различными СУБД и, если шлюз обеспечивает поддержку двухфазного протокола фиксации изменений (2 phase commit), создавать распределенную БД, в узлах которой находятся СУБД различных компаний. Например, в распределенной СУБД Oracle один из узлов может использовать СУБД DB2 на mainframe или СУБД SQL/400 на компьютере AS/400 (где СУБД Oracle не реализована).

Шлюзы помогают интегрировать данные различных СУБД и использовать мощные инструментальные средства одних компаний для работы с данными СУБД других компаний. Кроме того, шлюзы могут "камуфлировать" не только реляционные СУБД, но и СУБД с другими моделями данных (иерархической, инвертированные списки), а также файловые системы. Используя, например, шлюз Oracle к Adabas можно работать с СУБД Adabas, имеющей специфическую модель данных, как с реляционной СУБД и использовать для работы команды языка SQL. Аналогично, шлюзы Oracle к VSAM и RMS позволяет работать с файлами с таким методом доступа как с реляционной СУБД.

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

Некоторые шлюзы имеют ограниченные функции, т.е. позволяющие выполнять только чтение из "чужой” БД. Существуют также "двунаправленные" шлюзы, которые позволяют не только обращаться к "чужой" СУБД для чтения/записи, но и позволяют "чужой" СУБД самой обращаться к другим серверам БД для исполнения чтения/записи (пример таких двунаправленных шлюзов - Database Gateway компании MicroDecisionware Inc и Open Server компании Sybase).

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

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

Иногда шлюз может заниматься оптимизацией исполнения запроса, обеспечивать работу с удаленными процедурами RPC (remote procedure calls).

4.9 Средства обработки распределенных транзакций

Средства обработки распределенных транзакций (Distributed Transaction Processing - DTP) еще мало известны в нашей стране. Эти средства позволяют связывать разнородные компьютеры с различными операционными системами и различными СУБД в единую среду обработки приложений. Причем в этой среде поддерживается расширенная архитектура клиент-сервер.

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

Наиболее известными сегодня средством обработки распределенных транзакций является пакет TUXEDO ETP System, Release 4.2 компании USL (Unix system Laboratories). Он позволяет связать в единую среду персональные компьютеры с MS DOS, MS Windоws, OS/2, Unix; машины среднего класса с Unix и mainframe с MVS/CICS. Приложения работают на персональных компьютерах, а различные СУБД - на Unix-компьютерах среднего класса. Кроме того, поддерживается интерактивное взаимодействие по схеме запрос/ответ с MVS/CICS процессами через протокол LU6.2.

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

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

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

Среди недостатков DTP следует указать ограниченное количество поддерживаемых сетевых протоколов и СУБД. В приложении должен использоваться SQL конкретной СУБД или стандарт SQL. Использование специфического языка интерфейса с монитором транзакций не позволяет "уйти" из среды DTP. Опыт использования систем такого класса у нас в стране ограничен (а они достаточно сложны в использовании).

Заключение

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

Модель взаимодействия, в которой один участник сети инициирует выполнение какой-либо действия или набора действий, а другой ее выполняет, называется моделью «клиент-сервер». Участники подобного взаимодействия являются соответственно клиентом и сервером. В большинстве случаев клиентом (или сервером) называют вычислительную машину или их объединение, которые представляют из себя клиентское (или серверное) программное обеспечение.

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

Библиографический список

Специальная, научная и учебная литература

1. Л. Калиниченко. Стандарт систем управления объектными базами данных ODMG 93: краткий обзор и оценка состояния. - СУБД, 1, 1996. 49 – 51 с.
2. Д. Брюхов, В. Задорожный, Л. Калиниченко и др. Интероперабельные информационные системы: архитектуры и технологии. - СУБД, 4, 1995 , 96-113 с.
3. H. Мухамедзянов, Java. Серверные приложения, - Издательство: СОЛОН - Р, 2003 , 287 с.
4. Роберт Орфали, Дэн Харки, "JAVA и CORBA в приложениях клиент-сервер" , 2000, 614 с.
5. Дуглас Камер, Дэвид Л. Стивенс, Сети TCP/IP, том 3. Разработка приложений типа клиент/сервер, издательство «Вильямс», 2002 г., 501 с.
6. Фленов М.Е., Web-сервер глазами хакера: Проблемы безопасности Web-серверов; БХВ-Петербург, 2012 , 89 - 90 с.