Совместимость с Java и C #

У меня есть две программы. Один в C #, а другой в Java. Эти программы, скорее всего, всегда будут работать на одной машине.

Как лучше всего позволить им разговаривать друг с другом?

Итак, для выяснения проблемы:

Это личный проект (поэтому профессиональные / дорогостоящие библиотеки не нужны). Громкость сообщений мала, от 1 до 2 сообщений в секунду. Сообщения небольшие, несколько примитивных типов должны сделать свое дело. Я хотел бы сохранить сложность на низком уровне. Java-приложение развернуто как один jar-файл как плагин для другого приложения. Поэтому чем меньше внешних библиотек мне нужно объединить, тем лучше. У меня есть полный контроль над приложением C #. Как было сказано ранее, оба приложения должны работать на одном компьютере. Прямо сейчас, мое решение было бы использовать сокеты с чем-то вроде csv-подобного формата.

19.08.2008 18:31:32
Есть связанное обсуждение о совместимости CLR / JVM.
Anderson Green 1.05.2016 17:25:51
9 ОТВЕТОВ

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

1
19.08.2008 18:34:19

Я использовал JNBridge ( http://www.jnbridge.com/jnbpro.htm ) в относительно простом проекте, где у нас было клиентское приложение .NET, использующее относительно значительный файл JAR, полный логики бизнес-объектов, которую мы не хотели переносить , Это сработало довольно хорошо, но я бы не сказал, что мы полностью использовали возможности JNBridge.

3
19.08.2008 18:35:04

Я слышал хорошие вещи об IKVM , JVM, который сделан с .NET.

7
19.08.2008 18:41:12
недавно мы использовали IKVM для связи между Java-сервером и C # UI. Протокол связи был RMI, с которым IKVM справился очень хорошо.
Matt 22.09.2008 21:00:50

Ice от ZeroC - это действительно высокопроизводительный уровень взаимодействия между предприятиями, который поддерживает Java и .net среди других. Я думаю о нем как об обновленном Corba - у него даже есть свой собственный объектно-ориентированный язык определения интерфейса, называемый Slice (как IDL Corba, но на самом деле вполне читаемый).

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

4
19.08.2008 19:32:30

Кайл имеет правильный подход в вопросе о взаимодействии. Не существует «правильного» ответа, не зная, какие модели использования могут быть.

Любое архитектурное решение - особенно на этом уровне - это компромисс.

Вы должны спросить себя:

  • Какие сообщения необходимо передавать между системами?
  • Какими типами данных нужно поделиться?
  • Есть ли важное требование для поддержки сложных объектов модели, или это будут делать примитивы + массивы?
  • какой объем данных?
  • Как часто будут происходить взаимодействия?
  • Какова допустимая задержка связи?

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

9
19.08.2008 20:16:50
Хотя Cheekysoft абсолютно прав, я думаю, вам лучше всего использовать XML поверх сокетов и привязку объекта к XML в Java (JAXB) и C # (инструмент определения схемы XML). См .: stackoverflow.com/questions/765422/jaxb-equivalent-in-c
Carsten 16.11.2009 05:30:33

Я понимаю, что вы говорите о программах на одной машине, но мне всегда нравилась идея передачи сообщений в XML через HTTP.

Ваш сервер может быть веб-сервером, готовым принять полезную нагрузку XML. Ваш клиент может отправлять HTTP-сообщения с XML в теле и получать HTTP-ответ с XML в нем.

Одна из причин, по которой мне это нравится, заключается в том, что HTTP является настолько широко используемым протоколом, что его легко принимать или создавать запросы HTTP POST или GET на любом языке (в случае, если в будущем вы решите изменить язык клиента или сервера). HTTP и XML существуют уже давно, поэтому я думаю, что они здесь, чтобы остаться.

Еще одна причина, по которой мне нравится это то, что ваш сервер может использоваться другими клиентами, если они знают HTTP и XML.

4
24.11.2009 00:45:57
Мне было бы очень интересно услышать о пропускной способности в этом подходе. Моя первоначальная мысль при чтении этого состояла в том, что это будет возможно только для небольших полезных нагрузок просто из-за накладных расходов, связанных с сборкой и разборкой XML и помещением его в сообщение http.
Thorbjørn Ravn Andersen 16.11.2009 03:30:58

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

Однако, если у вас есть только две отдельные программы, но вы хотите запустить их как одно приложение, то, я думаю, IKVM - лучший подход, предложенный marxidad.

0
26.08.2008 08:01:59

Я являюсь автором jni4net , межпроцессного моста с открытым исходным кодом между JVM и CLR. Он построен на основе JNI и PInvoke. Код C / C ++ не требуется. Я надеюсь, что это поможет вам.

19
31.10.2009 18:37:10

Похоже, что очень похожий вопрос был задан здесь ранее при переполнении стека (я искал в Google общую память java для Windows):

Эффективная передача данных с Java на C ++ в Windows

Из ответа я бы предложил вам разобраться:

«Самым быстрым решением будет отображение памяти в разделяемом сегменте памяти, и они реализуют кольцевой буфер или другой механизм передачи сообщений. В C ++ это прямо, а в Java у вас есть метод FileChannel.map, который делает это возможным».

0
23.05.2017 10:29:37