RPC — кто чем пользуется?

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

У меня недавно была задачка — обернуть один достаточно тяжеловесный алгоритм в онлайновый сервис. Я использовал ICE, т.к. когда-то довольно активно использовал CORBA для подобных вещей. Все работает (причем превосходно), но стало интересно -, а чем вообще сейчас пользуются для RPC? Кто-то использует, например, Google Protocol Buffers (и с каким сервером?), или Facebook Thrift? Какие еще есть варианты? Плагин для веб-сервера + REST? Мои ограничения — алгоритмы все написаны на С/С++, очень прожорливы по памяти, и должны хранить свое состояние. Поделитесь опытом.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

For ex. WSO2/PHP автоматически генерит сервис из класса, в нем уже и делаете проверки

Мы писали нечто подобное для CORBA: www.gradsoft.ua/...broker_rus.html (активно эксплуатируется).
В принципе модуль apache написать не очень сложно. Но для этого надо либо протокол свести к http либо самому
протокол хандлер написать. Непонятно есть ли смысл: в IceBox все это и так уже есть.

А модуль на базе веб-сервера имеет смысл только если протокол поверх http.

WebServices на базе вебсервера,.NET Remoting на базе протоколов, ну еще DCOM кому как нравится

Вероятно, я не совсем верно сформулировал задачу. Уточню — вопрос не в протоколе (json/xml/protobuf/etc), а в том, как с минимальными усилиями обернуть монолитный объект в сервис. Может, кто-то, например, писал модуль для apache или там nginx — только как сделать, чтобы у нас был загружен ровно один экземпляр такого модуля, и он жил ровно столько, сколько запущен сам веб сервер? Какие еще есть варианты? Для того же protobuf есть разные RPC Add-ons, но вот на базе веб-сервера, как ни странно, ничего нет, да и вообще, непонятно, насколько это все годится для серьезной эксплуатации.

Часто просто json-а хватает.

это да, но мне казалось что поддерживать Java, С# приложение проще чем С++, а если все проблемное с точки зрения производительности и памяти собрано в С++ коде, то завернуть его как Dll, а далее работать с более простым и высокоуровневым языком... хотя все зависит от контекста задачи

по проще — взять что-то готовое типа Java или C# и от туда вызывать С++ код?

А зачем? на C++ и так море всякого готового.

если это он-лайн, то почему бы не высунуть мордочку ввиду веб-сервиса? ,
а реализация по желанию, либо в С++ коде слушать порт и парсить запросы и формировать ответы — наверное самый быстрый и эфективный способ,

по проще — взять что-то готовое типа Java или C# и от туда вызывать С++ код?

Підписатись на коментарі