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

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

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

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

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

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

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

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

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

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

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

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

Полное раскрытие: я веду проект Девы.