Я думаю, что если бы это был я, я бы определенно использовал очереди сообщений для связи между этими сервисами, хотя JRuby действительно является хорошим выбором и для внешнего интерфейса (я думаю, что большинство гемов на данный момент довольно совместимы, даже с собственными расширениями.) В конечном счете, вы можете использовать элементы обоих подходов.
То, о чем вы говорите, - это довольно типичная настройка SOA, и это одна из замечательных особенностей SOA - вы можете использовать разные языки и платформы там, где они работают лучше всего. Попытка использовать clojure в настройке jruby-on-rails может привести к большим страданиям и страданиям, и IIRC воспользуется некоторыми преимуществами использования clojure в первую очередь.
К сожалению, у меня нет каких-либо военных историй, которые бы точно соответствовали тому, что вы пытаетесь сделать, но я сейчас нахожусь в середине такой архитектуры, и она отлично работает, используя RabbitMQ, чтобы позволить MRI 1.9 поговорите с работниками бэкэнда под управлением JRuby. Не знаю, как вы будете использовать сообщения в ближайшем будущем, но я думаю, что где-то должны быть документы, и вы сможете поддерживать чистое разделение. Если бы вы запускали свой клиентский интерфейс на jruby, вы все равно можете обмениваться кодом между процессом jruby и серверным интерфейсом clojure без необходимости помещать их в один и тот же процесс.