Может ли сервер приложений Java (WebLogic) управлять собственным исполняемым файлом?

Question

Возможно ли (... прекрасно понимая, что это безумие и серьезно опрометчиво ...) иметь приложение J2EE, работающее на сервере приложений Java (в настоящее время использующее weblogic), и запускать собственный исполняемый процесс, используется и остановлен как часть жизненного цикла этого Java-приложения?(Примечание: это , а не JNI, на самом деле это отдельный нативный процесс. Это unix / linux, но также должен запускаться в Windows.) Я не нашел никаких документов по этой теме - и по уважительной причине, вероятно.

Предыстория: На самом деле нативный процесс - это некий монолитный сторонний программный пакет, который не может быть взломан, и нет никакого другого API, кроме stdin / stdout.Java-приложение требует собственного приложения для выполнения определенных услуг.Я могу легко обернуть собственный процесс через ProcessBuilder и запустить / остановить и общаться с ним (используя stdin / stdout).Для целей тестирования у меня есть простой exe (C ++), который общается через stdin / stdout и может получать «start», «shutdown» и выполняет простой «echo» сервис.(«Start» не работает, но просто возвращает «ok», если собственный процесс успешно запущен.)

Таким образом, в идеале, когда сервер приложений запускается / выключается и / или развернутая Javaприложение запускается / выключается, связанный с ним собственный процесс также может быть запущен / выключен.И в идеале это может происходить чисто и надежно (никаких затяжных процессов после выключения, все сбои запуска регистрируются, проблемы с синхронизацией жизненного цикла синхронизируются).

Если это действительно сработало, тогда «часть 2» вопроса будетэто может на самом деле работать в среде кластера / отработки отказа.Собственный процесс может быть привязан к платформе и специализированной службе мониторинга и управления, но я бы хотел, чтобы все связывалось и управлялось с приложением Java, если это возможно.

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

I 'Я пытаюсь собрать доказательство концепции, но любой четкий ответ «да, я сделал это» или «нет, это не сработает» будет высоко ценится и очень сэкономит время (с поддержкой ссылок на документы, если они у вас есть).

Редактировать: просто чтобы уточнить (тема может вводить в заблуждение): также запущено значительное Java-приложение (которое я написал и могу свободно изменять по мере необходимости);сторонний собственный процесс просто выполняет сервис, который требуется приложению Java.Я не просто пытаюсь управлять собственным процессом через сервер приложений.

Answer 1

Ответ на часть 1 - да, абсолютно возможно, чтобы сервер приложений Java управлял собственным системным процессом.Похоже, вы в значительной степени поняли это для себя, если вы думаете об использовании ProcessBuilder для запуска внешней программы и взаимодействия с ней.Это в значительной степени способ сделать это.

В прошлом я использовал именно такую ​​настройку для реализации службы транскодирования мультимедиа поверх сервера Java (сервер Java порождал задания перекодирования через процессы ffmpeg, отслеживая их состояние и отчитываясь перед остальнымизаявление об успехе / неудаче / и т.д.).Насколько четко все это можно сделать, зависит от того, как вы его реализуете, и от поведения вашего внешнего приложения (то есть гарантированно ли оно изящно и быстро отвечает на запрос на отключение?), Но это будет очень трудно (если не невозможно)получить это совершенно идеально.Как минимум, если кто-то выполняет kill -9 на вашем Java-серверном процессе, вы не сможете изящно завершить работу собственного процесса, по крайней мере, до тех пор, пока сервер не будет перезапущен и вы не увидите, что собственный процесс уже запущен.

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

Служба транскодирования, которую я реализовал, работала в кластерной среде (используя JBoss / Tomcat), и она работала так, что когда запрашивалось задание транскодирования, отправлялось сообщение.Это сообщение будет получено координирующим классом, который будет управлять очередью запросов на перекодировку, порождая задания, когда рабочие процессы становятся доступными.Состояние очереди реплицировалось по всему кластеру, поэтому, если узел, на котором выполняются процессы ffmpeg, вышел из строя, текущие запланированные задания будут запомнены, а затем возобновлены, как только подходящий узел снова станет доступным (служба перекодировки была настроена так, чтоможет быть включен / отключен для каждого узла).На практике система оказалась достаточно надежной.