Самый простой RPC в Java и C ++ - PullRequest
3 голосов
/ 14 марта 2011

Я ищу очень простой способ разрешить RPC между приложениями Java и C ++.

Моя система содержит несколько модулей Java и один модуль C ++.У меня не так много разных процедур для вызова (около 2-3 на модуль), и они не сильно изменятся (за исключением некоторых незначительных изменений, таких как добавление новой процедуры или изменение своего прототипа).Я пишу все модули, чтобы я мог использовать все, что захочу.Кроме того, все модули должны выполняться на одном и том же компьютере, за исключением одного, но возможность выполнения некоторых из них на другом компьютере без особых хлопот (в основном просто путем изменения файла конфигурации) была бы плюсом.

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

В данный момент я пытаюсь использовать RPC через сокеты TCP, поскольку я не хочу использовать ни RMI, ни примитивы Unix (нет стандартной реализации на Java и нетсетевые возможности).Я написал очень простой протокол RPC: через фрейм TCP вы даете сериализованное имя вызываемого метода, а затем сериализованный список аргументов.На стороне сервера он прослушивает объект и использует отражение для выполнения данного метода.В случае ошибки возвращаемый объект является DistantRPCError, инкапсулирующим ошибку.

Код очень прост (всего около 100 лок) и может использоваться в самых разных ситуациях (я работаю с потоками, поэтому я даже не зависим от сокетов).Проблема, с которой я сталкиваюсь, заключается в том, что я не могу тестировать свой код статически (простая инициализация локального теста длиннее, чем тестируемый код), и я не могу понять, насколько сложно будет реализовать его в C ++ (используя JNI для сериализации, Я полагаю).

Итак, мой вопрос: знаете ли вы о другом способе выполнения вызовов RPC как в Java, так и в C ++, который действительно прост (поэтому нет RMI) и которому можно доверять (я неЯ ищу что-то особенное, я хочу что-то стандартное и проверенное промышленностью.Кроме того, у меня есть некоторые ограничения по производительности (машина - недорогой компьютер, и у меня много криптологии, которую можно выполнять локально).И, как я уже сказал, большинство модулей (за исключением одного или двух) выполняются локально, поэтому меня также интересуют механизмы IPC (даже если было бы неплохо иметь только один механизм RPC для всех моих модулей).

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

Редактировать: Я, вероятно, буду использовать SOAP, так как не вижу особого интереса к использованию ORB для моей конкретной проблемы.Спасибо за идею!

Ответы [ 2 ]

4 голосов
/ 14 марта 2011

Я не знаю, будет ли один из них соответствовать вашим критериям простоты, но я бы сказал, что ваши две лучшие ставки - это что-то старое - CORBA - и что-то новое - веб-сервисы.

CORBA приходит на умпотому что совместная работа распределенных компонентов, написанных на разных языках, была частью ее вдохновения, но это не просто.Рынок также проголосовал против CORBA.Я бы сказал, что он достиг своего пика в начале и середине 90-х годов и с тех пор снижается.Я не очень много слышу о CORBA, для чего она стоит.

Веб-сервисы, особенно если вы отказываетесь от SOAP и переходите на REST, работаете по HTTP и относительно просты.Я не вижу никаких преимуществ в разработке и поддержке вашего собственного проводного протокола.Я бы использовал HTTP и придерживался REST.

2 голосов
/ 24 марта 2011

Просто чтобы вы знали, я, наконец, решил использовать MessagePack для всех моих RPC, суть в том, что он очень прост в использовании, с открытым исходным кодом (с небольшой базой кода) и прекрасно работает.

Недостатки: нет никаких комментариев вообще для java lib, но, как я уже сказал, это открытый исходный код с небольшой базой кода и простой архитектурой, поэтому проблем нетпонимание того, как это работает.

Также существует множество различных версий для Java-библиотек (которые могут означать нестабильный API, но я не буду обновлять библиотеку, когда система будет завершена, поэтомуне проблема), и я не смог скомпилировать библиотеку C ++ для Windows (что на самом деле не проблема для меня, поскольку я использую ее в Linux).

...