Добрый день. Возник следующий вопрос : необходимо реализовать удаленный интерфейс.
т.е. дан интерфейс
class foo
{
public:
virtual void do_some() = 0;
}
необходимо реализовать имплементацию этого интерфейса таким образом что бы функция do_some() выполнялась на удаленной машине.
Не подскажете, может быть существуют готовые классы или библиотеки реализующие этот принцип (желательно кроссплатформенные и не особо тяжеловесные)?
Здравствуйте, AlexDoberman, Вы писали:
AD>Добрый день. Возник следующий вопрос : необходимо реализовать удаленный интерфейс.
AD>необходимо реализовать имплементацию этого интерфейса таким образом что бы функция do_some() выполнялась на удаленной машине. AD>Не подскажете, может быть существуют готовые классы или библиотеки реализующие этот принцип (желательно кроссплатформенные и не особо тяжеловесные)?
Есть несколько разных RPC для С++, я бы начал с ProtoBufRemote на гугловском ProtoBuf или с Boost.RPC на Boost::Serialization. На Boost::Serialization легко делать сериализацию объектов, но сама Boost.RPС ещё в boost не включена.
Но ИМХО без нормальной рефлексии по настоящему удобного решения не сделать. Может лучше сделать интероп с каким-нибудь Пиотоном и уже использовать скриптовые возможности по RPC?
M>Есть несколько разных RPC для С++, я бы начал с ProtoBufRemote на гугловском ProtoBuf или с Boost.RPC на Boost::Serialization. На Boost::Serialization легко делать сериализацию объектов, но сама Boost.RPС ещё в boost не включена.
Спасибо за ссылки. Посмотрю.
M>Но ИМХО без нормальной рефлексии по настоящему удобного решения не сделать. Может лучше сделать интероп с каким-нибудь Пиотоном и уже использовать скриптовые возможности по RPC?
не совсем понял идею. У скриптовых языков есть более простые методы работы с RPC ?
Здравствуйте, AlexDoberman, Вы писали:
M>>Но ИМХО без нормальной рефлексии по настоящему удобного решения не сделать. Может лучше сделать интероп с каким-нибудь Пиотоном и уже использовать скриптовые возможности по RPC? AD>не совсем понял идею. У скриптовых языков есть более простые методы работы с RPC ?
Здравствуйте, Mazay, Вы писали:
AD>>необходимо реализовать имплементацию этого интерфейса таким образом что бы функция do_some() выполнялась на удаленной машине. AD>>Не подскажете, может быть существуют готовые классы или библиотеки реализующие этот принцип (желательно кроссплатформенные и не особо тяжеловесные)?
M>Есть несколько разных RPC для С++, я бы начал с ProtoBufRemote на гугловском ProtoBuf или с Boost.RPC на Boost::Serialization. На Boost::Serialization легко делать сериализацию объектов, но сама Boost.RPС ещё в boost не включена.
M>Но ИМХО без нормальной рефлексии по настоящему удобного решения не сделать. Может лучше сделать интероп с каким-нибудь Пиотоном и уже использовать скриптовые возможности по RPC?
Че это не сделать? Я делал.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
On 06/14/2012 11:17 AM, AlexDoberman wrote:
> Не подскажете, может быть существуют готовые классы или библиотеки реализующие > этот принцип (желательно кроссплатформенные и не особо тяжеловесные)?
CORBA.
Из реализаций посоветую OMNIOrb. Живой, поддерживается, развивается, работает.
Если будут тут говорить, что типа CORBA -- окаменелое говно мамонта,
тяжеловесное, и всё такое прочеее -- не верь, это всё туфта голимая.
Если тебе не нужны всякие WEB-хренеб сервисы и прочая мутотень, а нужно
именно удалённый интерфейс реализовать -- CORBA достаточно проста и понятна.
И главное — производительна.
А, ну да, можно и SOAP. Недостатки (по сравнению с CORBA) -- накладуха на
передачу данных, ОГРОМНАЯ (но чаще всего всем насрать), достоинства --
вожделенное хождение по публичным IP сетям.
gSOAP уже платный, порекомендовал бы его. Что ещё -- не знаю.
On 06/14/2012 01:01 PM, Хон Гильдон wrote:
> M>Но ИМХО без нормальной рефлексии по настоящему удобного решения не сделать. > > Че это не сделать? Я делал. > На улицах злая гопота, в офисах злые гомосеки.
Здравствуйте, MasterZiv, Вы писали:
>> M>Но ИМХО без нормальной рефлексии по настоящему удобного решения не сделать. >> >> Че это не сделать? Я делал.
MZ>А я не понял эту сентенцию.
Я имел в виду, что и без нормальной рефлексии можно залудить вполне удобный RPC. Шаблоны плюс макросы, и все получится.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
On 06/14/2012 01:35 PM, Хон Гильдон wrote:
>> > M>Но ИМХО без нормальной рефлексии по настоящему удобного решения не сделать. >> > >> > Че это не сделать? Я делал. > > MZ>А я не понял эту сентенцию. > > Я имел в виду, что и без нормальной рефлексии можно залудить вполне удобный RPC. > Шаблоны плюс макросы, и все получится.
ЭТО я понял. Я не понял изначальную идею автора, что это нельзя сделать.
Можно, нужны метаданные только (как обычно и делается ВЕЗДЕ, начиная DCOM-ом
кончая WSDL-ем).
Здравствуйте, AlexDoberman, Вы писали:
AD>необходимо реализовать имплементацию этого интерфейса таким образом что бы функция do_some() выполнялась на удаленной машине. AD>Не подскажете, может быть существуют готовые классы или библиотеки реализующие этот принцип (желательно кроссплатформенные и не особо тяжеловесные)?
Если производительность особо не критична, посмотрите на SOAP. Это протокол удаленного вызова процедур (RPC), который использует XML в качестве формата для представления данных и HTTP в качестве транспорта. Существует куча реализаций, для разных языков и платформ.
Здравствуйте, Mazay, Вы писали:
M>Но ИМХО без нормальной рефлексии по настоящему удобного решения не сделать. Может лучше сделать интероп с каким-нибудь Пиотоном и уже использовать скриптовые возможности по RPC?
Отсутствие рефлексии в одинаковой степени мешает сделать как удобный RPC, так и удобный биндинг к динамически типизованным языкам.
Здравствуйте, MasterZiv, Вы писали:
MZ>Если будут тут говорить, что типа CORBA -- окаменелое говно мамонта, MZ>тяжеловесное, и всё такое прочеее -- не верь, это всё туфта голимая. MZ>Если тебе не нужны всякие WEB-хренеб сервисы и прочая мутотень, а нужно MZ>именно удалённый интерфейс реализовать -- CORBA достаточно проста и понятна. MZ>И главное — производительна.
По-моему, последнее место, где CORBA жила в дикой природе — это был линуксный дектоп. Но линух ушел с корбы на d-bus, и у корбы не осталось естественной среды обитания. Теперь она встречается только в заповедниках и зоопарках.
On 06/14/2012 02:21 PM, Pzz wrote:
> По-моему, последнее место, где CORBA жила в дикой природе — это был линуксный > дектоп. Но линух ушел с корбы на d-bus, и у корбы не осталось естественной среды > обитания. Теперь она встречается только в заповедниках и зоопарках.
Почитай список пользователей OMNIOrb, там у них немало приложений разных.
Здравствуйте, MasterZiv, Вы писали:
MZ>ЭТО я понял. Я не понял изначальную идею автора, что это нельзя сделать. MZ>Можно, нужны метаданные только (как обычно и делается ВЕЗДЕ, начиная DCOM-ом MZ>кончая WSDL-ем).
Кстати, генерацию wsdl'я из шаблонов и макросов моего RPC я тоже делал. Пришлось, правда, boost::serialization слегка допиливать и вообще оно в продакшен не пошло, но при желании вполне реализуемо.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Pzz, Вы писали:
AD>>необходимо реализовать имплементацию этого интерфейса таким образом что бы функция do_some() выполнялась на удаленной машине. AD>>Не подскажете, может быть существуют готовые классы или библиотеки реализующие этот принцип (желательно кроссплатформенные и не особо тяжеловесные)?
Pzz>Если производительность особо не критична, посмотрите на SOAP. Это протокол удаленного вызова процедур (RPC), который использует XML в качестве формата для представления данных и HTTP в качестве транспорта. Существует куча реализаций, для разных языков и платформ.
SOAP — УГ, как и большинство универсальных всемогутеров. И вообще в нем буква O лишняя. Если не нужна совместимость со всякими там джавами, то лучше придумать свой протокол — тот, который из логики кода сам собой выкуется. А если надо с вебом скрещивать, то, опять же, удобнее без лишних прокладок json какой-нибудь на гора гнать. Все, естественно, IMHO.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
> SOAP — УГ, как и большинство универсальных всемогутеров. И вообще в нем буква O > лишняя. Если не нужна совместимость со всякими там джавами, то лучше придумать
Кстати, впервые сслышу вообще где-то что-то критическое про SOAP.
Обычто все "ОООоо ! SOAP!" — и чуть ли не кончают тут же.
Ну собственно-то особо плохого ничего в нём и нет,
только медленное (ну накладуха огромная) и недоделанное (собственно,
как оно на сервер идёт -- никого вообще не метёт).
Для УЭБ конечно пойдёт -- всяко лучше голого HTML.
>> SOAP — УГ, как и большинство универсальных всемогутеров. И вообще в нем буква O >> лишняя. Если не нужна совместимость со всякими там джавами, то лучше придумать
MZ>Кстати, впервые сслышу вообще где-то что-то критическое про SOAP. MZ>Обычто все "ОООоо ! SOAP!" — и чуть ли не кончают тут же.
MZ>Ну собственно-то особо плохого ничего в нём и нет, MZ>только медленное (ну накладуха огромная) и недоделанное (собственно, MZ>как оно на сервер идёт -- никого вообще не метёт). MZ>Для УЭБ конечно пойдёт -- всяко лучше голого HTML.
У меня к нему претензии простые — нафига оно вообще нужно простому человеку? Ну то есть единственное преимущество, которое я там заметил — это можно автоматом сгенерить жабовские вропперы. Смысла в этом лично для меня было не много. Потроха руками набивать, прямой поддержки версионности я при беглом знакомстве не обнаружил. Объектность только в названии, привязать хэндл экземпляра объекта к вызову — строго руками, никакого this обнаружить не удалось. Совместимость между разными имплементациями в части сложных структур данных (ну там вектор пар хотя бы) не блещет. Т.е., и жабского и шарпского клиентов одновременно сделать вроде бы можно, но потрахаешься вволю. Ну и вообще все достаточно глюкавое и на промышленный стандарт тянет слабо. Да и переусложненое, TinyXml'ем, например, просто так не распарсишь — неймспейсы понимать требуется. Это по состоянию 5 лет назад. Может чего уже исправили, может за давностью лет сам что путаю. Хотя вроде наоборот, какие-то видные жабоводы заявляли, что SOAP это уже тупиковый путь и потенциально мертвая технология.
То ли дело голый JSON. На клиенте жабаскриптом распарсить вообще не проблема, на сервере формировать тоже как два пальца.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, MasterZiv, Вы писали:
MZ>ЭТО я понял. Я не понял изначальную идею автора, что это нельзя сделать. MZ>Можно, нужны метаданные только (как обычно и делается ВЕЗДЕ, начиная DCOM-ом MZ>кончая WSDL-ем).
Рефлексия нужна чтобы эти метаданные руками не прописывать.
Здравствуйте, Pzz, Вы писали:
M>>Но ИМХО без нормальной рефлексии по настоящему удобного решения не сделать. Может лучше сделать интероп с каким-нибудь Пиотоном и уже использовать скриптовые возможности по RPC?
Pzz>Отсутствие рефлексии в одинаковой степени мешает сделать как удобный RPC, так и удобный биндинг к динамически типизованным языкам.
Вот именно — геморрой практически одинаковый. Только Boost.Python и питонский xmlrpclib это вполне зрелые библиотеки, в отличие от ProtoBufRemote и Boost.RPС. Кроме того, почти за те же деньги кроме RPC получаешь ещё кучу других питонских библиотек. По-моему вполне может оказаться лучшим вариантом.
Здравствуйте, Хон Гильдон, Вы писали:
M>>Но ИМХО без нормальной рефлексии по настоящему удобного решения не сделать. Может лучше сделать интероп с каким-нибудь Пиотоном и уже использовать скриптовые возможности по RPC?
ХГ>Че это не сделать? Я делал.
Здравствуйте, Mazay, Вы писали:
M>>>Но ИМХО без нормальной рефлексии по настоящему удобного решения не сделать. Может лучше сделать интероп с каким-нибудь Пиотоном и уже использовать скриптовые возможности по RPC?
ХГ>>Че это не сделать? Я делал.
M>Покажи пример использования.
Что конкретно фи? Прототип функции все равно описываешь, что для RPC, что для простого использования. В втором случае надо написать лишнее слово и несколько запятых и скобок. Будет рабочий decltype — возможно, от этого получится избавиться.
Перечислить, какие методы выставлять в RPC, по любому придется. Хотя атрибуты выставлять, хоть, как у меня, в список загнать, но придется.
Еще у меня указывается, из каких "интерфейсов" собирать "класс" (как в DCOM) — ну, если не нравится, можно и без этого обойтись. Мне нравится, потому что позволяет обойти ограничение буст-препроцессора на 25 методов.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, MasterZiv, Вы писали:
>> У меня к нему претензии простые — нафига оно вообще нужно простому человеку? Ну
MZ>Это смотря какие системы пишешь.
А для каких нужно?
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, AlexDoberman, Вы писали:
AD>Добрый день. Возник следующий вопрос : необходимо реализовать удаленный интерфейс. AD>т.е. дан интерфейс
AD>необходимо реализовать имплементацию этого интерфейса таким образом что бы функция do_some() выполнялась на удаленной машине. AD>Не подскажете, может быть существуют готовые классы или библиотеки реализующие этот принцип (желательно кроссплатформенные и не особо тяжеловесные)?
Здравствуйте, Аноним, Вы писали:
А>Apache Thrift
А>Плюсы — простой, быстрый. А>Минусы — нет асинхронных вызовов (по крайней мере не было год назад, когда последний раз с ним работал)
В Thrift’е есть асинхронные вызовы, см. ключевое слово oneway. Нет callback’ов.