Leo_Gan 4 авг 2015 в 23:18

RPC, Messaging, REST: Терминология

4 мин

86K

Комментарии 20

Meredian 5 авг 2015 в 05:08

REST != CRUD. CRUD — это только паттерн управления ресурсами, а REST — это очень широкий архитектурный подход к проектирования API, который позволяет целиком перенести состояние системы в запрос.

sndl 5 авг 2015 в 08:26

RPC технологии — наиболее старые технологии. Наиболее яркие представители RPC, это — CORBA и DCOM.

Вы, наверное, можете сказать, что они ранние. RPC цветет и пахнет сейчас. CORBA и DCOM — не наиболее яркие предствители. Thrift, Produbuf с новым gRPC. Все вполне актуально…

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

Я не могу проследить тут логику. Кодогенерация RPC имплентацию за вас не сделает. Реализация транспорта (ненадежная, медленная, низкоскоростная среда) может быть отделена от сгенерированного кода и вообще не является проблемой присущей только RPC.
Как именно помогает с этим Messaging?.. Чем контракты веб-сервисов с конвертами (видимо, подразумевается SOAP с его Envelope) отличется от контрактов (API) в RPC?

lair 5 авг 2015 в 09:02

Я не могу проследить тут логику. Кодогенерация RPC имплентацию за вас не сделает. Реализация транспорта (ненадежная, медленная, низкоскоростная среда) может быть отделена от сгенерированного кода и вообще не является проблемой присущей только RPC.
Как именно помогает с этим Messaging?..

RPC предпочтительно синхронен (и гарантированно точка-точка). Messaging изначально асинхронен, не требует точка-точка, не требует ответа, позволяет легко добавить гарантированную доставку, маршрутизацию, обработку ошибок и так далее.

sndl 5 авг 2015 в 09:30

Cинхронность RPC в настоящее время никак не предпочтительна. Насчет отличий Messaging, которые Вы приводите, согласен. Но Ваше (и мое) понятие этого термина существенно отличается от того, что приводится в этой статье.

C картинки Messaging описывается как:


Response GetPerson(Request request)

В пример приводятся веб-сервисы, контракты и тд…

lair 5 авг 2015 в 09:38

Cинхронность RPC в настоящее время никак не предпочтительна.

… только в языках, которые умеют нативные асинхронные вызовы. Иначе уже не RPC получается.

Но Ваше (и мое) понятие этого термина существенно отличается от того, что приводится в этой статье.

К статье у меня вопросов на отдельный комментарий.

Response GetPerson(Request request)

Это не messaging, это (семантически) тот же RPC, просто с другими типами данных. Честный messaging — это:

void Send(Message msg);
...
class GetPersonRequest: Message
{
  Guid PersonId;
}

Leo_Gan 5 авг 2015 в 15:36

У вас сложилась модель, в которой RPC — Messaging ложится на термины synchronous — asynchronous. В моей модели такой явной связи нет. Но я не претендую на истину. Я видел рассуждения, подтверждающие вашу мысль. Думаю в этом что-то есть.
«Это не messaging, это (семантически) тот же RPC, просто с другими типами данных.»
Да, вы правы. Я именно об этом и говорил.

lair 5 авг 2015 в 15:38

У вас сложилась модель, в которой RPC — Messaging ложится на термины synchronous — asynchronous. В моей модели такой явной связи нет. Но я не претендую на истину. Я видел рассуждения, подтверждающие вашу мысль. Думаю в этом что-то есть.

Вызов процедур в большей части языков синхронен, поэтому RPC исторически синхронная парадигма. Messaging — точно так же исторически — асинхронная.

Да, вы правы. Я именно об этом и говорил.

О чем?

Leo_Gan 5 авг 2015 в 15:21

Спасибо за дискуссию!
По новым RPC я полностью согласен! Пойду текст подправлю. Как же у меня из головы ProtoBuf выскочил.

По «автоматически генерируемый код», я имел в виду генерацию Proxy и Dispatcher. Надо тоже текст уточнить. Спасибо!

lair 5 авг 2015 в 09:00

RPC технологии

RPC — это не технология, это подход, характеризующийся «процедурностью» мышления — мы туда аргументы, нам оттуда результат. Желательно синхронно.

Поэтому вы не заметите, не должны заметить, никакой разницы между вызовом локальной функции и вызовом удаленной функции.

А это совершенно не обязательное свойство RPC. WCF — тоже RPC, но его дизайн прекрасно предполагает long-distance calls. Вообще, разница между локальным и удаленным — это дизайн API, а не технология или RPC-vs-messaging.

Messaging
[...]
Появились технологии веб-сервисов.

Давайте, опять-таки, не путать. Есть messaging, это интеграционный подход (см. Enteprise Integration Patterns); есть веб-сервисы, это группа технологий, которые могут реализовывать как RPC, так и messaging (и, скажем, WCF, пусть и веб-сервисы, в базовом виде предполагает именно RPC-стиль).

Не совсем понятно, почему появились контракты, которые по сути являются Envelope (конвертами) для входных аргументов.

Нет, контракты — это не конверты для входных аргументов. Контракт — это набор допустимых операций и данных в этих операциях (если шире — то еще предусловий, постусловий и инвариантов, но в распределенных вычислениях нас это не очень интересует). И именно поэтому, кстати, контракты чаще применяются к RPC-стилю, чем к messaging-стилю (потому что вот сообщение действительно чаще определяется схемой, нежели контрактом).

Сервис представлял из себя набор операций (Operation), каждая из которых на входе принимала запрос (Request) и выдавала ответ (Response). Клиент явным образом посылал (Sent) запрос, сервис явным образом получал (Receive) его и отвечал (Sent), высылая ответ. Клиент получал (Receive) ответ и на этом вызов завершался.

Вы c WCF или ASMX работали когда-нибудь?

Запросы и ответы явным образом преобразуются к формату, предназначенному для передачи по проводам.

Явным для кого? Если для программиста, то нет, я ни разу не видел адекватного messaging-решения, в котором бы была нужна явная сериализация, работа всегда идет с типизированным или хотя бы ключ-значение форматом.

Чаще всего это массив байт

Нет, понятно, что по проводам чаще всего передают массив байтов. Но вот утверждать, что это основной формат для messaging-решений я бы не стал. Как раз наоборот, messaging предполагает self-contained-сообщения, а для этого они должны быть легко понятны на промежуточных узлах, а это означает, что используются общеизвестные форматы. В период широкого расцвета этого добра использовался XML, сейчас тоже он используется, другое дело, что бесит всех адски.

Основной принцип REST в том, что операции-функции резко ограничили и оставили только набор операций CRUD: Create — Read — Update — Delete.

Нет, основной принцип REST в том, что состояние описано в униформном интерфейсе, предпочтительно — гипермедийном.

К примеру, вызов функции

EntityAddress ReadEntityAddress(string param1, string param2)

выразится в таком виде:

GET: entityAddress?param1=value1¶m2=value2

Это совершенно не обязательно REST. Более того, передача параметров в query string намекает нам, что это скорее всего не REST. А вот GET /entities/187/address — это, скорее всего, REST.

RPG18 5 авг 2015 в 15:45

Куда вы сунете AMQP, на котором при необходимости можно сделать RPC?

lair 5 авг 2015 в 15:51

Для кода, который вызывает response = fibonacci_rpc.call(30) — это RPC, потому что для него это синхронный блокирующий вызов (и транспорт для него не имеет значения). Для кода FibonacciRpcClient, который явным образом взамодействует с очередями, сообщениями и корреляцией, это типичный messaging.

Наглядная демонстрация того, что это всего лишь подходы, и одно при необходимости конвертируется в другое.

RPG18 5 авг 2015 в 16:02

потому что для него это синхронный блокирующий вызов

А вот это уже зависит от архитектуры и реализации.

lair 5 авг 2015 в 16:04

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

Leo_Gan 5 авг 2015 в 16:05

Хороший вопрос. Я бы его расширил: Куда деть очереди (queues)?
Хмм… Думаю, что этот термин используют все три типа, RPC, Messaging, REST. REST — меньшей степени (?)

lair 5 авг 2015 в 16:29

А чем подход, использующий очереди, отличается от подхода, использующего сообщения? Как вообще, по вашему, передаются сообщения?

Leo_Gan 5 авг 2015 в 16:38

Сообщения можно передать синхронно и асинхронно. Очереди можно использовать, а можно и не использовать. На самом деле очереди используются на многих реализациях транспортных протоколов. Если и не явным образом (без пользовательского доступа), то в конкретных реализациях очереди очень часто присутствуют.
Здесь я рассуждаю о терминологии application layer, хотя явно и не говорю об этом. Очереди присутствуют на разный layers, к примеру транспорт может быть целиком сделан на очередях (MSMQ, MQ). Но я здесь не об этом. Я тупо о том, какие термины всплывают в каком контексте. Грубо определил три контектса. Грубо раскидал термины по ним. Никто не определял эти контектсы с научной, непротиворечивой точки зрения.

lair 5 авг 2015 в 16:41

Я тупо о том, какие термины всплывают в каком контексте. Грубо определил три контектса. Грубо раскидал термины по ним. Никто не определял эти контектсы с научной, непротиворечивой точки зрения.

Если у вас (терминологически) неверно определены контексты, то любое последующее терминологическое разделение бессмысленно.

(не говоря уже о том, что я вообще не понимаю, зачем вам нужно раскидывать термины по контекстам, учитывая, что каждый термин обозначает конкретное явление, и есть оно в контексте, или нет — вопрос не терминологический, а бытийный)

Gaer 5 авг 2015 в 17:27

На картинке в REST: «POST = Update», «PUT = Create». Разве не наоборот «POST = Create», «PUT = Update»?

Leo_Gan 5 авг 2015 в 17:28

Вы правы. Явная ошибка.

lair 5 авг 2015 в 18:52

На самом деле, третьим образом. PUT может использоваться как для создания, так и для обновления, POST может использоваться для создания или выполнения произвольного действия, а для обновления еще может использоваться PATCH.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий