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

голоса
23

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

Что бы лучший способ позволить им общаться друг с другом?

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

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

Задан 19/08/2008 в 19:31
источник пользователем
На других языках...                            


9 ответов

голоса
16

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

Ответил 31/10/2009 в 19:37
источник пользователем

голоса
9

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

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

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

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

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

Ответил 19/08/2008 в 21:16
источник пользователем

голоса
7

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

Ответил 19/08/2008 в 19:41
источник пользователем

голоса
4

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

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

Ответил 19/08/2008 в 20:32
источник пользователем

голоса
3

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

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

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

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

Ответил 20/08/2008 в 03:19
источник пользователем

голоса
3

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

Ответил 19/08/2008 в 19:35
источник пользователем

голоса
1

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

Ответил 19/08/2008 в 19:34
источник пользователем

голоса
0

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

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

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

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

Ответил 16/11/2009 в 04:34
источник пользователем

голоса
0

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

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

Ответил 26/08/2008 в 09:01
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more