Введение в OSGi. Динамический ServiceTracker. Две стратегии использования сервисов.

В Челябинске опять прекрасная погода, а как там на Брайтон-Бич я не знаю. Суровый челябинский программист снова с вами и мы продолжаем знакомиться с OSGi. В предыдущей заметке мы остановились на вопросе: как сделать так, чтобы наш клиент мог получить информацию от двух сервисов с одинаковыми именами?

Еще раз вернемся к условию нашей задачи. Нам необходимо разработать меню цветов, котороее формировалось бы из палитр, предоставляемых разными бандлами. Мы выбрали такую схему решения: бандлы выставляют ColorizerService'ы, предоставляющие палитры меню. И есть некий бандл, который мы будем называть "центральным", который получает эти палитры от сервисов и объединяет их.

Приступим к реализации? Сначала создадим бандлы с сервисами. Пусть у нас будет два бандла: org.beq.equinox.p1 и org.beq.equinox.p2. Код и манифесты у них будут одинаковыми, отличаться будут лишь массивы цветов и конечно же значения полей Bundle-Name и Bundle-SymbolicName в манифестах. Поэтому сосредоточимся только на одном бандле org.beq.equinox.p1.

Введение в OSGi. Взаимодействие бандлов. Сервисы.

Hello, суровый челябинский программист here. И мы вновь продолжаем наше знакомство с OSGi. В предыдущей заметке мы говорили о взаимодействии бандлов посредством зависимостей. Однако, в OSGi существует и другой - более гибкий - способ обеспечить совместную работу бандлов и имя ему - сервисы.

Впрочем, предлагаю перейти сразу к делу. На рисунке представлена схема взаимодействия сервисов. Один Java-объект, который называется Service, представляет некий интерфейс доступа к себе - контракт сервиса. Другой Java-объект, который называется Client, может взаимодействовать с сервисом, через предоставляемый тем контракт.



Чтобы данное взаимодействие было возможно Client должен найти нужный ему Service и получить к нему доступ. Для этого используется Service Broker, в роли которого предстает OSGi-реестр сервисов. Бандл, предоставляющий сервис, регистрирует его в реестре, а бандл-клиент извлекает сервис оттуда и использует.

Введение в OSGi. Взаимодействие бандлов. Зависимости.

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

В прошлый раз мы с вами научились управлять жизненным циклом бандлов из консоли, а также познакомились со средствами Equinox, такими как org.eclipse.equinox.launcher.

Сегодня я предлагаю поговорить о взаимодействии бандлов. Сначала позволю себе немного пофилософствовать.

Понятно, что раз приложение многомодульное, то априори подразумевается какое-то взаимодействие этих самых модулей. И тут разумно поставить 2 вопроса: зачем и как? Ответ на вопрос "зачем" интуитивно понятен. Мы хотим, чтобы наше приложение было расширяемым, т.е. чтобы мы сами или сторонние разработчики могли изменять/наращивать его функционал. Здесь уместно ввести понятие "точка расширения". Точкой расширения (не в терминах Eclipse RCP, а в неком глобальном смысле) мы будем называть то место, в котором приложение позволяет нарастить свой функционал. Например, у нас есть главное меню приложения, в котором определены точки расширения для подменю и пунктов подменю. Это значит, что мы можем добавлять свои подменю, состоящие из пунктов меню. Но не можем, используя данные точки расширения, добавить новое окно. Переходя к бандлам видим, что концептуально здесь все просто: один бандл выставляет (публикует) некие точки расширения, а другой, подключаясь к ним, расширяет возможности первого бандла. Соответственно, третий бандл может еще больше расширить возможности первого и т.д.

Другим интересным вопросом является вопрос "как". Т.е. как определить точку расширения в одном бандле и как ее использовать в другом бандле?

OSGi предлагает несколько способов организации взаимодействия бандлов:

1. Обмен ресурсами. Под ресурсами здесь подразумеваются java-классы, java-пэкеджи, библиотеки и другие файлы. В Eclipse RCP, например, самым распространенным способом определения точек расширения является их регистрация в файлах plugin.xml, впрочем, об этом мы еще поговорим.


2. OSGi-сервисы. Собственно, OSGi и задумывалась, как среда выполнения и взаимодействия сервисов. Суть очень проста - один бандл выставляет сервисы, а другие их используют. Данный способ требует активации бандла, потому что выставление и подключение к сервисам, как правило, осуществляется в активаторе бандла. Активация бандла требует расходов на управление жизненным циклом бандлов, но в тоже время обеспечивает динамичность всей системы.


3. Декларативные сервисы. Некое объединение преимуществ первого и второго способов. Сервисы описываются декларативно в xml-файлах и становятся видимыми другим бандлам. При первом использовании сервиса стартует активатор бандла, сервис становится работоспособным и доступным для использования.


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

Введение в OSGi. Работаем с Equinox - реализацией OSGi R4 от Eclipse Foundation.

В предыдущей статье цикла мы говорили про спецификацию OSGi и ее реализации. В данной заметке попробуем написать простой бандл и поработаем с системой Equinox, которую разрабатывают парни из Eclipse Foundation.

Начнем с разработки нашего первого бандла. Бандл будет состоять из класса-активатора и манифеста. Код класса-активатора следующий:

package org.beq.equinox.hello;



import org.osgi.framework.BundleActivator;

import org.osgi.framework.BundleContext;



public class Activator implements BundleActivator

{

    @Override

    public void start(BundleContext context) throws Exception

    {

        System.out.println("Start plugin activator");

    }



    @Override

    public void stop(BundleContext context) throws Exception

    {

        System.out.println("Stop plugin activator");

    }

}

 

Активатор бандла состоит из двух методов: start(BundleContext context) и stop(BundleContext context). Когда бандл стартует (переходит из состояния RESOLVED в состояние ACTIVE) выполняется метод start. Соответственно, предполагается, что в данном методе будет происходить регистрация сервисов, которые выставляет данный бандл и подключение к сервисам, выставляемым другими бандлами.

Введение в OSGi. Знакомимся с "серебряной пулей" для разработки модульных приложений.

Как говорил небезызвестный герой небезызвестного произведения Н.В. Гоголя "Давненько не брал в руки шашек". Так и я - давненько не радовал своих читателей тематическими постами.

Последнюю неделю активно ковырял внутреннее устройство Eclipse, точнее то, что называется Eclipse as a platform. Не все знают, что Eclipse - это не IDE, это, прежде всего, платформа для разработки приложений различного профиля и уровня сложности. Вот об этом и хочется рассказать.

Что такое OSGi

Начнем рассмотрение снизу вверх. Начиная с версии 3.0 Eclipse перевели на новую основу. Имя ей - OSGi.

OSGi (Open Services Gateway Initiative) - спецификация динамической плагинной (модульной) шины для создания Java-приложений, разрабатываемая консорциумом OSGi Alliance. Круг применений данной спецификации довольно широк: изначально разрабатывалась для создания встроенных систем (в частности, для автомобилей BMW, также в разработке спецификации активно учавствует Siemens), но сейчас на базе OSGi строят многофункциональные десктоп приложения (например, Eclipse SDK) и Enterprise-системы (например, Naumen DMS). Последняя версия спецификации носит номер 4.1 и доступна вот здесь.