Передача данных по протоколу HTTP в режиме реального времени
Данная тема рассмотрена в презентации, которая находится в приложении к данному конспекту («FromPushTechnologytotheReal-TimeWeb.pdf»)
Основы RPC (Remote Procedure Call)
Общие сведения
Основная задача – обеспечить вызов из прикладных программ подпрограмм в библиотеках, которые работают на других узлах/компьютерах, прозрачно для вызывающих программ.
Это попытка перенести взаимодействие между программой и библиотекой в сетевую среду, где программа работает на одном узле, а библиотека – на другом.
Описание подхода
Любая подпрограмма имеет интерфейс, который составляет интерфейс библиотеки. Этот интерфейс подразумевает собой набор определений процедур с описанием наборов типов данных, которые используются и составляют часть библиотеки.
Идея разработчиков RPC: на основе интерфейса библиотеки автоматически генерируются две подпрограммы-программы, называемые «Stub» и «Skeleton».
«Stub»– это «заменитель библиотеки» для прикладной программы, который обладает в точности таким же интерфейсом, как интерфейс библиотеки (с таким же набором процедур и типов данных). Однако вместо реализации процедур, эти процедуры обращаются к библиотеке «RPCruntime», для того чтобы по протоколу TCP/IP установить соединение с сервером –>выполнить передачу по сети входных параметров ->дождаться получения результатов –>получить результаты –>изъять из входного потока ->передать программе. Это происходит с учетом того, кто библиотека как будто бы «физически» находится на компьютере рядом с прикладной программой, в том же самом адресном пространстве программы.
|
|
|
Передача данных из адресного пространства прикладной программы в адресное пространство на другом узле библиотеки выполняется с помощью так называемой «сериализации» и «десериализации» – записи в поток входных параметров, получения из потока выходных параметров и восстановления их в нужном виде/формате.
Кроме программы «Stub», «заменителя библиотеки», автоматически генерируется программа «Skeleton», то есть скелет в самой библиотеке. Внутри себя она использует средства, необходимые для получения входящих запросов через «RPCruntime», прослушивания входящих запросов, приема информации о запросах, чтения имени вызываемой подпрограммы, входных параметров, а также вызова подпрограммы через интерфейс библиотеки. Получив от библиотеки результаты, данные «сериализуются», записываются в выходной поток и возвращаются клиенту.
«Stub»и «Skeleton» генерируются автоматически по описанию интерфейса библиотеки. Поэтому задача программиста – «прикрутить» программу к «переходнику» («Stub»), а «Skeleton» связать с исходной библиотекой.
|
|
|
Изначально технология RPCсоздавалась для языка C. Со временем она сталаподдерживатьсявC++, «перекочевала» в другие языки. Однако, например, в C++существовали заголовочные файлы и информация, расположенная в них, была недостаточной для того, чтобы построить по ней заголовки (невозможно однозначно определить, какие параметры являются входными, а какие – выходными).
char * str – это ссылка на буфер, в который данные надо вернуть, или это ссылка на буфер входных данных? Если параметр является входным, то данные идут от программы к библиотеке (от клиента к серверу), а если выходным – от сервера к клиенту. Если параметр и входной, и выходной, он должен передаваться от клиента к серверу и обратно.
Для решения описанной выше проблемы был придуман специальный язык, называемый IDL (Interface Definition Language, язык описания интерфейсов).
IDLявляется C-подобным языком и предназначен исключительно для описания интерфейсов. Указание метаинформации около параметров (например, [in] –входной параметр, [out] – выходной параметр) позволяло проанализировать семантику данных, чего не хватало в C/C++, и помогало сформировать необходимые заготовки. В современных языках, таких как C# иJava, такая необходимость отсутствует, т.к. в этих языках по интерфейсу можно определить, какие параметры являются входными, а какие – выходными.
|
|
|
Технология CORBA
Появилась позднее RPC. По сути, CORBA – это технология RPC, но ориентированная на объекто-ориентированные средства программирования.
Ошибки технологий CORBAи RPC
Технологии RPC и CORBA были концептуально ошибочны. Ошибки заключались в следующем:
1) Наличие сети между двумя взаимодействующими узлами (разные компьютеры, разные адресные пространства) нельзя скрывать за интерфейсами, поскольку это влияет на сам интерфейс. Проектировать взаимодействие нужно с нуля, учитывая, что два объекта находятся на разных узлах, а не в одном адресном пространстве;
2) RPCи CORBAне придавали значения возможности взаимодействовать с разными программами (interoperability). Они исходили из того, что две программы, ранее работавшие в одном адресном пространстве, теперь работают по отдельности. Но прикладные задачи, как правило, требуют разрабатывать серверные приложения на одном языке программирования, а приложения-клиенты – на другом языке. Например, клиент может работать на Javascript в браузере или быть написанным на Java, сервер может быть написан на C# и работать на платформе .NET. Т.к. средства программирования могут быть совершенно разными, необходимо было стандартизировать формат обмена и протокол обмена.
Технологии RPC/ CORBA постепенно отошли на второй план, пришло новое решение – технология Web-служб.
Дата добавления: 2018-08-06; просмотров: 318; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!