Введение в OSGi. Декларативные сервисы - первое знакомство

Суровый челябинский программист вновь вышел на тропу войны. В WindowMaker запущена Opera, рядом mpd+sonata играет музло, но самое главное - запущен Eclipse, что как бы намекает. Намекает на то, что пришла пора рассказать читателям про замечательную вещь - декларативные сервисы в OSGi.

Понятно, что прежде чем один бандл будет использовать сервис, другой бандл должен его выставить. Чтобы сервис выставить, бандлу необходимо стартовать - т.е. перейти в состояние ACTIVE. Но зависимости между бандлами могут быть очень сложными (а самое худшее - циклическими), что приводит к очевидным проблемам. Для решения этих проблем некто Humberto Cervantes вместе с Richard Hall написали утилиту под названием Service Binder, которая и предназначалась для автоматического разрешения зависимостей между бандлами. Впоследствии данная утилита развилась в то, что называется Declarative Services (DS). Сами DS являются частью стандарта OSGi 4.0 и выше.

Введение в 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 и доступна вот здесь.

Hibernate: это должен помнить каждый

Долго мучался, разруливая зависимости между сущностями, хранящимися в БД (т.е. персистентными сущностями). Пришлось разобраться с каскадными операциями, в итоге родилась вот такая памятка:

- cascade="none" - значение по умолчанию. Hibernate будет игнорировать ассоциации, поэтому разруливать зависимости придется самостоятельно.

- cascade="save-update" говорит Hibernate'у, что разруливать зависимости необходимо при комите транзакции в которой делается save() или update() объекта. Суть разруливания заключается в том, что новые объекты, с которыми есть ассоциации у нашего, будут сохранены до него. Это позволяет обойти constraint-violations.

- cascade="delete" говорит Hibernate'у, что надо разруливать зависимости при удалении объекта.

- cascade="all" обозначает выполнение каскадных операций при save-update и delete.

- cascade="all-delete-orphan" обозначает то же самое, что и cascade="all", но к тому же Hibernate удаляет любые связанные сущности, удаленные из ассоциации (например, из коллекции).

- cascade="delete-orphan" обозначает, что Hibernate будет удалять любые сущности, которые были удалены из ассоциации.


Думаю такая краткая памятка будет полезна не только мне.

Понравилось сообщение - подпишись на блог