Как предоставлять услуги OSGi для каждого клиента

Мы разрабатываем веб-приложение (назовем его банком изображений) для чего мы определили следующие потребности:

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

Вопрос: Должны ли мы строить это на стандартной платформе OSGi или лучше использовать одну из новых платформ приложений (Virgo, Aries или будущий стандарт OSGi)?

Дополнительные сведения и некоторые начальные мысли:

Мы создаем веб-приложение, которое, как мы предполагаем, скоро будет иметь сотни клиентов (компаний) с сотнями пользователей (сотрудников) в каждой, иначе зачем беспокоиться;). Мы хотим сделать его модульным, следовательно, OSGi. В будущем клиенты могут сами разрабатывать и встраивать компоненты в свои приложения, поэтому нам потребуется изоляция клиентов. Мы также можем захотеть, чтобы разные клиенты получали разные наборы функций.

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

Мы могли бы использовать подход сервер-приложение (мы рассмотрели Virgo) и загрузить каждый объединить один раз для каждого клиента в его собственное «приложение». Однако это не похоже на принятие OSGi. Мы не размещаем множество приложений, 99% сервисов будут использовать один и тот же имп. для всех клиентов. Также мы хотим управлять (настраивать, контролировать и т. Д.) Приложением как единым целым.

Каждую услугу можно зарегистрировать (правильно настроить) один раз для каждого клиента вместе с некоторым свойством «токен клиента». Это немного запутано и должно быть обработано с помощью шаблона расширения или, возможно, ManagedServiceFactory? Также перед регистрацией услуги для клиента A необходимо будет приобрести A-версию каждой из его зависимостей.

«Текущий» клиент будет известен каждому запросу и может быть привязан к потоку.Это немного беспорядок, когда нужно предоставлять токен клиента каждый раз, когда вы ищете услугу. Это затрудняет использование компонентных фреймворков, таких как blueprint. Чтобы обойти проблему, мы могли бы использовать служебные перехватчики для прокси-сервера каждого зарегистрированного типа службы и позволить прокси-серверу отправляться в нужный экземпляр в соответствии с текущим клиентом (потоком).

Начало всего нашего опыта работы с OSGi с реализации обходного пути (взлома?), Описанного выше, действительно кажется указанием на то, что мы на ложном пути. так что нам делать? Вернуться к Деве? Попробуйте что-то похожее на то, что описано выше? Что-то совсем другое ?!

пс. Спасибо, что дочитали до конца! ;)