Как я могу вызвать метод в объекте вне JVM?

Question

У меня действительно простой Java-класс, который эффективно декорирует Map с проверкой входных данных с помощью очевидных методов void set () и String get ().

Я хотел бы иметь возможность эффективно вызывать эти методы и обрабатывать возвращаемые значения и исключения извне JVM, но все же на той же машине Обновление: вызывающий я имею в виду не другой JVM; спасибо @Dave Ray

Мои соображения по реализации типичны

• производительности
• Простота внедрения и обслуживания (простота?)
• надежность
• гибкость (т.е. я могу позвонить с удаленного компьютера и т. Д.)

Есть ли «правильный путь»? Если нет, каковы мои варианты, и каковы плюсы / минусы для каждого?

(Вещи, которые люди действительно сделали и могут предоставить реальную обратную связь, было бы здорово!)

Answer 1

Хорошо. Вот еще одна попытка, теперь я знаю, что клиент не Java. Так как вам нужен внепроцессный доступ и, возможно, удаленный доступ к компьютеру, я не думаю, что JNI - это то, что вам нужно, поскольку это строго внутрипроцессный (и полный хлопот). Вот еще несколько вариантов:

Raw Sockets : просто настройте сокет слушателя в Java и принимайте соединения. Когда вы получите соединение, прочитайте запрос и отправьте ответ. Почти каждый язык может использовать сокеты, так что это довольно универсальное решение. Однако вам придется определить собственную схему сортировки, разбора и т. Д.

XML-RPC : в наши дни это не так модно, но просто и эффективно. Существуют библиотеки Java , а также библиотеки на большинстве других языков.

CORBA : как уже упоминалось выше, CORBA является вариантом, но он довольно сложный, и экспертам становится все труднее найти.

Веб-сервер : настройте встроенный веб-сервер в вашем приложении и обрабатывайте запросы. Я слышал хорошие новости о Jetty или вы можете использовать , поставляемый с Java . Я успешно использовал последний для отправки файлов KML в Google Earth из симуляции, написанной на Java. Большинство других языков имеют библиотеки для выполнения HTTP-запросов. Как вы кодируете данные (XML, текст и т. Д.), Зависит от вас.

Веб-сервисы : Я думаю, это было бы более сложно, но вы могли бы использовать JAX-WS , чтобы представить ваши объекты как веб-сервисы. В NetBeans есть довольно хорошие инструменты для создания веб-служб, но это может быть излишним.

Answer 2

Будете ли вы звонить из другой системы на основе JVM, или язык клиента произвольный? Если вы звоните из другой JVM, один из самых простых подходов - представить ваш объект как MBean через JMX. Канонический Hello World MBean показан здесь . Плюсы:

• Действительно легко реализовать
• Действительно легко звонить с других JVM
• Поддержка удаленных машин
• jconsole позволяет вручную протестировать MBean без написания клиента

Минусы:

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

Answer 3

Поскольку ваш абонент не основан на JVM, это вопрос межпроцессного взаимодействия с JVM. Варианты, которые я имею в виду:

1. Общение через сокет: заставьте JVM прослушивать входящие соединения и отправлять команды вызывающему абоненту
2. Общение с использованием общих файлов (запись звонящего в файл, опросы JVM и обновления)
3. Используя JNI, запустите JVM внутри процесса вызывающей стороны, а затем используйте RMI / MBeans для связи с первой («серверной») JVM. Абонент будет иметь доступ к результатам, используя JNI

Вариант 3 IMO - это наиболее "Java" способ сделать это, и он наиболее сложен / подвержен ошибкам. Вариант 2 уродлив, но прост Вариант 1 умеренно простой (часть Java), а в остальном все в порядке.

Answer 4

Поскольку ваши абоненты не являются Java-приложениями, и вы уже предвидите сетевые абоненты, RMI-IIOP (CORBA) может быть вариантом. Хотя это, безусловно, нелегко реализовать, оно имеет преимущество в том, что является широко признанным стандартом.

Answer 5

Для простоты использования я бы использовал Spring Remoting . Если вы уже используете Spring в своем проекте, это не сложно. Если вы не ... ну, вы все равно должны посмотреть.

Spring предоставляет абстракцию, которая позволяет легко переключать протоколы удаленного взаимодействия. Он поддерживает наиболее распространенные протоколы (SOAP, Hessian, Burlap, RMI, ...). Если вы звоните из не Java-кода, Hessian имеет поддержку на ряде других языков, известно, что он более эффективен, чем SOAP, и проще, чем CORBA.

Answer 6

Beanshell - это подобный оболочке Java-интерпретатор, который может быть открыт через сетевой сокет. В основном вы делаете это из Java:

i = new bsh.Interpreter();
i.set( "myapp", this );  // Provide a reference to your app
i.eval("server(7000)");

и затем вы делаете это из любого другого места:

telnet localhost 7001
myapp.someMethod();

Эта маленькая утилита делает удаленные вызовы Java намного проще, чем когда-либо были JNI или RMI.

Более подробно, начните с: http://www.beanshell.org/manual/remotemode.html

Answer 7

Альтернативой CORBA является ICE , если только лицензия не является проблемой (это GPL, но вы также можете купить коммерческую лицензию).

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

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

В противном случае, другой вариант, о котором я не упомянул, - это новая инфраструктура промежуточного программного обеспечения / RPC, разработанная Cisco, которая теперь передана Apache и называется Etch . Это все еще довольно новое, и документация скудна.

Answer 8

Еще одна альтернатива, чтобы рассмотреть, будет ли другой процесс на той же машине, и ОС совместима с POSIX (не Windows), это Named Pipes.

Внешний процесс записывает операции в виде строк или некоторого другого согласованного байтового кодирования в именованный канал, пока приложение Java читает из канала, анализирует входящие операции и выполняет их для вашего объекта.

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

Answer 9

Вам нужен собственный интерфейс Java (JNI), несмотря на трудности, которые он может представлять. Не существует другой эквивалентной технологии, которую было бы так легко внедрить.

Как уже упоминалось в комментариях к предыдущему ответу, JNI оптимизирован для вызова нативного кода из Java, но его также можно использовать для обратной работы с небольшой работой. В вашем нативном коде вам нужно реализовать точку входа JNI - что-то вроде SetMapPointer () - затем вызвать эту функцию из кода Java, как только будет построена карта. Реализация SetMapPointer () должна сохранить указатель на объект Java где-нибудь доступным, тогда нативный код может вызывать методы Java для него по мере необходимости.

Вам нужно убедиться, что это происходит в правильном порядке (т. Е. Собственный код не пытается получить доступ к карте до того, как он был собран и передан в собственный код), но это не должно быть особенно сложным проблема.

Answer 10

У меня есть скрипт Inno Setup (установка программы Java), который вызывает некоторые методы Java для выполнения некоторых операций или проверки некоторых условий.
Я (фактически мой предшественник) просто создаю java.exe при каждом вызове. Что, очевидно, является дорогостоящим, хотя и не критичным в моем случае (и, я полагаю, включается кэш Windows).

Альтернативой является использование межязыкового общения / обмена сообщениями, ваша Java-программа выступает в качестве сервера. Корба приходит на ум, так как он не зависит от языка. Но немного тяжелым, возможно. Вы можете использовать сокеты. RPC - еще одно модное слово, но у меня мало опыта в этой области.