Вопрос 41. Технологии и средства удаленного доступа. Odbc, rpc.

Технологии и средства удаленного доступа.

При необходимости организации удаленного доступа используют так называемое ПО промежуточного уровня middleware, которое можно разделить на две категории: ПО доступа к БД, например интерфейса ODBC и SQL-шлюз, и ПО межмодульного взаимодействия (системы вывозов удаленных процедур RPC, мониторы обработки транзакции ТРМ).

ODBC – OPEN DATA BASIC CONNECTIVITY

Чтобы практически реализовать унифицированный доступ к разным СУБД посредством разных сетевых протоколов, в ODBC каждой паре СУБД-протокол соответствует свой DLL драйвер.

ODBC архитектура включает в себя:

Приложения - обрабатывает данные, вызывает ODBC функции для выполнения SQL инструкции

Менеджер драйверов – загружает драйверы по запросу приложения

Драйверы – обрабатывают вызовы ODBC функции, передают SQL инструкции и возвращают результаты приложения, при необходимости модифицируют SQL инструкции

Источники данных – включает СУБД, операционную и сетевую платформу

ODBC опирается на спецификацию SQL CLI – CALL LAVEL INTERFACE, входящую в стандарт SQL. Интерфейс ODBC API – реализован как набор DLL библиотек, библиотека ODBC DLLсодержит функции вызовов специализированных драйверов для различных СУБД.

RPC – REMOTE PROСEDURE CALL

Основные идеи:

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

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

Интерфейс взаимодействия описывается между клиент-серверной частями на языке IDL (INTERFACE DEFINITOR LANGUAGE).

Компилятор транслирует описание интерфейса в заглушки ли суррогат клиента, формируемый при этом заголовок интерфейса включается в приложение клиента. Заглушка клиента, к которой обращается приложение клиента, оформляет вызов определенной процедуры. Функции библиотеки RPC формируют из параметров вызова пакет, который доставяется через протокол RPC функции приема аналогичной библиотеки на сторне сервера. Библиотека RPC на сервере распаковывает параметры и передает заглушки с сервера. Заглушка с сервера формирует локальный выозов сервера. Заглушка сервера и заголовок интерфейса, используемый серверным приложением отдельно компилируются сервером.

Вопрос 42. Dcom.

COM (англ. Component Object Model — объектная модель компонентов; произносится как [ком]) — это технологический стандарт от компании Microsoft, предназначенный для созданияпрограммного обеспечения на основе взаимодействующих компонентов, каждый из которых может использоваться во многих программах одновременно. Стандарт воплощает в себе идеиполиморфизма и инкапсуляции объектно-ориентированного программирования. Стандарт COM мог бы быть универсальным и платформо-независимым, но закрепился в основном наоперационных системах семейства Microsoft Windows. В современных версиях Windows COM используется очень широко. На основе COM были реализованы технологии: Microsoft OLE Automation, ActiveX, DCOM, COM+, DirectX, а также XPCOM.

DCOM

Выпущенная в 1996 году технология DCOM (англ. Distributed COM — распределённая COM) основана на технологии DCE/RPC (разновидности RPC). DCOM позволяет COM-компонентам взаимодействовать друг с другом по сети. Главным конкурентом DCOM является другая известная распределённая технология — CORBA.

Как DCOM, так и CORBA решают задачу вызова метода объекта, расположенного на другой машине, а также передачу ссылки на объект с одной машины на другую.

Сетевой уровень DCOM называется ORPC (Object RPC) и является объектно-ориентированным расширением DCE RPC.

Технология DCOM обеспечивает базовые установки безопасности, позволяя задавать, кто и из каких машин (источник про фразу «из каких машин»?) может создавать экземпляры объекта и вызывать его методы.

DCOM является развитием многокомпонентной модели (СОМ). СОМ определяет, каким образом компоненты взаимодействуют со своими клиентами. Это взаимодействие осуществляется таким образом, чтобы клиент и компонент могли соединяться без необходимости использовать некоторый промежуточный компонент системы и клиент мог вызывать методы компонента. Рисунок 1 иллюстрирует это с точки зрения многокомпонентной модели.

Рис. 1 – COM-компоненты  в одном процессе

В сегодняшних операционных системах процессы изолированы друг от друга. Клиент, которому нужно связаться с компонентом другого объекта, не может вызвать компонент напрямую, а должен использовать некоторую форму связи между процессами, предусмотренную операционной системой. СОМ организует подобное соединение в полностью прозрачной манере: он перехватывает вызовы со стороны клиента и адресует их компоненту другого процесса. Рис. 2 показывает, как run-time библиотеки COM/DCOM организуют соединение между клиентом и компонентом.

Рис. 2 – COM-компоненты в разных процессах

Когда клиент и компонент находятся на различных машинах, DCOM просто заменяет локальное соединение между процессами сетевым протоколом. При этом ни клиент, ни компонент и не подозревают, что провода, соединяющие их, стали чуть длиннее.

Рис. 3 показывает архитектуру DCOM в общем: СОМ run-time предлагает клиентам и компонентам объектно-ориентированные сервисы и использует RPC и провайдер безопасности для генерации стандартных сетевых пакетов, соответствующих стандарту протокола DCOM.

Рис. 3 – DCOM: COM-компоненты на различных машинах