Распределенные вычисления и технологии Inprise

       

Как устроено взаимодействие клиентов и серверов


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

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

Рис. 5. Осуществление вызовов удаленных процедур

При обращении клиента к удаленному серверу функциональности внутри адресного пространства сервера создается так называемый серверный stub-объект (в терминологии CORBA он называется skeleton, в терминологии COM - stub; некоторые авторы переводят этот термин как "заглушка"), являющийся представителем данного клиента в адресном пространстве сервера (при многопользовательском доступе к одному и тому же экземпляру сервера этих объектов создается несколько).

Внутри адресного пространства клиента создается клиентский stub-объект (в терминологии CORBA он называется stub, в терминологии COM - proxy; иногда этот термин переводят как "заместитель"). Он может обладать таким же списком методов, как соответствующий ему серверный stub-объект, но никогда не содержит их истинной реализации (в лучшем случае вместо истинной реализации могут присутствовать функции API из библиотеки, реализующей вызовы удаленных процедур и передачу данных с помощью того или иного сетевого протокола, как, например, в случае stub-кода, сгенерированного утилитами из комплекта поставки Inprise Entera) Эти два stub-объекта общаются между собой, обмениваясь данными примерно так же, как взаимодействуют между собой сетевые приложения и сервисы.. Из передаваемых данных формируются так называемые пакеты данных, которые с помощью сетевых протоколов передаются другому stub-объекту (этот процесс иногда называется маршалингом или маршрутизацией), где и расшифровываются.


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

Многие инструменты для создания серверов функциональности содержат в комплекте поставки утилиты для автоматической генерации stub-кода. Код генерируется на основании описаний интерфейса сервера. Во многих случаях эти описания создаются на языке IDL (Interface Definition Language).

Отметим, что существует несколько диалектов IDL (для COM, для CORBA и др.). Тем не менее различия между ними невелики. Delphi 4 поддерживает как COM IDL, так и CORBA IDL.

Сервер приложений Inprise Entera содержит такой кодогенератор для большого количества языков программирования; существует компилятор MIDL для генерации stub-кода и proxy-кода на C++ на основе COM IDL (он активно используется при создании серверов и клиентов с помощью Microsoft Visual C++). В случае CORBA также имеются кодогенераторы для С++ и Java. При создании серверов функциональности, реализованных в виде серверов автоматизации, c помощью Delphi и C++Builder, stub-код генерируется автоматически при создании соответствующих классов, и создавать описания с помощью IDL необходимости нет. Однако в этом случае всегда можно сгенерировать описание на IDL (как для COM, так и для CORBA) на основании созданной библиотеки типов сервера.

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


Содержание раздела