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

Question

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

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

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

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

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

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

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

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

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

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

пс. Спасибо, что прочитали все здесь! ;)

Answer 1

У решения есть пара аспектов:

Прежде всего, вам нужно найти способ настройки различных ваших клиентов.Построение решения поверх ConfigurationAdmin имеет смысл, поскольку тогда вы сможете максимально использовать существующий стандарт OSGi.Причина, по которой вы можете захотеть построить что-то поверх, состоит в том, что ConfigurationAdmin позволяет вам настраивать каждую отдельную службу, но вы можете добавить слой сверху, чтобы вам было удобнее конфигурировать все ваше приложение (сборку пакетов) за один раз.Такая конфигурация затем может быть преобразована в отдельные конфигурации сервисов.

Добавление свойства в сервисы, которые имеют специфичные для клиента реализации, имеет большой смысл.Вы можете настроить их, используя ManagedServiceFactory, а свойство облегчает поиск службы для нужного клиента с помощью фильтра.Вы даже можете определить запасной сценарий, в котором вы будете искать специфичную для клиента услугу или общую (потому что не все услуги, вероятно, будут привязаны к конкретному клиенту).Поскольку вам необходимо явно добавить такие фильтры в ваши зависимости, я бы порекомендовал взять существующее решение для управления зависимостями и расширить его для вашего конкретного случая использования, чтобы зависимости автоматически добавляли нужные фильтры, специфичные для клиента, без необходимости указывать это вручную.Я понимаю, что мне, возможно, придется более подробно остановиться здесь, просто дайте мне знать ...

Следующий вопрос заключается в том, как отслеживать «контекст» клиента в вашем приложении.Традиционно здесь есть только несколько вариантов, причем локальный контекст потока является наиболее используемым.Привязка потоков к клиентам имеет тенденцию ограничивать вас с точки зрения вариантов реализации, хотя в целом это, вероятно, означает, что вы должны запретить разработчикам создавать сами потоки, и трудно разгрузить определенные задачи в пулы рабочих потоков.Ситуация становится еще хуже, если вы когда-нибудь решите использовать удаленные службы, поскольку это означает, что вы полностью потеряете контекст.

Итак, для передачи идентификации клиента из одного компонента в другой я лично предпочитаю решение, в котором:

1. Как только поступит запрос (например, в вашем HTTP-сервлете), каким-либо образом определите идентификатор клиента.
2. Явно передайте этот идентификатор по цепочке служебных зависимостей.
3. Используйте только такие решения, как использование локальных потоков в границах одного пакета, если, например, вы используете стороннюю библиотеку внутри своего пакета, которая нуждается в этом для отслеживания клиента.

Answer 2

Обратите внимание, что Virgo - это контейнер OSGi, основанный на Equinox, поэтому, если вы не хотите использовать какую-либо особенность Virgo, вам не нужно.Однако вы получите множество преимуществ , если будете использовать Virgo даже для базового приложения OSGi.Однако это звучит так, как будто вам нужна веб-поддержка, которая поставляется из коробки с веб-сервером Virgo и избавит вас от необходимости объединять ее вместе.

Полное раскрытие: я возглавляю проект Virgo.

Answer 3

Я уже давно думаю об этой же проблеме (думаю) и хотел бы узнать ваше мнение о следующей аналогии.

Рассмотрим серию веб-приложений, в которых вы предоставляете контроль доступа с использованиеминфраструктура единого входа (SSO).Пользователь аутентифицируется один раз, используя SSO-сервер, и - когда поступает запрос - целевое веб-приложение спрашивает сервер SSO, аутентифицирован ли пользователь (все еще), и определяет себя, авторизован ли пользователь.Информация об авторизации также может быть предоставлена ​​сервером единого входа.

Теперь представьте, что ваши пакеты приложений являются мини-приложениями.Хотя они не являются веб-приложениями, не имеет ли смысла иметь какой-то пакет единого входа, использующий методы единого входа для аутентификации и предоставления информации об авторизации?Каждый пакет приложений должен быть разработан или настроен для использования пакета SSO для проверки подлинности (токен SSO) и проверки авторизации, запрашивая пакет SSO, разрешен ли пользователю доступ к этому пакету приложений.

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