Uwp rpc service что это
Как работает RPC
Средства удаленного вызова процедур делают его пользователям, как будто клиент напрямую вызывает процедуру, расположенную в удаленной серверной программе. У каждого клиента и сервера есть свои адресные пространства; то есть каждый из них имеет свой собственный ресурс памяти, выделенный для данных, используемых процедурой. На следующем рисунке показана архитектура RPC.
Как показано на рисунке, клиентское приложение вызывает локальную процедуру-заглушку вместо фактического кода, реализующего процедуру. Заглушки компилируются и связываются с клиентским приложением. Вместо того, чтобы содержать фактический код, реализующий удаленную процедуру, код заглушки клиента:
Для вызова удаленной процедуры сервер выполняет следующие действия.
Затем выполняется удаленная процедура, которая, возможно, создает выходные параметры и возвращаемое значение. После завершения удаленной процедуры аналогичная последовательность действий возвращает клиенту данные.
Клиент завершает процесс, принимая данные по сети и возвращая их вызывающей функции.
Библиотеки времени выполнения предоставляются в двух частях: библиотеку импорта, которая связана с приложением и библиотекой времени выполнения RPC, которая реализована как библиотека динамической компоновки (DLL).
Серверное приложение содержит вызовы функций библиотеки времени выполнения сервера, которые регистрируют интерфейс сервера и позволяют серверу принимать удаленные вызовы процедур. Серверное приложение также содержит удаленные процедуры, связанные с конкретным приложением, которые вызываются клиентскими приложениями.
Службы и RPC/TCP
начиная с Windows Vista диспетчер управления службами (SCM) поддерживает удаленные вызовы процедур по протоколу управления передачей (rpc/TCP) и именованным каналам (rpc/NP). Функции SCM на стороне клиента используют RPC/TCP по умолчанию.
RPC/TCP подходит для большинства приложений, использующих функции SCM удаленно, таких как средства удаленного администрирования или мониторинга. Однако для обеспечения совместимости и производительности некоторым приложениям может потребоваться отключить RPC/TCP, задав значения реестра, описанные в этом разделе.
Когда служба вызывает удаленную функцию SCM, клиентский модуль SCM сначала пытается использовать RPC/TCP для связи со службой SCM на стороне сервера. если сервер работает под управлением версии Windows, поддерживающей rpc/tcp и разрешающей трафик rpc/tcp, подключение rpc/ткпп будет выполняться. если сервер работает под управлением версии Windows, которая не поддерживает rpc/tcp, или поддерживает rpc/tcp, но работает за брандмауэром, который разрешает только именованный канал, истекает время ожидания подключения rpc/tcp, и SCM повторяет подключение к rpc/NP. В конечном итоге это будет выполнено, но может занять некоторое время (обычно более 20 секунд), в результате чего функция OpenSCManager будет заблокирована.
Значения реестра RPC/TCP
В следующей процедуре описывается, как отключить RPC/TCP на стороне клиента.
Отключение RPC/TCP на стороне клиента
В следующей процедуре описывается, как отключить TCP на стороне сервера.
Отключение протокола TCP на стороне сервера
В следующей процедуре описывается, как отключить RPC/TCP и RPC/NP на сервере (например, чтобы уменьшить поверхность атаки).
Отключение RPC/TCP и RPC/NP на сервере
Значение реестра скмапиконнектионпарам можно также использовать для указания интервала времени ожидания RPC/TCP в миллисекундах. Например, значение 30 000 указывает интервал времени ожидания 30 секунд. Значение по умолчанию — 21 000 (21 секунда).
Русские Блоги
Принцип службы RPC Service и его простая реализация
оглавление
Объяснение концепции
Основной принцип клиента и сервера устанавливается:
Процесс устанавливает соединение с сервером:
RPC Framework Простая реализация
Определение Служба
Сначала определите интерфейс обслуживания, интерфейс может быть размещен отдельно в банке
Реализовать интерфейс
Затем добавьте реализацию
Аннотация RPCService здесь определяет, что каркас может сделать структуру найти класс реализации услуг через эту аннотацию.
Давайте посмотрим на аннотацию службы RPC
Реализация услуг
Сервер в основном Netty (рамка NIO) + пружина
Если один из ключевых точек RPC заключается в передаче сериализации, просто когда клиент звонит службу, необходимо создать запрос, а затем передавать этот запрос на сериализацию на сервер, а затем после завершения службы, результат сериализуется.
Запрос определения
Определить rpcresponse.
Кодер и декодер
Поскольку проект основан на Netty, он основан на Netty, ядро является сериализацией, что может принять разные рамки сериализации по мере необходимости, например, PB.
Сканировать Service.
Сервер использует пружину, а сервис добавляет аннотацию RPCService, поэтому сервер начинается сканировать RPCService
Следующий код позволяет услугу найти службу и поместить ее в поручение, что при вызове сервиса вы можете найти объект сервиса с карты в соответствии с именем службы, вы знаете способ сервисного объекта и услуг, вы можете Назовите это напрямую.
Запустить сервер
Начальная служба, обратите внимание на кодировщик и декодер в соответствии со стандартным кодом Netty Server
Запрос на процесс
RPCServerHandler отвечает за обработку запроса, знакомого с Netty, унаследовал SimpleChannel InBoundHandler, обрабатывает в функцию ChangleRead0, обратите внимание, поскольку Pipine декодирован как объект RPCrequest, поэтому вы можете использовать его прямо здесь.
Открытие услуг и регистрация
В распределенной системе автоматическое открытие и регистрация службы является стандартным, что обычно используется при использовании централизованных центров конфигурации, а сессия с открытым исходным кодом имеет Zookeeper, EtCD. Здесь используйте ZK в качестве центра конфигурации.
Обнаружение и регистрация услуг заключается в том, что сервис запускается, и адрес службы и сервисный адрес записываются в центр конфигурации. Когда клиентские вызовы, сначала прочитайте адрес сервера сервера, чтобы позвонить в сервис из централизованного центра конфигурации, если Есть несколько, случайных выбора одного (конечно, есть проблема дисбаланса нагрузки), подключите сервер и вызов.
Вернуться к интерпретации кода, что здесь используется, давайте посмотрим, как оно достигнуто.
Интерфейс первого определения:
Посмотрите на реализацию, ZK имеет два типа узлов, постоянные узлы и временные узлы, которые идеально подходят для открытия и регистрации услуг. Представить:
Нет больше деталей, см. Код:
Принцип состоит в том, чтобы создать адрес службы хранения временного узла.
Давайте посмотрим на открытие услуг:
Реализация клиента
Сервисный агент
Технология динамического агента, предусмотренная Java, реализует агент RPC (конечно, может также быть реализован с использованием CGLIB), конкретный код выглядит следующим образом:
RPC клиент
Используя класс RPCCClient для реализации клиента RPC, вам нужно только расширить абстрактный класс SimpleChannel Inboundhandler, предоставляемый Netty, код выглядит следующим образом:
Тест на обслуживание
Вышеуказанная статья я не полностью проверил, только для исследования.
RPC, Messaging, REST: Терминология
Цель данной статьи — обсудить терминологию. Статья — не о том, как и для чего, а только исключительно об использовании терминологии. Статья отражает мнение автора и не претендует на научность.
Вступление
Если вы работаете в области программирования распределенных систем или в интеграции систем, то большая часть изложенного здесь вам не в новинку.
Проблема возникает, когда встречаются люди, использующие разные технологии, и когда эти люди начинают технические разговоры. При этом часто возникает взаимное недопонимание, обусловленное терминологией. Я здесь попытаюсь свести воедино терминологии, используемые в разных контекстах.
Терминология
Четкой терминологии и классификации в этой области нет. Используемая ниже терминология является отражением модели, сложившейся у автора, то есть она строго субъективна. Любая критика и любые обсуждения приветствуются.
Я разделил терминологию на три области: RPC (Remote Procedure Call), Messaging и REST. Эти области имеют под собою исторические корни.
RPC технологии — наиболее старые технологии. Наиболее яркие представители RPC, это — CORBA и DCOM.
В те времена в основном приходилось связывать системы в быстрых и относительно надежных локальных сетях. Главная идея RPC была в том, чтобы сделать вызов удаленных систем очень похожим на вызов функций внутри программы. Вся механика удаленных вызовов пряталась от программиста. По крайней мере её пытались спрятать. Программисты во многих случаях вынуждены были работать на более глубоком уровне, где появлялись термины маршалинг (marshalling) и unmarshalling (как это по-русски?), что по сути означало сериализацию. Обычные вызовы функций внутри процессов обрабатывались на вызывающей стороне в Proxy, а на стороне системы, выполняющей функцию, в Dispatcher. В идеале ни вызывающая система, ни обрабатывающая система не занимались тонкостями передачи данных между системами. Все эти тонкости сосредотачивались в связке Proxy — Dispatcher, код которых генерировался автоматически.
Поэтому вы не заметите, не должны заметить, никакой разницы между вызовом локальной функции и вызовом удаленной функции.
Сейчас наблюдается своеобразный ренесанс RPC, наиболее яркие представители которого: Google ProtoBuf, Thrift, Avro.
Messaging
С течением времени выяснилось, что попытка оградить программиста от того, что вызываемая функция все же отличается от локальной, не привела к желаемому результату. Детали реализации и принципиальные отличия распределенных систем были слишком велики, чтобы решаться с помощью автоматически генерируемого кода Proxy. Постепенно пришло понимание, что факт того, что системы связывает ненадежная, медленная, низкоскоростная среда, должен быть явно отражен в коде программы.
Появились технологии веб-сервисов. Мы стали говорить ABC: Address, Binding, Contract. Не совсем понятно, почему появились контракты, которые по сути являются Envelope (конвертами) для входных аргументов. Контракты чаще усложняют всю модель, чем упрощают ее. Но… неважно.
Теперь программист явным образом создавал сервис (Service) или клиента (Client), вызывающего сервис. Сервис представлял из себя набор операций (Operation), каждая из которых на входе принимала запрос (Request) и выдавала ответ (Response). Клиент явным образом посылал (Sent) запрос, сервис явным образом получал (Receive) его и отвечал (Sent), высылая ответ. Клиент получал (Receive) ответ и на этом вызов завершался.
Так же, как и в RPC, где-то здесь работали Proxy и Dispatcher. И как прежде их код генерировался автоматически и программисту не надо было в нем разбираться. Разве только что, клиент явным образом использовал классы из Proxy.
Запросы и ответы явным образом преобразуются к формату, предназначенному для передачи по проводам. Чаще всего это массив байт. Преобразование называется Serialization и Deserialization и иногда прячется в коде Proxy.
Кульминация messaging проявилась в появлении парадигмы ESB (Enterprise Service Bus). Никто толком не может сформулировать, что это такое, но все сходятся на том, что данные по ESB движутся в виде сообщений.
В постоянной борьбе со сложностью кода, программисты сделали очередной шаг и создали REST.
Основной принцип REST в том, что операции-функции резко ограничили и оставили только набор операций CRUD: Create — Read — Update — Delete. В этой модели все операции всегда применяются к некоторым данным. Имеющихся в CRUD операций достаточно для большей части приложений. Так как REST технологии в большинстве случаев подразумевают использование протокола HTTP, то команды CRUD отразились на команды HTTP (Post — Get — Put — Delete). Постоянно утверждается, что REST не обязательно привязан к HTTP. Но на практике повсеместно используется отражение сигнатур операций на синтаксис HTTP команд. К примеру, вызов функции
EntityAddress ReadEntityAddress(string param1, string param2)
выразится в таком виде:
Заключение
Прежде, чем начинать дискуссию по распределенным системам или по интеграции, определитесь с терминологией. Если Proxy всегда будет означать одно и то же в разных контекстах, то, к примеру, request мало что будет значить в терминах RPC, а marshalling вызовет недоумение при обсуждении REST технологий.
Русские Блоги
Подробный удаленный вызов процедур (RPC)
В этой статье рассказывается, что такое удаленный вызов процедур (RPC), каковы распространенные методы RPC, какие этапы разработки испытаны RPC, а также сравниваются преимущества и недостатки различных технологий RPC.
Что такое RPC
Рисунок 1 описывает процесс передачи дейтаграммы в простом RPC
Примечание: вышеуказанные документы можно прочитать онлайнhttp://www.cs.virginia.edu/
Основные операции RPC
Давайте посмотрим, как реализован локальный вызов процедуры. Рассмотрим следующий вызов языка Си:
Рисунок 2 Передача параметров в процессе вызова
Хотя системный вызов выполняется в режиме чтения, он по-прежнему вызывается обычным способом, помещая параметры в стек. Как показано на рисунке 2 (б), программист не знает, что делает чтение.
RPC достигает прозрачности с помощью аналогичного подхода. Когда чтение на самом деле является удаленным процессом (например, процессом, выполняющимся на компьютере, на котором расположен файловый сервер), в библиотеку помещается другая версия чтения, называемая заглушкой клиента. Эта версия процесса чтения также следует последовательности вызова на рис. 2 (б), которая совпадает с исходным процессом чтения. Другое сходство в том, что локальный вызов операционной системы также выполняется. Единственное отличие состоит в том, что она не требует от операционной системы предоставления данных, а вместо этого упаковывает параметры в сообщение, а затем запрашивает отправку этого сообщения на сервер, как показано на рисунке 3. После вызова для отправки клиентская заглушка вызывает процедуру приема и затем блокирует себя, пока не получит ответное сообщение.
Рисунок 3 Принцип RPC между клиентом и сервером
Когда сообщение поступает на сервер, операционная система на сервере передает его в заглушку сервера. Заглушка сервера является эквивалентом заглушки клиента на стороне сервера, а также представляет собой фрагмент кода, который используется для преобразования запроса, введенного через сеть, в вызов локальной процедуры. Серверные заглушки обычно сначала вызывают прием, а затем блокируются, ожидая ввода сообщения. После получения сообщения сервер извлекает параметры из сообщения и затем вызывает соответствующий процесс на сервере обычным способом (как показано на рисунке 3). С точки зрения сервера, процесс, кажется, вызывается непосредственно клиентом: параметры и адрес возврата находятся в стеке, и все нормально. Сервер выполняет требуемую операцию и затем возвращает полученный результат вызывающей стороне обычным способом. Взяв в качестве примера read, сервер заполнит буфер, на который указывает второй параметр read, данными, которые находятся внутри заглушки сервера.
После завершения вызова серверная заглушка научит клиента управлять вызовом, он упаковывает результат (буфер) в сообщение и затем вызывает send, чтобы вернуть результат клиенту. После этого серверная заглушка, как правило, снова вызывает прием, ожидая следующего входящего запроса.
После того, как клиентский компьютер получает сообщение, клиентская операционная система обнаруживает, что сообщение принадлежит клиентскому процессу (на самом деле, этот процесс является клиентской заглушкой, но операционная система не может их различить). Операционная система копирует сообщение в соответствующий буфер, а затем разблокирует процесс клиента. Заглушка клиента проверяет сообщение, извлекает результат и копирует его вызывающей стороне, а затем возвращает его обычным способом. Когда вызывающий абонент восстанавливает управление после завершения вызова чтения, ему известно только то, что он получил необходимые данные. Это не указывает, должна ли операция выполняться локально или удаленно.
В целом метод, клиент может просто игнорировать безразличный контент. Операции, выполняемые клиентом, предназначены только для выполнения обычных (локальных) вызовов процедур для доступа к удаленному сервису, при этом ему не нужно напрямую вызывать и получать вызовы. Все детали передачи сообщений скрыты в библиотечном процессе обеих сторон, так же как традиционная библиотека скрывает детали выполнения реального системного вызова.
Таким образом, удаленный вызов процедуры включает в себя следующие шаги:
Вышеупомянутые шаги должны преобразовать локальный вызов, сделанный клиентским процессом в клиентскую заглушку, в локальный вызов к серверному процессу, и ни клиент, ни сервер не осознают существование промежуточного шага.
Основные преимущества RPC двояки. Во-первых, программисты могут использовать семантику вызова процедур для вызова удаленных функций и получения ответов. Во-вторых, это упрощает сложность написания распределенных приложений, поскольку RPC скрывает все функции заглушки сетевого кода. Приложению не нужно беспокоиться о некоторых деталях, таких как сокет, номер порта, преобразование и анализ данных. В эталонной модели OSI RPC охватывает уровень сеанса и уровень представления.
Реализовать удаленный вызов процедуры
Чтобы выполнить удаленный вызов процедуры, необходимо рассмотреть следующие вопросы.
Как передать параметры
Передать значение параметра
Передача значений параметров относительно проста. На следующем рисунке показан пример простого RPC для удаленного расчета. Среди них удаленная процедура add (i, j) имеет два параметра i и j, в результате возвращается арифметическая сумма i и j.
Рисунок 4 Шаги удаленных вычислений через RPC
Шаги для удаленного вычисления через RPC:
Конечно, это просто простая демонстрация. В реальных распределенных системах необходимо учитывать другие ситуации, потому что разные машины часто имеют разные представления чисел, символов и других типов элементов данных. Например, целочисленный тип делится на Big Endian и Little Endian.
Передать эталонные параметры
Передача эталонных параметров сравнительно сложна. Ссылки, которые просто передают параметры (включая указатели), абсолютно бессмысленны, поскольку адрес ссылки, передаваемый на удаленный компьютер, может указывать на область памяти, которая полностью отличается от удаленной системы. Если вы хотите поддерживать передачу параметров ссылки, вы должны отправить копию параметров, поместить их в память удаленной системы, передать им указатель на функцию сервера, а затем отправить объект обратно клиенту, скопировав его ссылку. Если удаленный вызов процедуры должен поддерживать ссылки на сложные структуры, такие как деревья и связанные списки, им необходимо скопировать структуру в представление без указателей (например, плоское дерево) и передать его на удаленный конец, чтобы восстановить структуру данных.
Как представлять данные
В локальной системе нет проблем с несовместимостью данных, поскольку формат данных всегда один и тот же. В распределенной системе разные удаленные машины могут иметь разные порядки байтов, целые числа разных размеров и разные представления с плавающей запятой. Для RPC, если мы хотим взаимодействовать с гетерогенными системами, нам нужно придумать «стандарт» для кодирования всех типов данных и передачи их в качестве параметров. Например, ONC RPC использует формат XDR (внешнее представление данных). Эти форматы представления данных могут использовать неявные или явные типы. Неявный тип относится к передаче только значения, а не имени или типа переменной. Типичными примерами являются XDR ONC RPC и NDR DCE RPC. Явный тип относится к типу и значению каждого поля, которое необходимо передать. Типичными примерами являются стандарты ISO ASN.1 (абстрактная синтаксическая нотация), JSON (объектная нотация JavaScript), буферы протокола Google и различные форматы представления данных на основе XML.
Как выбрать протокол передачи
Некоторые реализации допускают только один протокол (например, TCP). Большинство реализаций RPC поддерживают несколько и позволяют пользователям выбирать.
Что происходит, когда что-то идет не так
По сравнению с локальными вызовами процедур, существует больше возможностей для сбоя удаленных вызовов процедур. Поскольку локальные вызовы процедур не имеют концепции сбоя вызова процедур, проекты, использующие удаленные вызовы процедур, должны быть готовы проверить ошибки удаленных вызовов процедур или перехватить исключения.
Какова семантика удаленного вызова
Семантика вызова нормальной процедуры проста: когда мы вызываем, процедура выполняется. Очень трудно добиться успешного одноразового удаленного вызова процедуры. Выполнение удаленных процедур может иметь следующие результаты:
Системы RPC обычно предоставляют семантику по крайней мере один раз или самое большее один раз, или выбирают между этими двумя. Если вам необходимо понять природу приложения и безопасна ли функция удаленной процедуры, вы можете проверить это, вызвав одну и ту же функцию несколько раз. Если функция может быть запущена любое количество раз без влияния на результат, это идемпотентная функция, такая как время суток, математическая функция, чтение статических данных и т. Д. В противном случае это неидемпотентная (неидемпотентная) функция, такая как добавление или изменение файла).
Как насчет производительности удаленных звонков
Нет никаких сомнений в том, что удаленный вызов процедуры будет намного медленнее, чем обычный локальный вызов процедуры, из-за дополнительных шагов и задержек в самой передаче по сети. Однако это не должно мешать нам использовать удаленные вызовы процедур.
Безопасен ли удаленный вызов?
Используя RPC, мы должны обратить внимание на различные проблемы безопасности:
Преимущества удаленных вызовов процедур
Удаленный вызов процедуры имеет много преимуществ:
RPC API
Любая реализация RPC должна предоставлять набор библиотек поддержки. К ним относятся:
Поэтому, чтобы определить, является ли метод связи RPC, он зависит от того, предоставляет ли он вышеуказанный API.
RPC первого поколения
ONC RPC (ранее известный как Sun RPC)
Sun первой представила коммерческие библиотеки RPC и компиляторы RPC. В середине 1980-х компьютеры Sun обеспечивали RPC и поддерживались в сетевой файловой системе Sun (NFS). Соглашение продвигалось главным образом Open Network Computing, во главе с Sun и AT & T, в качестве стандарта. Это очень легкая RPC-система, которая может использоваться в большинстве операционных систем, подобных POSIX и POSIX, включая Linux, SunOS, OS X и различные версии BSD. Такая система называется Sun RPC или ONC RPC.
ONC RPC предоставляет компилятор, который требует определения интерфейса удаленной процедуры для создания функций-заглушек клиента и сервера. Этот компилятор называется rpcgen. Перед запуском этого компилятора программист должен предоставить определение интерфейса. Определения интерфейса, содержащие объявления функций, группируются по номеру версии и идентифицируются уникальным программным кодом. Код программы позволяет заказчику определить необходимый интерфейс. Номер версии очень полезен, даже если клиент, не обновивший до последнего кода, все равно сможет подключиться к новому серверу, если сервер также поддерживает старый интерфейс.
Преобразование параметров в неявный формат сериализации через сеть называется XDR (электронное представление данных). Это гарантирует, что параметры могут быть отправлены в гетерогенные системы для обычного использования, даже если эти системы могут использовать разные порядки байтов, целые числа разных размеров или разные представления с плавающей запятой или строки. Наконец, Sun RPC предоставляет библиотеку времени выполнения, которая реализует необходимую поддержку протокола RPC и процедур сокетов.
В старой версии транспортный протокол может указывать только соответствующий RPC службы IP, используя строку «tcp» или строку «udp», и он ограничен RPC, реализованным в Linux. Чтобы сделать интерфейс более гибким, процедура выбора сети в системах UNIX, начиная с версии 4 (SunOS с версии 5), допускает более общую спецификацию. Они ищут файл (/ etc / netconfig), чтобы найти первого поставщика, который отвечает вашим потребностям. Последний параметр может быть:
Каждый удаленный вызов процедуры изначально ограничен принятием одного входного параметра. Позднее система была модифицирована для поддержки нескольких параметров. Поддержка однопараметрического RPC по-прежнему используется по умолчанию в некоторых версиях rpcgen, таких как Apple OS X. Передача нескольких параметров должна выполняться путем определения структуры, содержащей необходимые параметры, ее инициализации и передачи этой структуры.
Если имя процесса RPC определено в файле определения RPC, оно будет преобразовано в нижний регистр, а цена суффикса будет подчеркнута, за которой следует номер версии. Например, BIN_DATE очередь становится ссылкой функцией bin_date_1. Ваш сервер должен реализовать bin_date_1.
Что происходит, когда мы запускаем эту программу?
Когда мы запускаем сервер, код-заглушка сервера (программа) запускается в фоновом режиме. Он создает сокет и может привязать любой локальный порт к сокету. Затем вызовите функцию svc_register в библиотеке RPC для регистрации номера и версии программы. Это используется для связи с преобразователем портов (port mapper). Преобразователь портов является независимым процессом, обычно запускаемым при запуске системы. Он отслеживает номер порта, номер версии и номер программы. В UNIX версии 4 этот процесс называется rpcbind. В системах Linux, OS X и BSD это называется portmap.
Рисунок 5 Поиск функции ONC RPC
Когда мы запускаем клиентскую программу, она сначала вызывает clnt_create с именем, номером программы, номером версии и протоколом удаленной системы. Он связывается с сопоставителем портов в удаленной системе, чтобы найти соответствующий порт для системы.
Затем клиент вызывает функцию-заглушку RPC (в этом примере bin_date_1). Эта функция отправляет сообщение (например, дейтаграмму) на сервер (используя ранее найденный номер порта) и ожидает ответа. Для службы дейтаграмм, если ответ не получен, она отправит фиксированное количество запросов.
Затем сообщение принимается удаленной системой, которая вызывает функцию сервера (bin_date_1) и возвращает возвращаемое значение заглушке клиента. Клиентская заглушка затем возвращается к коду, где клиент совершил вызов.
RPC (DCE RPC) в распределенной вычислительной среде
Недостатком Sun RPC является то, что логотип сервера является «уникальным» 32-битным числом. Хотя это пространство больше, чем 16-разрядное доступное пространство в сокете, оно все равно не может соответствовать уникальности числа. DCE RPC учитывает этот недостаток и не требует от программистов работы с кодированием. Первым шагом в написании приложения является получение уникального идентификатора из программы uuidgen. Эта программа создаст прототип файла IDN, содержащий интерфейс ID, и гарантирует, что он никогда не будет использоваться снова. Это 128-битное значение, которое содержит код позиции и код времени создания. Затем пользователь редактирует файл прототипа и заполняет оператор удаленной процедуры.
После этого шага компилятор IDN dceidl (аналогично rpcgen) генерирует заголовок, заглушку клиента и заглушку сервера.
Другим недостатком Sun RPC является то, что клиент должен знать, на каком компьютере находится сервер. Когда он хочет получить доступ, он должен запросить номер порта, соответствующий коду программы службы имен RPC на машине. DCE поддерживает организацию нескольких машин в объекты управления, называемые ячейками. Сервер каталогов ячеек позволяет каждой машине знать, как взаимодействовать с другой машиной, ответственной за обслуживание информационной службы ячейки.
В Sun RPC сервер может использовать только локальную службу имен (преобразователь портов), чтобы зарегистрировать свой номер программы для сопоставления портов. В DCE сервер использует демон RPC (сервер имен), чтобы зарегистрировать свою конечную точку (порт) на локальном компьютере, и использует сервер каталогов ячеек, чтобы зарегистрировать сопоставление имени своей программы на компьютере. Когда клиент хочет установить связь с сервером RPC, он сначала запрашивает у своего сервера каталогов ячеек местоположение машины, на которой расположен сервер. Затем клиент получает номер порта серверного процесса на компьютере от демона RPC. Кросс-ячейка DCE также поддерживает более сложные поиски.
DCE RPC определяет NDR (представление сетевых данных) для кодирования сети для сбора информации. По сравнению с использованием единой спецификации для представления разных типов данных, NDR поддерживает многоканонический формат. Разрешить клиенту выбирать, какой формат использовать. В идеале нет необходимости преобразовывать его из нативного типа. Если это отличается от локального представления данных сервера, сервер все равно необходимо преобразовать, но многоканальный формат может избежать преобразования в другие внешние форматы, когда и клиент, и сервер используют один и тот же локальный формат. Например, в случае, если указан сетевой формат данных с порядком байтов с прямым порядком байтов, клиент и сервер поддерживают только байтовый порядок с прямым порядком байтов, тогда клиент должен преобразовать все данные из байтового порядка с прямым порядком байтов в байтовый порядок с прямым порядком байтов И когда сервер получит сообщение, он передаст все данные обратно в порядке байтов с прямым порядком байтов. Сетевое представление данных с несколькими спецификациями позволит клиентам отправлять сетевые сообщения, содержащие данные в формате байтов с прямым порядком байтов.
Рисунок 6 Поиск функции DCE RPC
RPC второго поколения: объекты поддержки
Объектно-ориентированные языки начали появляться в конце 1980-х годов, и стало ясно, что ни Sun ONC, ни системы DCE RPC в то время не оказывали никакой поддержки, такой как создание экземпляров удаленных объектов из удаленных классов, отслеживание экземпляров объектов или обеспечение поддержки полиморфизма. Хотя существующие механизмы RPC могут работать, они все еще не поддерживают методы объектно-ориентированного программирования в автоматическом и прозрачном виде.
Microsoft DCOM (COM +)
Самым большим недостатком DCOM является то, что это эксклюзивное решение Microsoft: оно плохо работает через брандмауэры (большинство систем RPC имеют схожие проблемы), поскольку брандмауэр должен позволять определенным портам пропускать ORPC и DCOM.
CORBA
Хотя DCE устраняет некоторые недостатки Sun RPC, некоторые дефекты все еще существуют. Например, если сервер не работает, клиент не может подключиться к удаленной процедуре, чтобы выполнить вызов. Администратор должен убедиться, что сервер запущен до того, как любой клиент попытается подключиться к серверу. Если в систему добавлен новый сервис или интерфейс, клиент не сможет его обнаружить. Наконец, объектно-ориентированные языки ожидают полиморфизма в вызовах функций, то есть функции разных типов данных должны вести себя по-разному, и это как раз то, что традиционный RPC не поддерживает.
CORBA (Common Object Request Broker Architecture) предназначена для решения проблем, упомянутых выше. Это стандартная объектно-ориентированная спецификация прикладной системы, сформулированная организацией OMG. Другими словами, архитектура CORBA представляет собой решение, предложенное Группой управления объектами (OMG) для решения проблемы взаимосвязи аппаратных и программных систем в среде распределенной обработки (DCE). OMG была основана в 1989 году как некоммерческая организация, специализирующаяся на разработке технических характеристик взаимосвязей программного обеспечения, которые являются технически совершенными, коммерчески жизнеспособными и независимыми от производителей, продвигают технологию объектно-ориентированных моделей и улучшают переносимость программного обеспечения. (Переносимость), возможность повторного использования (Повторное использование) и совместимость (Совместимость). В начале организации ее членами были Unisys, Sun, Cannon, Hewlett-Packard, Philips и другие известные производители программного и аппаратного обеспечения. В настоящее время в организации насчитывается более 800 членов.
Основное содержание системы CORBA включает в себя следующие части:
Когда клиент делает запрос, ORB делает следующее:
IDL (язык определения интерфейса) используется для указания имени, атрибутов и методов класса. Он не содержит реализацию объекта. Компилятор IDL генерирует код для обработки сортировки, распаковки и взаимодействия между ORB и сетью. Он генерирует клиентские и серверные заглушки. IDL не зависит от языка программирования и поддерживает такие языки, как C, C ++, Java, Perl, Python, Ada, COBOL, Smalltalk, Objective C и LISP. Пример IDL выглядит так:
Типы данных IDL включают в себя:
Наиболее распространенной реализацией в программировании является реализация запросов через ссылки на объекты. Вот пример использования IDL:
В спецификации CORBA прямо не указано, что продукты промежуточного программного обеспечения разных поставщиков должны реализовывать все сервисные функции и позволять вендорам разрабатывать свои собственные типы сервисов. Поэтому продукты ORB разных производителей имеют разные возможности поддержки для услуг CORBA, поэтому у нас больше возможностей при выборе продуктов промежуточного программного обеспечения для функций разрабатываемой системы.
Недостатками CORBA являются:
Подробнее о преимуществах и недостатках CORBA вы можете обратиться к Мичи Хеннинг «The rise and fall of CORBA》。
Java RMI
Целью CORBA является предоставление полного набора услуг для управления объектами в разнородных средах (разные языки, операционные системы, сети). Изначально Java поддерживала только распределенную связь через сокеты. В 1995 году, как создатель Java, Sun начала создавать расширение Java под названием Java RMI (Remote Method Invocation). Java RMI позволяет программистам вызывать методы удаленных объектов из других виртуальных машин Java (JVM) при создании распределенных приложений.
Как только приложение (клиент) ссылается на удаленный объект, вы можете сделать удаленный вызов. Это делается для поиска удаленного объекта через службу имен (реестр RMI), предоставляемую RMI для получения ссылки в качестве возвращаемого значения. Java RMI по своей концепции похож на RPC, но может поддерживать семантику объектных вызовов в разных адресных пространствах.
В отличие от большинства других систем RPC, таких как CORBA, RMI поддерживает только построение на основе Java, но именно по этой причине RMI более аккуратен для языка и не требует дополнительной сериализации данных. Цели разработки Java RMI должны быть:
Распределенная объектная модель похожа на нативную объектную модель Java в:
Интерфейсы и классы
Все удаленные интерфейсы наследуются от java.rmi.Remote Интерфейс. Например:
Класс удаленного объекта
Java.rmi.server.RemoteObject Класс обеспечивает семантику реализации удаленного объекта, включая hashCode, equals и toString. java.rmi.server.RemoteServer А его подклассы обеспечивают удаленную видимость объектов. java.rmi.server.UnicastRemoteObject Класс определяет непосредственное соединение между клиентом и экземпляром объекта сервера.
Java RMI работает путем создания функций-заглушек. Заглушка генерируется компилятором rmic. Начиная с Java 1.5, Java поддерживает динамическую генерацию классов-заглушек во время выполнения. Компилятор rmic предоставляет различные варианты компиляции.
Сервис имен начальной загрузки предоставляет ссылку на именование для хранения удаленных объектов. Ссылка на удаленный объект может быть сохранена с использованием класса java.rmi.Naming Предоставлен метод на основе URL. Например,
Рисунок 7 Рабочий процесс Java RMI
Для выполнения вышеуказанных шагов вам необходимо выполнить следующие шаги:
Рисунок 8 Архитектура Java RMI
RMI распределенная сборка мусора
Согласно принципу механизма сборки мусора виртуальной машины Java, в распределенной среде серверный процесс должен знать, на какие объекты больше не ссылается клиент, и что он может быть удален (сборка мусора). В JVM Java использует подсчет ссылок. Когда счетчик ссылок вернется к нулю, объект будет собирать мусор. В RMI Java поддерживает две операции: грязную и чистую. Локальная JVM периодически отправляет грязный на сервер, чтобы указать, что объект все еще используется. Период периодически повторяющейся грязной передачи определяется временем аренды сервера. Когда клиенту не нужны дополнительные локальные ссылки на удаленный объект, он отправляет чистый запрос на сервер. В отличие от DCOM, серверу не нужно вычислять объекты, используемые каждым клиентом, а просто выполняет уведомление. Если он не получает грязных или чистых сообщений до истечения срока аренды, он может организовать удаление объекта.
RPC третьего поколения и веб-сервисы
Веб-дизайн ориентирован на контент. Разбор и отображение часто являются громоздкими. Традиционные решения RPC могут работать в Интернете, но проблема заключается в том, что они часто сильно зависят от динамического распределения портов и часто требуют дополнительной настройки брандмауэра.
Веб-службы становятся набором протоколов, позволяющих публиковать, обнаруживать и использовать службы в независимой от технологии форме. То есть сервисы не должны зависеть от языка, операционной системы или архитектуры клиента.
Реализация веб-сервисов обычно использует веб-сервер в качестве конвейера запроса сервиса. Сначала клиент обращается к службе, отправляя запрос на веб-сервер на сервере по протоколу HTTP. Конфигурация веб-сервера распознает часть имени пути или суффикса имени файла URL-адреса и передает запрос определенному подключаемому модулю браузера. Этот модуль может удалять заголовки, анализировать данные (при необходимости) и вызывать другие функции или модули по мере необходимости. Типичным примером этого потока реализации является поддержка браузером Java-сервлетов. HTTP-запрос будет перенаправлен на серверный код, выполняемый на JVM для выполнения обработки.
XML-RPC
XML-RPC использовался в качестве протокола обмена сообщениями RPC в 1998 году для анализа и анализа запросов и ответов в удобочитаемом формате XML. Формат XML основан на протоколе HTTP, который устраняет проблему, связанную с тем, что традиционным корпоративным брандмауэрам необходимо открывать дополнительные порты для приложений сервера RPC.
Ниже приведен пример сообщения XML-RPC:
В этом примере метод sumAndDifference имеет два целочисленных параметра 5 и 3.
Основные типы данных, поддерживаемые XML-RPC: int, string, boolean, double и dateTime.iso8601. Кроме того, существуют типы base64 для кодирования произвольных двоичных данных. массив и структура позволяют определять массивы и структуры.
XML-RPC не ограничен каким-либо конкретным языком и не является полным набором программного обеспечения для обработки удаленных процессов, таких как создание заглушек, управление объектами и поиск служб, которые не входят в протокол. Существует множество библиотек, предназначенных для разных языков, например, Apache XML-RPC можно использовать в Java, Python и Perl.
SOAP (Simple Object Access Protocol) основан на спецификации XML-RPC в качестве основы для создания SOAP, был создан в 1998 году и получил серьезную поддержку со стороны Microsoft и IBM. Этот протокол использовался только в качестве протокола доступа к объектам на ранних этапах его создания, однако из-за разработки SOAP его протокол использовался не только для простого доступа к объектам, поэтому аббревиатура SOAP была отменена после стандартной версии 1.2. Версия 1.2 стала рекомендуемой версией W3C 24 июня 2003 года. SOAP определяет XML как формат обмена сообщениями без сохранения состояния, включая вызовы процедур в стиле RPC.
Для стандартов SOAP, пожалуйста, обратитесь кhttps://www.w3.org/TR/soap/。
Вот простой пример:
среди Это корневой узел в сообщении SOAP и необходимая часть сообщения SOAP. Это необязательная часть сообщения SOAP, которая ссылается на заголовок сообщения. Это необходимая часть в SOAP и относится к телу сообщения.
Структура сообщения SOAP в приведенном выше примере выглядит следующим образом:
Рисунок 9 Структура сообщения SOAP
Документ WSDL включает в себя следующие части:
Ниже приведен пример WSDL версии 2.0:
.NET Remoting предоставляет платформу, которая позволяет объекту взаимодействовать с другим объектом через домен приложения. Эта структура предоставляет множество услуг, включая поддержку активации и срока службы, а также канал связи, отвечающий за передачу сообщений с удаленными приложениями. Форматер используется для кодирования и декодирования сообщений перед их передачей по каналу. Приложения могут использовать двоичное кодирование, где важна производительность, и XML-кодирование, когда им нужно взаимодействовать с другими средами удаленной обработки. При передаче сообщений из одного домена приложения в другой вся кодировка XML использует протокол SOAP. По соображениям безопасности удаленная обработка обеспечивает большое количество перехватов, поэтому перед передачей потока сообщений по каналу защищенный получатель может получить доступ к сообщению и сериализовать поток.
.NET Remoting объект
Для Marshal By Value (MBV) при передаче между приложениями создается полная копия.
Вот код клиента для доступа к этому объекту:
У объекта есть фаза аренды по умолчанию. Когда клиент хочет сохранить состояние в том же объекте сервера, существует много способов продлить фазу аренды, чтобы сохранить объект живым:
.NET Remoting объекты могут быть интегрированы в:
Ниже приведен пример файла Remoting.cfg:
Служба канала (System.Runtime.Remoting.Channels)
Используя пользовательские каналы, которые можно записывать в интегрированные гибридные приложения, можно подключать службы каналов (используя IChannel).
Ниже приведен пример загрузки службы канала:
Форматер сериализации (System.Runtime.Serialization.Formatters)
Внедрив интерфейс IRemotingFormatter и вставив его в канал, описанный выше, вы можете вставить модуль форматирования сериализации. Таким образом, вы можете гибко выбирать комбинацию канала и форматера и принимать наиболее подходящее решение для приложения.
Например: Вы можете использовать канал HTTP и двоичный форматер (сериализовать двоичные данные), или вы можете использовать канал TCP и формат SOAP.
Когда объект в одном контексте вызывает объект в другом контексте, вызов будет выполняться прокси-сервером контекста и будет зависеть от стратегии применения объединенных атрибутов контекста. Контекст нового объекта обычно выбирается на основе атрибутов метаданных класса.
Классы, которые могут быть связаны с контекстом, называются классами, привязанными к контексту. Класс привязки контекста может иметь специальные пользовательские атрибуты, называемые атрибутами контекста. Атрибуты контекста полностью расширяемы, вы можете создавать эти атрибуты и прикреплять их к своему классу. Объекты, связанные с контекстом, взяты из System.ContextBoundObject Экспорт.
Клиент может получить информацию метаданных, необходимую для доступа к объекту Remoting, следующими способами:
Типичный файл конфигурации содержит следующую информацию и другую информацию:
Ниже приведен пример файла конфигурации:
Использовать канал SOAP-HTTP
Использовать канал TCP
По умолчанию канал TCP использует двоичный форматер. Этот форматтер сериализует данные в двоичном формате и использует исходный сокет для передачи данных по сети. Этот метод идеален, если объект развернут в закрытой среде, защищенной брандмауэром. Этот метод использует сокеты для передачи двоичных данных между объектами, поэтому производительность превосходна. Поскольку он использует каналы TCP для предоставления объектов, он имеет преимущество в виде низких издержек в закрытой среде. Из-за проблем с брандмауэром и конфигурацией этот метод не следует использовать в Интернете.
Используйте неуправляемые компоненты COM
Веб-сервисы XML в Java
Создать конечную точку RPC
На стороне сервера выполните следующие шаги для создания конечной точки RPC:
Процесс выполнения JAX-RPC выглядит следующим образом:
Рисунок 12 Процесс вызова JAX-WS
Помимо МЫЛА
Хотя SOAP все еще широко используется, многие поставщики отказались от SOAP во многих средах и обратились к другим механизмам, которые легче, понятнее или имеют более четкую модель взаимодействия с Интернетом. Например, API Google больше не поддерживает интерфейс SOAP после 2006 года, но использует AJAX, XML-RPC и REST в качестве альтернативы. Анонимный сотрудник Microsoft критиковал SOAP за то, что он слишком сложен, потому что «мы хотим, чтобы его читали наши инструменты, а не люди». Независимо от точности вышеприведенных замечаний, одно можно сказать наверняка, SOAP, очевидно, является сложным и очень многословным форматом.
Первоначальный дизайн веб-браузера должен был обеспечить нединамическую модель взаимодействия для веб-страниц. Веб-браузеры построены на модели взаимодействия синхронизированного запроса-ответа (request-response). Отправьте запрос на сервер, и сервер вернет всю страницу. В то время не было никакого хорошего способа обновить некоторые страницы, и единственным возможным способом было использование фреймов, то есть загрузка различных страниц в каждый фрейм. Его реализация была громоздкой и очень ограничительной. Ключевые факторы, которые изменили все это:
AJAX играет важную роль в продвижении Web 2.0, например, в создании многих высокоинтерактивных сервисов, таких как Google Maps и Writely. По сути, он позволяет JavaScript делать HTTP-запросы, получать и обрабатывать результаты, а также обновлять частичные элементы страницы вместо всей страницы. Формат, запрашиваемый в большинстве браузеров, выглядит следующим образом:
SOAP основан на HTTP при создании собственного протокола обмена сообщениями, но на самом деле метод REST (REpresentational State Transfer) является основной частью поддержания принципов Интернета и использования протокола HTTP.
Исходный протокол HTTP определил четыре команды, четко сопоставленные с различными операциями с данными (определяемыми как «ресурсы»):
Идея REST состоит в том, чтобы использовать эти HTTP-команды для запроса и манипулирования данными. Как часть протокола HTTP, REST использует URL-адреса для ссылки на объекты и операции. Рассмотрим пример списка операций HTTP:
Эта команда вернет XML-документ с частичным списком. Обратите внимание, что возвращается не веб-страница, а структура данных XML, которая содержит запрошенные данные.
Для получения подробной информации о конкретной детали отправьте HTTP-команду get:
Это вернет определенный раздел информации:
Обратите внимание, что приведенный выше пример упрощает partid как параметр URL. Например:
REST не является RPC, но существует аналогичный шаблон запроса-ответа. Создание запросов на прозрачность, сбор данных и анализ ответов не являются REST. Широко используются REST, такие как Yahoo! Search API, Ruby on Rails, Twiter и Open Zing Services.
Буферы протокола Google: маршалинг
Обратите внимание, что это определяет только структуру данных, а не функцию. Примеры использования этой структуры:
Даже по сравнению с компактной версией XML, буферные протоколы будут более эффективными с точки зрения времени и пространства. Ниже приведено сравнение двух.
Это некомпилированный формат протокола Buffers:
Двоичные сообщения, генерируемые протокольными буферами, имеют длину около 28 байт, а разбор занимает около 100-200 нс. Напротив, версия XML требует 69 байтов (в 2,5 раза больше буферов протокола) и занимает 5000-10000 нс (в 50 раз больше буферов протокола).