Eclipse Indigo: Пять причин обратить внимание на ECF

Поздравляю всех читателей с официальным выходом Eclipse 3.7 Indigo. Здесь камрад James Sugrue написал статью на JavaLobby - Eclipse Indigo Highlights: Five Reasons to Check Out ECF. Позволю себе перевести ее на русский язык.

Eclipse Communication Framework [1] - традиционный участник Eclipse release trains (перевод "поездов релизов Eclipse" мне как-то не очень нравится, однако термин "поезд" применительно к релизу ПО меня забавляет уже третий год) - непрерывно добавляет новое в свой впечатляющий список возможностей. Данный год не стал исключением - в релиз Eclipse Indigo включен ECF 3.5. В данной статье я сосредоточусь на пяти ключевых возможностях новой версии.

ECF: Выпущен ECF 3.5

Через четыре месяца разработки выпущена новая версия Eclipse Communication Framework - ECF 3.5.

Из основных нововведений:

1. Поддержка спецификации OSGi Remote Services Admin - части 122 т.н. OSGi Enterprise Specification. Данная спецификация определяет сервис управляющих агентов для администрирования удаленных сервисов. Теперь архитектура ECF позволяет гибко и на лету заменять OSGi-совместимые модули, обеспечивающие взаимодействие и обнаружение сервисов. Под модулями взаимодействия подразумеваются различные протоколы, поддерживаемые ECF: R-OSGi, ECF Server, JMS, REST, SOAP, XMPP и т.д. Под модулями обнаружения сервисов подразумеваются: SLP, ZeroConf, ZooDiscovery и т.д.

Так же добавлена поддержка Endpoint Description Extender Format (EDEF) - части 122.8 Enterprise Specification. Данная реализация пришла на замену используемому ранее модулю основанного на файлах обнаружения сервисов.

2. XML-RPC провайдер. Данный провайдер реализует ECF Remote Services API, позволяя обращаться к XML-RPC серверам как удаленным OSGi-сервисам. Поддерживается вызов сервисов через прокси, а также асинхронное взаимодействие. Скромно замечу, что данный провайдер реализован вашим покорным слугой.

3. ECF4Felix - позволяет использовать все возможности ECF на OSGi R4-совместимой платформе Apache Felix.

4. Maven-репозиторий, доступный по-адресу.

С полным списком нововведений можно ознакомиться в разделе New and Noteworthy. Для установки через механизм p2 существует update site: http://download.eclipse.org/rt/ecf/3.5/site.p2.

Напомню, что исходники фреймворка теперь располагаются в Git-репозитории.

Помимо официальной ветки существует и ECF Extras, расположенные на GitHub. В состав ECF Extras входят провайдеры для NNTP, JMS, Yahoo, Call API (VoIP), Google Wave, JGroups, Net4J, JXTA, Skype, Twitter и т.д., в частности - OSCAR/ICQ-провайдер и большой набор примеров использования ECF от Сурового.

Стоит отметить, что в отличие от множества других OpenSource-проектов, в том числе и разрабатываемых под эгидой Eclipse Foundation, ECF является проектом, развиваемым исключительно сообществом. Нас не спонсируют крупные компании, такие как IBM, Oracle, Microsoft и т.д.

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

ECF: Выпущен ECF 3.4

После четырех месяцев разработки выпущена версия 3.4 Eclipse Communication Framework.

ECF: Eclipse Communication Framework мигрировал на Git

Сегодня свершилось радостное событие: Eclipse Communication Framework полностью переведен на использование распределенной системы управления версиями исходного кода - Git. Напомню, что Git начал разрабатываться Линусом Торвальдсом для его проекта Linux, однако сейчас используется во многих Open Source (и, смею предположить, что не только Open Source) разработках.

Веб-интерфейс репозитория расположен по адресу: Eclipse Git. Сами репозитории, которые можно клонировать:

- git://git.eclipse.org/gitroot/ecf/org.eclipse.ecf.git
- ssh://git.eclipse.org/gitroot/ecf/org.eclipse.ecf.git
- http://git.eclipse.org/gitroot/ecf/org.eclipse.ecf.git

"Переведен на Git" подразумевает, что созданы указанные выше Git-репозитории, а официальный CVS-репозиторий проекта переведен в режим "Только для чтения (Read Only, R/O)". Синхронизация между Git и CVS настраиваться не будет, все новые коммиты будут идти только в Git!

На днях наша команда обновит официальный сайт ECF и пропишет везде вместо путей к CVS - пути к Git.

Преимущества использования Git вместо CVS те же, что и для разработки ядра Linux. Во-первых, теперь коммиттеры могут осуществлять коммиты более часто - в свои локальные репозитории и только после завершения работы над какой-либо новой функциональностью отправлять код в публичный репозиторий. Во-вторых, контрибъютеры могут размещать свой код, например, на GitHub, а после прохождения кодом IP-процесса, коммиттер легко смержит его с основным репозиторием ECF. При этом будет сохранена вся история правок. Уже есть пример такой работы, правда коммиттер мержил свой код с GitHub и официальный репозиторий. В-третьих, у ECF есть особенность - часть кода хранится не в официальном репозитории, а на GitHub, что раньше приводило к проблемам при сборке - приходилось часть кода подгружать из CVS, часть - из Git. Теперь весь код хранится в Git-репозиториях, что конечно же решит данную проблему. В-четвертых, теперь проще делать патчи для Bugzilla и, соответственно, их накатывать. В-пятых, стала доступна операция Code Review с помощью замечательного инструмента - Gerrit, который уже довольно активно используется для проекта EGit.

З.Ы. В отличие от большинства молодых Eclipse-related проектов, перешедших на Git или изначально разрабатывавшихся с использованием этой системы контроля версий, ECF - достаточно развитый проект с многолетней историей правок и разветвленной структурой проектов (порядка сотни бандлов, 30Мб исходников).

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

47-й выпуск The Art of Programming: Реверансы в сторону Eclipse

Когда я был в городе-герое Москве, Виктор Гамов, ака gAmUssA пригласил меня записать подкаст, посвященный выходу новой версии замечательной IDE - Eclipse.

Основные темы подкаста:
- Временные понаехи в Нерезиновске
- Новое в Eclipse Helios: Marketplace, EGit, обновленный JDT.
- Интеграция Eclipse с операционными системами (с удивлением узнал, что хваленая Visual Studio из коробки этого не умеет).
- Новое в Eclipse Communication Framework.

Сам подкаст The Art of Programming слушаю с первого выпуска. Мне показалось, что сначала был выбран не самый удачный формат для программистского подкаста: все же диктовать и объяснять код - не самая лучшая идея. Но потом парни нашли свой формат. Получился очень интересный подкаст о Java, экосистеме Java, сопутствующих технологиях и в целом об IT. Так же нравятся интервью с известными программистами России. Считаю, что парни делают правильное дело.

Понравилось сообщение - подпишитесь на блог или читайте меня в twitter

Вышел Eclipse 3.6 Helios

Сегодня Eclipse Foundation объявили о выходе Eclipse 3.6 Helios.



Помимо IDE для Java и средства разработки плагинов Eclipse PDE в состав релиза вошли 39 проектов среди которых WTP (JavaScript + HTML + CSS), среды разработки для C/C++ и PHP, средство моделирования бизнес процессов - Eclipse BPMN, утилиты для построения сервисно-ориентированных систем - Eclipse SOA Tools, конечно же Eclipse Communication Framework и Eclipse Rich Ajax Platform. Полный список проектов доступен здесь.

Основной новостью года стала поддержка распределенной системы контроля версий Git "из коробки" с помощью плагина EGit, что послужило толчком к переводу на Git некоторых Eclipse-проектов.

Еще одним интересным нововведением стал единый репозиторий популярных плагинов - Eclipse Marketplace. Сам Eclipse IDE содержит удобный клиент для Marketplace, позволяющий установить нужный вам плагин за 2-3 клика.

Официальная страница релиза находится здесь: Eclipse Helios, скачать же можно по адресу.

Понравилось сообщение - подпишитесь на блог или читайте меня в twitter

ECF: Пишем SOAP-клиента на примере использования веб-сервиса "Аэрофлота"

В версии 3.2 Eclipse Communication Framework появилась возможность разрабатывать клиенты к SOAP-сервисам (до этого была возможность использовать только REST-сервисы), используя Remote Services API. Инкапсулирована данная возможность в бандле org.eclipse.ecf.remoteservice.soap.

Есть одно радикальное отличие в реализации ECF-клиента к SOAP веб-сервису от реализации клиентов к другим типам удаленных сервисов. Дело в том, что бандл org.eclipse.ecf.remoteservice.soap содержит лишь набор неких базовых классов, конкретный же контейнер, представляющий собой клиента к конкретному веб-сервису, придется писать самостоятельно. Точно так же самостоятельно придется реализовывать непосредственно логику обращения к веб-сервису, используя для этого такие библиотеки, как Axis, Axis 2 или XFire.

Давайте рассмотрим пример - реализуем бандл, name.samolisov.ecf.webservices.demo, который будет содержать удаленный сервис, инкапсулирующий обращение к некоторым методам веб-сервиса компании "Аэрофлот". WSDL-описание веб-сервиса компании "Аэрофлот" расположено здесь. Данный сервис предоставляет информацию об аэропортах, рейсах, предоставляет табло прилетов и табло вылетов. Мы реализуем обращение к следующим методам: AirportList - предоставляет список аэропортов, в/из которые/ых летают самолеты "Аэрофлота", AirportInfo - возвращает информацию об аэропорте по его коду и метод Arrival - принимает код эропорта, дату, поле по которому будет осуществляться сортировка и направление сортировки и возвращает табло прилетов для данного аэропорта на данную дату, отсортированное по указанным критериям. Мы реализуем обращение к данному методу, с сортировкой по аэропорту по возрастанию.

ECF: Пишем ICQ-бота с использованием Habra API

В статье Немного подробнее о проекте CaffeineIM и ICQLib я уже писал, что занимаюсь разработкой провайдера для Eclipse Communication Framework, реализующего работу с OSCAR/ICQ протоколом. Сейчас реализованы все основные API, в частности, ChatManager - часть Presence API, которая позволяет обмениваться сообщениями.

Реализация провайдера содержится в бандле org.eclipse.ecf.provider.oscar, код которого расположен в CVS-репозитории pserver://ecf1.osuosl.org/ecf (каталог plugins/org.eclipse.ecf.provider.oscar).

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

Немного подробнее о проекте CaffeineIM и ICQLib

Здравствуйте, уважаемые читатели. Сегодня немного необычный пост: Суровый программист будет рассказывать не о том, что сделано другими, а о том, чем иногда занимается он сам. Конкретнее - речь пойдет о написанной исключительно Just for fun Java-библиотеке, предназначенной для создания ICQ-клиентов.

Библиотека называется ICQLib и ее исходники можно невозбранно взять на Google Code. В 2007-м году был сделан форк мертвой на тот момент JOscarLib, возможности которого были существенно расширены и добавлена работа с русским языком (в кодировках UTF-8/cp1251). Кстати, злая ирония судьбы: примерно год назад JOscarLib начал развиваться, а работа над нашей библиотекой заглохла (энтузиазм иссяк), но сейчас я решил возродить проект и продолжить работу над ним.

На текущий момент ICQLib обладает следующими возможностями:

- Дополнительные статусы QIP (депрессия, на работе, дома и т.д.)

- X-статусы. Полная реализация, аналогичная возможностям QIP.

- Корректная поддержка русского языка. Подразумевается: отправка-прием сообщений, содержащих кирилицу, информация о себе на русском, информация о контактах, запрос авторизации, x-статусы.

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

- Работа с мета-информацией. Реализованы все запросы метаинформации о контакте (About user).

ECF: Взаимодействуем с Twitter с помощью REST API и XStream

Продолжаем беседу об Eclipse Communication Framework. Сегодня мы рассмотрим, как использовать появившийся в версии 3.1 REST API на примере взаимодействия с наиболее популярным сервисом микроблогов - с Twitter.

Поддержка REST была добавлена в ECF этой осенью горячим немецким парнем по имени Holger Staudacher в рамках Google Summer of Code (который я, кстати, считаю гораздо более полезным, нежели Imagine Cup от небезызвестной корпорации). Реализация данной функциональности представленна контейнером ecf.rest.client и базируется на Remote services API.

ECF: Пишем Jabber-бота с использованием Habra API

Сегодня Суровый челябинский программист хочет поделиться исключительно Just for fun'ом, а именно - рассказом о том, как легко и непринужденно написать Jabber-бота с использованием Bot Framework. Наш бот будет принимать команды вида ~karma %username% и воозвращать соответствующую информацию о хабражителе с указанным именем. Для получения данной информации используется Habra API.

Сначала поговорим о содержательной части задачи. Habra API предоставляет возможность получать с помощью GET-запросов по определенному урлу (заданному в формате http://habrahabr.ru/api/profile/%username%) XML-документ с информацией о пользователе или об ошибке, если, например, такой пользователь не зарегистрирован в системе. Понятно, что хотелось бы большего, в частности - получать информацию о месторасположении пользователя или его интересах, а также иметь возможность вытягивать посты целиком или даже публиковать информацию через API. Надеюсь, что хотя бы часть из этого хаброавторы сделают, пока же мы имеем то, что имеем.

Теперь, что касается Bot framework. Данный фреймворк представлен бандлом org.eclipse.ecf.presence.bot и позволяет писать ботов, работающих с поддерживаемыми ECF Messenger-ами (например, Jabber, Skype, Yahoo) и т.н. ChatRoom-ботов, т.е. роботов для IRC-каналов и/или Jabber-конференций. Включает в себя четыре точки расширения, позволяющие регистрировать роботов и обработчики команд. Рассмотрим их подробнее:

ECF: Распределенная обработка событий

Продолжаем разговор. Нынешняя заметка будет посвящена проблеме организации распределенной обработки событий с помощью механизмов, которые предоставляет Eclipse Communication Framework.

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

Вся обработка событий в OSGi базируется на интерфейсе EventAdmin. ECF предлагает свою реализацию этого интерфейса - класс DistributedEventAdmin, который расположен в бандле org.eclipse.ecf.remoteservice.eventadmin. К сожалению, данный бандл не входит в поставку ECF 3.0/3.1, поэтому его придется взять на CVS-сервере: pserver://dev.eclipse.org//cvsroot/rt в каталоге org.eclipse.ecf/server-side/bundles/org.eclipse.ecf.remoteservice.eventadmin.

Работает этот механизм так: DistributedEventAdmin представляет собой SharedObject. Как мы уже говорили, такие объекты копируются между ECF-контейнерами и могут обмениваться сообщениями. Соответственно, все вызовы sendEvent и postEvent - это отправка сообщений между репликами объекта DistributedEventAdmin (синхронная и асинхронная, соответственно).

ECF: Средства для взаимодействия команды разработчиков с помощью Eclipse

Мы уже успели поговорить и о том, что такое Eclipse Communication Framework, и о том, как программировать с его помощью. Сегодня рассмотрим графические средства, которые ECF предоставляет для Eclipse (и, соответственно, RCP-приложений).

Под графическими средствами подразумевается перспектива Communications и виды, которые представлены в группах Communications и File Transfer. Прежде всего эти компоненты GUI обеспечивают возможность взаимодействия разработчиков, использующих Eclipse между собой в команде. Однако, обо всем по-порядку.

ECF: Распределяем объекты между OSGi-фреймворками

Сегодня мы рассмотрим еще одну замечательную возможность, которую предоставляет нам Eclipse Communication Framework - обмен копиями объектов между бандлами, запущенными на разных экземплярах OSGi-фреймворка (т.е. на разных JVM), реализованную в виде SharedObject API. Данный механизм основан на понятии "репликация", суть которого применительно к ECF следующая: в контейнер добавляется экземпляр класса, реализующего интерфейс ISharedObject, который становится доступен всем другим контейнерам, подключенным к тому же серверу, что и донор. Фактически, в каждом клиентском контейнере создаются копии исходного объекта, которые называются репликами.

Прежде всего разберемся непосредственно с распределяемым объектом. В ECF реализован базовый класс BaseSharedObject, который содержит реализацию многих полезных возможностей, таких как идентификация, управление конфигурацией, логгирование, отправка и прием сообщений. Рекомендуется все свои распределяемые объекты наследовать от данного класса.

Наиболее интересными для нас методами являются BaseSharedObject#initialize(), описывающий стратегию репликации главного объекта (т.е. того объекта, который собственно копируется, для него метод BaseSharedObject#isPrimary() вернет true) и стратегию десериализации реплик из словаря свойств, и BaseSharedObject#getReplicaDescription(ID receiver), задающий порядок сериализации реплицируемого объекта в словарь свойств. Словарь свойств - это объект класса, реализующего Map<String, Serializable>. ECF умеет передавать объекты между контейнерами только в таком виде. Чем-то данный механизм напоминает словарь свойств события, которым оперирует EventAdmin. Данный механизм предоставляет программисту возможность наиболее гибко управлять процессом репликации своего объекта (например, определять какие поля не нужно копировать вовсе).

Стоит обратить внимание, что каждое реплицируемое поле класса должно иметь тип, реализующий интерфейс Serializable. Дело в том, что для сериализации полей класса ECF использует стандартные средства Java-платформы.

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).

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. Но давайте познакомимся с фреймворком поближе.