Приложение формирует пользовательское окружение на основе сервисов, которые зарегистрированы в контейнере. Например: в некую абстракция рабочей области встраивается возможность доступа к wiki-движку, и системе управления взаимодействием. Каждая из подсистем представляется в виде сервиса.
1. Параметры передаются также, как и в обычной Java программе.
2. Резольвинг происходит согласно правилам import и export. Т.е. ClassLoader модуля связан с фреймворком и знает какие классы доступны через export у других модулей, и знает какие сделать доступными текущиму модулю из import.
3. После изменения кода интерфейсов и классов необходимо выполнить операцию refresh на всех модулях, которые использовали их.
4. Возможно указывать правила фильтров, какие версии сервисов использовать. Можно получать целую коллекцию сервисов с заданными интерфейсами и выбирать необходимы сервис. При это коллекция будет при каждом обращении соответствовать актуальному набору сервисов, которые присутствуют в текущий момент.
5. Spring dm и Gemini Blueprint поддерживают модульное тестирования и имеют специальные классы для поднятия OSGi окружения при тестировании в jUnit. Смотрите Testing OSGi based Applications.
На данный момент я разрабатываю свой хобби-проект на базе Eclipse Virgo. Это будет набор приложений для совместной работы над проектами (преимущественно разработкой ПО). Выбор был сделан в пользу данной связки, дабы не изобретать свой плагинный движок. А в каком проекте вы используете Spring и OSGi?
А вы попробуйте. Для начала на тестовом проекте, а потом, возможно, и в production. Чем более популярна будет технология, тем активней будет развиваться.
Возможно стоит рассмотреть вариант с изменением задержек между попытками захвата блокировок. Длина задержки должна коррелировать со среднем временем удержания блокировки. Ну и механизм случайного изменения этой длины в нужном диапазоне. Первое может помочь в уменьшении накладных расходов соревнования за захват ресурса, а второе в более справедливом распределении. Конечно, если у вас нет особых требований к порядку выполнения.
Целью написания статьи было — минимальное введение в предмет, без перегруженности деталями. Поэтому я позволил себе опустить описание явлений связанных с различными уровнями изоляции. Но видимо зря.
Термин «конкурентный» (competitive) выбрал чтобы подчеркнуть именно соревновательный аспект. У Фаулера данный термин не присутствует. А там где речь идёт о параллелизме используется термин «параллельный». Хотя соглашусь, что повсеместно использования термина «параллельный» было бы менее запутанным.
2. Резольвинг происходит согласно правилам import и export. Т.е. ClassLoader модуля связан с фреймворком и знает какие классы доступны через export у других модулей, и знает какие сделать доступными текущиму модулю из import.
3. После изменения кода интерфейсов и классов необходимо выполнить операцию refresh на всех модулях, которые использовали их.
4. Возможно указывать правила фильтров, какие версии сервисов использовать. Можно получать целую коллекцию сервисов с заданными интерфейсами и выбирать необходимы сервис. При это коллекция будет при каждом обращении соответствовать актуальному набору сервисов, которые присутствуют в текущий момент.
5. Spring dm и Gemini Blueprint поддерживают модульное тестирования и имеют специальные классы для поднятия OSGi окружения при тестировании в jUnit. Смотрите Testing OSGi based Applications.