ECF: Обмен данными между бандлами с помощью DataShare API

Проголосуйте за ролик первой Российской команды, принявшей участие в конкурсе Imagine Cup Digital Media.

Суровый челябинский программист снова с вами и сегодня мы поговорим об ином аспекте взаимодействия бандлов нежели вызов сервисов - об обмене сообщениями. Под сообщением в данном случае подразумевается произвольный поток байт. Для обеспечения такого взаимодействия в состав ECF входит DataShare API.

Суть использования данного API заключается в том, что каждый контейнер может создавать сколь угодно много каналов. Каналы с одинаковыми ID являются связанными и по ним осуществляется асинхронный обмен сообщениями. Асинхронность в данном случае обозначает, что контейнер при создании канала регистрирует для этого канала листенер. При получении сообщений от других контейнеров данный листенер срабатывает. Все свободное от обработки сообщений время контейнер может заниматься своими делами.

ECF: Используем Remote Services API

При знакомстве с Eclipse Communication Framework'ом мы отметили, что некоторые его контейнеры поддерживают несколько разнородных API. В частности, R-OSGi и Generiс контейнеры, а так же появившийся в недавно вышедшем ECF 3.1 REST контейнер, поддерживают API вызова удаленных сервисов, т.н. Remote Services API.

Давайте поговорим о том, что можно делать с помощью данного API, а затем о том, как его использовать.

ECF Remote Services API это еще один (наряду с R-OSGi) способ обеспечения работы бандлов в распределенной среде. Точно так же одни бандлы могут выставлять сервисы, доступные другим бандлам на другой JVM (и, естественно, даже на другой машине). Отличие от R-OSGi в том, что данная система, во-первых, не стандартизирована (т.е. это не OSGi подсистема, а часть непосредственно ECF), а, во-вторых, - более гибка, т.к. можно явно указывать, где находятся бандлы, выставляющие сервисы, (т.е. отпадает необходимость в процедуре поиска сервисов) и использовать для обеспечения взаимодействия различные протоколы и реализации (ECF Generic, Active MQ, Weblogic, JavaGroups и даже XMPP).

IAdaptable - одно из основных понятий Eclipse Core

Как я и обещал, постепенно от введения в OSGi мы переходим в сторону рассмотрения непосредственно Eclipse Platform. Впрочем, об Eclipse Rich Client Platform (или даже Eclipse Rich Ajax Platform) речь пока не идет, пока будем знакомиться только с Eclipse Core. Дело в том, что для последующего рассмотрения возможностей того же Eclipse Communication Framework, невозможно оставаться только в рамках платформы OSGi.

Впрочем, это еще не значит, что я не буду больше писать про OSGi вообще (в том числе и про Equinox, как одну из реализаций OSGi).

Давайте, прежде чем перейти к рассмотрению IAdaptable, скажем пару слов об Eclipse Core (в дальнейшем я иногда буду называть его Ядром).

Ядро состоит из следующих основных бандлов:

org.eclipse.core.contenttype - поддерживает определение и управление типами файлового контента (в частности - MIME-типами).

org.eclipse.core.expression - содержит реализацию основанного на XML языка выражений, который используется для декларативного определения точек расширения.

org.eclipse.core.filesystem - общее API работы с файловой системой.

org.eclipse.core.jobs - обеспечивает инфраструктуру параллельного исполнения кода для Eclipse

org.eclipse.core.resource - содержит средства управления ресурсами: проектами, каталогами и файлами.

org.eclipse.core.runtime - обеспечивает основанный на Equinox рантайм для работы всех остальных бандлов и приложений. Является сердцем Eclipse Core.

Так же к Ядру можно отнести org.eclipse.equinox.registry - определяет так называемый реестр точек расширения. Точки расширения - специальные записи на XML-подобном языке, определяющие механизм взаимодействия бандлов. Используются еще с тех пор, когда Eclipse не был основан на OSGi. Как-нибудь поговорим о точках расширения подробнее.

Теперь можно перейти непосредственно к разговору об IAdaptable, определенному в бандле org.eclipse.core.runtime и являющемуся одним из краеугольных механизмов всей платформы.

ECF: Разбираемся с R-OSGi

В недавно вышедшей спецификации OSGi 4.2 декларировано такое новшество, как удаленные сервисы известные ранее, как Distributed OSGi или RFC 119. Давайте рассмотрим эту технологию, применительно к Eclipse Equinox.

RFC 119 реализуется в рамках Equinox с помощью контейнера ecf.r_osgi.peer, реализующего API удаленных сервисов. Для простоты будем рассматривать две Java-машины, на каждой из которых будет запускаться OSGi, причем ту машину, на которой выставляется сервис, назовем хостовой (host), а ту, на которой сервис будет использоваться - клиентской (client).

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

Алгоритм выставления сервиса:

1. Получить экземпляр IContainerManager - сервиса.

2. С помощью полученного ContainerManager создать новый контейнер типа ecf.r_osgi.peer

3. Зарегистрировать свой сервис, установив ему свойство osgi.remote.interfaces, равным * (данные константы определены в интерфейсе IDistributionConstants, как REMOTE_INTERFACES и REMOTE_INTERFACES_WILDCARD, соответственно). Именно это свойство говорит OSGi-платформе о том, что нужно разрешить удаленное использование сервиса.

Алгоритм подключения к сервису:

1. Получить экземпляр IContainerManager - сервиса.

2. С помощью полученного ContainerManager создать новый контейнер типа ecf.r_osgi.peer

3. Создать новый ServiceTracker, задав фильтр, под который попадает удаленный сервис. Согласно спецификации RFC 119 фильтр должен включать условие (" + REMOTE + "=*), где REMOTE - соответствующая константа, определенная в IDistributionConstants.

4. Открыть созданный ServiceTracker и работать с ним так же, как и при использовании обычного сервиса.

Давайте теперь перейдем к рассмотрению примера.

Знакомимся с Eclipse Communication Framework

Как я уже неоднократно говорил, неправильно считать, что Eclipse - это только IDE. Eclipse Foundation разрабатывают прежде всего качественную платформу для построения самых разных приложений. Основным компонентом платформы является Equinox - реализация спецификации OSGi R4. На базе Equinox строятся другие компоненты, такие, как, например, Eclipse Communication Framework, о котором мы сегодня и поговорим.

Не секрет, что большинство создаваемых сегодня приложений работают в сетевой среде. Особенно это характерно для т.н. Enterprise-приложений, для разработки которых в основном Java и используется. Естественно, что такие приложения нуждаются в средствах взаимодействия с локальной сетью и/или Интернетом. Писать такое взаимодействие самому довольно утомительно, поэтому для создания программ, основанных на OSGi (в частности - Eclipse RCP - приложений), был разработан ECF.

ECF - это реализация концепции распределенных контейнеров, осуществляющих передачу данных по различным прикладным протоколам. Контейнеры могут обеспечивать связь с сохранением состояния (т.е. с сессией) и без сохранения. Поддерживается взаимодействие типа "точка-точка" (например, клиент - сервер) и типа "публикатор - подписчики". Само взаимодействие может быть как синхронным, так и асинхронным.

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

Единый API позволяет не беспокоиться о том, что у нас находиться "на другой стороне" - в случае изменения протокола мы просто меняем создаваемый контейнер, остальной код (в идеале, конечно) менять не требуется. Вторым плюсом такой унификации является легкий переход от одной технологии (например, Apache ActiveMQ, представленный в той же IBM WebSphere) к другой (например, Weblogic от Oracle).

Что касается использования ECF в чисто OSGi-среде, то именно он содержит реализацию Distributed OSGi (RFC 119) для Equinox. Но давайте познакомимся с фреймворком поближе.

Модульная Java, что это?

Позволю себе привести свой перевод статьи Modular Java: What Is It?. Это мой первый более-менее крупный перевод, поэтому иногда наблюдаются отступления от канонического текста, но ногами все равно прошу не пинать.

В последние несколько лет модульность в Java является активно обсуждаемой темой. От (уже утратившего силу) JSR 277 через принятие JSR 291 и продолжаясь в JSR 294 модульность видится как необходимый этап в эволюции Java. Даже новые, основанные на Java языки (такие, как Scala), учитывают модульность. Данная статья, первая в серии о модульной Java, объясняет, что значит модульность и почему об этом нужно беспокоиться.