Комментарии 20
REST != CRUD. CRUD — это только паттерн управления ресурсами, а REST — это очень широкий архитектурный подход к проектирования API, который позволяет целиком перенести состояние системы в запрос.
RPC технологии — наиболее старые технологии. Наиболее яркие представители RPC, это — CORBA и DCOM.
Вы, наверное, можете сказать, что они ранние. RPC цветет и пахнет сейчас. CORBA и DCOM — не наиболее яркие предствители. Thrift, Produbuf с новым gRPC. Все вполне актуально…
Детали реализации и принципиальные отличия распределенных систем были слишком велики, чтобы решаться с помощью автоматически генерируемого кода. Постепенно пришло понимание, что факт того, что системы связывает ненадежная, медленная, низкоскоростная среда, должен быть явно отражен в коде программы.
Я не могу проследить тут логику. Кодогенерация RPC имплентацию за вас не сделает. Реализация транспорта (ненадежная, медленная, низкоскоростная среда) может быть отделена от сгенерированного кода и вообще не является проблемой присущей только RPC.
Как именно помогает с этим Messaging?.. Чем контракты веб-сервисов с конвертами (видимо, подразумевается SOAP с его Envelope) отличется от контрактов (API) в RPC?
Я не могу проследить тут логику. Кодогенерация RPC имплентацию за вас не сделает. Реализация транспорта (ненадежная, медленная, низкоскоростная среда) может быть отделена от сгенерированного кода и вообще не является проблемой присущей только RPC.
Как именно помогает с этим Messaging?..
RPC предпочтительно синхронен (и гарантированно точка-точка). Messaging изначально асинхронен, не требует точка-точка, не требует ответа, позволяет легко добавить гарантированную доставку, маршрутизацию, обработку ошибок и так далее.
Cинхронность RPC в настоящее время никак не предпочтительна. Насчет отличий Messaging, которые Вы приводите, согласен. Но Ваше (и мое) понятие этого термина существенно отличается от того, что приводится в этой статье.
C картинки Messaging описывается как:
В пример приводятся веб-сервисы, контракты и тд…
C картинки Messaging описывается как:
Response GetPerson(Request request)
В пример приводятся веб-сервисы, контракты и тд…
Cинхронность RPC в настоящее время никак не предпочтительна.
… только в языках, которые умеют нативные асинхронные вызовы. Иначе уже не RPC получается.
Но Ваше (и мое) понятие этого термина существенно отличается от того, что приводится в этой статье.
К статье у меня вопросов на отдельный комментарий.
Response GetPerson(Request request)Это не messaging, это (семантически) тот же RPC, просто с другими типами данных. Честный messaging — это:
void Send(Message msg);
...
class GetPersonRequest: Message
{
Guid PersonId;
}
У вас сложилась модель, в которой RPC — Messaging ложится на термины synchronous — asynchronous. В моей модели такой явной связи нет. Но я не претендую на истину. Я видел рассуждения, подтверждающие вашу мысль. Думаю в этом что-то есть.
«Это не messaging, это (семантически) тот же RPC, просто с другими типами данных.»
Да, вы правы. Я именно об этом и говорил.
«Это не messaging, это (семантически) тот же RPC, просто с другими типами данных.»
Да, вы правы. Я именно об этом и говорил.
У вас сложилась модель, в которой RPC — Messaging ложится на термины synchronous — asynchronous. В моей модели такой явной связи нет. Но я не претендую на истину. Я видел рассуждения, подтверждающие вашу мысль. Думаю в этом что-то есть.
Вызов процедур в большей части языков синхронен, поэтому RPC исторически синхронная парадигма. Messaging — точно так же исторически — асинхронная.
Да, вы правы. Я именно об этом и говорил.
О чем?
Спасибо за дискуссию!
По новым RPC я полностью согласен! Пойду текст подправлю. Как же у меня из головы ProtoBuf выскочил.
По «автоматически генерируемый код», я имел в виду генерацию Proxy и Dispatcher. Надо тоже текст уточнить. Спасибо!
По новым RPC я полностью согласен! Пойду текст подправлю. Как же у меня из головы ProtoBuf выскочил.
По «автоматически генерируемый код», я имел в виду генерацию Proxy и Dispatcher. Надо тоже текст уточнить. Спасибо!
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.
Куда вы сунете AMQP, на котором при необходимости можно сделать RPC?
Для кода, который вызывает
Наглядная демонстрация того, что это всего лишь подходы, и одно при необходимости конвертируется в другое.
response = fibonacci_rpc.call(30) — это RPC, потому что для него это синхронный блокирующий вызов (и транспорт для него не имеет значения). Для кода FibonacciRpcClient, который явным образом взамодействует с очередями, сообщениями и корреляцией, это типичный messaging.Наглядная демонстрация того, что это всего лишь подходы, и одно при необходимости конвертируется в другое.
Хороший вопрос. Я бы его расширил: Куда деть очереди (queues)?
Хмм… Думаю, что этот термин используют все три типа, RPC, Messaging, REST. REST — меньшей степени (?)
Хмм… Думаю, что этот термин используют все три типа, RPC, Messaging, REST. REST — меньшей степени (?)
А чем подход, использующий очереди, отличается от подхода, использующего сообщения? Как вообще, по вашему, передаются сообщения?
Сообщения можно передать синхронно и асинхронно. Очереди можно использовать, а можно и не использовать. На самом деле очереди используются на многих реализациях транспортных протоколов. Если и не явным образом (без пользовательского доступа), то в конкретных реализациях очереди очень часто присутствуют.
Здесь я рассуждаю о терминологии application layer, хотя явно и не говорю об этом. Очереди присутствуют на разный layers, к примеру транспорт может быть целиком сделан на очередях (MSMQ, MQ). Но я здесь не об этом. Я тупо о том, какие термины всплывают в каком контексте. Грубо определил три контектса. Грубо раскидал термины по ним. Никто не определял эти контектсы с научной, непротиворечивой точки зрения.
Здесь я рассуждаю о терминологии application layer, хотя явно и не говорю об этом. Очереди присутствуют на разный layers, к примеру транспорт может быть целиком сделан на очередях (MSMQ, MQ). Но я здесь не об этом. Я тупо о том, какие термины всплывают в каком контексте. Грубо определил три контектса. Грубо раскидал термины по ним. Никто не определял эти контектсы с научной, непротиворечивой точки зрения.
Я тупо о том, какие термины всплывают в каком контексте. Грубо определил три контектса. Грубо раскидал термины по ним. Никто не определял эти контектсы с научной, непротиворечивой точки зрения.
Если у вас (терминологически) неверно определены контексты, то любое последующее терминологическое разделение бессмысленно.
(не говоря уже о том, что я вообще не понимаю, зачем вам нужно раскидывать термины по контекстам, учитывая, что каждый термин обозначает конкретное явление, и есть оно в контексте, или нет — вопрос не терминологический, а бытийный)
На картинке в REST: «POST = Update», «PUT = Create». Разве не наоборот «POST = Create», «PUT = Update»?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
RPC, Messaging, REST: Терминология