Каковы хорошие альтернативы для связи между локальными программами C ++ и Java? - PullRequest
9 голосов
/ 12 октября 2010

Под «локальным» я подразумеваю, что оба работают в одной подсети, в большинстве случаев на одном хосте / ВМ, поэтому некоторые стандартные межплатформенные межплатформенные механизмы RPC, такие как SOAP, XML-RPC, CORBA и т. Д., Кажутся ненужными.

Полезная нагрузка состоит в основном из числовых (в основном табличных) данных с небольшим количеством метаданных (например, доступные службы данных, описание / тип данных и т. Д.) Из C ++ в Java и событиями пользовательского интерфейса консоли / сценария изJava для C ++.Таким образом, программа на C ++ действует как сервер, а программа на Java - как клиент.

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

  1. Общая память
  2. Pipe, stdin / stdout,и т. д.
  3. Пользовательская структура данных через обычный сокет (возможно, UDP) ( этот вопрос )
  4. Сообщения через простой сокет, могут быть буфером протокола Google, Thrift, JSON и т. д.. ( этот ответ , среди прочих)
  5. Java RMI с сервером C ++ RMI ( этот вопрос )
  6. JNI (некоторые ответы в этот вопрос )

Я почти уверен, что пропустил много вариантов.Спасибо всем за помощь!


Отредактировано: я забыл упомянуть, что производительность не является серьезной проблемой, поскольку ожидается, что пропускная способность не будет большой (сервер сильно привязан к базе данных), но этоБыло бы важно знать, если один из вариантов будет намного быстрее или медленнее.Например, я полагаю, что ничто не сравнится с разделяемой памятью (если все сделано правильно).

Ответы [ 2 ]

4 голосов
/ 12 октября 2010

Опции 3 и 4 используются в реальных тяжелых условиях.

Опции 1,2,6 не достигают другого хоста.

Возможно, вариант 5 слишком проблематичен дляне на стороне Java.

Я бы выбрал вариант 4, потому что вариант 3 слишком низкоуровневый (если вариант 4 не окажется слишком медленным).Выберите свой любимый кроссплатформенный легкий протокол обмена сообщениями из перечисленных вами.Все они «проверены в бою» и имеют библиотеки для большинства языков.

1 голос
/ 12 октября 2010

Я бы пошел с вариантом 4. Я бы пропустил 5. 2 было бы неуклюже.

Мы говорим о передаче чисел в виде простого текста, да?

...