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

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

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

Итак, чтобы прояснить проблему:

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

Ответов (9)

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

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

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

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

Из ответа я предлагаю вам изучить:

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

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

Я слышал хорошие отзывы о IKVM , JVM, созданной с помощью .NET.

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

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

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

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

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

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

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

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

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

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

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

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

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