Как я уже неоднократно говорил, неправильно считать, что 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. Но давайте познакомимся с фреймворком поближе.
Начнем с контейнеров. Контейнеры создаются с помощью специальных фабрик. Рассмотрим основные типы контейнеров, чтобы представить себе возможности фреймворка. Каждый контейнер будем характеризовать:
- протоколом,
- фабрикой,
- плагином, содержащим его реализацию,
- поддерживаемым API.
Типы контейнеров, предоставляемые dev.eclipse.org
1.
r-OSGi
ecf.r_osgi.peer
org.eclipse.ecf.provider.r-osgi
Remote Services
2.
HTTP/HTTPS file и другие протоколы, поддерживаемые URLConnection
ecf.base
org.eclipse.ecf, org.eclipse.ecf.provider.filetransfer
File Transfer
3.
HTTP/HTTPS через Apache HTTPClient
ecf.base
org.eclipse.ecf, org.eclipse.ecf.provider.filetransfer.httpclient
File Transfer
4.
None
ecf.container.trivial
org.eclipse.ecf.examples.provider.trivial
Core API
5.
ECF Generic Client
ecf.generic.client
org.eclipse.ecf.provider
Shared Object, Datashare, Remote Services
6.
ECF Generic Server
ecf.generic.server
org.eclipse.ecf.provider
Shared Object, Datashare, Remote Services
7.
ECF Bittorrent Filetransfer
ecf.filetransfer.bittorrent
org.eclipse.ecf.provider.bittorrent
File Transfer
8.
Zeroconf/Bonjour/Rendevous
ecf.discovery.jmdns
org.eclipse.ecf.provider.jmdns
Discovery
9.
Java Service Locator Protocol (RFC 2608)
ecf.discovery.jslp
org.eclipse.ecf.provider.jslp
Discovery
10.
XMPP/XMPP SSL
ecf.xmpp.smack
org.eclipse.ecf.provider.xmpp
Shared Object, Datashare, Presence, File Transfer
11.
MSN
ecf.msn.msnp
org.eclipse.ecf.provider.msn
Presence
Так же в ежедневных сборках уже появился RESTfull контейнер, но официально он будет доступен только с выходом версии 3.1.
Типы контейнеров, предоставляемые OSU Open Source Lab
12.
Yahoo
ecf.yahoo.jymsg
org.eclipse.ecf.provider.yahoo
Presence
13.
JavaGroups Client
ecf.jgroups.client
org.eclipse.ecf.provider.jgroups
Shared Object, Datashare, Remote Services
14.
JavaGroups Manager
ecf.jgroups.manager
org.eclipse.ecf.provider.jgroups
Shared Object, Datashare, Remote Services
15.
ActiveMQ Client
ecf.jms.activemq.tcp.client
org.eclipse.ecf.provider.jms.activemq
Shared Object, Datashare, Remote Services
16.
ActiveMQ Manager
ecf.jms.activemq.tcp.manager
org.eclipse.ecf.provider.jms.activemq
Shared Object, Datashare, Remote Services
17.
Weblogic Client
ecf.jms.weblogic.client
org.eclipse.ecf.provider.jms.weblogic
Shared Object, Datashare, Remote Services
18.
Weblogic Manager
ecf.jms.weblogic.server
org.eclipse.ecf.provider.jms.weblogic
Shared Object, Datashare, Remote Services
19.
Skype
ecf.call.skype
org.eclipse.ecf.provider.skype
Shared Object, Datashare, Presence
Думаю, что стоит привести такое довольно подробное описание контейнеров по друм причинам. Во-первых, из этого списка видно, что возможностей у фреймворка много и есть из чего выбирать, а во-вторых - на него будем ссылаться в следующих статьях цикла.
Как установить ECF? Все инструкции по установке собраны на этой странице. Последней официальной версией является ECF 3.0, предназначенная для Eclipse Galileo. Ее можно установить либо с помощью update site, либо из архива. Сейчас очень активно ведется работа над ECF 3.1, дневные сборки которого доступны через update site и архивы.
Основная документация по проекту собрана в Eclipse WiKi. Там же находится документация по всем предоставляемым API. Отдельно можно ознакомиться с JavaDoc. Ну и конечно читать Блог сурового челябинского программиста , в котором планируется уделить теме ECF пристальное внимание.
Интересным примером использования ECF является TweetHub - полнофункциональный твиттер-клиент, представляющий собой Eclipse RCP приложение. Данный проект пока находится в бете, официальных сборок нет, поэтому приходится собирать самостоятельно.
Для этого необходимо зачекаутить исходники с CVS-сервера OSU Open Source Lab. Строка соединения с CVS следующая: :pserver:anonymous@ecf1.osuosl.org:/ecf. Из дерева проекта выбираем каталог plugins, из которого в свою очередь закачиваем три бандла:
org.eclipse.ecf.provider.twitter - провайдер, предоставляющий ECF-контейнер для твиттера
org.eclipse.ecf.provider.twitter.ui.hub - плагин, предоставляющий пользовательский интерфейс
org.eclipse.ecf.provider.twitter.ui.hub.product - RCP-продукт.
После компиляции проектов необходимо запустить org.eclipse.ecf.provider.twitter.ui.hub.product как Eclipse Application, при этом не забыть в настройках запуска выбрать Run a product - org.eclipse.ecf.provider.twitter.ui.hub.product. Когда приложение запустится, нужно залогиниться в твиттер под своим аккаунтом, после чего можно будет увидеть примерно следующее:
Выглядит довольно оригинально, не так ли?
Понравилось сообщение - подпишитесь на блог или читайте меня в twitter
6 комментариев:
В статье кроме названия ECF по сути ничего нет. Зачем нужен фреймфорк. Пример задачи которая красиво решается именно с этим фреймворком.Описание контейнеров занимает большую часть. Какой смысл предоставления единого API к разнородным контейнерам. Вывод : за деревьями леса не видно.
Вы правы в том, что касается необходимости описания того зачем нужен и какие задачи решает. Добавил это в статью.
Что касается описания контейнеров, то оно необходимо, т.к. это - базовое понятие фреймворка и представление его возможностей.
А каков пример задачи, которая красиво решается, например Hibernate? Простой пример можно решить и с помощью JDBC, достаточно сложный для понимания преимуществ концепции ORM в одном посте не опишешь. Так и здесь. В последующих постах серии постараюсь подробно описать задачи, решаемые с помощью ECF.
Просто "знакомство" как мне кажется предполагает описание общей ключевой концепции с целью сформировать ощущение об объекте и.т.д. Акцентировать внимание на главном при анонсе - приоритетно. А так мы видим еще один уровень абстрации кот. не очевидно зачем нужен. И предлагается прочитать следующие статьи чтобы понять нужно или нет.
Цель внедрения ORM как раз достаточно просто описать, потому что понятно что абстрагируется, посредством чего и что это дает.
Стандартизацию соглашения по вызовам сложно переоценить, хотелось бы более подробно о том что абстрагируется, как и что это дает в итоге, причем чем проще тем лучше. А детали установка, контейнеры имеет смысл подробно упоминать когда уже понятно что жизненно необходимо изучить этот объект, фреймворк.
Понимаете, я не ставлю перед собой задачу кому-то навязать данный фреймворк. Просто если человек пишет Eclipse RCP приложение, то ему нужно средство для взаимодействия с сетью. Я думаю очевидно, что лучше выбрать средство основанное на той же технологии. Цель моей статьи показать, что такое средство есть, оно мощное и его можно использовать для разработки приложений (см. пример с твиттером).
В одной из предыдущих статей писал о том, что такое R-OSGi. ECF содержит средства реализации R-OSGi для Equinox. Я об этом написал. Если человеку нужен R-OSGi, значит ему уже стоит смотреть в сторону ECF. Зачем для принятия решения знать что и как абстрагируется мне не понятно. Тем более, что это единственный такой фреймворк для платформы Eclipse RCP.
Показывать что и как абстрагируется - это уже как раз детали реализации. О них лучше говорить отдельно, о каждой свое.
Павел, да все Вы нормально рассказали, мне лично все понятно, кратко и без тягомотины. Суть ясна и в каком направлении двигаться тоже понятно, ну а если кто не понимает, так значит нужно открыть документацию и почитать мат часть.. Все же есть, просто не надо лениться.. Труд, сделал из обезьяны человека!!
По поводу документации есть реальная засада. Т.е. в Wiki описаны основные UseCase применения фреймворка, но не описаны маленькие тонкости. Без которых ничего не работает. Постараюсь исправить это.
Отправить комментарий
Любой Ваш комментарий важен для меня, однако, помните, что действует предмодерация. Давайте уважать друг друга!