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

 Пользователь не озабочен, потому что как вы писали "типично пользователь аплоадит jar через специальный сервис веб-приложения". Сервис скрывает от пользователя технические детали. Озабочен создатель этого сервиса. Вы ищете способ внедрить присланный код (непонятно, как с безопасностью) в ваше серверное веб-приложение "на лету". Но иначе как средствами плагинной архитектуры этого не сделать, т.е. веб-приложение должно иметь встроенный контейнер плагинов. Моя же фантазия была на основе присланного кода сгенерировать war и положить в webapps. Принцип "на лету" будет реализован. Стартует новое веб-приложение. По сути - новый сервис. Функциональность - это набор сервисов, SOA.  А сервисы могут базироваться как на одном веб-сервере так и на многих, в том числе и в "облаке".  



Очевидно, "пользователь" в широком смысле. Можно сказать, что плагины к Эклипсу пользователи пишут.  

Ок, это другое дело, мне почему-то вначале показалось, что вы предлагаете пользователям где-то у себя деплоить сервисы и оповещать мое приложение о них. Кстати, тогда мы становимся зависимы от конкретного веб сервера/сервера приложений, но это не суть важно, потому что, и так не получается реализовать все только в Java EE.
Спасибо, я подумаю, как можно это прикрутить у себя.

С безопасностью стало более менее понятно. Есть Java Security - общий механизм для контролируемого безопасного выполнения кода на уровне JVM.