Пять абзацев про Service Component Architecture

Термин компонент в софтверной индустрии каждые три года
принимает новое содержание, но по этому поводу никто не напрягается. В
понятие компонент можно включать всё от возможности повторного
использования до обеспечения совместимости. Теперь этот термин
засветился и в наших любимых сервисных архитектурах. Как всегда, за
новой аббревиатурой стоят заинтересованные лица. В данном случае лобби
весьма солидно — BEA, IBM, IONA, Oracle, SAP, Siebel Systems и Sybase —
не то что SOE от Intel или JBI от Sun. Посмотрим есть ли что-нибудь новое в Service Component Architecture по сравнению с просто SOA?
В SCA заявлено, что отныне строить приложения надо используюя
принципы представления всей функциональности в виде сервисов. Однако,
при этом нарочито подчеркивается то, что сервисы предоставляются
компонентами. Именно компоненты являются кубиками для сборки. Таким
образом, создание нового приложения в соответствии со SCA заключается в
реализации компонентов, сборке и запуске на среде выполнения.

Для реализации, очевидно, можно использовать любой удобный язык.
Главное чтобы компонент выполнял свой кусок бизнес-логики приложения и
был готов взаимодействовать с другими SCA-совместимыми компонентами.
Это взаимодействие специфицировано в области безопасности, проведения
транзакций, набора настроек и, что самое главное, в области сборки из
компонентов более крупных композитов. Наконец, так как сервисы висят не
в вакууме, компоненты SCA запускаются на каких-то платформах в каких-то
средах выполнения (которые видимо скоро будут анонсироваться
вышеперечисленными вендорами).
Можно проследить много аналогий между J2EE и SCA, тем не менее во
втором случае нет привязки к языку Java, а также будут отброшены EJB и
другие сложные блоки. А для лоббирующих вендоров SCA — отличный путь
для перевода своих java-продуктов на "сервисные" рельсы. Гораздо
интереснее посмотреть как SCA соотносится с хитовыми аббревиатурами
сервисной шины (ESB) и менее известной JBI ("стандартизированной" через
Java Community Process спецификации сервисной шины). С технической
точки зрения SCA описывает несколько другую плоскость, нежели ESB и JBI
. Если ESB концентрируется на интеграции отдельных сервисов и
существующих приложений, а также на использовании инфраструктурных
сервисов трансформации и маршрутизации данных, то SCA обращает взор на
внутреннюю архитектуру приложений. Попросту говоря, Сервисная Шина —
это концепция промежуточного ПО, а Сервисные Компоненты — это концепция
разработки приложений.
Ложка дёгтя: несмотря на то что SCA специфицирует запуск
компонентов в среде выполнения, эти спецификации недостаточно четки, а
значит разрабатываемые компоненты придется разворачивать на одной из
платформ одного из вендоров. Зная что спецификация SCA 1.0
слабо описывает совместимость, получается привязка к платформе одного
из вендоров. А значит изначальная предпосылка SOA в виде распределенных
и независимых сервисов оказывается под угрозой. Можно считать, что
платформы разных вендоров будут взаимодействовать по сервисным
принципам, а SCA внесла лишь дополнительную чёткость и ясность как
будут эти платформы устроены изнутри. Подобно тому как Microsoft
предлагает использовать Windows Communication Foundation (WCF)
для строительства сервисов на базе .NET Framework, SCA видимо будет
фреймворком для создания сервисно-ориентированных приложений на java и
возможно других языках. 25308976.2a404a00890bb8637dd371c5f7549894.1182926029.b8ccf843a177a756e86521f2d0d85631
25308976.2a404a00890bb8637dd371c5f7549894.1183274315.f5ee831242808d1451396df4de023e55