Примерно год назад я опубликовал на Мтааламу несколько материалов о сервере Apache Felix (см., напр. здесь и здесь). Тогда интерес к этому продукту был обусловлен стремлением освоить новое и поделиться первыми положительными результатами. За прошедшее время Felix стал моим основным инструментом для разработки, запуска и отладки серверных приложений. Здесь хотелось бы вкратце напомнить основы технологии OSGi (которую как раз и реализует Apache Felix), а также осветить моменты, о которых еще не писал, а именно процедуру создания bundle и обработки их с помощью iPOJO.


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

Как ни странно, слово шина в понятии резиновая покрышка колеса автомобиля гораздо ближе к своему омониму — слову шина в значении магистраль для обмена энегрией или информацией, чем может показаться. До появления резиновых шин обода колес транспортных средств (телег и прочих дилижансов) обивали железом. Т.е. отковывали узкую и достаточно толстую железную полосу, которой оборачивали деревянные колеса. Таким образом, шиной стали называть и длинный кусок металла прямоугольного сечения. Позднее таковые стали применять в цехах промышленных предприятий для запитки электроэнергией длинных пролетов: три алюминиевых шины (соответствующие трем фазам силовой сети) прокладывали параллельно друг другу под потолком цеха, а от них отводили питание для отдельных станков. С появлением компьютеров слово шина перекочевало в сферу IT в значении «нечто, по которому можно передавать информацию для множества устройств (ISA, PCI, USB) или программ (D-Bus, OSGi)».

Шины в самом последнем из перечисленных значении, т.е. для обмена информацией между программами, развиваются сравнительно недавно. Зачем потребовалось их изобретать? Дело в том, что процессы, в которые ОС преврашает запущенные на компьютере приложения, работают в строго изолированном (по крайней мере в теории) пространстве активной памяти. Это сделано из соображений безопасности, ибо в противном случае «свалить» любую работающую программу или вытащить из нее секретные данные не представляло бы никакого труда. Тем не менее, многие процессы «испытывают потребность» в обмене информацией с другими приложениями, особенно в клиент-серверных системах. Архитекторы современных ОС предусмотрели подобные ситуации и внедрили для межпроцессорного взаимодействия такие понятия, как сокеты, конвейеры (pipes). В конце концов процессы могут обмениваться информацией и через обычный файл: одно пишет, другое читает.

Чем дальше развиваются IT, тем более велика потребность в межпроцессором взаимодействии, а в этом деле на сегодняшний день ситуация сложилась прямо-таки анархическая: программисты разных школ наизобретали для обмена информацией между программами мирриады способов связи (в частности, сетевых протоколов). Явно напрашивается наведение порядка в этом деле и тут на помощь приходит концепция шины. Правилом хорошего тона становится оснастить программу чем-то вроде действующего внутри ОС «почтового ящика», на который другие программы будут присылать ей сообщения или команды. Такова, например, концепция D-Bus, особенно бурно развивающаяся в рамках проекта freedesktop.org. С помощью D-Bus можно, например, сменить обои рабочего стола не из панели управления, а из любой программы, причем без всяких костылей, просто отправив по шине сообщение по определенному адресу.

Для приложений, написанных на Java концепция шины (OSGi) стала особенно революционной. Она преодолевает главный недостаток этой технологии — прожорливость по отношению к памяти, особенно в момент запуска. Представьте себе компьютер, на котором запущено несколько серверов, написанных на Java. Ну пусть, хотя бы, три: например Openfire, Tomcat и OpenDS. Каждый, кто запускал их стандартным способом, знает, что это потребует достаточно много времени (несколько секунд) и вызовем всплеск расхода памяти, т.к. запустятся три весьма прожорливых процесса, хотя со временем расход ее и придет к приемлимым показателям. Технология OSGi, создающая шину для Java-приложений, предполагает, что для всех Java-приложений, оформленных в виде модулей-бандлов (bundles) запускается единый общий процесс, а бандлы можно в этот процесс динамически подзагружать, останавливать, обновлять, перезапускать.

При таком подходе расход памяти уже не выглядит неадекватным (я имею в виду на практике). Но даже не это самое главное. В конце концов компьютеры сейчас мощные и поднять три вышеперечисленные сервера на современном железе не проблема. Главное в том, что запущенные в рамках OSGi модули имеют возможность обмениваться между собой не просто сигналами или простыми параметрами (числами, строками), но и целыми сложными объектами, такими как соединения с базами данных, доступ к серверной части веб-интерфейса и т.п., насколько хватит фантазии у программиста. К тому же OSGI предусматривает «горячую замену», т.е. для обновления одного модуля не нужно останавливать всю систему.

Продолжение следует.