Источник: Байсер М. Компонентная архитектура сервисов и внедрение зависимостей [Электронный ресурс].
Максимилиан де Байсер
SCA1 явилась в то время, когда сообщество Java-разработчиков, испытав сложность компонентных платформ, таких как EJB, перешло к более простым облегчённым контейнерам внедрения зависимостей, вроде Spring. По этой причине SCA пытается следовать тем же принципам, чтобы избежать таких проблем, как сцепление контейнеров, недостаточная переносимость и интероперабельность. В каком-то смысле все зависимости, вплоть до стека протоколов, внедряются, а не вводятся вручную.
Ядро выполняет решающую роль в обеспечении возможности установки компонентов путём внедрения зависимостей. При запуске оно считывает файл сборки, находит нужную реализацию, либо интерфейс, и связывает их с надстройками, а затем настраивает их в соответствии с пользовательскими указаниями. С этого момента, вплоть до реализации надстройки, нужно обеспечивать среду, подходящую для разработки компонентов, сконфигурированных извне.
Группа открытой сервисно-ориентированной архитектуры (OSOA) также имеет стандарты реализации расширений для Java и C++ [1]. В то время как средствами Java полностью поддерживаются внедрение зависимостей, в стандарте C++ этого нет. Причина этому, как поясняется в главе 3, заключается в том, что для реализации универсального контейнера, который может обрабатывать объекты классов, неизвестных во время компиляции необходимо определение типа и структуры данных во время выполнения. В то время, как Java имеет встроенную поддержку интроспекции, в C++ такая поддержка отсутствует. По этой причине стандарт SCA C++ требует, чтобы компоненты использовали специфический SCA API для извлечения конфигурации и ссылок на реализацию бизнес логики по мере необходимости. Это приводит к неблагоприятной ситуации, когда компоненты C++ почти не зависят от нижележащей инфраструктуры, но недостаточно пригодны для повторного использования в других контекстах.
Зависимость от API также подразумевает зависимость на уровне модулей между модулем компонента и модулем API. Т.о., даже если API является только абстрактным фасадом, который может иметь несколько реализаций, модуль компонента не может развертываться без модуля API.
На самом деле есть контейнер SCA C++ Trentino [2], который поддерживает урезанную форму инверсии управления, так как он построен поверх PocoCapsule [3]. Однако, как описано в главе 3, PocoCapsule использует конфигурационный файл, в данном случае составной файл, в качестве входных данных для генератора внедряющего кода и, следовательно, этот код адаптера должен быть повторно скомпилирован каждый раз, когда происходит существенное изменение в конфигурационном файле. Тем не менее, эта схема позволяет вносить незначительные изменения в конфигурации, такие, как изменение значения параметра. Ещё один недостаток этой схемы состоит в невозможности выполнить интроспекцию интерфейсов во время выполнения для генерации представлений на другом языке, таком как WSDL и CORBA IDL.