Справочник по C#

    Исходники по языку программирования CSharp

    Понимать концепции OSGi. Попытайтесь следовать подходу головоломки

    /
    /
    /
    22 Views

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

    Чтобы понять концепции OSGi, мы попытаемся следовать принципу головоломки, идея состоит в том, чтобы начать с тривиальной части этой технологии и искать другие части, связанные с найденными. И в сборке головоломки нам поможет JArchitect, который поможет обнаружить внутренний дизайн OSGi.

    Чтобы быть более конкретным, мы анализируем с помощью JArchitect приложение, использующее технологию OSGi, это касается знаменитой IDE eclipse, в которой используется равноденствие OSGi.

    Давайте начнем с типичного определения OSGi:

    OSGi снижает сложность, предоставляя модульную архитектуру для современных крупномасштабных распределенных систем, а также для небольших встроенных приложений. Сборка систем из собственных и готовых модулей значительно снижает сложность и, следовательно, затраты на разработку и обслуживание. Модель программирования OSGi реализует перспективы компонентных систем.

    Тривиальная часть OSGi – это модульность, давайте выясним, что такое модули OSGi?

    Модули OSGI называются комплектами, и поэтому каждое приложение состоит как минимум из одного комплекта.
    Эти пакеты выполняются внутри контейнера, и, поскольку каждый модульный подход, когда контейнер управляет модулями, вопрос в том, какой контракт должен реализовывать каждый модуль для интеграции в контейнер?

    Давайте возьмем в качестве примера пакет org.eclipse.equinox.jsp.jasper и ищем все его реализованные интерфейсы, для этого мы можем выполнить следующий запрос CQLinq:

    1
    2
    3
    4
    от T в Типы где
    т . Родительский проект . Имя == ” орг . затмение. равноденствие. JSP . Джаспер_1 . 0.300.v20110502
    пусть интерфейсы = т . InterfacesImplemented
    от я в выбор интерфейсов я

    Реализован интерфейс BundleActivator из пакета OSGi, который содержит два метода start и stop, полезных для настройки запуска и остановки пакета.

    Еще одной особенностью пакета является его файл манифеста, который является частью файла манифеста org.eclipse.equinox.jsp.jasper:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    МанифестВерсия : 1,0
    BundleЛокализация : плагин
    BundleRequiredExecutionEnvironment : CDC1.0 / Фонд1.0 , J2SE1.3
    BundleSymbolicName : орг. затмение. равноденствие. JSP . Джаспер
    ЗатмениеLazyStart : правда
    EclipseSourceReferences : scm : cvs : pserver : dev . затмение. org : / cvsroot / rt :
    орг. затмение. Равноденствие / серверная сторона / связки / орг . затмение. равноденствие. JSP . Jaspe
    r ; tag = v20110502
    ПакетАктиватор : орг. затмение. равноденствие. внутренний . JSP . яшма. возбудитель

    Как мы видим, этот манифест содержит некоторую метаинформацию, необходимую для контейнера, например, указание класса активатора пакета, который реализует интерфейс BundleActivator.

    Пакет представляет нашу первую часть головоломки, и вот упрощенное представление пакета:

    И просто, чтобы иметь представление обо всех пакетах, используемых eclipse, давайте найдем все классы, реализующие интерфейс BundleActivator.

    1
    2
    из т в типах, где т . Воплощать в жизнь ( « Org . Osgi . Framework . BundleActivator » )
    выберите новый { т , т . NbBCInstructions }

    Кто управляет комплектом и вызывает методы BundleActivator?

    Чтобы обнаружить это, давайте искать методы, вызывающие прямо или косвенно BundleActivator.start

    1
    2
    3
    4
    из м в Методы
    пусть глубина0 знак равно м. DepthOfIsUsing ( « org . Eclipse . Osgi . Framework . Internal . Core . BundleContextImpl . StartActivator ( BundleActivator ) » )
    где глубина0 > = 0 Сортировать по depth0
    выберите новый { м , depth0 }

    Пакет активируется платформой OSGi при запуске. Каркасный класс запускается контейнером равноденствия. И чтобы лучше понять, что происходит при запуске контейнера, вот некоторые действия, выполняемые при запуске контейнера:

    Когда контейнер запускается, он инициализирует каркас OSGi, каркас получает все установленные пакеты и для каждого создает экземпляр класса BundleHost и сохраняет в хранилище найденный пакет.

    Класс BundleHost реализует интерфейс Bundle, который содержит такие методы, как запуск, остановка, удаление и обновление, эти методы необходимы для управления жизненным циклом пакета.

    Итак, наша вторая часть головоломки – это контейнер OSGi, запущенный Equinoxlauncher, который инициализирует фреймворк. Класс Framework отвечает за загрузку пакетов и их активацию.

    После знакомства с некоторыми основными понятиями о пакетах и контейнерах, давайте углубимся в пакеты и узнаем, как они работают внутри.

    Давайте возьмем в качестве примера пакет org.eclipse.equinox.http.servlet и найдем методы, вызванные методом start его класса Activator.

    Этот пакет создает сервис и регистрирует его в контейнере. Служба в OSGi определяется стандартным классом или интерфейсом Java. Как правило, интерфейс Java используется для определения интерфейса службы. Услуга является предпочтительным методом, который следует использовать пакетам для связи между собой.

    Вот несколько полезных сценариев использования сервисов:

    • Экспорт функциональности из пакета в другие пакеты.
    • Импорт функций из других пакетов.
    • Зарегистрируйте слушателей для событий из других пакетов.

    Другое замечание из предыдущего графа зависимостей заключается в том, что фабрика сервисов используется для создания экземпляра сервиса.

    Наша третья часть головоломки – это уровень сервисов OSGi, каждый пакет может использовать или объявлять некоторые сервисы, что обеспечивает подход к проектированию компонентов, вот новое представление пакета OSGi.

    Если пакет использует сервисы для связи с другими пакетами, как он взаимодействует с другими банками?

    Если мы разрабатываем пакет и пытаемся использовать класс из другого jar, мы можем быть удивлены, что он не будет работать должным образом, причина в том, что ClassLoader перехватывается контейнером OSGi, чтобы проверить, что давайте искать, какой метод вызывает java. lang.Thread.setContextClassLoader.

    1
    2
    из м в Методы, где м . Использует ( «Java. Яз. Thread. SetContextClassLoader (ClassLoader)«)
    выберите новый { м , м. NbBCInstructions }

    Многие методы вызывают его, включая EquinoxLauncher. поэтому каждый раз, когда пакет пытается создать экземпляр класса, контейнер OSGi проверит, разрешено ли коду выполнять это действие или нет, и здесь появляется роль импортированного и экспортированного пакета в файле манифеста.

    1
    2
    3
    4
    ЭкспортПакет : орг. затмение. равноденствие. http . сервлет ; версия = 1.1.0
    ИмпортУпаковка : javax. сервлет ; версия = 2.3 , javax . сервлет. http ; версия
    = 2,3 , орг . Osgi . рамки ; версия = 1.3.0 , org . Osgi . сервис . http ; Versi
    на = [ 1.2 , 1.3 )

    Пакет объявляет явно экспортированный и импортированный пакет, и чтобы проверить это, давайте найдем пакеты, используемые пакетом org.eclipse.equinox.http.servlet, и проверим, использует ли он только импортированный пакет.

    1
    2
    от п в пакетах , где п. IsUsedBy ( «Орг. Затмение. Равноденствие. HTTP. Servlet_1. 1.200.v20110502«)
    выберите новый { н , п . NbBCInstructions }

    Как мы видим, все используемые пакеты указаны в файле манифеста, в разделе пакетов импорта.
    Однако экспортированный пакет представляет собой пакет, который можно использовать из других пакетов. он представлен интерфейсом ExportedPackage, и мы можем искать классы контейнера, используя этот интерфейс.

    1
    2
    из т в типах, где т . Использует ( « Org . Osgi . Service . Packageadmin . ExportedPackage » )
    выберите новый { т , т . NbBCInstructions }

    Что интересно с этой новой возможностью, так это то, что пакет будет иметь четко определенную границу, и то, что он использует и что он предоставляет в качестве сервисов, очень хорошо определено.

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

    Эта возможность обрабатывать импортированные и экспортируемые пакеты управляется уровнем модулей OSGi, и это была наша четвертая часть головоломки.

    Давайте вернемся к контейнеру OSGi и выясним, какие услуги он предоставляет?

    Контейнерные услуги

    Как мы выяснили до запуска контейнера классом EquinoxLauncher, а класс инфраструктуры инициализирует и запускает пакеты, чтобы определить, какие службы предоставляются, давайте найдем все классы, используемые в методе инициализации платформы.

    1
    2
    из т в типах, где т . IsUsedBy ( « Org . Eclipse . Osgi . Framework . Internal . Core . Framework . Initialize ( FrameworkAdaptor ) » )
    выберите новый { т , т . NbBCInstructions }

    Некоторые классы уже были обнаружены ранее, например, BundleRepository, BundleHost, PackageAdminImpl и ServiceRegistry.

    А как насчет других классов:

    • StartLevelManager:
      Каждый OSGi Bundle связан с начальным уровнем, который позволяет серверу контролировать относительный порядок запуска и остановки пакетов. Только пакеты, начальный уровень которых меньше или равен активному начальному уровню серверной платформы, должен быть активным. Обычно, пакет с меньшим начальным уровнем имеет тенденцию запускаться раньше.
    • SecurityAdmin:
      Уровень безопасности управляет аспектами безопасности, ограничивая функциональность пакета предварительно определенными возможностями.
    • Менеджер по корпоративным мероприятиям:
      Служба Event Admin предоставляет модель публикации-подписки для обработки событий. Он реализован в соответствии со спецификацией службы администратора событий OSGi. Служба администратора событий отправляет события между издателями событий и подписчиками событий (обработчиками событий), вставляя канал событий. Издатели публикуют события в канале, а канал событий определяет, какие обработчики должны быть уведомлены. Таким образом, издатели и обработчики не имеют прямого знания друг о друге, что упрощает управление событиями.

    OSGi вся картина

    Давайте соберем все части головоломки, описанные ранее, и у нас будет следующая картинка OSGi:

    Эта архитектура имеет следующие интересные преимущества:

    • Просто.
    • Снижение сложности.
    • Простое развертывание.
    • Secure.

    Что делает его очень привлекательным и достойным обхода, и вы не будете тратить свое время, если будете изучать его подробно.

    Понимать концепции OSGi. Попытайтесь следовать подходу головоломки

    0.00 (0%) 0 votes

    moyadcode13
    • Facebook
    • Twitter
    • Google+
    • Linkedin
    • Pinterest
    moyadcode10
    moyadcode11
    moyadcode9