В итоге мы внедрили фреймворк, использующий mq-коммуникацию, чтобы справиться с этим. каждый «пакетный узел» регистрирует себя и любые параметры «пакетного класса», такие как «nodeType = A» или «jobSizeiCanHandle = BIG» (это вымышленные, но вы понимаете, в чем суть). Клиентская консоль считывает эту информацию и запрашивает узлы через MQ для получения списка заданий. Затем он отправляет запросы на задание с параметрами через простой текстовый протокол (формат файла свойств).
command=START_JOB
job=JobABC
param1=x
param2=y
Один из пакетных узлов заберет сообщение и начнет задание, он вернет статус успеха / сбоя таким же образом с сообщением с тем же идентификатором корреляции. так что клиент может показать ответ пользователю.
это позволяет нам делать то, о чем вы говорите, и запускать задания через внешний планировщик (Control-M). Упомянутый выше «nodeType = A» позволяет нам запрашивать отдельные узлы (узлы прослушивают, где «nodeType = A или nodeType = *». Это позволяет командам «ориентироваться» на конкретные узлы, если это необходимо.
Имейте в виду, что это наша собственная консоль, а не консоль администрирования Spring Batch. Так что, возможно, это вам не поможет, но создание простой консоли не займет так много времени с использованием API пакетного режима (4 или 5 осин).
Пакетные узлы также могли запускать простые сервисы, такие как HTTP REST-сервисы или «что угодно», но мы интенсивно используем MQ, и мне понравилась идея отсутствия предварительной регистрации узлов (код фреймворка не знает / не заботится о том, что он находится в контейнер HTTP, поэтому он не может легко зарегистрировать конечную точку). В MQ канал предварительно настроен, и все приложения просто «используют его», так что это кажется проще.
Удачи.