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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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